►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 26 August 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
Okay,
all
right
good
morning,
everyone.
So
this
morning
I
actually
had
a
call
with
jeff
we
were
talking
about
the
cap
and,
and
one
of
the
things
he
mentioned
was
it'll
be
good.
If
the
people
here
on
this
call
can
actually
take
a
look
at
the
cap
and
all
of
us
agree
that
the
kept
looks
right.
A
So
so
what
I
want
to
do
is
next
week
before
the
call
or
when
the
call
just
starts
I'd
like
to
just
you
know,
have
you
give
your
feedback
on
the
kept
leave
your
comments
there
and,
and
each
of
you,
if
possible
and
and
I'd
like
to
then
then
discuss
your
comments
or
get
your
vote
of
approval
that
that
cap
actually
looks
good.
A
The
reason
is,
even
though
I've
tried
tried
to
capture
everything,
we've
talked
about
jeff
found
a
few
inconsistencies
that
I'm
gonna
fix
right
away.
They
seem
they
seem
minor,
but
they
still
seem
important
in
a
sense
they
seem
like
they
can
be
fixed
easily,
but
but
they're
still
important
that
you
fix
it.
A
So
so
what
I'd
like
is
ben
shane,
nicholas
jeff,
all
of
you,
if
you
can,
if
you
can
take
a
look
at
the
cap
and
and
make
sure
it
is,
it
is
exactly
everything
we
discussed
or
everything
we
talked
about
and
and
make
sure
that
I
haven't
missed
anything
like,
for
instance,
we
once
at
one
point
decided
that
deletion
policy
should
go
into
the
bucket
requests
and
not
stay
in
the
bucket
class.
A
A
These
are
minor
errors,
it
might
seem
like,
but
it's
worth
getting
it
right
before
before,
eventually
takes
a
look,
so
I
would
really
urge
you
to
take
a
look
at
the
cap
again
and
and
make
sure
that
you're
satisfied
with
that
make
sure
it's
it's
how
you
expected
it
to
be
based
on
all
the
discussions
we've
had
and
and
if
you're,
not
sure
of
something
like
say,
you
aren't
a
part
of
the
discussion
where,
where
we
talked
about
this
deletion
policy
or
just
about
anything
else,
you
can
ask
a
question
either
on
slack
or
on
the
cap
itself
as
to
why
we
made
a
decision
or
why
something
is
designed
the
way
it
is
and-
and
we
can
have
further
discussions
there.
A
Does
that
sound
good?
Can
I
can
I
can?
I
expect
some
reviews
before
next
thursday?
Would
that
be
possible.
A
To
read
and-
and
you
don't
you
don't
have
to
like
read
it
word
by
word
and
we
have
jeff
who's
doing
a
great
job
of
making
sure
the
details
are
right,
but
but
say
the
design
decisions
that
you
came
up
with
or
you
helped
come
up
with.
If
you
read
them
and
say
they
look
outdated
or
something
I
don't
think
there
will
be.
But
let's
just
say
it's
the
case
then
then
it'll
be
good.
A
If
you,
if
you
can
correct
it
or
ask
a
question
there
or
bring
it
up
here
so
so
we
can
all
be
on
the
same
page
and
along
with
the
cap.
C
A
In
the
beginning,
you're
welcome
so
next
week
in
the
beginning
of
the
meeting
I'll,
ask
you
again
and
and
yeah
hopefully,
you've
all
had
a
chance
by
then
to
you
know,
review
the
cap.
Xing
has
already
reviewed
it.
I
think
maybe
one
more
read
through.
If
you
have
time
that
will
be
very
helpful.
Yeah.
A
Thank
you
and
jeff
jeff
and
I
are
actively
working
on
it.
Thank
you,
jeff,
okay.
So
let's,
let's
get
into
the
topic
of
discussion,
so
to
give
a
quick
recap
on
where
we
were:
we've
been
going
back
and
forth
the
last
two
weeks
on
the
bucket
sharing
a
model
we
weren't
quite
fully
satisfied
with
having
allowed
namespaces.
A
So
we
talked
about
having
selectors
instead
and
selectors
had
the
same
issues
that
allowed
namespaces,
where
an
admin
still
needed
to
come
in,
and
you
know,
update
the
selectors
or
update
namespaces,
based
on
a
new
requirement
like
if
a
bucket
had
to
be
shared
to
a
new
namespace,
for
instance.
A
So
then
we
came
up
with
a
way
where
market
sharing
can
be
done
without
involving
an
admin,
and
that
was
the
idea
of
having
a
bucket
export
and
a
bucket
import
on
the
receiving
namespace,
a
bucket
export
from
the
namespace.
The
bucket
is
already
present
and
a
bucket
import
from
the
namespace
where
it's
being
received.
A
We
talked
about
various
approaches
for
doing
it
and
that's
where
we
were
so
so.
So
let
me
quickly
explain
what
all
approaches
we
discussed.
One
was
in
the
namespace
where
the
br
is
present.
The
br
that
resulted
in
the
bucket
being
created
a
user
would
create
the
bucket
export
object
and
it
would
be
intended
specifically
for
one
namespace
and
on
the
on
that
receiving
name
system
that
namespace,
where
it's
intended.
E
B
The
design
I
thought
we
were
talking
about
like
a
transfer
kind
of
a
thing
right,
because
that
was
the
terminology
we've
been
using
with
like
pvcs
and
snapshots,
is
transferred.
A
Yeah
except
pvcs
are
yeah-
I
don't
know
about
so,
probably
because
it's
expensive
to
move
data
you're,
probably
just
transferring
ownership,
but
by
the
object-
storage.
It's
always
over
the
network,
so
you
can
have
multiple
accessors.
So
would
that
I'm
not
sure
if
transfer
is
the
right
terminology
here.
B
C
A
So
another
other
approach
we
talked
about,
I
think
ben
you
might
like
the
terminology
here
better
was-
was
not
to
create
new
resources
for
this
expert
import
behavior.
We
can
stop
calling
it
export
import.
So
what
was
said
was
let
me
try
and
remember
this
so
we
said
there
would
be
on
on
the
receiving
namespace.
We
said
we
could.
We
could
have
a
br.
A
B
Is
there
a
use
case
for
also
transferring
the
whole
bucket?
I
mean
I
thought
all
the
use
cases.
Could
you
know
if
alice
creates
a
bucket
and
she
wants
to
share
with
someone
like
she
doesn't
need
to
give
anyone
else
the
bucket
she
can
retain
ownership
of
it
as
long
as
she
gets
everyone
access
to
the
bucket.
Is
there
a
use
case
where
alice
says
bob
take
this
bucket?
I
never
want
to
see
it
again.
A
Yeah,
so
the
use
case
is
you
don't
need
to
take
the
bucket?
I
see
what
you're
saying
in
terms
of
conceptually.
A
It
seems
like
we're
transferring
the
bucket
over
what
what
confu
or
what
what
is,
what
doesn't
quite
fit
the
model
is,
if
I
were
to,
if
I
were,
to
call
this
a
bucket
transfer,
where,
just
by
having
a
br
in
that
other
name
space
I
so
so
or
if
you
were
to
define
br
as
a
request
for
a
bucket,
not
just
for
requests
to
create
a
bucket,
but
just
a
request
for
a
bucket.
A
What
I
mean
by
that
is,
I
request
to
be
able
to
access
a
bucket
from
from
that
namespace.
If
you
were
to
redefine
a
br
that
way,
then,
then
that
that
definition
of
br
would
work
for
bucket,
sharing
across
name
spaces
would
work
for
importing
buckets
from
outside
the
cluster
and
also
for
you
know,
creating
new
buckets.
B
A
It's
just
access,
that's
what
it
is!
It's
clearer
and
it's
just
access
right.
B
Right
right
because,
because
I
mean
the
terminology
again
sort
of
gets
in
the
way
like
with
pvcs,
we
we
call
the
object,
a
persistent
volume
claim,
which
is
the
worst
name
in
the
world,
but
it
it's
it's
the
one
we
have
but
and
what
it
means.
It's
like
you
create
one
and
it
actually
a
volume
will
get
created
for
you
and
then,
when
you
delete
it,
the
volume
will
get
deleted.
B
You
know
I've
seen
any
weird
policies
that
prevent
that,
but,
like
the
we're
trying
to
mirror
that
with
the
bucket
request
is,
is
what
we
really
mean
by
bucket
request.
Is
I
want
you
to
make
me
a
new
bucket
when
you
delete
the
bucket
request?
What
you
really
mean
is
I
want
you
to
delete
that
bucket
and
then
everything
else
is
accessed.
A
B
Well,
in
the
very
old
days
that
that
that
is
true,
like
the
volumes
would
pre-exist
and
you
would
create
a
claim
and
it
would
bind
to
an
existing
volume
and
that's
how
it
worked,
but,
like
those
days
are
far
behind
us
and
we
when,
with
dynamic
provisioners
the
pvc
became
the
way
you
asked
the
dynamic
provisioner
to
make
you
a
new
volume
and
the
deletion
was
the
way
you
asked
the
diamond
provisioner
to
destroy
that
volume
and
that's
the
model
we've
had
for
a
couple
of
years.
Now.
B
A
B
A
Fair
enough,
so
here's
the
here's,
the
other
question
so
so
the
reason
I
was
thinking
of
unifying
all
under
the
br
again,
the
benefits
of
unification
come
there
when
you
do
that,
for
instance,
all
bucket
accesses
or
access
requests
would
always
just
point
to
brs
and
for
the
user
the
model
for
accessing
a
bucket,
regardless
of
it
being
an
external
bucket
or
a
bucket
from
a
different
namespace
or
a
bucket.
They
created
in
that
namespace.
B
A
You
know:
veto
free,
like
you
said
anyone
can
delete
or
we
can
design
the
semantics
to
be
such
that
only
people
that
that
alice,
who
created
the
bucket
originally
you
know
explicitly
intended
to
have
deletion
privileges
can
do
it.
So
if
alice
says,
I'm
I'm
giving
over
the
bucket
ownership
or
giving
the
same
privilege
that
I
have
to
bob,
then
bob
can
delete
it.
But
if
alice
doesn't
say
that,
then
bob
can't
right,
but.
B
B
Alice
can
just
create
the
level
of
access
she
intends
to
give
and
then
transfer
that
access
to
the
intended
recipient
and
okay
and
she's
in
the
driver's
seat,
and
no
one
you
know
and
and
then
bob
receives
the
the
the
bar
in
his
name
space,
but
he
can't
create
another
one
with
a
higher
level
of
access.
He
has
to
go
back
to
alice,
to
ask
for
that.
It's
just
it's
just
simpler,
because
you're
right,
you
could
set
it
up
so
that
you
can
create
these
vr
delegate
objects.
B
A
A
I
mean
it's
really
a
question
of
what's
needed
and
I
think
you're
right
we
go
the
simpler
one
first
and
and
if
users
want
that
level
of
access
which
I
doubt
they
will,
I
don't
think
so
that
level
of
control.
Then
then
we
could
go
for
that
approach,
but
right
now
I
think
what
you're
saying
makes
more
sense.
Okay.
So
in
this
case
what
is
alice
share.
So,
let's
talk
about
that
like
how
does
how
does
alice
say?
A
B
What
should
that
so?
The
way
I'm
imagining
it
is.
She
creates
a
bar,
like
any
other
br,
that
she
you
know
that
she
would
intend
to
use
herself
except
she
adds
a
a
like
recipient
namespace
to
the
request,
and
then
it
goes
and
it
gets
created.
Ordinarily,
you
know,
and
as
long
as
it
doesn't
transfer,
it's
still
hers
and
she
could
in
principle
use
it.
Although
we
might
want
to
inhibit
that,
but
but
the
only
difference
is
she
basically
says
I'm
willing
to
transfer
this
to
bob
and
then
out
of
band.
B
And
then
you
would
have
a
bidirectional
pointer,
because
alice's
would
be
pointing
at
bob's
and
bob's
would
be
pointing
at
alice's,
and
you
could
do
the
handshake
and
say:
okay,
we're
gonna,
take
the
ba,
that's
underneath
alice's
bar
and
attach
it
to
bob's
bir
and
then
bob
has
it
and
alice.
Just
has
a
an
unbound
bar
that
can
go
away.
B
A
It's
kind
of
confusing,
like
the
confusion,
is:
why
would
alice
have
to
create
the
bar?
Because
now
the
conceptually.
B
A
So
let
me
let
me
put
it
this
way,
yeah
fair
enough,
so
so
so
on
on
bob's
side,
would
that
mean
they?
They
can
only
so,
ideally,
if
a
bucket
is
you
can
you
can
access
a
bucket
from
one
name
space?
Then
then
multiple
parts
should
be
able
to
access
that
bucket
right.
A
See
the
issues
if
they
were
to
reuse
the
same
bar,
then
that
means
that
they
are
they're
sharing
the
same
credentials
and
I
can't
selectively
revoke
or
manage
credentials
for
one
of
the
workloads
without
affecting
the
others.
A
No,
that's
where
I
was
coming
up,
but
that's
that's
why
I
was
coming
up
with
the
whole
ba
br
being
the
point
of
import,
but
but,
like
you
said,
the
the
decision
making
point
that
is
which
bc
to
use
or
which
bac
to
use
that
should
come
from
alice.
So.
B
B
I
don't
see
any
problems
with
it
just
being
at
the
whole
name
space,
and
if
and
if
you
have
some
weird
case,
where
you
really
do
need
separate
ones,
you
can
keep
going
back
to
alice
and
say:
hey
alice.
I
actually
need
five
bars
to
be
transferred
and
she
can
do
it
right.
She
can
just
make
five
of
them.
Tell
you
all
their
names
and
you
can
transfer
all
of
them
like
it's,
it's
not
impossible.
It's
just
the
the
original
the
br
owner
has
to
be
involved
with
creation
or
every
new
access
which.
A
B
But
the
other,
the
other
approach,
aside
from
you
know,
making
these
vr's
directly
have
fields
that
allowed
them
to
be
transferred,
would
be
to
still
have
alice,
create
her
own
bar,
but
have
a
different
object
that
organizes
the
transfer
of
that
bar
to
bob's
namespace.
I
was
thinking
of
that
too,
like.
A
Sounds
better
okay,
so
what
would
the
advantage
of
that
be?
It
is?
It
is
easier
to
understand,
I
think,
than
than
using
a
bar.
B
The
advantage
of
creating
a
whole
new
object
is
then,
when
the
handshake
occurs
and
a
controller
sees
two
different
batters
and
two
different
namespaces
pointed
at
each
other.
It
can
actually
delete
the
old
br,
create
a
new
br
on
the
other
side,
rebind
it,
and
then
the
only
garbage
left
behind
is
the
two
batter
objects,
but.
A
B
The
batter
would
so
alice
would
have
to
create
a
transfer
request,
pointed
at
her
bar
and
bob's
name,
space
and
bob.
A
B
A
B
B
I
guess
the
issue
you're
gonna
end
up
with
then
is
no
one
can
create
new
bars
because
the
br
is
gone,
but
I
mean
at
that
point
you
kind
of
need
an
admin
to
come
in
and
do
something
anyways
like
like
reconstruct
a
new
vr
in
a
different
name
space,
because
the
problem
is
someone
has
to
own
it
at
all
times
and
if,
if
it's
not
alice,
then
it's
the
administrator
and
or
you
could
do
the
thing
where
you
explicitly
transfer
it
over
to
bob
and
now
bob
is
the
owner.
B
A
B
B
Right,
that's
what
I'm
saying
is
the
br
binds
to
the
b
and
there's
only
ever
one
of
them
right
in
principle.
We
could
move
it
across
namespaces
with
a
transfer
mechanism
or
an
admin
being
involved
or
something,
but
I
like
the
idea
of
only
having
one
so
that
it's
clear
who
owns
it
and
if
alice
wants
to
wipe
out
her
name
space
without
wiping
out
the
bucket,
then
it's
incumbent
on
her
to
make
the
transfer
happen
first.
Otherwise
she
will
destroy
the
the
bucket
and
make
everyone
else.
Sad.
A
A
B
A
So
let's
say
I
create
okay,
let's
say
I'm
alice,
I
create
the
bucket
using
my
bar
and
somehow
the
you
know.
I
I
want
to
delete
my
name
space,
but
I
don't
want
the
bucket
to
go
away.
How
do
I
do
that.
A
B
I
don't
know
shang,
how
do
we
do
this
with
snapshots
when
you
set
the
deletion
policy
to
retain
on
a
volume
snapshot
content?
I
don't
know,
I
don't
know
if
shane's
still
listening.
Okay,.
D
I
just
listened
to
this
one
question
since
you
pinned
me
okay,
so
we,
if
you
set
it
to
retain,
then
we
do
not
delete
the
residential
content.
B
A
B
B
A
How
would
you
do
that,
so
so,
by
the
way
so
far,
we've
had
the
deletion
policy
set
on
the
br,
so
so
so
that
that
would
be
fine,
so
so
the
bucket
itself
doesn't
have.
The
deletion
policy
should
be
said
on
the
bc
and
the
b,
so
we
we
moved
away
from
that
to
have
it
on
the
vr
reason
being
we
said,
it's
the
it's,
the
creator
of
the
bucket.
That
knows
what
the
deletion
policy
should
be.
B
Okay,
I
I
think
in
the
old
volume
world
the
thinking
was
the
only
reason
you
would
ever
muck
with
the
deletion
policy,
as
if
you
were
doing
one
of
these
things
where
you
had
pre-existing
volumes
and
you
weren't
using
a
dynamic
provisioner.
I
think
that
the
principle
is
for
using
the
dynamic
provisioner
every
create
should
make
a
new
volume
and
every
delete
should
delete
that
volume
and,
like
that's
just
how
it
works
right,
there's
no
way
to
have
volumes
that
don't
have
pvcs
associated
with
them
in
the
provisioning
world.
B
The
only
way
you
end
up
in
that
situation
is
when
you're
in
the
static
provisioning
world
and
that's
something
that
only
an
admin
can
help
you
with
in
the
volume
world
need
with
volumes
right.
You
can
never
get
statically
provisioned
volumes
without
an
admin's
help
yeah,
because
you
can
create
previous
on
your
own
yeah.
So
so
so
that's,
I
think,
that's
that's
why
the
it
grew
up
that
way
where
basically,
the
admin
has
control
over
this,
because
he's
the
one
who
knows
you
know,
are
we
dynamic
provisioning?
Are
we
static
provisioning?
B
Are
we
playing
funny
games
and
the
end
user?
Is
just
you
know,
expressing
an
intent
to
have
volumes
or
do
not
have
volumes
with
the
creation
and
deletion
of
the
pvc
objects,
so
you're
kind
of
granting
the
users
an
extra
level
of
authority
by
you
know
giving
them
the
power
over
the
statically
configured
book.
I
mean.
A
B
A
Yeah
it
makes
okay,
so
so
you're
saying
so
I'm
trying
to
remember
why
we
said
the
deletion
policy
should
be
on
the
br.
Then
if
there
was
another
reason
I
mean
so
so
you're
saying
duration
process
should
be
on
the
bc.
A
Okay,
so
let's
that's
how
it's
in
the
cap,
but
we
thought
that
the
cap
is
outdated
with
regards
to
that
the
one
thing
I'll
try
and
dig
back
up
the
old
old
recording
and
see
what
the
discussion
was
about.
But
for
now
let's
say
the
deletion
policy
is
on
the
bc
just
for
the
sake
of
this
conversation.
B
B
Well,
it
no
like
it's:
if
we
don't
build
in
an
automatic
transfer
mechanism,
then
you
need
an
admin
to
do
it,
but
nothing
stops
someone
from
writing
a
controller
that
performs
the
transfer
function
on
behalf
of
the
admin
you
just
need
elevated
privileges
to
do
it,
which
means
it
has
to
be
a
controller
or
an
administrator.
It
can't
be
an
ordinary
user,
but
a
controller
can
very
well
be
the
thing
that
does
it.
A
Okay,
what's
up
what's
a
clean
way
to
explain
this,
so
so
in
the
sense
I
I
want
to
try
and
understand
this
whole
transfer
model
for
a
second,
like
everything
we've
discussed.
Just
summarize
it.
So
what
we're
saying
so,
what
you've
been
saying
so
far
in
the
last
few
discussions
in
this
call
is
we
need
a
way
to
ensure
that
there's
only
one
owner
for
a
bucket
and
initially
whoever
creates
the
bucket
is
the
de
facto
owner?
A
And
if,
if
they
want
to
relinquish
ownership,
they
would
have
to
make
sure
that
they
create
a
bucket
access
transfer
request
or
a
bucket
transfer
request.
I
guess
one
of
those
two
and
once
that
is
done,
a
controller
could
automatically
go
and
change
the
deletion
policy
or
set
some
parameter
in
the
bucket
to
make
sure
that
the
bucket
isn't
deleted.
But
it's,
but
it's
opened
up
for
someone
else
to
take
ownership
of.
B
Yeah,
I
think
so
so
the
important
thing
to
realize,
maybe
not
everyone
realizes
is
you
can
transfer
pvcs
across
namespaces
today
right,
you
just
need
an
admin
to
come,
do
it
for
you
right
and
what
you
do
is
you
you
go
in.
You
modify
the
deletion
policy
or
the
retention
policy
is
what
it's
called
with
the
pv
to.
A
B
You
unbind
the
pvc
from
the
from
the
pv.
You
delete
the
old
pvc,
you
clear,
a
new
pvc
in
another
name
space.
You
point
it
at
that
one
and
then
you
can
change
the
deletion
policy
back.
There's
also
ways
you
can,
I
guess
force
it
to
unbind
without
changing
the
relation
policy.
But
but
the
point
is
someone
with
admin.
Privileges
can
just
go.
Do
this
anytime,
they
want
for
any
ppc.
B
Any
snapshot
in
fact,
like
administrators,
are
empowered
to
make
these
transfers
happen
if
they
want
to,
and
the
same
will
be
true
of
buckets
right
when
we
create
buckets
and
bars,
nothing
will
stop
an
admin
from
coming
in
and
saying
you
know
what
I'm
going
to
transfer
this
bar
to
this
other
name
space.
They
can
just
do
it.
B
The
whole
point
of
the
transfer
controller
is
it's
a
way
to
get
the
admin
out
of
the
loop,
so
it
does
what
the
admin
would
have
done
under
certain
defined
conditions
where
both
users
have
agreed
and
everything
is
secure,
and
you
know
yadda
yadda
so
like
yeah.
We've
got
to
emphasize
that,
like
this
is
always
possible
for
an
admin
to
do
and
we're
just
making
it
also
possible
to
do
it
peer-to-peer
if
you
use
these
special
transfer
objects.
F
Ben,
do
you
think
that
this
kind
of
transfer
of
ownership
is
needed
for
the
alpha
version
of
cozy.
B
B
How
do
I
get
access
to
existing
buckets
or
how
do
I
share?
You
know,
because
people
intuitively
understand
that,
like
buckets
are
the
kinds
of
things
that
you
use
to
share
data
and
if
you
say
oh
we're
not
doing
that
in
alpha,
then
they're,
gonna,
they're
gonna,
wonder
if
you've
figured
it
out
or
not,
and
I
think
that
that's
why
we
keep
coming
back
to
this
is
like
yeah.
We
don't
need
it
for
alpha,
but
we
need
it
so
that
people
believe
our
our
long-term
direction
is
is
correct.
F
F
The
the
whole
I
this
idea
of
well
originally
since
that
exporting,
but
transferring
either
bucket
ownership
or
orchestrating
how
sharing
is
done
and
the
discussion
today
has
been.
The
sharing
is
under
the
control
of
the
of
the
author
of
the
br
or
the
name
space
where
the
vr
was
created
and
and
that
person
has
authority
to
control
sharing,
not
the
admin
and-
and
that
brings
well.
B
Oh
well,
the
the
the
way
you
would
prevent
sharing
is
by
configuring,
the
controller
that
manages
transfers
with
some
rules
or
a
policy
right.
You
would
take
the
maybe
there's
some
bucket
transfer
policy
that
has
to
be
installed
when
you
deploy
the
the
transfer
controller.
That's
going
to
be
watching
these
batr
objects
or
btr
objects.
B
If
you
also
want
to
transfer
buckets
and
he
can
express
his
intent
and
say
I
I
don't
want,
I
don't
want
anyone
to
be
able
to
do
anything
or
I
want
to
limit
what
people
can
do
and
then
the
that
the
controller
will
have
to
enforce
those
rules.
Somehow
that
would
be
the
the
knob
that
the
because,
because
if
the
admin
doesn't
install
this
transfer
controller,
then
you
just
can't
do
anything
right.
You
can
still
use
cozy
and
create
buckets.
You
just
can
never
transfer
them
without
the
presence
of
this
controller
so
yeah.
F
B
So
it's
like
the
the
the
thing
that
has
to
not
do
the
transfer
is
the
transfer
controller
and
you
can
say
yeah.
The
transfer
controller
is
going
to
take
its
marching
orders
from
the
bc,
but
it's
like,
but
why?
Why
would
you
make
the
bc
serve
two
purposes
when
you
could
separate
it
out
into
two
separate
policies?.
F
I
think
my
reason
would
be
for
initial
versions
of
cozy
that
it's
simpler
and
you
don't
have
to
create
other
controllers
or
policy.
B
Yeah
I
mean
certainly
in
terms
of
like
documenting.
This
is
how
you
do
it.
It
would
be
nicer
to
not
have
you
know.
800
pages
of
of
how
to,
but
I
don't
know
like
modularity
is
great
breaking
things
down
into
smallest
possible
chunks
makes
things
more
manageable
a
lot
of
times
and
and
especially
just
in
terms
of
phased
delivery
like
it
seems
entirely
possible
to
me
that
we
deliver
all
this.
B
B
A
B
So
for
bar,
you
would
just
I
guess,
edit
the
ba
pointer
to
not
point
at
the
bar
anymore,
basically
force
it
to
unbind.
This
is
what
you
do
with
pvs
right.
You
can
point
you
can
take
your
pv
as
bound
to
pc
and
just
edit
its
bind
to
say
it's
not
binding,
bound
anymore
and
then
the
the
bind
controller
will
say
oops
my
bind
got
broken
it'll
just
mark
the
mark.
B
The
pvc
is
lost
and
at
that
point
you
can
delete
the
pvc
or
the
bar,
and
nothing
will
happen
to
the
underlying
va
that
was
bound
to
it.
You
can
just
go
create
another
bar
in
the
other
name
space
and
you
would
need
a
way
to
create
a
bar
that
has
an
existing
ba
with
a
name
sort
of
like
you
can
do
with
pv
with
pvcs
and
snapshots,
but
you
can
supply
the
volume
name
or
the
snapshot
content
name
in
the
spec.
A
The
only
issue
I've
seen
this
approach
is,
you
know,
going
back
to
the
pvc
and
pv.
We
can
see
this
too.
If
a
pv
is
being
used,
then
you
know
the
pv
protection
finalizer
goes
on
it
and
even
if
you
unbind
it
you
you
still
have
to
eventually
you
know
remove
that
finalizer
when
you,
when
you
delete
the
pvc,
so
it's
it's.
It's
like
two
things
to
do
instead
of
one
and
that
could
be,
you
know
a
point
where
a
lot
of
errors
happen.
B
C
B
E
B
B
B
The
bind
controller
should
say.
Oh,
this
is
not
a
request
for
a
new
par.
This
is
a
request
for
an
existing
one
and
I'm
just
going
to
bind
them,
and
the
security
mechanism
is
if
the
ba
is
named
in
an
unpredictable
way.
A
malicious
person
should
not
be
able
to
sneak
in
and
create
a
bar
and
bind
to
that
in
the
meantime,
because
they
would
never
know
what
name
to
use.
B
A
B
G
A
Fair
enough,
okay,
I
yeah.
I
think
this
is
great.
This
is
this
is
actually
simpler
and
easier
to
understand,
like
you
said,
predictable,
cumbersome,
yeah,
but
but
let's
see
how
many
people
need
it
and
then
we'll
go
from
there.
A
How
many
people
really
need
it?
Okay,
so
nicholas
had
a
question:
it's
pretty
basic
question:
do
we
need
a
plan
in
the
first
place?
Can't
we
say
we
don't
ever
intend
to
provide
functionality
for
this,
we
do
need
a
mechanism
to
share
buckets
object.
Storage
is
inherently
over
the
network,
so
it's
designed
to
be
used
by
multiple
accessors,
unlike
block
devices
and
and
file
systems
which
are
node
local.
A
Yeah
sure
nfs
has
its
own
problems,
though
yep
no
argument
there
yeah.
C
C
You're
talking
about
one
cross
namespace,
because
multiple
applications,
as
long
as
they
still
as
you
know
they
put
in
the
same
namespace,
could
be
able
to
access
the
storage.
Secondly,
if
there
is
really
a
need
to
consume
object,
storage
from
applications
that
sit
in
multiple
namespaces,
we
still
have
the
brownfield.
B
A
B
C
That
what
you're
saying
list
well,
what
I'm
basically
saying,
is
if
you
are
in
a
scenario
where
you
need
a
bucket
that
is
used
through
multiple
by
multiple
applications,
where
each
application
sits
in
a
different
name
space.
It's
like
a
different
user
alice
involved.
Then
why
can't
we
say:
okay,
if
you're
really
in
that
case,
create
a
bucket
using
the
standard,
aws
or
whatever
mechanism
to
create
a
new
bucket
and
treat
that
bucket
as
a
running
theme
focus
twice
once
in
alice's
namespace
and
once
it
involves
namespace.
A
B
I
mean
transferring
objects
between
namespaces,
is
generically,
useful
and
and
can
address
this
particular
use
case
of
two
users
want
to
be
able
to
create
buckets
and
share
them
like
we
don't
know
how
common
that
use
case
is.
But
if
someone
comes
to
us
and
says
that's
what
they
want
to
do,
we
can
tell
them
how
to
do
it.
It's
a
common
use
case.
A
B
I
think
the
the
important
difference
is,
if
you
use
the
brownfield
use
case,
which
yeah
you're,
nothing
stops
you
from
doing.
You
will
end
up
in
a
situation
where
both
users
can
create
bars
of
whatever
class
they
want
so
like
you
have
to.
That
has
to
be
what
you
intend
and,
and
similarly
neither
user
can
actually
delete
the
actual
bucket.
Their
br
is
only
a
handle
to
the
to
the
real
thing,
because,
presumably
both
of
them,
presumably
in
the
brownfield
use
case,
the
deletion
policy
is
always
set
to
retain
in.
B
Indeed,
oh
okay,
okay,
well,
that
too,
but
yeah
you're,
just
gonna
have
a
situation
where
anyone
can
create
a
bar
of
arbitrary
power
and-
and
if
that's,
if
that's
what
you
wanted,
then
sure
it'll
work.
I
mean,
I
think
we
want
to
give
users
a
tool
kit
where
they
can
slice
and
dice
it,
how
they
want
and
and
yeah
so
so
in
in
the
first
version,
assuming
we
don't
deliver
the
like
any
kind
of
transfer
controller
until
a
follow-on
version,
you'll
still
have
multiple
ways
to
to
to
skin
this
cat.