►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 06 Jan 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
Yep,
thank
you
shane,
so
jeff
had
a
question
about
the
cap.
I
wanted
to
also
provide
an
update
about
where
we
are.
I
I
pinged
michelle
yesterday
and
she
said:
she'll
take
a
look
at
the
cap
again,
but
but
jeff
has
been
reviewing
it
as
well,
and
one
of
the
questions
he
had
was
about
using
brownfield
buckets.
A
We
tried
to
open
the.
I
just
tried
to
open
the
github
page
for
it
it's
a
little
slow,
so
I
ended
up
just
opening
it
up
locally
and
we'll
just
quickly
go
over
how
we
do
brownfield
buckets
so
to
to
kind
of
bring
the
context
back.
So
we
we
decided,
we
will
call
the
resources
for
creating
a
bucket
as
bucket
claim
and
we
don't
have
any
bucket
access
requests
or
bucket
requests
anymore.
A
You
it's
just
like
pvcs,
persistent
volume
claims
and
pvs,
so
you
have
bucket
claims
and
buckets
and
then
to
get
access.
We
just
have
one
object,
called
bucket
access,
so
in
case
of
green
field
buckets
or
buckets
that
we
create
fresh
new,
we
create
a
bucket
claim,
and
that
ends
up
calling
the
appropriate
functions
in
cosy
to
create
the
bucket
itself
and
in
case
of
brownfield
buckets
or
existing
buckets.
B
A
We
can
fix
yeah,
we
can,
we
can
fix.
The
wording
is,
more
importantly,
the
design.
Am
I
missing
something
that
you're
seeing.
B
Yeah,
what
I'm
gonna
I'll
make
some
wording
suggestion
changes
around
brownfield
now
that
I
have
heard
definitively
that
a
bucket
claim
is
not
needed
for
the
brownfield
use
case.
So
I
will
now
not
knowing
that
now
I
will
read
some
review
some
of
my
own
comments
and
some
of
those
paragraphs
and
said
I'll
just
make
some
suggestions
for
wording
that
will
make
it
clearer,
at
least
for
me.
It
would
make
it
clear.
A
For
sure
yeah
no,
I
appreciate
that
and
and
we'll
incorporate
it.
B
So
and
otherwise.
A
B
Still
need
to
review
more
and
your
your
point
at
the
beginning
of
the
meeting
is
correct.
That
a
lot
of
my
comments
are
cons
would
just
be
considered.
Knits,
they're,
they're,
syntax
or
you
know,
grammar
or
something
like
that.
I
just
when
I
go
through
it.
B
I
just
sort
of
look
at
everything,
so
that's
kind
of
how
the
way
I
do
reviews,
but
I
will
also
try
to
spend
some
time
to
think
of
the
more
deeper
issue
that
this
will
meet
all
the
r
intended
use
cases
it
seems
like
it
will
to
me.
A
Okay,
perfect
yeah.
We
appreciate
the
review
jeff
so
yeah.
Do
it?
Do
it
yourself?
Okay,
so
really
the
one
thing
that's
that's
really
left
to
address
is
reference
policy,
but
before
that,
before
we
jump
into
a
new
discussion,
I
wanted
to
ask
so
so
we
really
want
to
get
this
kept
through.
We
really
want
to
move
things
along.
A
I
know
michelle
is
going
to
take
a
look,
but
what
else
can
we
do
so?
Who
can
help
with?
So
I'm
just
looking
for
ideas
of
what
can
we
do
to
push
this
along
faster
like?
Should
we
just
keep
pinging
michelle,
or
is
there
someone
else
also
what
what
like
I
want
to
come
up
with
some
plan
of
of
how
we
address
this?
Let's
just
assume
that
you
know
the
cap
is
in
a
decent
state
like
ready
to
be
reviewed,
maybe
not
perfect
yet,
but
ready
to
be
reviewed.
C
C
And
then
she
can,
because
I
think
tim
has
already.
I
think
you
can
also
steal,
pin
tin
as
well.
Okay,.
C
But
then
you
know,
you
know,
after
michelle
review,
that
michelle
can
also
ping
tim.
So
I
think
this
one
also
still
need
the
api
reviewer
to
approve.
So
okay.
A
A
Yeah
I
spoke
with,
I
mean
I
sent
her
a
slack
message
yesterday
and
she
said
she'll
take
a
look
so
yeah.
I
was
just
wondering
if
there's
anything
else
we
can
do
like
like
have
some
other
reviewer.
Take
a
look.
So
it's
easier
for
michelle
or
something
like
that.
C
D
E
C
C
Anyway,
I'll
show
you
she's
listening
so
but
that's
okay.
So
let's
just
ping
ping,
michael,
oh,
hey,.
D
On
the
road
yeah,
so
do
you
have
a
question
like.
C
Okay,
so
are
you
also
going
to
review
this
cap.
D
I
can't
chat
with
michelle,
so
I
I
think
I'm
not
I'm
a
new
joint.
So
oh.
C
I
I
see
so
maybe
you
can.
Maybe
you
can
help
us
pin
michelle
to
your
understand.
It's
just.
You
know,
because
I
think
she
knows
that
as
well.
D
C
A
Thank
you
all
right,
so
any
other
topics
that
anyone
thinks
we
need
to
address.
If
not,
we
can
jump
into
reference
policy.
A
Okay,
so
reference
policy,
the
the
sentence
here,
the
the
what
I'm
sharing
here
itself,
kind
of
points
to
what
we
need
to
address
currently
there's
no
mechanism
to
restrict
which
users
can
get
access
to
which
bucket.
A
We
said
that
within
a
namespace,
anyone
can
access
any
bucket.
If
it
was
created
by
someone
in
that
namespace,
there
are
no
restrictions
within
the
namespace
we're
using
namespace
as
that
boundary
now
across
namespaces.
A
We
want
to
set
up
this
boundary
where
some
some
there
should
be
some
mechanism
to
ensure
that
people
who
want
to
gain
access
to
a
bucket
in
a
different
name
space
should
only
do
so
if
they
have
explicitly
been
granted
permissions
to
do
it
and
that's
when
we
stumbled
into
this
this
idea
of
reference
policy,
it's
where
you
can
define
a
policy
which
says
these
are
the
resources
which
defines
what
resources
you
can
refer
to
from
another
resource,
so,
for
instance,
what
kind
of
or
which
buckets
can
be
referred
to
by
by
a
new
bucket
claim
or
by
a
new
bucket
access.
A
So
let
me
let
me
open
up.
I
believe
we
had
a
document
on
this
at
one
point,
let
me
see
if
I
have
that
still.
A
So
we
said
I'm
just
going
over
this
again
after
a
long
time,
so
just
bear
with
me.
While
I
try
to
figure
what
I've
done
here.
So
what
we've
said
here
is
from
resources
bucket
access
in
namespace
alice.
A
Is
this?
Does
anyone
then
is,
do
you
remember
where
we
left
off
this
conversation.
G
A
G
To
not
do
this
in
the
alpha
version
and
we
had
convinced
ourselves
that
there
was
a
way
to
do
it
eventually.
I
I
don't
know
if
I
mean
I
remember
that
the
version
of
the
reference
policy
we
were
looking
at
a
couple
months
back
was
like
not
not
done
like
it
was
a
proposal
or
something
yeah.
Is
it
the
case
now
that,
like
reference
policies,
are
officially
supported
or
usable.
G
I
mean
I
don't
know
how
we
can
implement
anything
until
there's
something
to
implement
on
top
of,
and
I'd
be,
very
nervous
about,
delving
too
deep.
You
know,
while
they
might
still
change
something
on
us,
unless
we
want
to
like
go
get
involved
in
that
community
and
talk,
you
know,
make
suggestions
about
how
they
should
design
the
reference
policy
or
something
I
I.
A
No,
so
we
we've
already
gotten
in
touch
with
cigar
and
we're
gonna
go
ahead
with
our
own
implementation
of
reference
policy
and
and
then
they're
going
to
oh.
G
F
Yeah
yeah-
probably
not,
but
coming
back
to
this
so.
G
So
so
my
concern
with
if
we're
gonna
go
off
and
develop
our
own
thing,
then
the
the
way
that
the
original
reference
policy
was
sketched
out
was
significantly
more
complicated
than
what
we
needed
right,
because
we
we
don't
need
any
type
information
or
any
of
that
kind
of
stuff.
Because
it's
all
inferred
right.
We
know
what
the
what
the
referent
type
is
and
what
the
referee
type
is,
and
it's
just
a
matter
of
putting
some
names
in
an
object.
And
then
it's
a
name
space
right.
That
says
this.
G
We
could,
if
it's,
if
it's
an
object
just
for
us,
we
could
simplify
it
dramatically
and
just
have
a
few
fields
that
express
what
we
actually
care
about
and
then,
if,
if
the
real
reference
policy
that
eventually
emerges
is
significantly
more
flexible
and
then
either
we
can
map
onto
it,
in
which
case
we
do
or
we
can't,
in
which
case
we
stick
with
our
simple
thing
that
works,
but
I
wouldn't
I
wouldn't
attempt
to
design
the
complicated
thing
on
their
behalf
when
they're
not
even
done
yet.
A
G
A
D
G
A
Yeah,
so
we
can
just
call
it
bucket
reference
policy
instead
of
a
generic
reference
policy,
and
it
basically
just
defines
what
namespace
can
access
what
buckets.
That's
it.
G
G
A
In
world
do
we
have
to
yeah?
This
is
where
it
gets.
I
don't
want
to
complicate
it,
but
maybe
it's
worth
just
thinking
about
whether
we
should
also
define
what
kind
of
access
is
possible.
G
A
Yeah,
so
I
think
I
think
we
did
oh,
so
I
do
you
mean
in
in
the
references
you
mean.
G
D
G
B
G
A
G
I
mean
it
would
be
nice
to
say,
like
this.
Guy
has
read
only
access,
but
the
problem
is,
is
that
you
have
to
put
the
bucket
access
class
name
in
the
reference
policy
and
the
meaning
of
the
bucket
access
class
can
change
over
time
right
if
someone
changes
the
bucket
accident,
and
so
it's
like
from
a
security
perspective,
it's
it's
kind
of
like
standing
on
sand.
G
You
know
you
could
you
could
sink
in
if,
if
someone
changes
something
underneath
you,
it
doesn't
seem
like
a
good
way
to
to
do
security.
A
A
A
A
Gateway
the
gateway
folks
are,
I
think
they
abandoned
the
idea
of
reference
policy
they're
doing
it
a
different
way.
Now.
G
F
A
Is
the
new
thing
better?
I
mean.
D
C
If
you
look
at
the
yeah,
it
actually
has
still
has
this
diagram.
It's
like
shared,
it's
still
somewhere
and
then
there's
the
diagram.
So
I
was
trying
to
figure
out
what
how
the
it
can
look
like.
C
G
A
Yeah
so
they
have
yeah.
This
is
kind
of
what
we
talked
about
and
we
thought
was
not
a
good
idea,
so
they
have
this
option
of
sharing
is,
is
defined
up
front
same
name.
Space
is
the
default
option
only
routes
in
the
same
namespace
as
this
gateway
may
be
attached,
all
is
all
name
spaces
and
selector
is
based
on
names.
We
selectors.
G
G
Yeah
yeah,
I
mean
normal
people
can't
edit
namespaces
so
yeah
I
mean
you
could
imagine
a
scheme
like
that
right.
So
so
then,
at
that
point
for
the
buckets
whole
lifetime,
the
question
of
whether
a
given
bucket
access
can
bind
to
it
or
not.
Can't
change
right.
It's
a
well!
I
guess
in
a
selector
someone
could
modify
the
names,
but
I
don't
know.
A
A
I
I
what
I
want
to
figure
out
is
why
why
they've
entered
this
route
instead
of
doing
the
reference
policy,
we
need
to
get
in
touch
with
them.
G
G
Is
there
a
better
way
because,
because
the
reference
policies
had
some
advantages,
but
it's
also
feels
extra
complicated
to
have
another
object
for
this
strange
use
case,
not
a
strange
use
case.
I
mean
like
it's
a
use
case
that
we
expect
to
be
reasonably
common
and
and
to
like,
introduce
a
whole
new
object
just
to
address
it.
A
G
Although
the
problem
was
was
that
it
could
only
be
modified
by
the
administrator,
we
we
never
created
a
scheme
to
upfront
at
bucket
creation.
Time
say
I
want
to
share
my
bucket
with
alice,
find
bob,
or
vice
versa,
whereas
they
seem
to
have
done
that
we
were
always
assuming
that
this
was
something
you
would
do
after
the
fact.
G
A
So
the
difference
between
them
and
us
is
gateways
are
admin
controlled
entirely
from
what
I'm
reading,
I
don't
think
a
gateway
can
be
defined
by
a
user,
so
the
admin
gets
to
create
the
gateway
with
these
parameters
up
front,
so
the
admin
would
know
what
are
the
other
name
spaces.
The
admin
would
know
just
they'll
have
full
view
into
the
cluster,
whereas.
A
The
bucket
is
created
by
a
bucket,
you
know,
user,
who
creates
a
bucket
claim
and,
and
a
user
doesn't
know
like,
wouldn't
know
just
what's
out
there
and
who
to
give.
G
So
so
so
you
could
take
the
view
that
you
know
four
buckets
that
are
meant
to
be
shared
across
multiple
namespaces,
like
those
are
going
to
be
the
responsibility
of
the
administrator.
The
administrator
should
create
a
special
shared
bucket
name
space,
put
all
the
shared
buckets
there
and
set
up
whatever
needs
to
be
set
up
to
give
everyone
access
to
those
shared
buckets
and
then
for
people
who
create
their
own
buckets
in
their
own
name
spaces
like
those
ones
can't
be
shared
like
you
could
look
at
it.
G
That
way,
and
just
say
this
is
an
admin
problem
and
ordinary
users
can
do
self-service,
but
they
can't
do
self-service
sharing.
I
think
we
had
been.
We
had
been
presume.
You
know
we
had
been
going
along
the
lines
of.
We
want
two
individual
users
to
just
be
able
to
collaborate
by
creating
a
bucket
and
then
sharing
it.
But
I
don't
know
if
that
really
exists
in
the
kubernetes
world.
Like
I
don't.
A
You're
right
actually
yeah,
if
you're,
sharing
it
across
namespaces.
Getting
an
admin
involved
is
probably
the
right
thing
to
do
and
I
don't
think
anybody
any
other
resources
work
any
other
way.
You
have
to
get
the
admin
involved.
Like
I
mean,
except
if
it's
a
service
or
something
potentially.
G
You
know
namespace
transfers
for
things
like
pvcs
and
snapshots
that
are
that
don't
require
an
administrator,
because
we
we
somehow
thought
that
was
an
important
thing
to
do
and
what
I,
what
I
don't
know
is:
are
there
people
out
there
who
are
like
sharing
a
kubernetes
cluster
but
not
sharing,
namespaces
and
talking
to
each
other
and
wanting
to
collaborate
like?
Is
that
a
thing
that
happens
or
is
it
just
the
case
that
people
who
work
together
are
in
the
same
name,
space.
G
Yeah,
but
I
mean
I
I'm
trying
to
think
of
a
real
world
situation
where
you
have
a
kubernetes
cluster
and
a
bunch
of
users,
that
kind
of
don't
trust
each
other,
but
still
need
to
interact
a
little
bit,
and
so
they
have
their
own
name
spaces
and
then
they're
yeah.
You
can
share
services
across
name
spaces
and
presumably
there's
some
out-of-band
communication
where
you
become
aware
of
them,
but
like
for
data
storage,
is
it
the
same?
G
Yeah
I
mean
we've
always
had
that
freedom,
but
but
we
don't
want
to
design
for
the
situation
that
doesn't
really
exist,
which
is
which
is
why
I'm
nervous
about
you
know.
G
I'm
nervous
about
spending
a
bunch
of
our
time.
You
know
trying
to
design
that
when
it
might
not
be
something
anyone
cares
about.
You
know.
The
more
important
thing
is
the
self-service
use
case
and
the
the
admin
creating
a
shared
one
use
case
and
then
maybe
a
distant
third
is
two
two
ordinary
users
collaborating
with
each
other.
A
So
I
think
I
think
one
of
our
requirements
was.
A
G
A
So,
generally
this
you
know
in
any
big
data
workload
that
kind
of
sends
data
to
object,
storage,
there's
a
there's,
a
separate
set
of
services
that
that
push
data
in
and
there's
a
separate
set
that
actually
process
it.
I'm
I'm
looking
at
like
one
one
one
common
use
case
that
we
see
with
many
other
deployments.
A
Fair
enough,
okay!
So
let's
do
this,
then,
let's,
let's
talk
to
these
guys
at
gateway
api
and
find
out
why
they've
gotten!
A
You
know
why
they've
moved
on
from
from
the
reference
policy
approach
and
I'll
I'll
also
look
into
how
people
deploy
mineo
and
see
if,
if
they're
in
the
same
namespace
or
not,
I
don't
think
it
matters
as
much,
but
it's
worth
knowing
curious
anyways,
because
I
think
we
can
keep
going
in
circles,
but
I
feel
like
we
don't
have
enough
information
to
really
understand
why
why
it
was
done
this
way
we
can
and
and
then
we
can,
the
open
question
still
remains:
should
the
user
be
able
to
set
up
or
define
who
gets
to
use
which
bucket
or
or
is
it
the
admin?
A
Who
does
this?
I
mean
there's
another
question
that
kind
of
comes
along
the
way
when
you
ask
that
question,
which
is,
which
is
how
many
buckets
are
going
to
be
there?
If
there's
going
to
be
lots,
something
that
that
that's
going
to
tax
the
admin
a
lot,
then
then
it's
reasonable
to
say
the
user
should
be
able
to
do
it,
but
I
don't
think.
That's
generally
the
case.
E
The
way
they're
doing
it
here
seems
to
make
sense
for
that
a
user
would
choose
whether
they
don't
want
it
to
be
shared.
They
want
to
be
shared
with
all
or
they
want
to
be
shared
with
the
select
group
that
is
known
and
then,
if
there's
a
new
group
that
comes
along
or
a
new
namespace
that
comes
along,
then
the
admin
would
have
to
get
involved.
To
add
that
namespace
as
an
option
right.
E
E
Or
all
right
or
the
selection
that
they
know
of
at
that
time
at
the
time
of
creating
the
bucket
yeah.
And
if,
if
you,
in
that
one-off
use
case
or
whatever,
that
a
new
namespace
comes
along,
that
you
want
to
share
a
bucket
with
an
admin,
would
have
to
get
involved
to
modify
the
namespace
either
modify
the
namespace
or
modify
the
the
selector
list
so
that
that
new
name
space
could
be
added.
But.
G
A
There's
no
links
to
it.
I
think
they
just
left
the
old
pages,
as
it
is
so
it's
probably
hosted
on
github
no.
A
Yeah,
but
I
like
what
we're
talking
about
what
you're
saying
is
we're
not
aiming
for
a
100
self-service
it
is.
It
is
self
service.
As
long
as
you're
you
define
upfront
who
all
gets
access
to
your
bucket,
but
if
you
need
changes
beyond
that,
you
get
an
admin
involved
and
okay,
so
then
then
comes
the
question
of
who
all
can
you
allow
to
access
this
bucket?
So
let's
say
I'm
user
foo
and
I'm
working
in
namespace
foo.
A
A
Isn't
foo
kind
of
super
privileged
now.
E
A
A
Something
makes
me
apprehensive
about,
like
we've
discussed
this
for
a
long
time
and
I'm
wondering
if
there's
something
we
missed
when
we
just
discussed
this
idea
right
now,.
E
E
A
Yeah
yeah,
this
is
actually
simpler
and
it's
clear.
I
I
like
this
approach.
We
we,
we
have
simplified
the
scope
here
for
sure
all
right.
So
next
steps.
E
A
A
A
A
Well:
okay,
yeah
yeah!
I
I
I
like
this.
Actually
it's
simpler.
I
like
this
approach,
but
I
still
want
to
talk
to
cigar
or
these
guys
at
gateway
api
figure
out.
Why
they've
gone
with
this
approach?
A
G
Well,
if
you
wanted
flexibility,
you
would
use
the
selector
scheme
and
then
put
like
labels
on
namespaces
and
do
it
that
way
and
you
get
your
flexibility.
But
if
you
did
pick
static
listed
namespaces,
it's
not
clear
that
an
admin
could
modify
that
list.
Maybe
he
can.
Maybe
he
can't
depends
on
admission.
A
All
right,
okay,
so
I'll
I'll,
follow
up
with
the
cigar
and
well
gateway
api
and
I'll
find
out
why
it
was
done
this
way.
A
That's
all
I
have
for
today.
I
want
to
start
implementing
this.
I
want
to
start
writing
code.
I
think,
since
we've
been
kind
of
going
back
and
forth,
we've
kind
of
just
fallen
back
on
just
having
something
to
show,
so
I'm
just
going
to
start
start
writing
some
code
and
and
having
something
that
that's
demo-able
well.
Well,
it
might
not
be
fully
flushed
out
or
production
quality.
A
It
should
be
demo
already
at
least.
I
think
the
way
the
way
we
can
start
showing
it
to
people
and
even
proving
that
some
of
our
designs
work
and
while
implementing
we
might
even
run
into
some
issues
that
that
we
didn't
foresee
so
so
I
so
I'm
just
gonna,
I'm
announcing
it
here,
because
if
there's
anyone
here
who
who
wants
to
contribute
or
anyone
here
who
knows
someone
who
can
contribute,
please
please
put
them
in
touch
with
me.