►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 12 August 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
A
A
It
comes
from
the
bucket
class
and
then
put
into
the
bucket
object
when
a
bucket
is
created,
and
only
only
users
from
the
list
of
allowed
namespaces
is
allowed
to
request
access
to
that
bucket.
That's
kind
of
the
security
model
we
follow
and-
and
you
know,
in
order
to
add
a
new
namespace
or
in
order
to
allow
someone
to
start
using
the
bucket
from
a
different
name
space.
That's
not
already
there
in
the
list
and
admin
have
to
get
involved.
A
So
it
adds
that
extra
burden
on
the
admin
it
kind
of
messes,
with
the
self-serve
model
that
you're
aiming
for
and
so
and
so
we're
talking
about
using
a
selector
based
mechanism
where
an
admin
would
just
set
a
bunch
of
selectors
on
the
bucket
namespace
selector
and
any
namespace
that
has
the
matching
labels
would
be
able
to
access.
The
bucket
was
what
we
said
and
again.
If
a
new
namespace
wants
access
now
the
namespace
needs
to
have
that
label.
It's
it's
better.
A
While
talking
about
this,
I
don't
know
if
someone
came
up
with
a
really
cool
idea,
which
is
kind
of
like
doing
decentralized,
bucket
transfer,
bucket,
sharing
kind
of
mechanism
where
we
said
in
in
the
originating
namespace
there
would
be
there
would
be
some
sort
of
mechanism
to
to
or
no
in
the
name
space
where
someone
wants
to
get
a
bucket
from
another
namespace.
Let's
say,
let's
say:
alice,
creates
a
bucket
in
namespace
one
and
bob
in
namespace.
A
Two
wants
to
access
the
bucket
created
in
alice's,
namespace
bob
would
initiate
a
transfer
request
of
some
sort
and
alice
would
have
to
go.
Approve
that
request
and,
and
once
that
happens,
when
both
sides
are
in
sync,
the
controller
would
go,
cozy
would
go
and
and
provisioned
or
go
create
access
for
that
bucket
in
this
new
name
space.
A
C
A
B
Yeah
we
did
talk
about
that
last
week.
Some,
I
guess
so.
The
the
thing
that's
popping
into
my
head
is:
we've
been
talking
about
the
original
plan
as
if
there
would
be
an
actual
admin
sitting
around
pressing
buttons
to
cause
buckets
to
be
accessible
in
other
namespaces,
but
I
don't
think
that
was
ever
really
the
plan
it
would
just
be
like
for
alpha.
B
B
That
needs
to
be
created
in
both
namespaces
and
there's
some
controller.
That
needs
to
do
something,
and
maybe
the
exact
internals
of
the
something
don't
matter
as
much
as
the
actual
ui.
So
to
get
this
right,
I
guess
we
kind
of
have
to
just
define
what
those,
what
those
objects
that
alice
and
bob
need
to
create
are,
and
then
you
know
sketch
out
what
the
controller
will
do
in
response
to
them
and
then
fully
design
it.
That
might
be.
C
A
C
A
B
It
sounds
like
we're
equivalent
over
what
owner
means
exactly
in
my
in
my
mind,
what
owner
means
is
the
person
who
is
allowed
to
delete
it
or
mutate
it
and,
and
it
the
vision
has
always
been
for
the
greenfield
case.
The
person
who
creates
the
vr
is
the
person
who
is
allowed
to
delete
it.
Therefore,
that
person
is
the
owner
in
my
mind
and
and
if
you
have
one
that
you
pull
in
from
outside
the
cluster,
maybe
you
don't
even
give
kubernetes
the
ability
to
delete
it.
B
A
Okay,
so
so
well,
okay,
the
whole
discussion
and
just
taking
a
step
back
is
is
is
because
we
want
to
avoid
a
an
admin
step
when,
when
someone
from
a
different
name,
space
requests
a
bucket
now
now
the
question
is:
who
gets
to
decide
which
all
namespaces
are
or
who
all
get
to?
You
know
share
this
bucket,
get
access
to
a
bucket
that
that
I
initiated
the
creation
of
so
so.
Let's
say
I
I
create
a
bucket
request.
I
end
up
with
a
bucket.
Why
is
it
who
gets
to
decide?
B
The
argument
I
would
make
is
you
know
when
you
create
the
bucket
in
your
name
space
and
you
consume
it
in
your
workloads,
you're.
Putting
your
data
in
that
bucket
and
my,
I
would
argue,
users
should
have
custodianship
of
their
data
right.
If
I
create
a
container
and
put
my
data
into
it,
I
would
like
to
be
the
custodian
of
that
container
so
that
people
can't
just
steal
it
now.
B
A
container
might
be
a
bad
word
to
use
here
because
it
has
two
meanings,
but
you
know
bucket
is
what
we're
really
talking
about.
I
I
you
know
as
long
as
you're
doing
the
completely
inside
cozy
greenfield
use
case.
I
see
it
very
similar
to
pvcs.
You
know
you
create
a
pvc,
it's
your
pvc!
It's
your
data
in
the
pvc,
you
don't!
You
would
be
very
surprised
if
someone
else
could
steal
your
pvc
from
you
or
read
your
pvc.
Without
your
permission,
so
you
know
it.
B
C
B
I
mean
kubernetes
will
not
make
my
my
pvc
available
to
anyone
else
like
you're,
right
that
there
are
security
holes
in
the
whole
system
that
allow
the
data
to
become
accessible
from
outside
the
cluster,
but
like
there
are
csi
drivers
that
create
nfs
shares
that
are
extremely
secure
and
can't
be
accessed
by
anyone,
except
the
exact
pods
that
are
supposed
to
have
access,
because
they
use
categorized,
nfs
and
all
kinds
of
security
mechanisms.
And
you
know
strong
encryption
like
it's
an
implementation
detail.
How
much
you
lock
down
the
the
actual
bits,
but
cooper
did.
B
C
B
B
It
has
been
scoped
down
to
only
snapshot
because
of
race
condition
concerns
with
pvcs,
but
in
principle
people
want.
You
know
if
alice
has
a
pvc
and
she
wants
to
give
it
to
bob
like
we
would
like
there
to
be
a
way
to
do
that.
You
know
implementation
wise,
it's
hard,
so
it
might
not
happen
soon
and
we're
starting
with
snapshots,
because
it
has
less
technical
issues,
but
ultimately,
alice
should
be
able
to
hand
over
control
of
her
objects
to
other
namespaces
if
she
wants
to
and
the
recipient
wants
to,
like.
B
Yeah,
this
feels
very
parallel
and
that's
why
we
started
talking
about
you
know
if
alice
creates
a
bucket
using
cozy
in
her
name
space
and
she
and
bob
agree
that
bob
should
have
access
to
it
or
or
maybe
bob
gets
full
control.
Maybe
she
just
hands
it
over
to
bob
and
it's
not
her
bucket
anymore.
I
mean
there's
a
few
different
ways.
You
could
imagine
it
like.
You
could
have
an
object
that
alice
creates
and
another
object.
B
B
That
was
another
similar
api
that
was
brought
up
in
response
and
and
the
difference
with
that
one
is
certificate.
Signing
is
usually
an
interaction
between
a
low,
privileged
user
and
a
high
privileged
user.
I
actually
prefer
but
go
on,
and
and
we
really
are
envisioning
peer-to-peer
operations
in
the
storage
space.
You
know
alice
and
bob
are
both
low-level
users
and
they
should
still
be
able
to
trade
data
back
and
forth
with
no
additional
privileges.
B
Well,
so
that
was
why
that
my
specific
proposal
last
week
was
that
alice
would
actually
create
the
bar
with
whatever
bac
she
wanted.
You
know
it
could
be
a
full
control,
it
could
be
a
read-only.
It
could
be
something
in
the
middle
kind
of
a
bac
and
allow
the
bar
to
bind.
So
it
has
a
defined
level
of
access
that
alice
decides
and
then
she
could
hand
over
that
specific
bar
to
bob,
so
that
bob
can't
get
more
access
than
alice
agrees
to
that.
That
was
one
of
the
proposals
that
we
talked
about.
B
Yeah
there
would
have
to
be
something
on
both
sides,
because
otherwise
you
have
you
have
denial
of
service
type
attacks
where
you
can
just
push
objects
in
other
people's
name
spaces
that
they
don't
want,
and
that's
that's
bad,
so
yeah
alice
would
have
to
put
something
into
the
system
and
bob
would
have
to
put
something
into
the
system.
That
would
be
some
sort
of
a
bi-directional
pointer
and
then
once
the
controller
saw
both
pointers
pointing
at
you
know
the
opposite
objects.
You
could
say
they
have
agreed
now.
B
A
B
B
B
And
and
rewinding
all
the
way
back
to
jeff's
original
question,
like
can
this
scheme
work
with,
like
alice,
saying,
make
this
bar
available
to
everybody,
so
she
doesn't
have
to
create
a
thousand
of
them
if
they're
a
thousand
consumers,
depending
on
how
we
design
it.
The
answer
is
probably
yes
right.
There
should
be
a
way
that
I
can
create
a
bar
and
say
this
is
not
just
for
bob.
B
It's
for
all
comers
who
want
to
grab
it
and
then
all
I
need
to
do
is
publish
you
know
the
token
associated
with
that
one,
and
it
could
again
could
just
be
the
bar
name
and
then
all
of
the
other
namespaces
that
know
that
bar
name
can
just
go
and
alice's
namespace
name
could
just
go,
claim
it
and
get
their
own
bars
and
start
using.
The
bucket,
in
theory,
would.
B
Yeah
I
mean
we
can
get
as
fancy.
We
can
get
as
fancy
as
we
want
right.
You
know
you
could
have
a
a
simple
like
this
is
the
name
space
you
could
have
a
a
wild
card
or
you
could
go
all
out,
make
it
a
fancy
selector
thing
again
and
say:
I
want
to
share
with
all
the
name
spaces
that
end
in
fubar,
and
then
you
know
as
long
as
someone's
namespace
ends
in
fubar,
they
can
get
the
bucket.
You
know
you
could
invent
whatever
you
wanted.
B
A
A
B
B
Yeah,
so
that
the
idea
would
be,
I
think,
if,
if
alice
created,
one
of
these
for
sharing
with
bob
and
bob
didn't
claim
it
for
whatever
reason
and
then
alice
changes
her
mind.
She
could
just
delete
her
bar
and
then
later.
If
bob
tried
to
complete
the
claim,
it
would
fail
because
alice
had
deleted
her.
Her
ba.
B
B
B
Right
but
but
what
we
were
envisioning
was
that,
when
alice
creates
her
bar
the
you
know,
the
regular
thing
will
happen
where
the
the
the
sidecar
will
see
that
it
will
create
a
ba.
The
call
will
happen
down
to
the
driver.
The
cozy
driver
to
do
a
publish
access,
keys
and
secrets
will
get
generated
and
stored
in
kubernetes
for
that
ba
and
then,
when
the
transfer
occurs
from
alice
to
bob
like
we
don't
get.
A
second
ba,
like
bob
just
uses
the
ba
that
alice
created.
B
So
under
those
circumstances,
if
alice
deletes
that
ba
then
yeah
everyone
who
has
pointers
to
it
is
out
of
luck
because
they
didn't
get
their
own
copies
of
the
ba.
They
just
got
a
pointer
to
alice's
copy,
so
alice
remains
in
control
of
the
ultimate
ba
underneath
that
bar
because
she
has
the
power
to
delete
it.
B
That's
actually
so
so
that's
one
way
to
do
it.
I
think
we
were
contemplating
in
the
in
the
snapshot
design
that
you
would
actually
clone
the
equivalent
of
the
b
or
the
ba,
which
is
called
a
vsc
and
volume
snapshot,
content
object.
They
were
considering
making
a
second
one
because
they
have
one
to
one
binding
rules
and
then
the
problem
becomes
that
you
know
if
you,
if
you
delete
your
you,
can't
revoke
access
to
it.
B
B
What
you
wouldn't
want
to
have
happen
is
like
you,
wouldn't
want.
You
know
in
the
case
where
alice
wants
to
share
it
with
the
world.
You
wouldn't
want
everyone
who
who
tries
to
gain
access
to
get
a
separate
ba,
because
everyone
every
ba
that
gets
generated,
is
a
call
down
to
the
driver
and
a
new
secret
key
and
access
to
you
to
pop
out
and
like
if
a
thousand
people
do
that
that's
a
lot
of
bas.
B
C
A
B
B
B
Yeah,
I
guess
I
guess
we
could
maybe
it's
possible
to
do
both
to
have
both
modes
to
say,
hey
when,
when
this
gets
transferred
generate
a
new
ba
for
the
for
the
transferee
and
maybe
there's
a
mode
where
I
just
they
just
get
a
pointer
to
my
ba
they're,
probably
considerations
around
whether
we
allow
many
to
one
binding
between
the
bar
and
the
ba,
which
I
think
we
have
been
talking
about.
Doing.
A
Yeah,
I
have
a
quick
question
here.
It
might
seem
slightly
tangential,
but
but
in
case
of
pvcs
and
secrets,
I
know,
there's
a
there's
a
volume
provisioning
secret
you
can
get.
I
don't
know
what
it's
exactly
called,
but
but
it's
a
secret.
That's
given
through
the
pvc
all
the
way
into
into
the
csi
driver
which
can
which,
which
can
use
that
secret
to
talk
to
the
back
end
and
then
make
some
requests.
B
Yeah
well,
yes,
the
the
secrets
were
not
always
part
of
csi
and
they
ended
up
being
grafted
on
in
a
fairly
ugly
way
and
it
the
the
requirement
to
support
secrets,
almost
killed
the
proposal
to
do
the
pvc
transfer,
because
we
couldn't
figure
out
how
to
handle
what
happens
about
with
pvcs
that
depend
on
secrets
in
the
originating
name
space.
You
know,
if
you
just
transfer
the
pvc,
but
not
the
associated
secrets.
B
A
A
So
I
was,
I
was
kind
of
going
along
the
same
lines.
What
if,
instead
of
transferring,
we
had
some
mechanism
based
on
secrets,
so
so
what
I'm
saying
is
if
the
driver
could
recognize
based
on
a
secret
who's,
making
the
request
and
then
allowed
that
person
to
make
the
request
as
long
as
they
have
the
correct
secrets
or
correct
credentials.
A
So
so
this
would
be
like
a
separate
set
of
credentials
for
talking
to
the
driver.
I
know
it
sounds
confusing
to
call
it
another
set
of
credentials,
but
but
something
along
those
lines
where,
instead
of
instead
of
initiating
this
transfer,
what
if
you
could
off
band,
get
some
sort
of
secret
to
request
from
the
driver
a
new
bucket,
a
new
new
new
bucket
yeah.
B
The
moment
you
involve
secrets,
like
there's
a
bunch
of
new
security
problems
you
have
to
deal
with,
so
I
think
we
should
just
say
that
yeah,
if
you're
willing
to
share
secrets,
you
just
go,
pull
out
the
bucket
access
secrets
yourself
and
start
sharing
them
with
people
and
they'll
be
able
to
do
you
know
at
that
point.
You
don't
need
cozy
anymore,
you
just
you
have
the
secrets
you
can
access
the
bucket,
but.
B
A
Okay,
let's
take
a
simpler
approach.
What
if
we
said
alice
cannot
revoke-
let's
just
start
with
that,
just
as
a
third
experiment,
so
if
alice
just
cannot
revoke,
if,
if
the,
if
the,
if
the
bucket
is
or
credentials
are
passed
over
to
bob
bob,
just
has
access
to
the
bucket
and
until
bob
deletes
the
bar
himself,
it's
not
going
away
the
credentials.
B
A
B
Yeah,
okay,
but
so
so
alice
gives
access
to
bob,
and
then
bob
gives
access
to
charlie
and
alice
can't
stop
either
of
those
and
either
of
those
people
from
using
her
bucket
right
that
that's
what
is
implied
by
saying
alice,
can't
revoke
access
that
she
gives
away
is
that
it
can
spread
it
can
spread.
You
know
out
of
out
of
her
control
when
she
gives
someone
else
access
and,
if
we're
okay
with
that,
like
that's,
we
can
design
it
that
way,
but
it.
A
A
So
how
would
this
mechanism
look,
let's
say,
there's
a
namespace
that
hasn't
been
created
yet
and
alice
wants
to
allow
anyone
from
that
name
space
to
access
the
bucket?
Oh,
oh,
would
it
be
something
like
okay?
So
so
what
would
the
transferable
bar
just
have
like
a
transfer
two
namespaces
and
a
selector,
or
something
like
that
like
like
someone
was
bringing
it
up.
Yeah
yeah.
B
We
could
implement
all
of
this
as
extensions
to
the
existing
bir
object
with
some
optional
fields.
So,
ordinarily,
when
you
create
a
bar
for
yourself,
you
leave
these
fields
blank,
but
if
you're
creating
a
bar
with
the
intention
of
transferring
it
to
somebody,
you
could
fill
in
the
destination
name,
space
field
or
the
destination
name,
space,
selector
field
or
whatnot,
and
then
share
the
name
of
that
bar
with
the
user
in
that
namespace.
B
And
then
they
know
your
namespace
name
and
they
know
your
bar
name
and
they
can
similarly
construct
a
bar
with
like
a
namespace
from
and
a
bar
from
field,
and
then,
instead
of
the
normal
thing
happening,
they
would
get
this
and
and
exactly
how
the
kubernetes
object
needs
to
look.
You
know
I'm
sure
we
could
figure
out,
but
yeah.
You
could
do
this
all
within
the
bar
with
a
bunch
of
optional
fields.
B
So
you
would
have
different
styles:
you'd
have
a
bars
designed
for
self-consumption,
you'd
have
bars
designed
for
export
and
you'd
have
bars
designed
for
import,
but
they
would
all
function
the
same
in
terms
of
after
they
got
bound.
Pods
can
just
use
them
right,
it'd
be
a
question
of
where
they're
getting
their
source
material
from.
A
Yeah,
the
the
few
things
that
bother
me
are
the
first
thing
that
bothers
me
is
I
mean
I
still
don't
know
the
answer.
I
would
say
that
way.
Is
it
okay
to
that
you
know.
Is
it
okay
that
once
it's
shared,
the
originator
really
doesn't
have
any
more
control
over
sharing,
because
if
that's
the
case
really
there's
no.
B
So
so
this
is
this.
This
is
why
revocation
would
would
be
a
good
thing
if
you,
if
you
also
force
people
to
decide
between
copy
and
move
semantics,
where
copy
means,
like
they're
gonna,
get
the
exact
same
secret
and
access
key
that
I
have
for
that.
Bar
and
move
means
they
just
get
the
whole
thing
themselves
and
mine
goes
away
in
in
the
for.
In
the
first
case,
the
deletion
of
mine
will
cause
the
deletion
of
theirs
because
it's
using
the
same
secret.
B
B
So
I
could
just
create
one
and
then
everyone
who
comes
to
get
it
will
effectively
get
their
own
ba
with
their
own
access
key
and
their
own
secret.
The
problem
I
worried
about
there
is
scaling
right
if
a
thousand
people
come
in
and
create
bas,
you're
gonna
have
a
thousand
access
records
on
that
bucket.
That
have
to
be
plumbed
all
the
way
down
to
the
back
end,
and
I
don't
know
if
bucket,
I
don't
know
if
bucket
services
support
thousands
of
access,
keys
and
secrets.
B
A
I
don't
think
so,
so
they
use
the
same
access
credential
mechanism
as
the,
so
they
have
a
unified
access
and
and
authentication
mechanism
for
all
of
for
the
entirety
of
their
cloud
offering.
So
so,
if
you
can
have
a
million
key
users
in
in
in
your
gcs
or
google
cloud
account
you,
you
could
probably
do
it
for
the
buckets
too.
B
A
Yeah,
maybe
I'll
go
check
it
up
once
in
case
you
know,
I'm
missing
something
too,
but
but
last
I
remember
you
know,
you
know
this
is
how
it
is
at
least
with
s3.
I
know
I
know
this
for
sure
and-
and
you
know
like
in
in
amazon
the
the
their
their
you
know.
Cognito
storage
or
user
management
mechanism
allows.
A
A
Well,
usability
aside,
I
mean
like
just
the
functionality
first,
so
this
is
a.
This
is
absolutely
a
completely
new
model,
something
like
this
hasn't
been
done
before,
but
but
there's
a
good
reason
for
it.
You
know
with
stateful
stuff
kubernetes
is
just
coming
around
and
buckets
are
the
most
natural
way
to
you
know:
consume
storage
in
in
cloud
native
environments
and
and
the
way
we're
designing
it.
C
A
My
second
second
question
is,
I
think
we
can
work
out
the
semantics
of
how
sharing
gets
work,
whether
you
can
revoke
or
not.
I
think
that's,
that's
the
smaller
concern
here.
The
bigger
concern
is,
are
we?
Are
we
making
a
big
enough
of
a
difference
between
this
model
and
just
saying
namespace
selectors,
where
an
admin
has
to
come
and
just
select
a
bunch
of
namespaces.
B
Well
and
again,
the
vision
isn't
that
an
admin
actually
does
that
work.
The
vision
is
that
later
we
add
some
new
objects
to
facilitate
sharing
and
then
the
controller
that
can
no
that
manages
those
objects,
would
mutate
the
field
for
you
right
that
that
would
be
the
actual
plan.
If
we
go
to
that
the
original
path.
B
It
doesn't
have
any
built-in
support
for
sharing
and
then
the
idea
is
we
later
layer
that,
in
with
an
additional
api,
object
to
facilitate
sharing
and
then
there's
a
new
controller
that
that
consumes
that
object,
that
does
all
of
the
work
of
you
know
binding
and
modifying
your
buckets
for
you,
so
that
so
the
admin
just
has
to
install
that
controller.
He
doesn't
actually
have
to
sit
around
and
edit
buckets
all
day
all
right.
B
It's
just
a
matter
of
so
some
bucket
sharing
controller,
that
that
would
be
how
we
would
actually
do
it,
but
that
that's
just
that's
just
a
pun
right,
it's
saying
that's
pushing
into
the
future
and
saying
we
don't
know
how
we're
going
to
do
it,
we'll
figure
it
out
later
in.
In
the
meantime,
an
admin
can
do
it
for
you,
but,
like
the
plan,
isn't
actually
to
have
an
admin
involved
for
all
time.
It's
just
we
don't
know
what
we're
going
to
do
yet.
A
A
However,
I
want
to
make
sure
we're
not
over
engineering
at
the
same
time,
because,
because
how
about
this,
how
would
we
put
the
namespace
selector
approach
out
there
and
and
see
how
how
it
turns
out
there
is?
There
is
a
real
risk
of
us
getting.
You
know
pigeonholed
into
that
yeah.
So
so
I
I
you
know
I'm
kind
of
asking:
let's
take
a
poll,
probably
how
do
you
think
we
should
move
forward,
because
so
so
the
trade-offs
are
clear.
A
B
A
B
A
B
A
Certificate
mechanism,
where
I
mean
the
good
thing,
is
this
model
we're
going
with,
gives
us
the
flexibility
to
add
things
like
a
certificate
where
only
only
pods
from
you
know,
with
with
bob
selectors
get
to
access
something
like
that,
get
to
access
the
back
end
or
something
I
mean
with
certificates.
You
can
restrict
what
all
ip
addresses
get
access
to
the
to
the
bucket
or
to
a
particular
service.
B
But
we'd
like
to
keep
all
the
control
in
in
kubernetes
in
the
api
right
where
you
know
if,
if
for
whatever
reason,
I
change
my
mind
about
giving
access
to
bob
that
I
know
what
to
do.
If
I'm
alice,
I
can
just
go
delete
something
in
bob's,
accessible
poof.
It's
like
that.
That's
pretty
easy
to
understand.
A
A
A
C
A
C
A
A
A
A
Current
right-
and
it
was
fine
so
far,
but
but
you
know
we
should
do
this
before
we
reach
alpha.
We
should
start
this
practice
before
we
go
alpha
because
after
alpha,
the
first
thing
you
know
I'm
going
to
focus
on
is
bringing
people
from
aws
and
and
gcs
and
azure
to
start
coming
to
our
meetings
regularly,
yeah
and
and
once
that
happens,
you
know
it
will
be
good
to
have
had
this
practice
or
by
the
time
that
happens.
B
Sounds
good
and
if
you
need
help
writing
up
the
design,
please
ping
me,
I
think
the
hard
the
hard
decision
is
going
to
be
how
much
flexibility
you
know
to
get
you
know.
Do
you
want
to
have
things
like
selectors?
Do
you
want
to
support
both
move
copy,
doing
a
support
clone?
Do
you
want
to
support?
You
know,
there's
all
the
different
little
nuances
that
you
could.
A
Yeah,
no,
I
think
flexibility
is
more
important
here.
A
lot
of
kubernetes
apis
feel
like
their
machine.
Api
is
not
really
human
apis,
and
if
someone
wants,
because
it's
a
framework
for
building
frameworks,
that's
how
we
define
it
right
and
if
someone
wants
to
like
make
it
easier,
you
know
build
a
controller
on
top
of
it,
put
your
own
crd
and
make
it
better
for
users.
A
So
so,
from
that
perspective
you
know,
I
think
it
makes
and
and
it's
not
flexible
enough
for
for
for
object,
storage
vendors
to
provide
all
their
services.
So
obviously
we're
going
towards
this
part
of
having
more
or
providing
more
flexibility
for
object,
storage,
vendors
to
to
implement
their
object,
storage.
The
way
the
way
they
want
to
while,
while
while
just
providing
this
opinion
of
this
is
the
way
to
share
them.
But
but
you
know,
you're
free
to
apply
all
sorts
of
access
policies
on
it.
We're
not
going
to
restrict
you
from
that.
A
A
So
we're
going
through
another
round
of
reviews.
Now
I
believe
we
we
are
not
as
time
constrained
as
we
were
last
time,
so
I've
rewritten
the
entire
cap,
so
so
ben
and-
and
I
think
jeff
already
had
a
chance
to
go
through
it.
So
then
I'll
paste
the
link
again
in
six
storage
cozy.
It's
actually
the
last
message
on
sixth
stories.
Cozy,
please
take
a
look
again
and-
and
you
know,
share
your
thoughts.
Maybe
I
missed
something.
Maybe
maybe
I've
explained
something
wrong.