►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 20 January 2022
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Sidhartha Mani (Minio)
A
A
A
D
That's
about
it
right.
This
is
a
question
raised
by
michelle
right.
Do
we
have
michelle
no
yeah?
I
mean
I
would
like.
I
agree
with
everything
you
said,
because
I
think
that
was
the
argument
I've
been
making,
but
I
want
to
if
someone
has
counter
argument,
I'd
like
to
come
state
it
because
there's
there
is
a
lot
of
consternation
around
this.
I
am
versus
secret
key
design
and
all
the
requirements
on
it,
and
I
don't
know-
maybe
other
people
have
have
a
different
feeling
about
the
balance
of
complexity
versus
portability.
D
D
The
the
the
complexity
is
is
on
the
workloads,
the
requirement
that
they
take
whatever
we
give
them
right
that
that's
that's
more
work
that
every
workload
has
to
do
to
be
compatible
with
cozy.
If
you
could,
if
we
relax
that
requirement
said,
look
if
you
ask
for
a
secret
key,
we'll
give
you
a
secret
key
100
of
the
time
or
vice
versa.
Then
you
could
write
your
workloads
to
always
expect
a
secret
key
or
whatever
it
is.
You
were
going
to
request
and
it
would
make
writing
your
workloads
easier.
D
A
So
I
mean
you,
you
can
add
services
or
you
can
have
a
controller
that
makes
it
easier
for
you,
the
the
base
api,
the
the
lowest
layer
of
the
platform,
the
provisioning
platform
that
is
cozy
need.
Not
I
mean
it.
I
think
it
should
focus
more
on
functionality
than
it
should
provide
all
the
functions
needed
and
for
usability's
sake.
A
People
can
build
a
crd
or
you
can
build
a
upstream
service
that
that
takes
care
of
it.
If
it's
really
that
much
more,
if
usability
is
that
much
more
desired,
but
but
that
being
said,
even
in
pvcs
and
tvs
like
take
the
example
of
storage
class,
a
bunch
of
things
can
only
be
specified
via
the
storage
class
and
and,
like
you
know,
the
file
system.
A
So
so
I
I
don't.
I
don't
know
if
it's
any
more
complex
than
other
kubernetes
resources,
but
but,
like
you
said,
if
someone
has
a
strong
point,
I
just
think
the
pla.
The
the
main
thing
is
the
platform
should
shouldn't
be
something
that
compromises
functionality,
because
complexity
can
be
addressed
at
a
higher
layer
of
abstraction.
D
Okay,
I
I
don't.
I
don't
know
what
you
mean
by
the
higher
layer
of
abstraction,
but
but
I
do
agree
that
you
know
it's
totally
possible
to
have
libraries
inside
the
workloads
that
are
just
cozy
compatible
and
can
deal
with
anything
we
throw
at
them
and
as
long
as
we
stand,
stand
fast
and
say
you
know,
you
must
support
both
of
these
in
your
library
and
everyone
does
that
then
there's
no
problem.
A
A
So,
I'm
trying
to
understand
this
question
a
little
bit
more,
but
I
think
she
means
the
workflow
is
focused
on
a
lot
of
workloads,
but
we
also
want
to
support
users
instead
of
granting
access
to
service
accounts.
Can
we
also
grant
access
to
a
user?
Maybe
I
haven't
been
clear
so
far,
but
I'm
not
sure
if
she
means
grant,
as
in
like
does
she
mean
only
people
with
a
particular
kubernetes
user,
or
only
a
particular
kubernetes
user?
D
A
D
A
D
It
would
be
good
to
have
michelle
here
to
explain
what
she
means,
but
I
have
to
assume
that
she's
getting
confused,
because
on
the
on
the
actual,
like
gcs
implementation,
of
course,
buckets
can
have,
can
grant
access
to
both
users
and
service
accounts,
and
so
it
seems
natural
to
ask
like.
Is
it
only
service
accounts
on
the
kubernetes
side?
D
Why
not
users
on
the
kubernetes
side,
and
I
think
the
answer
is
because
it
wouldn't
do
any
good
to
grant
access
to
a
user
on
the
kubernetes
side,
because
you
can't
run
a
pod
as
a
user.
To
my
knowledge,
you
can't
do
anything
with
a
bucket.
If
you're
a
user,
you
have
to
create
a
workload,
but
maybe
she
knows
something
we
don't
yeah.
A
A
E
D
A
So
that's
why
I
was
getting
to
this
like
if
yeah,
maybe
we
should,
we
should
clarify
or
we
should
find
out
what
she
meant
here.
But
but
if
she
means
kubernetes
uses
provisioning,
buckets
or
using
buckets
and
if
it's
just
cloud
provider
users,
then
the
answer
can
be
straightforward.
It's
not
needed,
but
if
it's
kubernetes
users,
then
it's
kind
of
confusing,
because
because.
A
C
D
D
A
Yeah
it's
required
when
pod
has
access
to
more
than
one
bucket.
I
mean
whether
the
question
is
straight
forward.
I
so
one
of
the
reasons
I'm
bringing
this
up
is
because
you
know
they
weren't
completely
straightforward
to
me
the
questions.
So
I
figured
you
know.
Maybe
michelle
was
going
to
join
this
call,
so
it's
worth
it
to
bring
this
up.
A
A
A
E
B
E
First
to
point
to
the
existing
resource,
then
you
create
a
one
snapshot
to
bind
with
that
one
central
content
same
as
the
pvc
tv
case,
so
temporarily.
Of
course
you
will
have
just
one
resource,
but
then
to
use
it,
you
will
have
to
have
this
other
resource
for
user
to
use
it.
So
now,
in
this
model
we
are
going.
You
know,
kind
of
going
away
from
that.
This
is
a
little
weird.
I
also
find
that
a
little
weird
I.
A
See
so
so
so
the
last
solution
we
made
was
if,
if
a
bucket
already
exists,
anyone
can
bind
to
buy
into
that
bucket.
I
think
there
was
some
complexity
around
who
gets
to
delete
the
bucket.
I
think
that's
the
reason
or
did
okay
so
yeah.
Now
I
think
I
remember
so.
We
said
if
a
bucket
was
created
outside
of
cozy,
then
we
we
don't
delete
it
or
the
retention
policy
on
the
bucket
or
the
deletion
policy
on
the
bucket
is
always
or
by
default,
retained.
A
Yeah
it
was
created
outside
of
cozy,
so
we
don't
want
to
take
up
the
we
don't
want
to
accidentally
delete
it.
I
think
that
so
that's
the
reason.
If
we
had
the
deletion
policy
to
be
deleted,
like
we
do
with
cozy
created
buckets,
then
then,
when
the
bucket
goes
away,
it'll
get
deleted.
We
don't
want
that.
E
B
E
A
A
A
A
A
D
Is
this
before
you
do
want
the
bucket
to
go?
You
want
the
bucket
object
to
go
away,
but
you
don't
want
the
actual
bucket
to
go
away
right
right
right.
Otherwise,
you
have
a
bucket
hanging
around
forever
it'll
never
get
deleted.
So
you're
saying,
if
I
heard
about
the
claim
you
got
a
bucket
claim
it
was
down
to
the
bucket
and
then
you
deleted
the
name
space.
Obviously
the
bucket
claim
will
go
away
and
then
the
bucket
that's
bound
to
it
should
go
away
for
garbage.
B
D
D
A
D
D
Of
copies
of
everything,
now
lots
of
copies
of
everything
isn't
great,
but
it's
really
simple
right,
because
you
can
just
follow
extremely
straightforward
rules
about
how
things
work.
Everything's
one-to-one,
everything's,
simple,
nothing
goes
across
name
spaces,
and
it's
just
you
know:
there's
no
ambiguity
right
right,
so.
A
A
E
A
D
A
So
so
her
question,
michelle's
question
was:
is
there
a
reason
why
we
don't
have
a
bucket
claim
for
every
every
bucket
that
is
utilized
or
or
for
brownfield
buckets?
Why
do
we
not
have
bucket
claims
and
the
answer
was
it's
not
very
different
from
buckets
that
I
use
from
name
spaces
where
the
bucket
you
know
in
in
other
name
spaces
than
the
one
the
bucket
is
created
in
it?
Brown
field
is
the
same
as
accessing
bucket
from
a
different
name
space.
That's
what
we
said.
D
My
interpretation
of
what
michelle
is
saying
is
she's.
Looking
at
the
way
we
do
brownfield
snapshots
where
you
create
a
volume,
snapshot,
content
object.
First
then,
you
point:
the
volume
snapshot
object
at
the
vsc
and
they
bind
that's
interesting
and-
and
it's
still
one
to
one,
but
it's
just
that
that
you
can
there's
a
mechanism
in
the
via
in
the
vs
object
where
you
can
give
it
a
vsc
name
directly,
and
you
have
to
do
one
or
the
other
right.
D
You
either
have
to
say
I'm
taking
a
snapshot
of
an
existing
pvc
or
I'm
creating
a
snapshot
that
already
exists,
and
then
two
very
different
things
happen.
Depending
on
that
choice.
Now
we
don't
have
a
concept
of
like
creating
a
bucket,
that's
not
empty
or
you
either
ask
for
an
empty
bucket
or
an
existing.
But
I
guess
those
are
the
two
cases
I
either.
D
A
D
A
So
remember
we
did
consider
having
it
here.
I'm
just
trying
to
you
know
I'm
asking
if
you
can
help
remind
me
why
we
chose
to
go
with
this
model.
I
remember
we.
We
discussed
one
sometime
back
where,
if,
if
we
could
have
the
bucket,
if
you
could
have
a
bucket
claim,
regardless
of
whether
it
was
greenfield
or
ground
field.
D
We
ended
up
going
back
and
forth
on,
does,
does
a
bucket
access
need
a
bucket
claim
or
doesn't
it
right,
because
if
it
needs
a
bucket
claim,
then
obviously
you
need
to
be
able
to
create
bucket
claims
for
existing
buck.
You
know
for
brownfield
situations,
but
if,
if
it
doesn't
need
a
bucket
claim,
then
you
don't
I
mean
if
the
bucket
access
can
point
directly
to
a
bucket,
then
in
the
brownfield
situation
you
just
do
that.
D
A
I
could
possibly
believe
it
because
I
can't,
I
can't
think
of
I
mean
if
you
say
the
value
is
the
fact
that
it
it
is.
It
is
symmetric
or
it's
exactly
like
some
other
model,
maybe
that's
valuable,
but
but
technically
speaking,
I
don't
see
what
benefit
do
we
get
from
having
a
bucket
claim
every
time
you
want
to
access
a
bucket,
even
if
it's
a
bucket
created
outside
of
this
namespace
or
outside
of
cozy.
A
D
You
have
to
think
through
the
situation
where
you
know
I
want
to
be
able
to
create
an
app
with
a
brand
new
bucket
versus.
I
want
to
be
able
to
create
an
app
with
an
existing
bucket
and
how
the
existing
bucket
will
get
sort
of
injected
into
the
automation
that
sets
up
the
app,
because
if
the
automation
is
responsible
for
creating
bucket
accesses,
then
you're
going
to
have
two
different
branches
for
the
bucket
access
creation
to
go
down
right.
One
is
for
create
a
bucket
claim
and
bind
to
that.
A
D
We
can't
do
it
any
way.
We
want
it's
a
question
of
like
what's
going
to
feel
right
for
consumers
of
the
api
right
because
in
a
kubernetes
world,
it's
very
common
to
just
like
check
all
your
kubernetes
objects
into
some
git
repo
and
then
have
some.
You
know
and
templatize
certain
things
and
then,
when
you're
ready
to
instantiate
your
app,
you
just
you
know,
do
git
clone
cue,
cuddle
apply
or
you
know,
use
customize.
A
D
E
A
D
Yeah,
I'm
not
saying
that
I'm
an
expert-
or
I
know
what
the
right
answer
is
here.
I'm
just
saying
like
going
through
those
kinds
of
exercises
will
tell
you
what
the
right
answer
is:
we've
gone
through
them,
and-
and
I
mean
I
mean
actually
using
the
api
as
as
an
application
user
would
use
it.
You
know
and
trying
to
do
things
like
you
know,
deploy
a
new
application,
clone
an
application
back
up
and
restore
an
application.
D
You
know
all
the
kinds
of
things
that
the
people
are
trying
to
use
the
kubernetes
api
for
with
you
know,
today,
with
volumes
and
snapshots
and
stuff,
and
when
you
layer
in
buckets
you
just
got
to
figure
out
what
is
it?
What
does
it
look
like
to
back
up
an
application
that
has
a
bucket
and
then
to
restore
that
application
to
a
new
cluster
and
to
use
the
same
bucket?
You
know
what
what
exactly
do
you
have
to
do
and
and
is
it
awkward
or
is
it
natural.
A
Know
that
we
did
the
wrong
thing
yeah,
it's
okay
to
say
we
will
see
how
it
goes,
and
you
know
or
we'll
see
how
people
use
it
and
then
improve
from
there.
As
long
as
we
are
aligned
with
the
idea
that
we
we
are
ready
to,
you
know,
tear
it
all
up
and
start
from
scratch
if
needed
it
shouldn't
get
to
that
point.
But
you
know
I'm
saying
that
we
might
have
to
change
stuff
later
on
yeah
yeah
yeah.
We
do
need
a
bucket
claim
name
in
the
bucket
access.
That's
pretty
clear!
A
D
E
D
Your
your
prerequisite
would
be
that
that
snapshot
has
to
get
there
somehow
whether
it
was
a
pre-existing
snapshot
of
a
volume
when
you,
you
know
previously
snaps
out
of
your
application
or
whether
it
was
a
snapshot
that
some
administrator
created
and
then
you
bound
a
vs
to
it.
You
know
the
idea
would
be
your.
The
prerequisite
is.
D
A
snapshot
exists
in
the
namespace,
with
a
known
name
that
that
is
chosen
by
the
application,
deployer
and,
and
then
everything
else
is
automatic
in
this
world,
like
you
can't
specify
the
name
of
the
bucket,
because
that
that's
going
to
be
it's
a
non-namespace
object,
so
you
have
to
be
taken
as
an
input,
not
as
an
output,
and
then
you
would
have
to
use
that
input
in
your
bucket
access,
and
so
then,
then,
at
that
point
the
prerequisite
is
something
has
to
exist.
You
have
to
pass
in
the
name.
D
A
D
Right,
it's
just
that
with
snapshots.
You
can
control
your
your
starting
snapshot,
name
because
it's
a
name-based
object
and
then
you
can
just
put
a
requirement
on
someone
to
to
set
that
up
ahead
of
time
and
and
with
this
model,
you
can't
do
that
because
the
name
is
got
to
be
chosen
by
someone
else
and
input
into
the
process.
A
D
A
D
E
A
C
B
D
E
A
Right
right,
so
if
for
a
pre-existing
vsc,
if
you're,
trying
to
if
you,
if
you're
trying
to
bind
a
vs
to
a
pre-existing
vsc,
you
know
someone
should
someone.
Should
you
know
it's,
it's
not
possible
to
predict
the
vsc
name
right,
so
you
can't
really
just
have
a
declarative
specification
of
the
vs
name
now,
because
it
has
to
point
to
an
existing
vsc.
Isn't
that
right?
A
D
A
E
D
A
D
But
you
could
require
that
the
bucket
claim
exists
ahead
of
time
and
so
that
you
can
refer
to
it
by
name,
and
then
you
can
just
have
a
requirement
that
if,
if
your
application
is
expecting
a
non-empty
bucket,
somebody
has
to
create
that
bucket
claim
and
bind
it
to
the
bucket
ahead
of
time.
But
but
you
can't
do
that
today
with
this
design
right,
because
because
now,
but
a
new
bucket
claim
will
always
result
in
a
new
empty
bucket.
A
D
A
A
A
A
A
A
C
A
D
E
E
A
A
E
A
E
E
A
D
No,
so
is
that
specified
on
the
bucket
claim
or
the
bucket
class
it
has
to
be
in
the
rocket
class,
but
that
that's
kind
of
weak
right,
because
then,
then
users
can't
anyone.
You
can
use
any
bucket
class.
Anyone
can
use
any
bucket
classes.
What
you
mean?
No,
no.
What
I
mean
is
like:
if
there
is
no
bucket
class
that
offers
the
kind
of
sharing
you
want,
then
you
can't
do
what
you
want.
A
D
A
E
A
D
A
A
Yeah,
so
so
it's
still
self-service
because
it's
like
run
time
versus
compile
time
I
mean
it's.
I
mean
we're
not
compiling
or
running
anything
here,
but
when,
when
setting
up
the
cluster,
the
admin
could
create
a
bunch
of
bucket
access,
bucket
classes
and
and
the
user
gets
to
choose
one
from
the
many.
The
admin
doesn't
have
to
be
involved
during
the
bucket
creation
step
itself.
A
Don't
think
we're
really
losing
self-service
here
but
anyways
again,
I
think
it's
important.
We
focus
here.
We
don't.
We
don't
have
to
answer
this
now,
because
we
said
version
alpha
of
the
cap.
We're
not
going
to
do
that
all
right.
So
there's
this
question
about
retention
period
for
compliance
use
cases
will
that
conflict.
I
think
I
explained
what
this
use
case
was
for
those
who
might
not
know
where
you
know
at
mania.
A
A
I
don't
have
to
get
a
raise
or
I
don't
know
what
it
is
it's
funny,
but
I
don't
think
it's
it's
that
frivolous,
but
but
being
more
serious.
I
think
that's
what
she's
trying
to
say
shouldn't
there
be
a
retention
period
for
compliance
use
cases
I
think
bucket
specific
policies
like
that
can
be
yeah.
It's
something
that
has
to
be
specified
during
during
the
creation
of
the
bucket.
A
A
B
A
D
C
A
D
G
A
A
D
D
A
A
D
A
C
A
A
A
A
A
A
I'm
guessing
it's
actually
requests
so
yeah
I'll.
Take
a
look
at
this,
but
I
think
request
party
service,
so
this
is
for
so
so
you
can't
create
a
bucket
at
the
name.
Okay,
so
this
is
insert
okay,
so
bucket,
create,
is
here
and
lock
retention
policy
yeah.
So
in
google
cloud
it's
something
that's
done
afterwards!
A
A
Yeah
yeah,
I
think
it's
fair
to
say
it
has
to
be
done
up
front
and
we're
doing
so.
So
I
think
it's
fair
to
say
that
cosi
only
supports
bucket
locking
enablement
up
front
when
creating
the
bucket,
and
if
we
go
with
that,
I
I
don't
think
that's
that's
that's.
I
don't
think
we're
really
restricting
users
too
much
when
we
say
that
I
think
I
think
that's
fair
and
in
that
model
yeah
yeah
we.
This
could
be
that
proprietary
extension
that
that
gets
specified
in
the
in
the
bucket
class.
A
Okay,
good
to
know
all
right,
so
I
have
an
answer
here,
we're
almost
out
of
time.
Okay,
so
just
this
last
one,
so
I
suggest
looking
into
the
new
liens
feature
for
design
in
this
area,
the
current
approach
that
we
do
with
finalizes
for
previous
and
snapshots.
I
think
it's
too
complex
all
right.
So
what
is
the
new
lanes
feature?
Is
there
is.
E
A
A
I
think
I
think
if
someone
wants
forced
elite,
they
they
they
could
forcibly
remove
the
bucket
accesses,
so
they
remove
the
users
and
then
delete
the
bucket.
I
think
that's
okay
as
an
admin,
they
have
the
privileges
to
do
it.
I
don't
see
why
it
needs
to
be
heard
from
under
someone
who's
using
it
rather
than
by
first
taking
the
user
away
and
then
deleting
it.
I
think
it
didn't
even
give.