►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 19 August 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
Of
having
all
right,
recording
just
started
so
I'll
give
a
quick
so
good
morning,
everyone
I'm
just
going
to
give
a
quick
recap
of
what
we
started
off
with
so
last
week.
We
ended
the
discussion
talking
about
allowed
namespaces
or
how
we
gonna
restrict
access
to
certain
namespaces
and
and
instead
of
calling
it
as
restriction
of
access,
we
started
defining
it
as
bucket
sharing
or
sharing
across
name
spaces.
A
Alpha
yeah
so
as
a
part
of
alpha
we're
proposing
just
allowed
name
spaces:
okay,
the
current
one,
however.
However,
if
there
is
pushback
on
it,
you
know
we
have
our
alternate
approach
that
we're
considering
for
post
alpha.
A
So
the
alternate
approach
is
going
to
be
shown,
assuming
we
all
come
to
a
decision
to
to.
You
know
to
we
all
agree
on
on
new
approach.
So
so
during
this
week
I've
been
thinking
about
the
approach
we
discussed
last
week.
So
I'll
give
a
quick
recap
on
what
that.
A
What
that
last
week's
decision
was
so
we
we
discussed
about
allowed,
namespaces
or
or
having
a
list
of
namespaces
set
in
our
bucket
class,
which
will
be
copied
over
to
the
bucket
when
bucket
is
created
and
and
this
this
the
list,
the
namespaces
in
the
list
are
the
only
ones
where
you
can
have.
You
know
this
bucket
used.
That
was
the
original
idea.
We
then
moved
on
and
talked
about
using
selectors
instead
of
having
a
static
list
or
because
selectors
are
much
more
friendly.
A
So
so
the
issue
we
saw
with
the
allowed
namespaces
was
that
in
order
to
share
it
with
the
new
namespace,
you
would
still
need
an
admin
step
because
or
you
would
need
an
admin
step,
because
admin
would
have
to
go
and
update
the
bucket
object,
which
is
cluster
scoped
object,
so
so
we're
trying
to
remove
that
admin
step.
A
We
came
up
with
the
concept
of
namespace
selectors.
We
thought
that
would
be
better,
but
but
even
within
namespace
selectors.
A
If
the
selector
is
not
there
either
on
the
namespace
or
if
the
bucket
doesn't
select
it,
you
need
the
admin
step
anyways,
it
seems
more
kubernetes
style,
but
but
it
doesn't
really
take
the
admin
step
out
of
the
picture
so
bucket
sharing
across
users.
You
know
we
hadn't
discussed
yet
by
that
point
I
am
not
sure
who
came
up
with
this
idea,
but
someone's
talked
about
this
idea
of
sharing
a
completely
different
way
where
someone
expresses
intent
of
wanting
to
share
the
bucket
to
a
particular
namespace
and
then
on
that
namespace.
A
Someone
accepts
that
that
new
bucket
that
comes
in
and
and
that
was
that
was
kind
of
the
approach
we
all.
We
all
finally
ended
up
with
and.
C
I
mean
that
approach
is
similar
to
the
like:
the
name,
space
transfer
thing,
yeah.
B
C
A
So
we
won't
do
any
transfer,
we
will
do
an
export,
so
so
the
difference
is
yeah.
So
I'm
going
to
present
something.
C
Yeah,
I'm
just
saying
that
there
seems
to
be
a
difference:
the
name
space
one.
Basically
you
you
request
the
transfer,
but
then
after
the
transfer,
then
it
just
goes
to
this
other
name.
So
it
does
not.
A
Yeah
yeah,
so
yes,
we
do
so
so
the
bucket
itself
doesn't
go
to
another
name
space
in
this
case,
so
so
this
is
another
other
example
of
how
this
export
is
done
by
someone
from
carvel
vmware
tanzas.
If
someone
from
vmware
shared
this,
if
that
person
is
on
the
call,
thank
you
very
much.
I
I
this
is
the
the
names
to
how
it's
been
described.
This
is
a
great
way
to
explain
what
what
we
were
thinking
of.
A
I
think
I
think
it
moves
us
a
step
in
the
right
direction,
so
so
shane
to
answer
your
question,
we
don't
transfer
instead,
we
export.
So
I
think
you.
A
Yeah
gateway,
okay,
so
gateway
was
there
because
we
had
resources
that
was
managed
both
within
namespaces
and
outside
of
it,
because
at
one
point
we
were
talking
thinking
about
having
a
namespace
bucket
and
a
non-namespace
bucket
and
tim
was
saying
the
way
gateway's
managed
at
google
is
there
are
there?
Are
you
know
there
are
top
level
gateways
that
are
managed
by
you
know
a
specific
admin
team
in
google
and
then
each
team
gets
to
manage
their
own
smaller
level
gateways
based
on.
A
However,
their
application
looks,
and
something
like
that
is
what
tim
was
suggesting,
but
that's
again
for
for
mutation
use
case,
because
we
wanted
to
be
able
to
change
the
bucket.
You
know
you
wanted
to
be
able
to
do
self-service
bucket
mutation
in
some
cases
and
and
in
other
cases
we
wanted
to
have
like
only
admin
driven
ones,
but
that
doesn't
apply
here.
C
A
Yeah,
so
this
is
bucket
sharing
use
case,
it's
it's
different
from
bucket
mutation.
A
So
so
this
this
was
a
good
good
piece
of
you
know,
design
someone
shared
on
on
our
slack
channel
and
it
captures
what
we
discussed
last
week.
So
so
again
allowed
names,
allowed
names,
say
selectors.
We
talked
about
the
issues
with
them
this
one
this.
This
approach
lets
us
share
buckets
across
namespaces
without
requiring
an
admin.
A
Just
the
cozy
controller
will
be
able
to
enable
this.
So
what
this
does
is
it
does
something
like
a
bucket
export.
A
So
I'll
just
explain
what
happens
here
with
secrets
and
we
extrapolated
the
buckets,
so
they
have
two
concepts
called
as
a
bucket
export
and
a
sorry
secret
export
and
a
secret
request,
so
secret
export
is,
is
a
way
to
offer
your
a
secret
in
one
name,
space
to
another
namespace,
but
then
the
first
namespace
I
ideally
shouldn't
just
be
allowed
to
create
a
resource
in
the
second
namespace,
so
so
the
second
name
space.
In
order
to
make
sure
that
you
know
the
export
facility
is
not
is
not
abused.
A
The
the
second
namespace
accepts
it,
or
in
shows
the
intention
that
that
you
can
create
a
bucket
or
secret.
In
my
name
space
by
by
having
the
secret
request
object,
the
secret
request
object
expresses
the
intention
that
a
secret
you
know,
needs
to
be
brought
into
this
namespace
and
a
secret
export
from
the
other
namespace.
That's
actually
providing
the
secret
here
shows
how
or
or
starts
the
operation
to
export
it.
A
A
A
A
Well,
the
the
the
person
who
created
the
bucket
or
the
person
who
created
the
secret
in
this
case,
chooses
to
export
it
to
specific
other
namespaces.
A
A
A
Okay
yeah,
so
you
can
only
accept
a
secret
if
it's
already
exported
it's
it's
coming
to
you,
calling
it
secret
request.
Yeah
makes
it
makes
it
sound
like
your
request
first,
but
either
way
it
doesn't
matter.
E
A
Right,
it's
you
know
you,
you
can
either
create
a
pv
by
using
a
pvc
or
or
by
creating
a
pvc
or
or
you
can
just
put
the
volume
in
a
part,
and
that
ends
up
creating
a
pvc
for
you
right
yeah
that
can
be
like
a
syntactic
sugar.
I
mean,
like
the
underlying
object,
would
still
be
on
its
own.
F
E
A
Well,
okay,
so
here's
the
other
question
then.
So
do
you
want
to
allow
okay?
So
if,
if
we
went
down
that
route
of
having
it,
you
know
be
embedded,
always
just
that's,
the
only
way
of
would
be
embedded
into
the
bar,
then
that
would
mean
that
would
mean
one
c.
One
bucket
export
is
only
for
one
bar,
wouldn't
it
like.
If
what
if
I
wanted
multiple
bars
for
one
bucket
from
a
different
name
space,
do
I
have
to
export
it
multiple
times.
E
Yeah,
a
bar
is
named
space.
So
to
me,
this
idea
of
exporting
a
bucket
request
and
export
is
a
way
of
bridging
namespace
barriers
right
and
so,
and
so
a
bar
in
a
different
name,
space
from.
D
E
Is
this
cross
namespace
case
and
the
bar
is
already
a
little
different
in
that
scenario,
where
it
references
the
bucket
instance
directly,
instead
of
referencing
a
br,
and
so
it
seems
like
in
that
that
you
could
also
accommodate.
E
A
Yeah
that
makes
sense
if,
if
we
go
down
that
route,
here's
the
trade-off
it
seems
like
so
when
I
exported
from
the
namespace,
where
I
create
the
bucket
I'm
exporting
it
to
the
other
namespace.
A
Is
if
we
define
the
intention
that
way
that
that
I'm
exporting
it
to
another
namespace,
then
then
multiple
bir
should
be
able
to
utilize
that
bucket
by
creating
a
implicit,
you
know
bucket
request
or
bucket
accept,
I
don't
know
the
name
yet,
but
what
have
we
come
up
with
by
having
it
be
implicitly
embedded
into
into
the
receiving
bar?
A
E
Get
I
I
guess
it
wouldn't
make
sense
to
have
multiple
bars
in
the
same
name,
space
requesting
access
to
the
same
bucket,
because
it
seems
to
me
that
if
you
had
multiple
workloads
in
a
namespace
sharing
a
bucket
that
was
created
out
of
a
different
name
space,
you
would
only
need
one
bar
right,
because
those
workloads
can
use
the
same
credentials,
secret
and
credentials
right
because
they're
in
a
they're
in
the
lowest
they're
in
the
most
granular
security
yeah
boundary
that
kubernetes
provides
namespace.
E
That's
yeah
right!
That's
what
I
was
just
thinking
I
haven't.
This
is
just
top
of
my
head
said
I
I
haven't
given
it
any
other
thought
than
just
right
now.
A
Flush
it
out
as
much
as
possible.
No,
I
I
see
where
you're
coming
from.
Would
it
be
fair
to
say
that
you
might
want
to
revoke
credentials
of
one
workload?
That's
using
the
bucket
versus
you
know,
another
workload.
F
A
E
It
just
means
that,
well,
I
guess
that's
a
really
good
question.
The
kubernetes
views
everything
within
a
namespace
as
equal.
Essentially
I
know
there's
cluster
role
bindings
where
you
can
you
can
reference
a
service
account
or
a
group
right,
but
in
general
the
name
space
is
the
security
boundary
and.
E
E
A
Design
yeah,
we
don't
we
don't
as
a
security
design.
I
don't
think
we
need.
We
need
more
than
one
accessor
per
per
bucket
because
just
like
you
said
you
know,
if,
if
I
have
two
accesses,
it
doesn't
make
it
more
secure,
but
it
does
add
flexibility,
though
right,
because
I
can
now
turn
off.
E
Yes,
I'm
sorry,
I
have
a
delay
still.
Yes,
it
adds
flexibility
for
the
case
of
a
a
runaway
workload
or
something
within
the
namespace.
One
workload
is
rogue,
it's
going
bad
and
you
want
to
stop.
You
want
to
revoke
its
credentials
and
the
other
one
is
good,
but
it
seems
like
you
could
just
kill
that
pod.
E
A
E
E
D
E
Off
that's
a
feature:
that's
not
enabled
but
you're
getting
I
mean
it's
getting
a
little
bit.
You
know
theoretical
now
I
mean
yes,
it's
probably
it's
possible.
Now.
A
The
question
is
yeah
the
reason
we
yeah
the
question
is:
should
we
should
we
design
for
that?
Should
we
allow
that
or
no,
because
I'm
still
trying
to
answer
the
question
of
do
we
need?
Do
we
embed
it
in
the
bac
or
sorry
bar
or
do
we
do?
We
have
it
be
a
separate
object
so
based
on
the
answers
to
these
questions,
we
we
can
decide
as
in
if
we
need
the
flexibility
to
revoke
one
and
not
the
other.
We
probably
want
to
have
you
know
an
object
on
its
own.
E
Right,
I
kind
of
yeah-
I
I
see
it
as
a
typical
trade-off
that
we
have.
We
often
deal
with
of
flexibility
versus
opinionated,
simplicity,
right,
and
so
you
know
we
could
have
the
opinion
in
cozy
that
you
have
one
set
of
credentials
per
name
space.
That's
the
way
we
want
to
do
it
at
the
cost
of
some
flexibility,
for
maybe
narrow
use
cases
it.
You
know
this
is
our
standard
trade-off
that
you
look
at
all
the
time
in
design
like
this.
Is
flexibility
versus
simplicity,.
A
I
agree:
yeah,
I'm
not
sure
how
how
we
go
about.
I
I
think
we
have
to
decide
as
a
group.
Actually
we
have
to
decide
as
a
group
yep
how
we'll
address
this.
So
so,
if
so,
quick
question,
so
is
everyone
following
what's
what's
going
on
here.
A
I'll
take
that
as
a
no,
so
I'll
I'll
quickly
explain
what
we're
discussing
so
we're
discussing
how
we
share
buckets.
I
mean-
I
don't
understand
this
part
so
far.
I
think
so
we
were
talking
about
this.
A
This
concept
of
bucket
export
equal
into
the
secret
export
that
I'm
showing
on
the
screen
and
some
form
of
instead
of
you,
know
yeah
bucket
request,
that
is
on
the
other
side,
so
bucket
export
says
that
I
want
to
export
this
bucket
to
another
namespace
and
bucket
request
on
that
namespace
says
I
want
to
receive
that
bucket
on
this,
so
we
were
talking
about
how
this
bucket
request
should
look
on
the
on
the
receiving
saving
namespace,
and
we
were
saying
instead
of
having
a
separate
object
of
its
own.
Why
not?
A
The
reason
for
that
is
bucket
access
request
is
currently
the
the
way
we
have
to
request
access
to
a
bucket,
and
so
it
seems
like
a
natural
fit
to
just
embed
it.
Now,
we're
kind
of
evaluating
that
approach
against
another
approach
where,
instead
of
embedding
this,
this
request
this
this
acceptance
of
the
bucket
and
the
other
name
space
into
a
bucket
access
request,
we're
thinking
of
creating
a
whole
new
crd.
That
would
that
would,
you
know,
accept
this
bucket.
A
So,
let's,
let's
set
names
for
these,
so
so,
let's
call
this:
let's
call
the
the
exporting
crds
bucket
export
and
on
the
other
side,
do
we
call
it
bucket
accept.
Is
that
a
decent
name.
A
Yeah
bucket
receive-
or
you
know
it
can
be
a
part
of
a
bucket
request
too.
A
bucket
request
can
be.
You
know
enhanced
to
you
know
I
love
this,
so
either
you
create
a
bucket
request
for
creating
a
bucket
or,
for
you
know,
sharing
a
bucket
something
of
that
in.
E
D
E
Need
a
b-a-r
anymore.
I
don't
know
yes,
that's
interesting
sid!
I
don't
wanna
derail
us,
but
it's
interesting
that
you
could
maybe
eliminate
a
bar
and
the
br
is
a
request
for
either
a
new
bucket
or
a
request
to
share
a
bucket
anyway.
A
So
so,
let's
just
say
we're
going
to
enhance
bucket
request
the
current
resource
to
also
be
able
to
request
a
shared
bucket
from
another
namespace,
and
we
have
this
bucket
export
object
which
which
will
be
used
to
export
a
bucket
or
you
know,
create
a
shared
bucket
and
and
it's
going
to
be
point
to
point
because
we
want
to
specifically
say
this-
is
the
other
name
space
that
I'm
sending
this
bucket
to
so
bucket
export
and
an
enhanced
bucket
request.
A
A
There's
no
conversation
of
right
yeah.
We
don't
have
to
worry
about
this.
Other
other
thing
that
we
just
talked
about
yeah.
I
like
that.
I
actually
like
that
now.
What
are
the
implications
for
you
know
in
this
approach?
What
are
the
implications
for
brownfield
buckets
like
buckets
that
are
created
out
of
cozy?
E
It
for
that
concept
we
end
up.
You
know
referencing
the
bucket
instance
directly
today
in
the
bar,
or
it
could
be
directly
in
a
br.
But
but
that's
our
connection.
We
we
make
a
direct
reference.
The
creator
of
the
bar
or
the
br
makes
a
direct
reference
to
the
bucket
instance
that
already
exists,
and
that
gives
us
brown
chill
right.
A
Right
right
so
static,
brownfield
yeah,
so
so
in
the
br
in
the
in
this
new
br
would
we
have
some
mechanism
to
say
this
is
a
static
from
brownfield
bucket,
like
the
the
difference
between
static
brownfield
and
a
shared
bucket
or
regular?
Brownfield
would
just
be
that
you
know
the
regular
brown
field
was
created
by
cosy
in
a
different
name
space,
but
the
static
broad
field
was
cleared
outside
of
cozy.
A
So
so,
currently
to
do
static.
The
reason
I
bring
it
up
is
currently
the
way
to
do
static.
Ground
field
requires
an
admin
to
go
and
create
this
bucket
object.
In
you
know
the
clustered
object
the
bucket
with
the
right
values.
A
But
with
this
concept
of
bucket
export
and
the
new
bucket
request,
I'm
just
wondering
if
there's
a
way
to
you
know
also
solve
that
use
case.
E
Right
right,
the
other
thing
I
mentioned,
though,
just
thinking
about
self-service
when
you
say,
eliminate
an
admin
step
that
gets
us.
You
know
more
towards
self-service
yeah
model,
which
I
I
recognize
the
benefit
of
that,
but
at
the
same
time,
we've
just
shifted
a
burden
from
an
administrator
to
the
user,
because
this
user
has
to
do
exports
and
and
so
we're
gated
on
this
user.
I
mean
the
people
that
the
workloads
that
want
to
share
this
bucket-
and
maybe
there's
a
lot.
You
know-
maybe
there's
a
thousand
workloads.
E
A
E
E
We've
made
trade-offs
almost
every
time
where
we
give
admin
control
instead
of
the
user
and
that's
been
deliberate
and
and
this
this
is
a
change
to
that
direction
and
it
could
be
based
on
feedback
from
tim
or
it
could
be
just
we've
thought
about
it
long
enough
that
we
think
self-service
is
important
to
deal
with
now,
but
I
just
I
just
wanted
it
to
be
recognized
as
a
little
bit
of
a
change
in
philosophy
or
or
in
a
goal.
It's
a
it's
kind
of
a
different
goal.
A
Yes,
yes,
you're
just
saying
so:
yeah
tim
brought
this
up
yeah,
we
didn't
explicitly
define
services
ago.
I
think
I
think
it's
I
don't
yeah.
I
see
I
see
what
you're
saying
and
it's
important
to
be
wary
of
you
know
or
even
self-aware
of
such
such
you
know,
drastic
changes
even,
but
I
think
it's
still
worth
thinking
about
and
and
having
a
discussion
about.
A
So
we
understand
what
alternate
approaches
are
possible
and
and
what
the
trade-offs
are
like
you
said
there
are,
there
are
a
bunch
of
places
and
you
know
where
we
decided
that
admin
has
the
manual
say
and
and
it's
kind
of
baked
into
the
design.
So
so,
if
we,
if
we
were
to
go
against
that
philosophy,
all
of
a
sudden
we'll
have
to
possibly
rethink
you
know
all
of
it.
That's
where
you're
coming
from
right.
A
Yes,
fair
enough,
yeah,
we'll
take
it
one
step
at
a
time.
So
so
forget
the
the
the
the
static
brown
field
bucket
right.
Let's,
let's
not
go
down
there
just
yet
and
then
we'll
we'll
bucket,
sharing
has
has
always
been
questionable.
So
bucket
sharing
was
has
always
been.
It
really
didn't
enable
the
level
of
control
that
that
we
really
wanted
for
it.
A
I
think
just
that
one
use
case
in
that
case,
I
think
I
think
it
makes
sense
to
at
least
explore
this.
You
know
export
and
the
new
bucket
request
concept.
What
do
you
think
about
drawing
the
line
there?
Just
for
sharing?
We
do
it,
but
we
don't.
We
don't
go
ahead
and
solve
solve
a
self-service
for
all
use
cases.
E
So
it's
it's
worth
doing.
It's
worth
doing
that.
I
think
it's
also
important
that
we
don't
necessarily
have
a
full
design
in
place.
I
mean,
I
think
we
need
to
temper
these
designs
with
what
we're
trying
to
with
trying
to
get
to
alpha
right
to
just
get
the
first
merge,
and
I
think
that
if
we
can
convince
ourselves
that
we
could
do
this
later,
that
it
and
it
doesn't
have
to
be
done
at
the
beginning
right
now,
that
will
help
us.
A
Agreed
agreed
so
so
you're
saying
that
we
just
have
the
approach
in
hand.
Now
we
don't
even
have
to
have
it
fully
ironed
out,
you're
saying
at
least
for
the
sake
of
it.
You
have
to
be.
E
A
Okay,
so
let's
talk
about
that
so
so
we
did
get
pushback
last
time
on
this
allowed
name
swiss
concept
because
it
really
wasn't
achieving
much.
It
was
a
staggering
at
that
point.
E
Yeah,
it's
a
it
was
fair
criticism
on
tim's
part.
It's
always
been
like
you
said,
it's
always
been
difficult
allowed.
Namespaces
this.
This
cozy
is
the
only
enhancement
I
can
think
of
that.
Has
this
list
of
names
faces,
so
it's
very
different
from
everything
else.
It
always
feels
awkward,
but
we
couldn't
come
up
with
anything
better,
but
what
I'm
suggesting
sid
is.
Maybe
we
just
maybe
alpha
v
one
alpha
one
doesn't
do
bucket
sharing,
we
don't
have
allowed
name
spaces
in
there
and
and
we
just
don't-
share
the
bucket
across
name
spaces
yeah.
E
C
B
Yeah,
so
so
that
that
would
mean
that
the
bucket
is
only
accessible
to
the
namespace
on
which
it
was
created,
right,
yeah,
alpha,
yeah
and
and
beta.
We
can
come
up
with
a
bucket
export
and
something
like
that.
E
It
would
mean
you
can
share
a
bucket
within
a
namespace,
multiple
workloads
and
the
name
same
namespace
could
share
the
bucket.
But
a
workload
in
a
different
namespace
could
not
share
it
in
v1l
for
one,
but
we
have
to
be,
but
we
we
believe
you'll
need
to
share
it
across
namespaces.
So
we
have
to
have
some
idea
of
what
how
we
would
do
that
still,
but.
B
No,
so
good
so
for
the
alpha.
We
do
just
nothing
for
sure
yeah
and
for
the
beta,
something
like
bucket
export
and
bucket
hello
export
for
sharing.
A
Yeah,
so
I
I
already
think
it's
modular
in
the
sense,
so
so
what
what
we're
trying
to
answer?
What
jeff
is
saying
is
we
could
go
with
this
approach,
but
we
want
to
know
that
with
where
we're
leaving
off
the
design
at
alpha,
we
don't
have
any
restrictions
that
prevent
us
from
going
towards
this
approach.
B
You
know
yeah
jeff.
If
we
want
to
converge,
maybe
it's
the
best
unless
somebody
the
people,
people
approving
the
cap.
Besides,
we
absolutely
need
some
method
to
share
the
packets
in
the
alpha.
B
A
Enough
so
so
yeah
the
sense.
So
no
that's
a
good
question,
so
it's
it's
a
choice.
We
make.
We
say
we
we
don't
do
it
now,
but
we'll
do
it
in
the
future.
We
made
that
you
know
we
kind
of
made
that
made
the
choice.
Last
time
also-
and
we
said
we
won't
do
bucket
mutation
now,
we'll
do
it
later,
but
but
he
was
still
interested
in
seeing
a
possible
approach.
A
So
you
know
he
wanted
to
know.
How
would
you
do
it
later
like?
Is
there?
Is
there
a
idea?
Is
there
something
you
already
know
and
and
the
reason
he
was
asking
was
to
make
sure
that
the
current
design
didn't
prevent
us
from
from
actually
solving
the
problem
in
the
future.
B
So
it
makes
sense
so
so,
for
instance,
if
we
do
nothing
for
the
alpha
and
we
come
up
with
a
design
like
bucket
export
and
we
can't
accept
export,
for
instance,.
A
B
What
prevents
us
from
from
doing
that?
Is
there
a
technical
reason.
A
There
isn't
yeah,
there
is
not
that's
exactly
what
jeff
is
saying,
though,
he's
saying
make
sure
that
we
have
another.
We
have
the
next
steps
planned
out
so
that
you
know
and
make
sure
that
the
current
stage
does
not
prevent
us
from
going
there
like
have
an
answer
for
how
would
you
solve
it?
I
know
you're
not
doing
it
for
alpha,
but
how
would
you
solve
it?
You
know
to
have
that
have
an
answer
to
that
question.
So.
B
E
A
Okay,
cool,
perfect,
all
right!
So,
let's,
okay!
So
how
do
we
go
about
this
then?
Shall
we
write
a
document
or
should
we
should
we?
Should
we
give
a
hint
in
the
cap?
What
do
we
do
so
so
so
we're
going
to
say
we're
going
to
take
this
stance.
That
bucket
sharing
will
not
be
you
know,
enabled
or
possible,
with
the
alpha
design
and
then
and
then
do
we
say
the.
C
I
think
you
can
put
that
in
maybe
nango
just
say
this
is
what
we
address
in
the
future.
Maybe
then,
then,
we'll
see
what
the
you
know,
what
team
will
say?
Maybe
he
make
this
like
a
face
fun
face
too,
but
that's
fine.
Just
as
long
as
you
mentioned
that
it'll
be
addressed
in
the
future.
A
B
Yeah,
you
can
say
we
plan
to
do
we're
not
sure
yet,
but
we
plan
to
do
a
design
similar
to
secret
export,
and
we
we
see
what
we're
gonna
say
right.
A
Yeah
yeah,
that
makes
sense
okay,
so
I
was
just
wondering
how
we
do
this.
Okay,
that
makes
sense.
That
makes
a
lot
of
sense.
Actually,
okay,
so
the
let's,
let's
I
I
think
this
is
a
good
place
to
you
know
close
the
discussion
on
bucket
sharing,
I
mean,
like
conclude,
the
discussion
on
bucket
sharing.
A
I
think
I
think
one
question
that
still
hasn't
been
answered
so
here
is
where
I'm
not
sure
of
and
and
again
we
can
decide
as
a
group
as
to
you
know
what
we
do
about
this
problem.
So
so
I
think
bucket,
export
and
bucket,
you
know
accept
the
bucket
request
is
seems
like
a
good
model.
As
of
now,
I
don't
think,
we've
gotten
to
a
point
where
you
know
we
know
every
it
satisfies
all
the
different
concerns
we
have.
A
A
So
so
that
is
like
a
bucket
import
concept.
I
don't
know
if
you
know,
given
that
we
have
we've
come
up
with
this
approach
of
export
and
you
know
bucket
requests
on
the
two
different
name
spaces.
Should
we
have
another
concept
or
should
we
should
we
follow
something
similar
or
should
we
see
if
we
can
use
this
this
bucket
export
and
request
infrastructure,
or
this
this
design
for
for
static
brownfield
buckets
also.
A
I
actually
think
that
I
think
it
will
work,
but
but
my
question
is
see
we
we
have
a
different
approach
already
in
place
for
for
static
brownfield,
which
is
the
admin
goes
and
creates
the
bucket
object
in
in
in
in
the
cluster
name.
You
know
the
cluster
scope
as
admin
would
go
and
manually
put
in
all
the
different
values
and
and
they
would
create
the
bucket
object.
A
That's
that's
what
we've
said,
but
with
the
concept
of
bucket
export
or
this
this
whole
design.
I
feel
like
something
like
either
either
we
can
make
the
bucket
request
to
have
a
provision
to
import
a
bucket,
or
we
can
have
this
all
new
separate
bucket
import
object
to
to
to
import.
You
know
buckets
created
out
of
cozy.
Now
my
question
is:
should
we
like
you
know
I
want
to
explore
that
question
like
I
want
to
know?
How
does
this?
B
I
don't
think
it
would,
because
you
have
the
bracket
object
and
then
we
do
have
the
credentials
somewhere
and
then
you
export,
I
mean.
D
So
like
so
the
idea
with
the
sick,
bucket,
esport
and
workout
request,
we
are
changing
the
mechanism
to
have
a
bucket
request
right,
so
we
can
use
the
same
so
bucket.
Suckers
need
to
have
the
bucket
object
and
even
for
the
static
brown
field,
we
have
the
bucket
object
right.
It
will
be
the
person,
so
even
I
don't
feel
it
won't
make
any
difference
or
like
it
won't
be
a
difficult
thing.
B
That's
why
you
want
a
separate
bucket
export
and
another
one
which
would
be,
for
instance,
bucket,
accept
export.
B
B
B
A
So
so
like
so
so
vienne
can
you
can
you
repeat
what
you're
saying
so
so
or
let
me
try
to
capture.
Let
me
know
if
I'm
thinking
of
what
you're
saying
is
correct
or
if
I'm
thinking
of
it
the
way,
you're
thinking
so
so,
you're
saying
that
so
this
concept
of
bucket
export
and
bucket
request
makes
sense.
Did
you
also
somewhere
in
the
middle
mention
bucket
access
export.
B
B
Bucket
export
and
a
low
export
or
yeah,
but
imports,
maybe
but
import
yeah
and
those
concepts
are
independent
from
the
the
other
cozy
concepts
so
totally
independent.
We
don't
try
to
mix
up
well.
B
But
the
problem
is
in
bound
field,
you
don't
have
wicket
requests.
A
A
Currently
currently,
in
case
of
brownfield
bucket
access
request
points
directly
to
the
bucket
and
in
case
of
green
field,
it
points
to
the
bucket
request.
So
it's
not
an
invariant
it
depending
on
on
the
situation.
It
changes
varies,
but
if
we
were
to
go
with
this
concept
of
bucket
sharing,
where
we
said
bucket
request
can
have
an
embedded
field
to
say
I'm
importing
the
bucket,
then
then
you
know
you
can
maintain
that
invariant
of
saying
bucket
access,
request,
points
to
the
bucket
request
always
and
that
solves
that
simplifies
the
architecture.
A
A
B
Yeah,
but
you
you
one
way
is
to
the
brownfield
the
boundary
cases
to
declare
an
external
bracket
inside
kubernetes
with
a
going.
The
green
field
is
to
auto
automatically
create
a
project
because
right
and
this
new
scheme
bucket
export
and,
let's
say
bucket
import,
it's
it's
just
about
to
share
a
briquette
across
them
space
by
nothing
else.
A
I
see
what
you're
saying
so
so
so
here's
the
thing:
how
would
they
refer
to
the
bucket
that's
shared
with
other
namespace
when
they
create
a
bucket
access
request?
How
would
they
refer
to
it.
A
Okay,
so
let's
say
bucket
bucket
name
is
pictures
or
something
and
and
you're
exporting
from
namespace
1,
the
pictures
bucket
to
namespace
2
and
in
namespace
2.
You
have
a
bucket
import
object
which
imports
whatever
right
it
imports,
or
it
allows
this
name
space
to
request
buckets
yeah,
okay.
So
what
happens
then
like
what
would
happen
with
like
how
would
they
utilize
this
imported
bucket?
B
I
don't
know
so.
The
controller
would
know
that
access
is
a
load
from.
A
A
It
needs
to
point
somewhere
right,
like
it
could
point
to
the
the
global
bucket
that
that
is
fine.
But
wouldn't
it
be
better
if
it
could
point
to
the
br.
B
A
A
B
A
So
yeah,
so
that's
that's
kind
of
how
I'm
thinking,
maybe
next
time
next
week,
I'll
draw
a
diagram.
So
maybe
it'll
be
easier
to
talk
about
this
that'll
help.
Okay,
so
I
don't
think
we
can
conclude
just
yet
on
this,
but
but
I
think
we
we
have
some
changes
that
we
agreed
on
with
the
cap
related
to
the
cap.
I
think
it's
fair
to
say,
like
jeff
was
saying
that
that
maybe
we
we
don't
solve
bucket
sharing
for
alpha,
but
we
have.
We
have
an
alternate
solution.
A
So
so
there
is
another
concern
that
needs
to
be
addressed,
which
is
bucket.
Mutation
and
jeff
came
up
with
an
interesting
proposal.
Last
week
after
the
meeting,
and
I
had
a
chance
to
review
it
I'll
bring
it
up
next
week
we
didn't
have
the
chance.
We
don't
have
enough
time
to
do
it
this
week,
I'll
bring
it
up
next
week
and
and
we'll
go
from
there,
we'll
we'll
discuss
that.
What
does
he
do?
Just
limitations.
A
So
so
we
want
to
change
properties
of
the
bucket
say
we
want
to.
We
want
to
change
some
some
properties
of
that
bucket.
Whatever
that
means
say
say
we
want
to
increase
the
storage
class
standard
or
topology
of
it.
I
don't
know
whatever.
A
A
We
don't
need
for
alpha.
No,
no,
no
we're
already
talking
about
the
next
steps
because
yeah
we
we
can't
keep
talking
about
alpha
when
we
have.
You
know,
conclusions
and
decisions
being
having
been
made
already
on
how
we
want
to
do
it
like.
As
far
as
stage
we,
we
have
a
consensus,
we're
going
to
the
next
step.
A
Yeah
yeah,
so
we
want
to
talk
about
mutation,
so
so
jeff's
proposal
come.
You
know
it
was
explaining
something
else,
but
but
it
seems
like
driving
this
change
through
the
br.
A
The
bucket
request
would
be
the
right
way
and
and
yeah
I'll
bring
it
up
next
week
when
we
get
some
time
and
then
we'll
discuss
it
further
and
then
we'll
see
what
we
can
do
with
that
and
if
we,
if
we
solve
sharing
and
if
we
solve
mutation
we
we
can,
you
know
we'll
will
be
more
than
you
know
beta
at
that
point
like
we
would
have.
We
would
address
all
the
major
concerns
and
then,
after
that,
it's
just
going
to
be
integrating
with
different
vendors.
A
So
sharing
and
mutation
are
the
two
things
that
we
need
to
iron
out
with
sharing
itself
like
we
need
to
figure
out
what
this
bucket
export
is
going
to
look
like
what
the
import
is
going
to
look
like
and
all
that,
and
we
have
to
answer
the
question
of
buckets
created
outside
of
cozy
but
but
yeah.
I
think
I
I
think
we're
in
a
good
shape.
Actually,
so
I
don't
know
today,
it
seems
like
we're
very
productive.
B
Yeah,
so
just
if
I
see
if
I
can
something
so
so
are
vendor
I'm
talking
for
the
skt
here.
We
really
need
something
like
the
alpha
to
be
frozen
somewhere
to
make
progress
because
we
have,
we
do
have
customers.
We
are
asking
for
the
first
few
skills
which
are
going
to
film
and
bronfeel
right.
A
Hey
so
you
can
help
us
do
this:
let's,
let's
no.
B
Just
just
yeah
and
then
the
the
what
you're
talking
about
the
mutation
stuff
is
interesting.
The
sharing
you
know,
but
it's
not
I
mean
for
the
alpha
as
it
is
defined
today,
is,
I
think,
useful
enough
to
be
used
also.
B
No,
we
want,
I
mean,
I
see
I'm
talking
for
all
the
vendors
here,
so
I
don't
know
if
I
cannot,
but
we
need
something
frozen
out
to
to
basically
ship
our
first
implementation
and
of
you
know,
customers.
A
B
A
I
mean
it's
still
alpha,
I
don't
know
anyway,
so
so
you
know.
A
So
the
thing
is
even
after
alpha,
you
have
to
set
up
the
controllers,
and
you
know
the
cozy
controllers
and
everything
yourself
and,
and
whatever
you
have
so
far,
you
should
already
be
able
to
show
it
to
customers.
B
A
It's
quite
reality.
Bro,
like
you
could
say,
this
is
something
we've
worked
on.
You
don't
have
to
say
it's
cozy,
but
but
I
understand
where
you're
coming
from
and
and-
and
you
know
we're
pushing
as
hard
as
we
can.
You
know
we're
definitely
on
the
way,
but
the
problem
that
you
mentioned,
I'm
just
trying
to
understand,
because
you
know
I
also
remember
what
we
would
just
do
is
simply
go
give
them
the
software
tell
them.
A
That's
what
I
asked
so
you
wanted
to
freeze
it
rather
than
just
have
something
called
alpha
so
yeah
for
that.
For
that
we
need
to
hear
back
from
tim
that
that's
that's
the
whole.
You
know
step
so
we're
waiting.
Unfortunately,
you
know
he's
very
busy
and-
and
you
know
we
have
to
work
with
him.
So
so
that's
kind
of
you
know
we
don't
get
enough
reviews
to
be
honest.
A
Last
time
the
review
we
got
was
on
the
last
day
a
few
hours
before
the
deadline,
and
you
know
that
was
not
good.
This
time
we're
pinging,
but
but
you
know
we
need
some
help
to
make
sure
that
he
he
looks
at
it
more.
A
Luckily
we're
not
near
the
deadline.
So
so
you
know
it's
good
thing,
but
that's
why
I
said
you
can
help
as
a
vendor
and
you
can
help.
So
what
you
can
do
is
ping
them
ping
them
and
ask
them
to
take
a
look
here.
A
Yeah-
it's
not
so
shane
can
we
can?
How
do
we?
How
do
we
make
them?
Look
at
this
sooner
this
time
like
he
seems
very
busy
or
is
there
someone
else.
C
I
think
api
review
would
be
him
right
so
since
he
has
already
reviewed
the
earlier
version,
it's
actually
better
because
you
find
someone
else,
they
start
from
scratch.
It's
the
same
thing.
The
api
reviews
are
all
like
this:
they
they're
all
very
busy
overloaded
and.
C
Yeah,
so
I
think
just
ping
him
again
early
next,
you
know
monday
just
being
running
and
also
sending
emails
right.
So
try
both
yeah
his
attention.
Maybe
he's
out,
I
don't
know
yeah.
He
did
say
this
week
right.
I
remember
he
said
this
because
he's
yeah
I'll
say:
maybe
you
know
when
you
ping
him
on
the
slack
or
send
me
an
email,
just
make
sure
that,
because
he
probably
got
pinned
by
a
lot
of
people,
maybe
he
missed
it.
That's
possible
too.
That's.
A
Very
possible
okay
I'll,
send
an
email,
because
slack
message
is
easy
to
miss.
I
see
what
you're
saying:
okay,
okay,
shin
we're
out
of
time
baby.
I
hear
what
you're
saying
no
you're,
very
it's
very
valid.
What
you're
saying
I
I
take
it
very
seriously
and,
like
I
said
you
know,
we're
pushing
it
as
hard
as
we
can
we'll
do
more,
we'll
do
more,
we'll
get
it
done.
That's
all
I
can
say
yeah,
of
course,
all
right.
A
So
so
that's
it
for
this
week
next
week,
let's,
let's
iron
out
this
export
and
talk
about
cluster
scope
buckets,
but
all
of
these
discussions
will
not
affect
alpha
that
that's
the
stance.