►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket Standup Meeting - 08 March 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
B
B
B
Sometime
sometime
in
the
next
few
weeks,
in
times
of
in
terms
of
deployment,
we've,
we've
got
all
the
different
components
deployable
using
a
customized
templates
and,
and
that
is
in
a
pretty
good
shape.
The
only
thing
that
we
need
to
work
on
there
is
having
a
different
deployment
step
for
a
sample
provisioner
and
the
site
car
right.
Now
they
both
deploy
as
one
and
and
that's
that's.
B
You
know,
that's
a
function
of
the
fact
that
you
know
we
want
to
run
those
two
as
two
containers
in
the
same
part,
even
though
technically
it
doesn't
have
to
be,
you
know,
things
can
be
over
the
network
and
the
grpc
calls
will
just
work
fine,
but
that's
just
how
it
is
today.
So
so
that's
one
tiny
change
that
needs
to
go
into
the
deployment
of
the
site
car
and
then
we
should
be
good
to
go
in
terms
of
testing
end-to-end
tests.
Other
things
are
one
of
the
things.
B
That's
missing
that
on
the
major
things
that's
missing,
but
otherwise
we're
in
a
good
shape.
We
have
unit
tests,
we
have
functional
tests,
you
know
marked
out
clients
and-
and
you
know,
tests
of
different
functions
of
all
the
three
components-
we're
also
well
underway
with
the
documentation
effort.
We
have
decent
docs
right
now,
which
talks
about
what
the
different
projects
are
for,
how
they
integrate,
and
then
there's
still
more
to
do
on
that.
C
B
D
B
C
B
B
Now,
let's
actually
get
into
oh,
no,
let's
actually
go
back
and
talk
about
where
we
continue
where
we
left
off
last
week,
so
where
we
left
off
last
week,
we
were
looking
at
the
at
the
api
repo.
We
were
talking
about
what
fields
should
be
left
in
there.
What
fields
can
be
removed,
and
one
of
the
things
we
agreed
on
was
that
we
can.
B
Given
that
you
know
every
every
different
provider
like
s3,
azure
and
gcs,
every
one
of
them
can
can
represent
the
api
in
their
own
way,
so
it
makes
more
sense
to
have
a
version,
that's
specific,
to
a
provider
inside
of
the
provider
specific
struct,
so
so
that
was,
that
was
one
of
the
things
we
decided
on
and
then
we
were
so.
I
have.
B
E
B
E
Because
it's
the
spec
of
the
bucket
object,
not
the
bucket
request,
it
would
be
weird
if
we
were
putting
if
we
were
modifying
the
spec
of
the
bucket
request
other
than
maybe
to
perform
the
two-way
binding.
I
mean
we
do
this
with
pvcs
and
it's
it's
weird
there,
but,
but
because
we
are
creating
the
bucket
in
response
to
the
bucket
request,
we
wouldn't
well.
Let
me
think
about
this.
No,
we
do
create
the
object
first
and
then
the
sidecar
modifies
it
and
and
yeah.
E
E
They
they
don't,
I
think
the
key
is
they
don't
have
to
right
if,
if
they
want
to,
they
can
specify
something
in
the
bucket
class,
which
would
perform
a
hint
or
a
filter
or
recommendation
or
whatever
to
the
plugin.
But
if
the
plug-in,
if
they
don't
care,
the
plug-ins
should
pick
one
and
tell
you
where,
to
put
it.
B
E
E
When
you
invoke
the
sidecar,
where
the
sidecar
calls
the
controller,
it
will
go,
read
the
bucket
class
and
obtain
whatever
region
parameters
or
whatever
was
in
the
bucket
class
and
pass
those
in
at
the
time
that
invokes
the
plug-in
and
then
whatever
the
plug-in
returns.
That's
what
you
stamp
onto
the
bucket
object,
but
the
initial.
B
E
E
B
E
D
B
E
So
so
what
it
needs
to
be
now
is
it
needs
to
look
at
s3
protocol
and
azure
protocol
and
gcs
protocol
and
make
sure
that
only
one
of
them
is
non-now
or
zero.
It's
okay
for
all
of
them
to
be
nil,
if
it's
not
set
yet
well.
Maybe
the
protocol
itself
is
nil
in
that
case.
So
then
you
would
always
expect
exactly
one
to
be
set.
D
C
B
Yeah
yeah,
I
mean
yeah.
I
think
it's
too
much
work
to
actually
add
that
validator
right
now
like
we
could
do
something
with
struck
tags.
But
again
I
don't
know
if
it's
worth
it,
it's
not
worth
it
all
right.
So
so,
let's,
let's
go
to
the
topic
we
finally
left
off
last
week
and
so
ben
I
sent
you
some
links
to
the
proposal
for
network
gateway.
Did
you
did
you
get
a
chance
to
look
at
them.
E
B
E
I
was
going
to
say,
the
feedback
from
tim
was
a
little
bit
more
complicated
than
that.
It
wasn't
only
about
mutation.
It
was
about
this
whole
concept
of
doing
the
namespace
object
bound
to
the
non-namespace
object
right,
which
was
something
that
he
didn't
like,
especially
when
it
comes
to.
Even
if
we
don't
allow
mutation,
the
the
mirror
sharing
across
name
spaces
gets
funky,
and
I
thought
that
was.
I
felt
like
that's
what
he
was
objecting
to
more
than
the.
How
do
you
do
mutation
right.
B
B
Yeah
you're
right
so
so
we
we
were
exploring
this
other
approach.
Where
you
know
we
said
it,
you
know
we
just
wanted
to
explore
it.
We
don't
think
it's
you
know
unless
it
makes
a
huge
difference
to
in
terms
of
benefits.
You
know
we
we
said
that
you
know
it
might
not
be.
You
know
we
need
to
justify
justify
the
effort
that
it's
going
to
take,
because
if
we
do
go
down
that
route,
everything
else
has
to
be
reinvented.
B
They
might
have
their
own
rules
that
the
infrastructure
team
would
wouldn't
necessarily
know,
and
in
that
case
the
way
network
gateway.
If
I
understand
correctly,
the
way
it
is
designed
is
you
have
the
concept
of
say
just
like
roll
bindings
and
cluster
roll
bindings,
you
have
namespace
objects
and
you
have
non-namespaced
objects.
B
They
both
behave
symmetrically.
What
that
means
is
the
namespace
object
binds
to
the
namespace
version
of
so
so
a
name
says
bucket
request
would
bind
to
a
namespace
bucket
and
similarly,
a
non-namespace
bucket
request
would
bind
to
a
non-namespace
bucket,
and
then
this
is
the.
This
is
the
approach
that
that
tim
or
I
understood
from
what
tim
suggested,
and
we
were
just
beginning
the
exercise
of.
If
how
that
would
work,
and
if
that
that
would
work
for
us.
A
B
B
B
B
That
is,
if
I
create
a
bucket
in
one
namespace
and
say
I
want
to
bring
that
bucket
to
or
have
that
bucket
be
available
in
this
different
name.
Space
you'll
have
to
share
the
bucket
in
case
of
network
gateways.
If
I
you
know,
there's
there's
no
concept
of
sharing.
You
can
have
two
different
network
gateways
in
each
in
their
own
namespaces
and
have
them
be
exactly
the
same
set
of
rules
but
they're
still
not
the
same.
There's
no
sharing
involved
in
there,
which
is
which
is
unlike
buckets.
B
E
Yeah
and
the
other,
the
other
use
case
that
we
can
use
as
a
comparison,
is
what
we
did
with
volume
snapshots
where
we
did
go
down.
This
path
of
a
namespace
object
bound
to
a
non-namespaced
object
and
if
you
wanted
to
share
it
across
namespaces,
currently
the
only
way
to
do
that
is
to
make
a
copy
of
the
volume
snapshot
and
the
volume
snapshot,
content
and
and
bind
them
and
that's
how
it
works
today.
A
A
A
Okay,
so
if
you
look
at
here
right
here,
some
examples,
this
is
still
a
namespace
right.
It's
not
really
like
cluster
space
right,
so
this
gateway.
If
you
look
at
the
one
on
the
left
shared,
but
this
still
has
a
namespace
so
meaning
it
is
still
it's
not
like
the
class.
It
also
has
a
gateway
class
which
it
says,
that's
a
cluster
scope,
but
it
says,
but
it
didn't
say,
gateway
is
also
like
a
classic
scope.
A
B
D
A
A
Oh
okay,
interesting.
It
also
talks
about
manage
one
all
right,
so
he
shows
a
one
too
many
and
one
to
one,
but
it
says:
there's
also
many
one.
What
how
does
that
work?
Oh,
okay!
So
basically
that's
the
route
like
this.
It
can
also
point
to
some
other
okay.
Okay,
I
see
all
right,
it's
kind
of
messy,
okay,
yeah,
it's
pretty
complicated.
It
says
it
has
like
yeah
this.
It
can
also
this
route
can
also
go
here.
It
can
also
it
can
also
be
you
know,
going
this
way
as
well,
yeah,
so
yeah.
B
So
three,
if
a
bucket
is
in
a
different
name
space,
then
an
asp
is
using
it.
I
mean
we
had
this
conversation.
We
said
buckets
have
to
be
cluster
scope
because
we'll
have
no
control
over
buckets
from
a
different
name.
Is
we
won't
even
know
if
it's
still
alive
or
just
usable-
and
you
know
discovery
is
also
not
easy?
A
A
B
G
Yes,
yeah,
okay!
Well,
I
made
I
haven't,
read
this
shing,
but
but
we,
but
maybe
this
is
interesting.
We
did
for
a
little
bit
consider
that
a
bucket
could
live
in
the
provisioner's
namespace.
You
know,
provisioners
are
namespaced
and
that's
where
the
the
plug-in
and
sidecar
run
and
a
b
a
bucket
instance
could
be
namespaced
and
it
the
namespace
is
the
same
namespace
as
the
provisioner,
but
we
for
simplicity
and
and
possibly
to
mimic
the
pv
pvc
model
more
closely
and
and
possibly
related
to
easier
sharing.
G
E
E
B
D
G
G
Yeah-
okay,
great
thanks
good
to
know,
okay,
so
on
the
this
is
just
an
idea
of
trying
to
get.
I
was
just
thinking
a
little
bit
of
how
to
get
rid
of
cloning
and
and
make
it
a
little
simpler
for
the
admin
and
and
maybe
a
more
accurate
abstraction
of
a
a
of
a
bucket
instance
mapping
to
a
single
back
end
bucket,
in
other
words,
not
many
bucket
instances,
mapping
to
the
same
back
in
bucket,
but
just
one
kubernetes
bucket
instance,
mapping
to
the
back
end
bucket.
G
So
those
were
my
thoughts
on
the
left.
Side
of
this
diagram
is
what
we
have
today.
Essentially
within
the
same
name,
space
multiple
bars
can
point
to
a
single
br.
You
get
multiple
bas
as
a
result
of
those
multiple
bars
and
they
point
to
a
bucket
and
okay.
So
that's
today,
but
one,
but
today,
when
you
try
to
say
bar-3
in
namespace
2,
then
it
gets
complicated.
G
G
G
So
so
in
namespace
2,
you
don't
need
a
br
anymore,
because
you're
just
sharing
you're
not
requesting
anything
new,
and
you
still
have
the
comp
complexity
of
the
admin
having
to
tell
a
user
what
the
name
of
the
b
is,
but
but
in
today's
kept,
the
admin
has
to
tell
the
the
br
author,
the
name
of
the
b
that
hasn't
really
changed.
Instead
of
the
name
of
the
b
being
in
a
br
for
brownfield,
the
name
of
the
b
is
in
the
bar,
the
the
communication.
G
E
G
B
B
E
Right,
well
it
it
can
always
be
pulled
out
from
underneath,
because
somebody
can
always
just
go
to
the
back
end
and
and
delete
it.
The
the
point
is:
there's
an
orderly
way
of
doing
it
and
and
there's
an
orderly
way
of
avoiding
it
when
you
want
to
avoid
it
and
what
I'm
trying
to
figure
out
here
is
clearly.
If
you
want
it
to
go
away,
you
just
delete
it
no
big
deal,
but
if
you
want
to
not
go
away,
how
do
you
make
sure
that
that
happens.
E
G
B
So
so
this
is
really
yeah,
I'm
thinking
through
all
the
different
trade-offs
yeah.
We
do
have
that
benefit
of
never
having
to
copy,
and
I
really
like
that
to
be
honest,
so
so
bar
one
would
point
to
ba
one.
How
would
that
work
like?
What
would
the
user
experience
be?
Like
say,
a
user
wants
to
create
a
bucket
and
utilize.
It.
B
G
B
All
right,
how
does
the
ba1
and
ba2
get
created
in
the
oh
yeah?
That's
that's
the
usual
thing:
yeah!
That's
the
name!
Yeah
yeah!
That's
true!
All
right!
That's
yeah
yeah!
This
is
why
I
like
this
proposal
last
time.
Also
you
brought
it
up.
There
was
some
issue,
though,
that
we
had
I'm
trying
to
remember
what
there
was,
or
maybe
I
explained
it
wrong
last
time.
Maybe
that's
what
they
show
us
is
that
right.
G
E
G
I
think
so
ben
I
mean
it's
a
good
question,
but
I
believe
that
bucket
one
as
long
as
ba
three,
so
let's
say
you
get
rid
of
the
whole
left
side
of
that
picture.
Right,
yeah
and
all
that's
left
is
namespace
two
bucket
one
and
ba
three
right
and
and
and
the
you
know,
so,
there's
still
a
link
between
ba3
and
bucket
one
right.
E
E
B
E
E
E
H
E
G
E
Well,
if
I
have
a
bucket
class
that
sets
it
to
delete
and
then
I
create
the
bucket
presuming
the
normal
green
field,
workflow
and
then
I
change
my
mind
and
say
wait.
I
actually
want
to
keep
this
one
around
for
a
long
time,
because
I've
shoved
a
bunch
of
really
important
data
in
it
yeah.
I
can
go
change
that
that
deletion
policy
to
retain
and
then
delete
my
br
and
then
the
cozy
controller
will
just
let
the
br
go
and
leave
b1
dangling
right
like
yes,
just
like.
I
E
A
A
E
B
H
B
E
Right
right
that
that
is
how
pvs
work,
but
that's
not
what
we
want
here
right.
If
you
retain
it,
you
don't
want
the
bucket
to
go
away,
you
need
it
to
hang
around.
So
I
was
thinking
about
our
model
would
be
the
snapshot.
Model
snapshots
also
have
deletion
policies
and
they're
on
the
non-namespace
volume,
snapshot,
content,
object
and,
and
the
way
I
think
it
works
is
if
you
set
the
deletion
policy
to
retain
and
then
go
delete
your
snapshot.
The
namespace
snapshot
goes
away
and
the
unnamed
space
volume
snapshot
content
just
sits
there
and
nothing.
A
A
A
A
E
A
A
A
E
It
just
feels
a
little
bit
less
self-service
because
I
guess
every
bar
you
create.
You
have
to
know
the
name
of
the
non-namespaced
object
in
the
old
model.
You
would
be
a
one-time
operation
to
create
a
br
in
the
in
the
other
name
space,
and
then
all
the
other
objects
in
the
namespace
would
just
refer
to
that.
So
once
the
initial
object
had
been
created
in
the
other
name
space,
you
wouldn't
you
wouldn't
need
to
know
anything
special.
G
E
So
so
so
the
only
grossness
of
this
introduces
into
the
design
is
now
bars,
combined
to
two
different
things:
well,
they're,
just
granting
access
to
a
bucket
yeah.
I'm
not
saying
like
this
is
a
big
problem.
I'm
just
saying
like
it's,
it's
a
it's
additional
complexity
that
we
wasn't
in
the
original
design.
Originally
bir
is
always
binded
to
brs,
and
so
you
just
have
one
field.
You
know
what
it
is.
Validation
is
easy.
Now
we're
going
to
have
two
fields
and
validation
is
going
to
be
a
little
bit
more
complicated.
E
Right
and
presumably
you
actually
have
like
a
bucket
request
field
and
a
bucket
field,
and
only
one
of
them
can
be
filled
in
right
and
then
so.
The
validation
has
to
enforce
that.
And
then
assuming
you
have
an
additional
level
of
validation
that
make
sure
that
the
thing
that
you
point
to
is
actually
there.
You
gotta
go,
look
in
the
appropriate
place
and
and.
G
E
Yeah,
no,
I
I
there's
a
lot
to
like
here.
I
I'm
still
wondering
like
can,
can
another
namespace
adopt
the
bucket
in
such
like,
like
let's
say
we
implemented
mutability
at
some
point
in
the
future,
where
you
could
make
changes
to
br1.
That
would
result
in
b1
also
changing
and
the
sidecar
doing
some
work
to
enforce
the
change
like
then.
G
E
E
G
E
No,
I'm
saying
it's
okay,
if
zero
things
point
to
it,
but
if,
if
I
want
to
make
something
point
to
it,
so
that
a
user
can
mutate
it
or
do
all
whatever
else
you
want
to
be
able
to
do,
it
should
be
okay
to
have
exactly
one
thing
pointing
to
it.
We
just
wouldn't
allow
two
or
three
or
four
things
to
point
to
it's:
zero
or
one.
G
I
see
and
the
reason
you're
liking
the
idea
of
always
having
a
br
point
to
bucket.
One
in
this
diagram
is
for
the
eventuality
of
mutation
that
you
think
we'd
be
doing
mutation,
a
user
could
mutate
for
self-service.
A
user
would
mutate
something
in
br,
something
that's
not
there
now,
but
something
added
to
a
br
later
on
a
user
would
mutate
that
and
it
would
be
reflected
in
bucket
one.
Is
that
what
you're
thinking.
E
E
Why
not
give
him
the
ability
to
do
self-service
deletion?
If
I'm
not
saying
like,
we
should
bend
over
backwards
for
this
use
case,
I'm
just
trying
to
think
through.
Can
we
is
it
possible
to
just
construct
an
object
and
force
it
to
bind
in
such
a
way
that
now
namespace
2
owns
the
bucket
and
has
the
only
br
that
points
to
it.
E
G
E
It
I
I
don't
know
yeah
yeah.
No,
it
would
you
would
have
a
race,
since
one
guy
would
win
the
race
and
one
guy
would
lose
the
race,
which
is
how
it
works.
With
pvcs
right,
two
pvcs
can
race
to
bind
to
a
pv
and
whoever
wins
gets
it,
and
that's
fine
so
and
then,
and
if
there's
a
true
conflict,
an
admin
can
step
in
and
clean
up
the
mess
right.
E
E
Unless
we
wanted
that's
a
possibility,
unless
maybe
you
wanted
to
have
a
way
to
disable
that
and
say
this
is
an
unbindable
bucket
for
because
for
security
reasons
you
know
you
might
want
to
be
able
to
create
a
bucket
in
such
a
way
that
no
br
can
ever
bind
to
it.
For,
for
a
true
brownfield
kind
of
a
use
case
where
you,
you
really
don't
want
anyone
to
be
able
to
delete
it
through
kubernetes
or
mutate
it
through
kubernetes.
G
G
E
E
G
G
Right,
well,
it
doesn't
have
to
be,
I
mean,
that's
pretty
similar
to
linux
file
deletion
right.
You
know
you,
you
you,
the
file,
the
inode
goes
away,
but
the
file's
still
there
until
the
last
accessor
closes
it,
and
then
the
file
goes
away.
So
that
is
not
so.
This
is
that
that's
one
of
the
worst
decisions
people
ever
made
like.
E
Well,
if
you
think
about
it,
if,
if
what
we're
saying
is
like
the
existence
of
a
bar
keeps
the
bucket
alive,
then
what
that
implies
is,
after
everything
is
gone,
except
for
the
last
bar.
The
deletion
of
a
bar
causes
a
bucket
to
go
away,
and
that
would
be
very
surprising
to
a
user,
I
think
to
say.
Oh,
I
deleted
my
bar
and
the
bucket
poofed,
because
nobody
would
expect
that.
E
G
G
E
E
E
G
G
E
B
Why
can't
we
always
make
that
the
default
like,
like
you
know,
you're,
saying,
like
there's
a
force,
delete
versus
normal
delete
yeah
in
case
of
a
force,
delete
you,
you
don't
care
if
someone's
using
it
in
case
of
normal,
delete
you
do
yes,
I
mean.
If
someone
wants
to
really
force
the
lead
they
can
they.
You
know
we
could
we
could
you
know
they
just
go
and
admin
can
just
go
and
remove
the
finalizer
or
something-
and
we
always
just
you
know-
do
a
normal
delete.
E
B
C
E
E
G
And
then
that
name's
keeping
your
name
space
hostage,
like
you
said
you
don't
have
control
over
it.
As
the
br
author
anyway,
you've
you
got
retention
policy
through
your
bucket
class
that
was
created
by
an
admin.
So
unless
you
have
a
bucket
class
that
gives
you
the
delete,
the
retention
policy,
you
want
the
user
really
doesn't
have
say
on
the
bucket's
retention.