►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 17 December 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
A
A
So
I'm
going
to
click
on
demo
on
milestone,
so
we
have
to
process
bucket
access
request,
delete
for
the
demo.
We
did
not
need.
We
did
not
say
we
will
do
delete
of
a
bucket
access
request
or
a
bucket
access.
However,
this
is
low
hanging
and
also
it's
a
it's
a
place
where
new
people
get
started
if
they
would
like
and
and
similar
to
that
updates
for
bucket
requests.
B
C
B
A
A
Okay,
yeah,
because
your
handle
is
different
here
from
slack.
That's
why
okay,
so
another
thing
is
bucket
request,
delete
which
is
similar
to
bucket
access
request,
delete
again,
it's
not
needed
specifically
for
demo
one,
but
it
would
be
it's
low
hanging
and
it
can
be
quickly
implemented
so
srini.
Another
question:
doesn't
the
bucket
request
delete
actually
follows
the
same.
B
A
B
I'm
sorry
when
we
started
with
working
on
the
finalizers
I
just
wanted
to
update
the
community.
We
did
not
had
a
whole
well,
we
had
to
discuss
the
whole
picture,
so
I
I
created
these
these
issues
so
that
we
start
working
on
the
delete
aspect
of
it
and
then
I
realized
okay.
If
we
have
the
finalizers
on
bar
and
br,
we
just
need
to
process
them
and
we
don't
really
need
the
dealing
and
then
we
also
were
planning
to
have
the
finalizers
and
other
objects
right.
So
that's
the
whole
reason.
A
Yeah
yeah,
we
were
implementing
this
and
I
believe
there
was
an
issue
that
was
raised
so
the
the
I
think
this
you
know
we've
addressed
this
before
it
just
had
to
be
discussed
again.
The
issue
was:
how
do
we
process
a
bucket
request,
delete
if
the
corresponding
bucket
is
still
in
use
currently
in
used
by
a
part-
and
we
already
discussed
this
before-
which
is
we
have
a
finalizer
on
the
bucket
request
for
the
bucket
on
the
bucket
itself?
A
B
A
He
has
a
conflict
this
at
this
time.
Okay,
so
the
rob
is
an
admin
at
red
hat
and
he
has
a
lot
of
experience
using
object,
storage,
provisioning
it
for
the
developers
and
customers
of
red
hat,
and
he
brought
up
a
good
issue.
What
if
there
was
a
scenario
where
the
admin
had
to
revoke
access
for
a
particular
bucket
without
pulling
the
part
down,
so,
for
instance,
you
can
have
you
can
have
a
pod
using
multiple
buckets
and
you
might
want
to
remove
access
just
for
one
of
them.
A
So
so
we
did
come
up
with
the
working
solution
for
this
but
yeah,
but
I
hope
I
wish
rob
was
here
to
also
explain
the
the
admin
side
of
things
better.
So
so,
in
a
case,
so
first,
the
simple
scenario
of
of
revoking
access
is:
if
a
bucket
access
request
is
deleted.
Let
me
go
back
to
the
type
that'll
be
easier.
A
If
a
bucket
access
request
is
deleted,
then
we
trigger
the
deletion
of
the
bucket
access.
If
a
bucket
access
is
currently
in
use
by
a
pod,
then
it
doesn't
go
away
because
there's
a
finalizer
and
once
the
pods
go
away,
the
node
agent
is
going
to
take
the
finalizer
out
and
then
this
can
be
deleted
when
the
finalizer
is
taken
out.
A
A
A
Okay,
so
so
yeah,
so
a
bucket
access
gets
cleaned
up
on
the
simple
use
case,
where
a
bucket
access
request
is
deleted
and
a
bucket
access
corresponding
bucket
access
gets
deleted
once
the
pod
stopped
using
it
now.
What
if
you
want
to
rework
access
while
a
bucket
access
is
in
use?
That
is
a
part,
is
using
it
at
that
point.
A
So
for
that
what
we
decided
long
back
as
well
was
if
the
user
deletes
a
bar
bucket
access
request,
then
we
wait
for
the
parts
to
die
before
bucket
tax
is
removed,
but
if
an
admin
deletes
the
bucket
access
directly,
that
is,
if
a
delete,
if
the
deletion
timestamp
is
set
for
the
bucket
access,
but
the
corresponding
bucket
access
request
is
not
been
deleted.
There's
no
deletion
timestamp
on
that,
then
we
know
it's
a
force
removal
and
at
that
point
we
go
ahead
and
revoke
the
credentials
alone.
E
Spec
sid,
I
have
a
question
on
that,
but
maybe
this
is
too
lower
in
the
code,
but
the
only
trigger
would
need
to
be.
The
change
would
be
the
deletion
of
the
ba,
because
that
would
result
either
a
force
delete
by
the
admin
or
as
a
natural
consequence
of
the
user,
deleting
the
var
it
gets
deleted.
So
do
you
need
to
do
you
need
to
have
special
code
to
handle
them
as
two
different
cases
yeah,
so.
D
So
I
think
one
drawback
to
this
approach
is
this
idea
that
you
can't
really
enforce
order
in
kubernetes,
especially
in
the
creation
and
deletion
of
objects,
and
so
you
can
imagine
if
finalizer's
finalizers
enforce
right
right
without
finalizers.
I
guess
is
my
point
and
in
this
case,
if
you
you
know,
imagine
that
somebody
manually
created
a
bucket
access
and
bucket
access
request
in
a
single
yaml
file,
and
then
they
went
and
deleted
that
yaml
file,
the
order
of
deletion
would
not
be
necessarily
guaranteed.
D
H
G
To
tell
the
system
like
I
don't
care
what
the
user
is
doing.
I
want.
I
want
this
gone
yeah,
but
but
under
normal
circumstances,
if
the
user
deleted
a
bucket
access
request,
while
the
pod
was
still
there,
the
bucket
access
request
would
hang
around
until
the
pod
cleaned
up
and
then
correct,
and
then
I
like
both
of
those
behaviors
that
makes
sense
to
me.
D
G
Anyone
with
the
appropriate
or
baggy
game-
oh
sorry,
go
ahead
ben.
Anyone
with
the
appropriate
our
back
access
to
delete
that
object
right
would
typically
be
an
admin
or
some
controller
that
the
admin
had
granted
access
to
and-
and
I
can
imagine
you
know-
various
controllers
coming
in
and
helping
people
do
these
things.
A
If
that's
universally
good,
but
I
think
in
this
case
I
think
we
we
do
have
enough
of
fail
safes
and
and
if,
if
it's
used
the
way
we
intend
it
to
be
used,
which
is
which
is
a
loaded
statement.
I
would
say,
but
if
if
the
system
is
used,
where
our
back
roles
are
not
given
for
all
bucket
resources
to
just
about
anyone.
D
D
A
A
I
D
A
G
G
J
G
J
G
D
A
D
A
G
G
G
G
I'm
saying
like
the
in
kubernetes
the
whenever
anything
goes
wrong.
Your
first
recourse
is
just
delete
the
pod
right,
because
then,
if
you
ever,
if
you
have
a
replica
set,
it'll
just
make
a
new
one
and
it'll
get
rescheduled
and
all
your
problems
will
be
solved
for
not
all
of
them,
but
a
large
class
of
problems
is
solved
by
just
deleting
your
pod
and
letting
the
replicas
that
do
its
thing,
and
so
this
is
a
case
where
that
remedy
applies,
who
uses
replica
sets
anymore?
G
A
Replica
group-
maybe
I
forgot
there-
was
something
else
anyway.
So
so
what's
the
conclusion
here?
How
do
you
want
to
move
forward?
I
think
it
sounds
like
we,
the
design
that
I
just
described
before
we
got
into
the
discussion
about
how
we
deal
with
the
revoked
credentials
where,
if
a
credential
is
revoked,
then
we
expect
the
user
or
admin
to
go
ahead
and
restart
the
product.
A
A
Okay,
so
now
getting
into
customize,
so
we
were
adding
a
customized
template,
a
customize
spec
that
would
that
would
allow
us
to
deploy
all
of
the
object,
storage
components
in
in
one
shot.
Now,
to
do
that,
you
know
we
got
started
with
customize
and
I
just
want
to
track
the
progress
of
what's
going
on
here.
I
believe
stages
on
the
call
tejas
is
working
on
a
part
of
it
yeah.
This
is,
I
did
this.
A
C
A
A
B
M
B
B
A
A
D
C
A
C
C
C
C
A
So
so,
to
summarize
what
chris
is
saying,
so
this
goes
back
to
the
old
bucket
access
request,
delete
and
bucket
request
delete.
We
talked
about
how
we
wait
for
pods
to
die
before
we,
you
know,
delete
it
in
some
cases,
he's
talking
about
how
we
know
if
a
pot
is
died
so
for
every
part
that
uses
the
bucket,
we
add
a
finalizer
for,
for
every
instance
of
the
part
we
add
a
finalizer
into
the
bucket
axis
and
the
the
the
value
of
the
finalizer.
A
The
string
is
going
to
be
the
the
pod
id
or
oh,
the
volume
id
that
is
the
unique
pvc
id
that
the
pod
uses,
that
instance
of
the
part
uses
and
when
the
part
dies
there
is
no
run
stage.
Volume
is
called
in
the
same
by
the
csi
driver.
Then
we
go
ahead
and
remove
that
finalizer.
For
that
part
from
bucket
access,
that's
how
we
know
if
a
pod
is
using
a
bucket
access
or
not.
L
A
A
A
The
final
focus
that
I
want
to
bring
up
in
terms
of
tasks
in
the
project
is
documentation.
I
want
to
first
of
all
thank
summers.
They've
added
a
whole
bunch
of
pull
requests
regarding
documentation
there.
There
was
an
issue
I
think
that
was
brought
up
with
one
of
the
tables
and
I
believe
they've
also
addressed
that
issue.
I
need
to
follow
up
on
that.
I
haven't
yet
done
that.
Okay,
that's
the
one.
A
A
Can
be
easily
answered
with
documentation
and
also
it
will
it
will
help
ensure
consistency
in
in
our
design,
thinking
where
we
don't
have
to
revisit
how,
for
instance,
finalize
this
work
in
respect
to
this.
So
so,
if
there's
anyone
available
to
help
with
the
documentation
effort,
so
summers
is
obviously
helping
quite
a
bit.
Others
are
also
encouraged
to
help
get
this
out
of
the
way,
basically
just
early,
simple
documentation
that
talks
about
key
parts
of
the
design
so
other
than
the
readme.md.
A
We
want
to
document
how
bucket
creation
works.
Access
creation
works
just
minor
details
about
the
grpc
spec,
and
I
say
that
minor
details
right
now,
because
the
grpc
spec
will
evolve.
There
will
be
changes
requested,
possibly
from
the
api
review
or
as
we
write
more
code,
so
we
don't
have
to
go
heavy
on
that's
that
front.
Similarly,
some
documentation
about
the
api
is
needed.
A
K
A
Spec,
I'm
I'm
okay
with
that.
I
want
some
input
from
the
csi
people
here.
So
assad
is
maintaining
this
container
storage
interface
spec.
This
one
just
has
the
specification
for
the
grpc
api.
However,
this
might
as
well
be
extended
to
do
both.
Do
you
have
any
thoughts
on
this
or
do?
Can
you
tell
us
why
only
the
documentation
for
spec,
the
grpc
spec
is
here
and
the
rest
of
the
documentation
is
in
the
github,
the
what
was
the
other
other
than
the
grpc
spec?
D
Yeah,
so
the
spec
itself
is
self
documenting
what
each
individual
operation
does,
and
this
page
that
you're
looking
at
is
kind
of
kubernetes
developers
of
csi
drivers.
Right.
If
you
look
at
the
specification
alone,
it's
it
tells
you
about
all
the
different
csi
specific
calls,
but
it
doesn't
really
tell
you:
how
do
you
take
a
driver
package
it
deploy
it
on
kubernetes
and-
and
so
this
this
page
is
like
the
end-to-end
developer,
csi,
developer,
documentation
and
so
the
way
that
we
looked
at
it
was.
D
You
know
we
want
to
have
a
standalone
place
where
a
csi
developer
can
come
and
find
out
everything
that
they
need
to
know
which
is
this
website,
and
then
we
have
end
user
facing
documentation
on
the
kubernetes.io
page,
which
basically
just
says
you
know,
use
this
csi
volume
type.
If
you
want
to
use
it
and
for
details,
go
to
your
storage
vendor
for
details
on
how
to
deploy
a
csi
driver,
and
then
the
storage
vendors
come
here
to
figure
out
how
to
create
their
drivers.
Yeah.
A
Feature
yeah
right
right,
okay,
that
sounds
good.
I
think
we
can
follow
almost
a
similar
model
here,
maybe
because
we
we
we've
seen
how
csi
has
done
it.
We
can
even
do
some
improvements
on
top
of
it.
I
think
our
main
priority
right
now
is
one
getting
onboarding
developers,
so
some
sort
of
documentation
about
just
I
mean
even
an
architecture
diagram-
would
help
like
something.
A
A
A
A
Just
a
little
bit
of
forethought
in
planning
can
avoid
that.
I
think
we
can
get
started
on
a
very
basic
website
right
now.
It
can
just
be
an
empty
website.
It's
a
github
website,
so
it's
a
markdown
repository
really
just
with
markdown
files
that
that
just
goes
over
an
introduction
which
has
a
diagram
that
says
what
it
is
and
maybe
something
like
a
grpc
spec
and
in
the
future.
We'll
add
a
line
item
for
writing.
Your
own
drivers.
A
A
A
You
know
I'm
working
on
cozy
today
and
he
gets
confused
and
then
I
have
to
go
back
and
explain
to
him,
contain
object,
storage,
interface
and
so
on
and
so
forth
and
same
thing.
When
I
talk
to
customers,
you
know
when
I
use
the
word
cosy.
There's
this.
It
brings
about
a
strong
reaction,
no
doubt,
but
I
wouldn't
say
it's
necessarily
something
that
makes
us
look
the
best.
A
Storage
is
going
to
be
just
as
big
as
csi,
simply
because
of
the
scale
issue.
That
file
and
block
today
cannot
solve.
Maybe
it'll
solve
in
the
future,
so
so,
and
kubernetes
is
the
forefront
of
any
kind
of
standard
or
any
kind
of
common
interface
that
we
come
up
with
for
different
vendors.
What
kubernetes
defines
ends
up
being
the
new
standard
I
mean
oci
is
a
very
good
example
of
that
docker
dominated
that
space,
and
you
know
the
cto
of
core
os
came
up
with
this.
A
A
I
believe
what
we
do
are.
The
work
we
do
is
is
very
important
for
the
future
and
we
should
have
an
acronym
that
sounds
simple,
like
csi
or
oci,
that
doesn't
mention
kubernetes
right
it.
It
doesn't
have
to
mention
kubernetes,
because
ben.
I
think
you
brought
it
up
and
I
think
it's
a
very
good
point,
which
is:
it
is
completely
possible
that
people
use
the
grpc
spec
without
anything
to
do
with
kubernetes
and
and
integrate
with
the
grpc
spec
to
provision
object,
storage
across
different
vendors.
G
I
E
G
G
A
D
A
It
really
does,
but
it
doesn't
collide
with
anything
in
the
kubernetes
world
and
also
if
you're
gonna
get
a
good
good
acronym
like
osi.
It's
definitely
going
to
collide
with
something
just
as
long
as
it's
not
something
current.
It's
not
something.
That's
already
there
in
the
same
space,
it
should
be
fine.
A
J
A
G
I
G
G
A
G
I
I
just
I
don't.
I
don't
see
the.
I
don't
share
your
objections
to
to
having
this
the
c
I
mean
if
it's
the
pronunciation
like
you
could
call
it
cosi
or
something
you
could
just
change
it.
In
fact,
when
I
was
a
kid
there
was
a
museum
in
my
hometown
of
columbus,
ohio
called
c-o-s-I
and
everyone
called
it
cosi,
and
so
the
first
time
I
saw
a
c-o-s-I.
I
was
like
oh
it's
cosi
and
then
people
started
saying
cozy
and
I
was
like.
Why
are
you
saying
it
that
way?
G
I
was
used
to
the
other
pronunciation,
but
I've
gotten
used
to
this
one.
I
don't
know.
I
think
pronunciation
is
a
solvable
problem,
especially
as
it
becomes
better
known
by
whatever
name
we
do
choose.
People
will
just
take
it
on
board.
Just
like
I
mean
csi
was
weird
to
people
when
it
was
new
and
then
once
everyone
had
read,
18
blog
articles
about
csi
like
oh
okay,
I
know
what
that
is.
A
D
A
A
D
The
big
difference
with
csi
was
that
we
wanted
it
to
be
compatible
beyond
kubernetes
with
other
orchestration
systems
as
well.
Kubernetes
wasn't
kind
of
the
de
facto
orchestration
system
back
then,
and
so
mesos
wanted
to
implement
it
and
others
as
well.
So
that's
why
there
is
no
mention
of
kubernetes
at
all
in
the
csi
spec
and
it
stands
alone
as
a
separate
repo
for
cozy.
I
don't
believe,
there's
any
intention
to
adopt
it
beyond
kubernetes
so
yeah.
I
don't
think
that
would
be
problematic
in
my
head.
J
J
A
A
Again,
we
are
when
we're
building
this
for
kubernetes.
That's
what
we're
really
doing.
We're
saying
it's
open
for
others
to
use
we're
not
we'll
even
support
them
to
do
it,
but
the
name
is
not
going
to
be
something:
that's
holding
them
back.
They'll
just
use
they'll
just
call
this
the
spec
for
kubernetes
osi.
A
B
G
B
G
J
A
D
H
I
like
either
of
those
and
and
part
of
the
reason
for
my
preference
is
I
like
drawing
our
lineage
back
to
the
csi,
because
there's
a
lot
of
you
know
inspiration
that
we're
taking
from
csi
in
the
design
and
the
architecture,
and
I
think
some
of
the
success
shine
from
csi
will
get
onto
to
cosi
or
cosi,
whichever
and-
and
I
think
that's
a
a
very
big
benefit,
as
opposed
to
like
service
catalog
that
you
know
really
really
didn't
have
that
going
for
it.
You
know
service.
A
A
A
H
H
H
A
Developers,
yes,
like
sadha's,
mentioning
branding
is
difficult
or
it's
tricky,
I'm
looking
at
it.
Also,
I'm
also
taking
into
consideration
how
an
enterprise
is
looking
to
buy
storage
looks
at
it
now,
some
some
developer,
actually,
admin
would
be
responsible
for
going
and
making
a
case
for
this,
and
and
csi
has
a
strong
case
today
at
minio
when
we
deploy
on
kubernetes,
and
the
first
question
we
get
asked
is:
is
this
a
csi,
that's
as
f
as
much
as
they
know,
even
though
they
have
the
buying
power?
G
It
is
a
csi
driver
and
it
does
many
things
for
many
storage
platforms
when
we
eventually
ratify
this
cozy,
whether
it's
cosi
or
kosi,
something
else
we're
just
going
to
add
it
to
trident
it's
just
going
to
be
another
thing
that
trident
does
and
we're
going
to
tell
our
customers.
Look
you
get
trident,
you
get
csi,
you
get
the
cozy
thing
you
get.
You
know
it's
all
there
yeah.
I.
A
G
A
D
I
think
I
would
caution
against
it
and
the
reason
is
there
is
already
a
lot
of
momentum
for
the
existing
naming
in
terms
of
you've
got
a
bunch
of
github
repos
with
that
name.
We've
already
got
cube
contacts.
You
know
with
with
that
existing
name,
and
I'm
people
are
starting
to
recognize
that
this
is
the
thing
even
up
at
the
cncftoc
meetings
like
it's
come
up.
Oh
cozy
is
starting
and
it's
a
project,
and
you
know
it's
a
thing
so.
D
A
Sorry
yeah,
the
the
main
thing
is
I
I
can
tell
you
pretty
confidently
that
coming
from
someone
who
is
making
the
buying
decision,
it
does
become
an
ambiguity
and-
and
it's
going
to
help
all
the
vendors
here
to
to
have
this-
be
a
slightly
more
distinct
from
what
it
is
today,
simply
being
able
to
call
it.
Kubernetes
osi
is
different
enough
that
that
the
branding
will
will
pick
up
and
make
sense
for,
for
whoever
the
buyer
is
like
someone
suggested,
aaron
suggested
a
service
catalog
didn't
work
out.
A
D
I
think
it's
you
know,
how
much
is
it
the
name
and
how
much
is
it
the
product
right?
If
you
talk
about,
you
know,
service
catalog,
how
much
of
it
was
the
you
know
the
name
versus
what
was
actually
delivered,
and
I
think
I
tend
to
lean
towards
if
we
deliver
a
very
solid
product
in
terms
of
an
interface
that
is
reusable
it's
portable,
it
is
an
attractive,
useful
thing.
It
won't
matter
what
name
we
put
on
it.
H
There's
plenty
of
voices
on
the
on
the
phone
that
that
kind
of
work
regularly
and
talk.
You
know
a
lot
with
enterprises,
you
know,
I'm
you
know
I'd
come
from
delhi
and
see
you
know
spent
20
years
working
with
enterprises,
but
I
don't
think
necessarily
that
the
failure
service
catalog
was
the
naming.
I
think
it
didn't
help
that
it
wasn't
something
that
very
descriptive,
but
also.
H
A
H
A
No,
I
I
get
it,
we
can
still
call
it
cozy,
there's
nothing
wrong
with
that.
I
just
want
to
rename
it
to
kubernetes
osi,
because
we're
really
not
integrating
at
the
container
layer
either
and
calling
it
kubernetes
osi.
We
could
still
go
with
the
cozy
name,
except
in
the
documentation.
We
can.
We
can
write
this
as
just
kubernetes
osi
people.
I.
D
A
I
A
A
That's
that's!
That's
all
I
have
actually
now.
If
the
community
feels
strongly
that
the
cosi
is
the
right
way,
we
can
go
forward
with
that.
Obviously,
but
I
would
ask
everyone
to
just
consider
it
once
again.
I
do
spend
a
lot
of
time
talking
about
this,
so
that's
where
I'm
coming
from.
That's
all,
I
have
to
say
yeah
yeah,.
A
I
think
the
repositories
you
know
it's
really
long,
I
mean
just
in
terms
of
using
it.
Obviously
it's
usable,
obviously
you
can
bookmark
it
type
it
out.
It's
not
too
much
of
a
big
deal
but
again,
making
things
simpler,
making
things
easier
and
small-
and
you
know
easier
to
consume-
does
help
in
a
big
way
in
the
long
run,
at
least
like.
D
I
think
there's
two
things
that
are
being
brought
up
here.
One
is
like
the
name
of
the
existing
repos
is
too
long
right.
You
could
just
collapse
that
down
to
cosi,
dash
spec.
If
you
want,
I,
I
don't
think
we
should
do
that.
We
didn't
do
that
for
csi
and
it
wasn't
an
issue.
The
second
is
about
changing
the
names
and
the
first
part.
I
think
I
would
lean
against
in
a
second
honestly
renaming
I'd
say
I
don't
see
the
benefit
honestly.
A
I
yeah,
I
think
I
think
what
will
help
is
you
know,
speaking
to
some
speaking
more
about
it.
We
can
bring
it
up,
maybe
once
again
next
year,
this
is
the
end
of
the
year.
We've
made
excellent
progress
as
right.
Now,
cozy
is
a
great
name.
We
also
own
kubernetes,
osi,
github,
r,
sorry
cozy,
github
cosi.
A
A
L
A
A
D
A
Thank
you
I
wanna
say
one
last
thing:
again:
we've
done
a
great
job.
This
year
we
have
made
excellent
progress
and
I
want
to
congratulate
the
team.
I
want
to
congratulate
all
the
contributors,
all
the
new
contributors
and
thank
you
all
for
the
effort
you've
put
in
next
year.
We're
definitely
set
we're
on
the
right
track
to
go
ahead
and
achieve
alpha
and
and
have
vendors
using
this.
So
thanks
again
and
happy
new
year
to
everyone.
Merry
christmas
and
see
you
see
you
next
year.