►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 16 December 2021
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
Hey
so
we
updated
the
cap
with
everything
we
talked
about
last
week,
so
the
next
thing
to
talk
about
is
reference
policy
and
that's
something:
we've
not
gotten
into
whatsoever.
So.
A
No
for
the
for
the
current
release,
where
we
left
off
last
week
completes
the
picture,
but
one
part
of
it,
which
is
bucket
sharing.
We've
we've
been
saying
that
across
namespaces,
bucket
sharing
is
currently
free
for
all
that
is.
Anyone
who
creates
a
bucket
in
any
namespace
can
be
can
be
utilized
that
that
bucket
can
be
accessed
from
a
different
name
space,
with
with
no
restrictions
that.
C
D
Sense
but
I
like
to
say
sorry
to
interrupt
like
last
week,
there
was
a
discussion
whether
we
need
to
host
it
all
or
like
need
to
provide
or
like,
and
I
don't
know
whether
we
made
a
conclusion
about
that.
We
still
a
small
key
into
the
stitched
on
like
only
provide
access
to
the
name
space
where
the
bucket
is
created
or
something
like
that
and
later.
A
Yeah,
that
was
the
other
other
idea,
which
was
maybe
just
cannot
be
scared.
You
know
at
alpha
so
but
then.
B
That
will
be
very
limited
right.
I
thought
we
were
talking
about
similar
to
pubvc,
then
in
that
case
you
admin
can
actually
make
it
available
admin.
Basically,
this
is
like
admin
is
the
one
who
make
a
decision
right.
So
if
admin
allows
this
one
to
be
shared
by
others,
then
that's
fine.
Basically,
this
admin
will
be
creating
another
bucket
pulling
into
the
same
physical
bucket
right
in
that
case
yeah.
So
think
that
should
be
fine,
because
this
is
the
same
as
what
we
do
with
like
volumes.
A
A
So,
that's,
that's!
That's
what
we
discussed
last
week
so
different!
Yes,
so
we
were
still
going
to
love
free-for-all
access.
The
the
way
we
did
it
was
the
admin
would
go
and
create
a
copy
of
the
bucket
that
can
be
used
in
other
namespaces.
A
Yeah,
so
let's
get
into
reference
policy,
so
the
idea
of
reference
policy
is,
we
want
to
restrict
who
gets
to
access
what
bucket,
especially
if
a
bucket
is
created
in
one
name
space,
and
we
want
the
bucket
to
be
accessed
from
a
different
name
space.
What
kind
of
odd
z
or
not,
and
we
can
force
on
it,
is,
is
or
are
going
back
to
requirements.
Let
us
first
define
what
kind
of
authorization
constraints
we
need
to.
A
We
need
to
place
on
it,
so
so
so
so
far
the
assumption
has
been
if
a
bucket
was
created
in
one
namespace
or
if
bucket
was
created
in
response
to
a
claim
in
one
namespace
that
bucket
should
not
by
default,
be
accessible
in
other
namespaces.
A
However,
there
is,
there
are
legitimate
reasons
to
imagine
why
we
want
the
bucket
to
be
accessible
from
other
spaces,
especially
because
buckets
are
by
by
definition
over
the
network
and
it's
it's
meant
to
be
utilized.
A
Across
clusters,
even
across
name
spaces,
so
so
in
order
to
restrict
who
gets
to
access
what
buckets
and
what
kind
of
access
they
get
to
those
buckets,
we
were
trying
for
a
long
time
to
figure
out
a
clean
solution
until
this
concept
of
reference
policy
came
along,
which
was
originally
proposed
by
the
gateway
api
group.
A
A
A
There
it
is
seriously
anyway,
so
here
it
is
crosstalk,
which
is
references
so.
B
A
So
I
want
to
finalize
this,
if
possible,
or
at
least
make
some
progress
on
how
our
reference
policies
will
look
like,
so
the
idea
currently
is,
we
will
develop
this
independently
and
once
we
both
have
working
solutions.
Sig
art
is
going
to
take
this
and
make
a
more
generic
one
that
that
we
can
switch
over
to
once.
That
is
ready,
but
for
now
we
have
we
have
the
green
light
to
develop
our
own
and
and
bring
it
up.
A
So,
in
this
case,
what's
being
discussed,
is
they
have
a
http
route,
and
here
they
want
to
define
from
which
name
spaces
this
http
route
can
be
accessed
so
the
way
they
define
it
is
they
created
a
reference
policy
which
says
from
this
apis
in
this
namespace
they
can
refer
to
code
service
in
bar
namespace.
A
So,
given
that
this
reference
policy
exists,
it
is
now
allowed
for
http
routes
created
in
namespace
foo
to
refer
to
services
in
namespace
bar
without
it
without
it,
it
wouldn't
be
allowed.
This
policy
explicitly
allows
you
to
to
make
that
reference
or
allows
others
to
make
that
reference
to
this
namespace.
A
Creating
a
bucket,
then,
if
the
user
wants
someone
else
to
also
refer
to
the
bucket,
they
would
have
to
create
a
reference
policy
allowing
people
from
other
name
spaces
to
access
this
bucket.
A
So
here's
where
it
gets
tricky
because
bucket
is
a
is
not
a
namespace
resource.
It
is.
It
is
a
cluster
of
research,
it's
a
global
one.
So
so
really
the
reference
policy
would
have
to
be
set
on
the
cluster
resource
or
we
need
to
start
allowing
people
to
refer
to
the
bucket
claim
instead
of
the
bucket
directly.
D
D
A
Yeah,
I
don't
think
we
made
a
decision,
though
yeah
I
I
remember
having
the
discussion.
The
the
question
at
that
point,
where
we
left
off
was
who
who
defines
the
reference
policy?
A
The
the
problem
remained
that
if,
if
the
creator
of
the
bucket
or
the
creator
of
the
bucket
claim
defines
a
reference
policy,
do
they
define
it
for
the
bucket
itself
or
do
they
define
it
for
the
bucket
claim
and
and
if
they
define
it,
for
the
bucket
claim,
as
in,
if
they
say
a
reference
policy,
saying
that
say
their
name,
space
foo
and
they
say
namespace
bar
can
cr
can
have
references
to
my
bucket
claim.
Then
in
name
space
bar,
they
would
have
to.
A
You
know,
start
referring
to
bucket
claims
and
other
name
spaces.
Bucket
claims
are
the
equivalent
of
bucket
requests
instead
of
directly
referring
to
the
bucket.
So
that
changes
our
api
model.
Doesn't
it.
A
So
I
have,
I
have
a
bucket
claim
say
in
say
this
is
in.
A
B
C
A
A
Right
and-
and
let's
say
this
is
from
this
nexus
bar,
so
I
have
a
bucket
claim.
Do
I
do
I
point
to
another
bucket
claim
or
or
is
this
just
bucket
access.
A
A
A
C
A
C
A
So
what
different
brought
up
earlier,
we
want
to
love
any
sort
of
bucket
sharing
across
namespaces.
Someone
really
wants
to
do
it,
get
an
admin
to
create
another
copy
of
the
bucket
and
then
have
that
be
pointed
to
from
a
rocket
claim
in
a
particular
name,
space.
C
Yeah
I
mean
many
things
are
possible
with
with
admin
magic.
I
think
we
would
be
wise
to
limit
the
scope
of
what
we
support
to
some
bare
minimum
that
we
really
like
and
then
and
say.
If
it's
not
good
enough,
you
know
come
back
for
beta
or
or
do
it
yourself
right
that
that's
always
the
escape
hatches
we'll
get
around
to
it
and
if
you're
impatient,
you
know,
go
invent
your
own
solution.
A
Yeah
yeah,
I
think
that's
the
approach
we're
taking
so
so
really
pre-alpha
or
before
we
reach
alpha
in
terms
of
open
questions.
A
We
don't
have
that
many
left,
I
mean
the
one
open
question
is:
when
is
someone
going
to
review
the
cap
but
other
than
that
in
terms
of
design?
We
don't
have
many
open
questions
left.
A
C
Did
we
close
on
the
the
very
thorny
I
am
mechanism.
C
A
We
we've
gone
through
the
steps,
but
we
don't
have
like
a
poc.
C
A
Okay,
so
yeah
that
gets
tied
to
the
workload,
identity
and
or
that
gets
tied
to
the
cloud
identity
and
whenever
the
pod
or
another
sdk
queries
the
internal
metadata
service.
With
this,
with
this
particular
token,
it
gets
identified
as.
C
A
That's
how
I
am
should
work,
and
I
get
that
yeah
just
a
way
to
get
rid
of.
You
know,
access
credentials
that
are
that
can
move
around
it's
tied
to
the
the
instance
and
and
that's
it,
it's
not
tied
to
an
account.
Even
if
someone
were
to
get
a
hold
of
it
unless
they're
on
an
instance,
they
can't
really
do
anything.
A
So
so
that's
all.
I
miss
instant
access
management.
A
So
so
yeah
that
that's
where
we
conclude
with
iam.
A
Yeah,
so
really
we
have
to
get
back
into.
I
mean
the
main
concerns
that
are
remaining
are
one
is
reference
policy.
I
think
reference
policy
is
not
going
to
be
as
simple
as
what
we
just
discussed.
I
think
there
are
going
to
be
more
more
edge
cases
that
will
come
up,
but
other
than
that.
I
think
I
think
this
this
you
know
things
like
onboarding
new,
new
cozy
drivers.
A
That's
going
to
be
a
thing
inviting
a
bunch
of
other
clouds,
that's
going
to
be
a
thing
that
we'll
focus
on,
but
other
than
that
for
alpha
itself.
Technical
questions
wise,
I
think
we're
pretty
solid
right
now
and
mitchell
has
been
a
part
of
the
discussion.
She's
he's
gonna
be
one
of
the
reviewers
from
what
I
understand.
A
So
as
the
next
step,
unless
we
want
to
answer
this
question
of
reference
policy
right
away
and
then
and
you
know,
move
forward-
I
think
it's-
I
think
it's
okay,
okay,
to
say
no
to
that
question.
I
think
it's
okay
to
fund
this
for
later
and
conclude.
You
know
about
alpha
for
right
now,
just
just
if,
if
you
feel
like
there's
nothing
more
to
discuss
on
alpha,
then
then
we
can
actually
conclude
even
right
away
the
meeting
and
we
can
reconvene
you
know
for
the
next.
B
A
Where,
where
we,
we
can
start
with
the
new
steps
right
now,
I
don't
think
misha
is
on
this
call
and
let
me
check,
but
really
there's
nothing.
Much
else
talk
about,
if
not
for
this.
C
B
B
It's
she's,
probably
off
already,
but
I'll
ping
her
and
see
if
response
just
being
hard
to
review
the
cap,
because
it's
important
to
get
her
review,
it
is
at
least,
I
think
she
is
more
available
than
and
team
team
is
even
more
busier.
So
yeah.
A
Yeah,
it's
good
that
you
know
we
have
another
reviewer,
so
so
yeah.
So
if
that's
the
case
again,
like
I
said
we
can,
we
can
conclude
for
now
and
we
can.
We
can
follow
with
michelle
and
we
can
go
from
there.
B
All
right,
so
we
are
going
to
cancel
the
next
two
meetings
and
meet
again
the
new
year.
Then
okay,
then
happy
holidays
to
you.
Everyone.