►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting- 16 September 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
B
A
B
Any
better
now
yeah,
perfect,
okay,
okay,
so
I
got
a
chance
to
attend
segat's
bi-weekly
meeting
today
or
yesterday
to
talk
about
cross
namespace
resource
sharing.
So
one
of
the
one
of
the
remaining
items
in
our
cap
and
in
our
you
know
something
in
our
way
of
getting
to
alpha
has
been
this.
This
you
know
a
good
mechanism
to
share
resources
across
namespaces.
B
There
was
never
a
very
clean
approach
to
do
this
and
you
know
it
makes
sense
that
you
know,
even
though
we
we've
had
a
lot
of
different
people,
some
of
the
most
capable
people
in
the
community
come
and
contribute
in
this
group
we've
it's
been,
it's
been
difficult
to
find
a
good
model,
but
luckily
you
know-
or
not
luckily,
but
more
like.
This
is
not
a
problem.
B
Just
that's
just
that
we're
the
only
ones
dealing
with
there
are
other
groups
that
that
have
the
same
problems,
so
I
wanna
quickly
go
over
what
the
gateway
api
is
and
how
they're
struggling
with
the
same
issue
or
how
they're
trying
to
solve
the
same
issue.
B
Let
me
put
it
that
way
and
and
and
what
we're
going
to
do
moving
forward
with
with
with
a
possible
solution,
so
the
gateway
api
is
very
similar
to
to
bucket
api,
where
they
need
cross
name
space
access
to
a
particular
resource.
B
Oh
on
the
on
the
screen,
I
do,
I
don't
have
something
ready
to
share.
Actually,
unfortunately,
let
me
see
if
I
can
find
something.
B
Yeah
I'm
looking
for
it.
Do
you
have
a
link
tradition
that
I
can
show.
B
Okay:
okay,
hey
one
more
thing,
so
I
remember
last
week
mauricio
came
and
he
mentioned
that
it
would
be
good
if
we
took
notes.
Is
there
anyone
here
who
could
help
with
that.
B
B
All
right
yeah-
this
is
the
this-
is
the
this.
Is
their
proposal
yeah
between
it's
possible
for
them
to
refer
to
objects
across
namespaces?
So
now
a
gateway
is.
C
B
No
cap
is
not
merged
either
so
yeah
yeah,
as
of
yesterday,
all
we
decided
was
what
we're
going
to
do
about.
This
is
cigar
okay,
with
us
going
and
using
this
across
in
in
both
gateway,
api
and
bucket
api,
and
what
cigar
said
was
actually
both
of
us
can
develop
our
own
implementations
of
reference
policy,
which
more
or
less,
are
going
to
be
very
similar,
and
then
they
can
once
it's
proven
out
by
either
of
us
or
both
of
us.
A
For
snapshots,
it
makes
sense
to
me
for
pvcs.
I
would
need
to
know
more
so
so
my.
A
Yeah
yeah
I
mean
if
we
can
economize,
we
absolutely
should.
My
big
questions
are
first
of
all,
looking
at
this
proposal
here
I
don't
see
an
actual
example
of
what
a
reference
policy
looks
like
I
don't
see
which
oh
I
see
the
yaml
is
an
embed
is
a
double
two
things
in
the
same
yemo,
okay,
so
the
reference
policy
has.
A
It's
a
namespace
thing.
I
guess
the
name
of
the
reference
policy
is
irrelevant
or
no
wait.
Oh
no.
The
the
http
route
refers
to
the
reference
policy
with
a
rule
that
matches
look
forward
to
okay.
I
I
don't
really
understand
what's
going
on
here,
but
the
important
question
is
like
what
things
get
replicated
in
this
scheme
and
what
things
don't
get
replicated
in
this
scheme.
So
it
looks
like
there's
at
least
two
different
http
route
objects.
B
B
And,
and
the
thing
is
if,
if,
if
me,
as
as
the
infrastructure,
admin
would
like
to
specify
rules
for
two
different
teams,
each
one
in
its
own
name,
space
I'll,
need
something
like
this.
B
No
140
yeah
one
for
each
rule,
I'll
end
up
with
an
http
object
and,
along
with
that,
a
reference
policy
that
that
allows
me
to
refer
to
that
that
service
in
that
in
that
namespace.
Yes,.
A
B
A
I'm
just
what
I'm.
What
I
want
to
make
sure
of
here
is
that,
like
what
they're
doing
is
similar
enough
to
what
we're
doing
in
terms
of
like,
are
they
actually
taking
a
cookie
cutter
and
stamping
multiple
cookies
with
the
cookie
cutter?
Are
they
actually
sharing
one
cookie?
You
know
that
that
they're,
just
that,
neither
one
is
consuming
because,
like
with
the
snapshot,
it
makes
sense
to
say,
okay,
you
know
I
have
a
snapshot,
you
can
clone
it,
I
can
clone
it.
Alice
can
clone
it.
Bob
can
clone
it
like.
A
We
can
all
clone
the
snapshot,
because
we're
going
to
end
up
with
a
bunch
of
different
volumes
that
will
not
be
shared.
So
if
you
share
the
snapshot,
nothing
can
go
wrong.
If
you
try
to
share
pvc,
lots
of
things
can
go
wrong,
because
if,
if
alice
and
bob
try
to
use
the
same
pvc
at
the
same
time,
you
know
you
can
have
all
kinds
of
attachment
problems
all
the
same
problems
you
have
when
you
try
to
attach
multiple
pods
to
a
pvc
in
your
namespace,
and
so
it's
like
you
have
to
think
through.
A
Is
that
really
what
you
want
and
then,
similarly,
if
we
extend
the
buckets,
you
know,
are
we
sharing
the
bucket?
Are
we
sharing
the
bucket
access
like
what
are
we
sharing
and
just
making
sure
that
the
thing
that
gets
shared,
if
there's
no
downsides
to
having
it
be
accessible
to
a
bunch
of
different
name
spaces
in
its
raw.
C
C
B
Yeah,
so
so,
actually,
if
you
can
use
reference
policy,
I
I
don't
see
why
I
even
need
you
know
we,
we
don't
need
bucket
access
to
be
name
space
or
to
be
global,
and
I'm
thinking,
why
do
we
even
need
buckets
to
be
global?
Assuming
that's
what
we
refer
to.
B
One
reason
could
be
that
we
want
buckets
to
outlast
the
name
space-
that's
fair,
but
but
coming
back
to
bucket
accesses.
A
B
I
mean
so
we
don't
have
to
think
of
them
as
two
two
separate
mechanisms
in
the
sense.
Let's
just
go
with
this
idea
that
you
you,
you
know
you
either
you
either
refer
to
the
bucket
a
request
in
the
same
name,
space
or
you
refer
to
a
bucket
directly
in
in
your
bucket
access
request.
A
D
B
A
A
There
is
already
a
bucket
and
I
want
to
be
able
to
refer
to
it
and
then,
in
both
cases
you
want
to
be
able
to
share
it
potentially
or,
and
you
also
want
to
be
able
to
say
no
sharing.
I
want
to
say
this
is
my
bucket:
keep
your
paws
off
it
right.
You
might
want
to
be
able
to
enforce
that,
and
so
you
just
need
to
have
a
clear
way
to
achieve
each
desired
outcome.
B
Yeah
yeah,
so
so
so
I
see
where
your
question
is
coming
from
you
you're
saying,
if
you're
referring
to
the
b
anyways,
why
do
we
need
to
you
know,
have
this
mechanism
to
refer
to
a
like
you,
you're,
not
going
to
refer
to
a
br
in
a
different
name,
space.
A
B
A
B
We're
missing
a
simple
approach
here.
The
the
simple
similar
approach
here
is
a
reference
policy
need
not
always
be
to
name
space
resources.
Reference
policy
can
be
two
clustered
resources,
so
so
we
could
set
a
reference
policy
that
says
only
bas
from
this
namespace
or
matching
some
parameter
can
can
refer
to
this
bucket.
That's
what
you
get
to
say.
A
A
B
D
B
B
So
like
like,
like,
like
the
who
can
be
an
anti-name
space
because
it
doesn't
make
sense
to
constrain
any
further
namespace
being
the
you
know,
the
the
security
domain
and
and
per
bucket
you
get
to
set
rules
now.
B
B
B
So
so,
okay,
so
I
see
what
they're
saying
so,
if
bob
creates
a
br
that
ends
up
creating
a
bucket
and
bob
decides
that
this
bucket
should
only
be
usable
from
namespace,
x,
y
and
z,
none
of
the
other
namespaces,
then
bob
creates
three
reference
policies
having
the
from
b
or
or
you
know,
from
the
name,
spaces
x,
y
and
z,
and
to
be
the
the
actual
bucket.
A
To
the
bucket
okay,
so
once
they
have
bucket
like
now,
they
need
to
go,
create
their
own
bucket
accesses
to
get
their
own
credentials
right,
okay
and
and
once
they
do
that,
if
even
if,
even
if
the
original
creator
of
the
bucket
revokes
the
reference
policy
or
changes
it
such
that
they
can't
access
it
anymore,
they
already
have
their
own
bars.
B
Other
nations,
you
could
revoke
those-
I
mean
the
the
reference
policy,
so
that
was
a
good
question
that
came
up
during
the
meeting.
One
is:
how
do
you
deal
with
reference
policy
revocation
because
it
has
to
be
domain
specific,
so
so,
in
case
of
the
bucket
reference
policy,
we
will
need
the
bucket
reference
policy
controller,
I'm
just
giving
it
a
name
right
here
to
to
go
ahead
and
listen
on
events,
deletion,
events
and
and
if
a
particular
reference
policy
is
deleted.
A
B
But
it's
it's
not!
It's
not
very
different
from
taking
out
a
role
for
a
particular
service
account
that
a
pod
is
using
so
but.
A
B
Don't
here
we're
talking
about
that,
we
can
just
revoke
access,
so
you
know
it's
no
different
from
that.
I
don't
think
it's
a
lot
of
work
per
se.
I
know
it's
it's
a
new
way
to
do
this,
but
but
I
don't
think
it's
it's
a
lot
of
work
right
like
I.
A
B
A
A
B
No,
no,
it's
not
comfortable,
though
I
mean
right
now.
Let's,
let's
I
mean
implementation
aside,
there
are
some
unanswered
questions
that
design
itself.
How
about
we
address
them.
First,
like,
for
instance
like,
for
instance,
let's
say
I
create
the
bucket
and
I
create
the
br,
which
leads
to
a
bucket
being
created.
B
B
A
A
The
retention
policy
is
triggered
by
the
the
deletion
of
my
name
space,
but
if,
but
if
they're,
if
the
bucket
is
retained,
and
so
my
name
space
can
go
away
without
deletion
of
the
bucket,
but
the
reference
policy
is
in
my
namespace.
It
goes
away
what
about
other
people
that
had
access
to
the
bucket
before
my
namespace
was
deleted?
Did
they
continue
to
have
access
to
the
bucket,
even
after
the
retention
policy
has
been
wiped
out
I
mean
not
the
retention
policy,
the
the
reference
policy.
B
B
It's
possible
right
with
an
annotation
annotation
or
a
field
whatever
in
the
reference
policy
that
says,
even
after
this
is
gone
or
it's
like
ignored
during
execution,
you
know,
prefer
you
know,
used
during
scheduling.
It's
like
that.
A
Right
but
but
then,
even
if
you
have
a
some
some
signal
that
tells
the
system
you
know
leave,
leave
existing
br
or
bucket
accesses
intact.
When
the
namespace
goes
away,
you
still
can't
create
new
ones.
You
still
don't
know
what
to
do
with
all
the
existing
objects
when
they
get
deleted
right.
You
just
have
a
bunch
of
stuff
flying
around
that
can
that
you
can
use
to
access
the
bucket,
but
if
you
ever
want
to
get
that
bucket
back
into
usable
shape,
you're
going
to
have
to
do
some
serious
work.
B
But
that
problem
always
existed
with
with
the
name
says
going
away,
so
so
the
one
problem
of
what
can
we
do
if
the
bucket
reference
policy
goes
away?
The
answer
was
what
I
just
said.
That
would
work
where
you
have
some
sort
of
you
know
reference
or
some
sort
of
parameter
on
the
reference
policy
that
says
let
this
reference
stick
around.
Even
if
you
know
during
the
execution,
just
don't
allow
new
references
to
happen
so.
A
A
Okay,
so
there
are
no
bsp
errors,
so
so,
if
I
can
reference
a
bucket,
that
means
I
can
create
a
bar
and
and
then
when
the
when
the
reference
policy
goes
away,
my
bar
might
just
continue
to
function
yeah,
but
but
I
won't
be
able
to
create
new
ones
if
the
reference
policy
doesn't
say
I
can
so
and
then
and
then,
if
if,
if
the,
if
the
person
who
originally
created
the
bucket
wants.
B
B
A
B
A
B
B
Her
bucket
yeah,
that's
the
annotation,
so
so
we
need
some
mechanism
we're
still
figuring
out.
This
is
all
open
question.
So
how
do
we
say
this
is
the
kind
of
reference
it's
possible,
so
you
say
like
access
control
like
that,
and
I
think
our
reference
policy,
our
bucket
reference
policy,
is
going
to
be
a
little
different
from
this
gateway
reference
policy,
which
is
which
is
no
bare
bones.
We're
going
to
have
one
something
saying
whether
you
know
when
this
reference
policy
goes
away,
should
existing
references
be
cleaned
up
or
not.
B
A
B
B
A
B
Yeah
that
seems
too
complex
that
I
agree
with
you,
but
there
is
a
simpler
design
here,
so
I
just
feel
like
reference
policy
by
itself.
The
concept
is
a
powerful
concept
now,
if,
if
we
just
need
to
make
some
tweaks
to
the
concept
in
order
to
get
what
we
want,
that's
fine
like
like
from
what
I
see
here.
I
I
think
we
need.
We
need
to.
You
know,
improve
reference
policy
to
to
have
the
ability
to
do
these
things
that
we
just
talked
about.
B
B
If
we
have
reference
policy
at
that
level
of
granularity,
then
what
we
can
do
is
we
can
have
a
reference
policy,
another
one
for
a
bar
and
a
bc.
So
we
will
say
this:
br
can
only
refer
to
this
bsc.
Sorry
and-
and
you
know
we
get
then
then,
and
then
we
select
the
same
bar
for
for
for
the
reference
to
the
b
as
well.
So
so
that
way,
we
end
up
in
a
situation
where
that
bar
can
only
use
that
bc.
B
Let
me
know
I
was
just
I
was
thinking
it
through.
Let
me
let
clearly
explain
it
so
simple
thing
is:
if
you
were
to
set
the
reference
policy
at
the
granularity
of
a
single
resource,
then
you
can
restrict
what
bc
can
be
ac
can
access,
and
you
can
also
refer.
You
can
also
restrict
what
b
it
can
refer
to
that
way.
You
can,
you
can
cleanly
restrict
what
kind
of
access
it
can
get
for
a
particular
bucket.
A
So
I
would
create
one
reference
policy
that
would
say
this
bar
and
this
bac
and
then,
if
I
had
a
different
bar
and
the
same
bac,
I'd
create
another
reference
policy.
For
that
other
wait,
wait!
No!
It's
not
the
ba
or
it's
just
the
b.
You
said
because
I
never
I'm
not
sharing
the
bars
yeah
you're,
just
sharing
the
b.
B
A
A
A
B
A
A
Cluster
roles
are
only
referred
to
by
cluster
role,
bindings
and
cholesterol.
Bindings
are
referred
to
by
the
or
the
they
bind
the
service
account,
so
they
point
to
the
service
account,
and
so
I
guess
I
guess
the
the
thing
that
that
enforces
them
just
knows
about
all
of
the
cholesterol
findings.
A
Just
has
to
have
it
has
to
have
comprehensive
notion
of
every
cholesterol
binding
in
the
whole
system,
so
that
every
time
a
service
account
wants
to
do
something
it
can
quickly
look
up.
Can
I
do
it
or
can
can
that
principle
do
it?
Here
we
have
a
situation
of
you
know:
random
user
creates
a
bar
and
points
to
a
b,
and
now
we're
trying
to
decide.
Can
it
bind
or
not,
and
the
controller
has
to
figure
out.
B
Sorry,
access
provisioning
yeah,
it's
not
performance
critical.
It
would
be
good
to
have
it
fast.
That
being
said,
let's
explore
cluster
reference
policy.
B
B
D
A
B
A
B
So
so
it
only
becomes
so
in
our
case
then
then
same
thing,
you,
you
have
the
bucket
reference
policy.
If
you
have
multiple
bucket
reference
policies
to
different
namespaces,
it's
okay,
it's
good.
A
But
it
isn't
because
so
so,
with
cluster
role
bindings,
the
only
one
who
can
create
them
is
the
administrator.
So
if
one
exists,
you
know
that
it
wasn't
an
evil
person
that
created
one
here.
It's
a
name-faced
object.
So
now,
if,
if
charlie
wants
to
gain
access
to
alice's
bucket,
he
can
create
his
own
reference
policy
that
gives
himself
access
in
his
own
namespace,
and
we
won't
know
that
that
was
an
evil
thing
to
do
right.
He
can
just
create
the
reference
policy
in
his
own
name.
B
A
B
A
Right
so
that
at
least
filters
out
all
the
other
name-
spaces
uh-huh,
what
okay
right
right?
Okay
and
then
you
can
have
multiple
reference
policies
that
stack
with
each
other
inside
one
name:
space.
That's
all
fine,
okay!
So
so
then,
then,
my
only
question
is
in
the
static
provisioning
case,
where
you
just
create
the
b,
and
there
is
no
br.
A
B
Interesting,
I
mean
we
could
do
the
forcing
thing,
but
how
would
that
look.
A
We,
it
would
just
be
that
no
one
could
use
the
b
until
it
was
bound
right
and
unbound,
br
or
b
would
be
unusable,
because
we
wouldn't
know
how
to
find
what
namespace
to
look
for
reference
policies
to
perform
our
access
checks.
So
we
could
just
so
you
know
what
nothing
happens
until
it
binds
and
when
you
do
the
static
provisioning
thing.
You
have
to
also
create
a
br
somewhere
and
allow
it
to
bind
before
those
access
checks
can
proceed.
B
B
What
would
you
say
with
all
this
experience?
Would
you
say
it's
okay
to
go
down
this
route
like?
Is
that
something
that
we
should
avoid?
No
matter
what,
because
of
whatever
you've
seen
through
the
years,
or
is
that
okay,
like
we
know
the,
we
know
the
trade-offs?
This
is
okay,
we
can
just
do
it
and
we
should
be
able
to
deal
with
it,
even
though
it's.
A
Not
I
I
don't
want
to
stand
in
the
way
of
progress.
I
I
guess
what
what
I
will
say
is
that
you
know
the
the
original
design
that
involved
everything
being
bound
and
required
like
very
complicated
transfers
of
objects
across
namespaces
to
achieve
the
various
sharing
scenarios.
I
know
that
that
would
work
because
I've
written
it.
A
A
A
B
A
Yeah
yeah,
so
so
I
do
want
to
think
about
it
through
that
lens
too.
It's
like
assuming
that
this
approach
catches
on
and
the
network
guys
are
using
it
and
we're
using
it
with
object.
Storage.
Maybe
the
snapshot
snapshots
can
use
something
like
this
and
we
should
think
about
it
through
that
lens
too,
and
I'd
have
to
sort
of
sit
back
and
think
about
all
the
problems
in
that
context,
but
can
I
ask
you
said
you
got
a
lot
of
tim's
attention
last
week.
D
B
A
Okay!
Okay,
so
so,
if
tim
is
involved
in
the
in
the
design
of
the
the
router
thing
through
the
http
route
thing,
and
he
feels
like
it's
going
to
work
and
he
also
thinks
it's
going
to
work
for
cozy
like
that
gives
me
a
lot
of
hope,
because
he
knows,
I
think
way
more
than
any
of
us
about
kubernetes
apis
and
the
potential
pitfalls.
B
I
mean
I
don't
know
about
that,
just
because
tim
feels
that
way.
I
don't
think
it's
given,
but
just
by
reasoning
about
this,
it
seems
like
there
is
no.
I
mean
there
are
pitfalls.
Obviously,
but
but
it
seems
like
the
abstraction
is,
is
powerful
enough
that
we
can.
We
can
come
up
with
clean
ways
to
you
know
solve
any
of
the
use
case
that
we
have
so
far.
It's
been.
It's
been
the
cleanest
approach.
B
A
Well,
it
means
that
you
could
write
all
of
your
controllers
the
first
time
around
without
having
to
worry
about.
You
know,
checking
policies
and
things
they
can
just
deal
with
the
individual
objects
that
they
need
to
deal
with.
Each
controller
can
be
very
modular,
and
you
never
need
to
worry
about
these
chains
of
events.
A
Right,
like
like
the
controller
that
sees
brs
and
creates
b's,
is
a
very
simple
job
it
just
it
just
you
know,
looks
for
b
for
brs
checks
if
they're
bound
and
if
they're
not
it,
creates
a
b
and
then
it
binds
them,
and
it's
done
and
like
that
controller
can
be.
You
know
a
couple
hundred
lines
of
code
and
it's
code
complete,
and
then
you
have
another
sidecar
that
sees
bees
and
then
calls
into
the
cozy
driver
and
causes
a
bucket
to
get
created
and
then
takes
the
results
of
that
and
sticks.
A
It
back
on
the
status
of
the
b
and
like
and
that's
done
and
that's
self-contained
and
doesn't
have
to
worry
about
anything
else
and
like
you
can
have
a
bunch
of
these
tiny
little
modules
that
have
very
small
jobs
when
everything
is
bound.
One
to
one
and
you
never
have
a
situation
where
you're
looking
at
two
or
three
three
or
four
or
five
objects
to
decide
whether
something
is
doable.
A
I
feel
like
once
you
had
a
reference
policy
and
it's
able
to
point
to
bcs
and
you
have
a
situation
where
someone
creates
a
bar
you're
looking
at
that
bar
you're,
looking
at
the
b
that
it
refers
to
you're,
looking
at
the
br
that
the
b
refers
to
you're
looking
at
the
bc
or
then
you're.
Looking
at
the
reference
policy
like
quickly,
you
have
five
or
six
objects,
you're,
looking
at,
maybe
even
seven,
if
you're
looking
if
you're
like
scoping,
which
bc's
can
be
referred
to
just
to
make
the
decision
of
like.
B
I
mean
that
that's
the
case
with
even
parts
scheduling.
You
know
you
look
at
a
lot
of
different
things
to
see
if
you
can
just
run
the
part
somewhere.
I
I
I
I
like.
I
see
the
complexity
of
bringing
up,
but
if
you
were
to
make
these
modular
and
so
instead
of
looking
at
it,
as
as
you
know,
another
step
in
the
same
workflow
of,
can
you
you
know
provisioning
a
bucket
or
accessing
provisioning,
a
bucket
access.
Think
of
it
as
two
separate
modules.
B
One
is
just
checking
if
you're
allowed
to
do
it.
Another
is
the
provisioning
modules.
It's
completely
separate.
They
interact
at
some
point,
but
but
while
designing
them,
you
do
it
separately.
While
writing
the
code,
for
you
do
it
separately,
and
only
in
that
point
of
convergence
where,
where
you
refer
to
a
b
from
a
bar,
this
has
to
be
taken
into
account
or
bsc
from
the
whatever.
So.
A
You
know
in
scope
for
any
given
decision,
it's
much
easier
to
think
about
all
of
the
strange
things
that
could
occur
right
all
of
the
race
conditions,
all
of
the
all
of
the
the
strange
corner
cases
it's
just
easier
to
reason
about
them
when
there's
less
involved
in
any
one
code
path-
and
it
feels
like
this
is
creating
a
situation.
A
A
Yeah,
just
as
a
person
that,
like
writes
controllers,
I,
like
I
like
brain
dead
simplicity.
No
me
too.
B
Any
piece
of
software
don't
get
me
wrong,
but
yeah
I
mean
the
only
way
to
achieve
that
is
through
abstractions.
Then
it's
not
possible
to
do
it
any
other
way.
A
B
D
Question
like
it's,
maybe
I
didn't
like
follow,
follow
up
in
the
beginning,
so
so
do
we
mandatory
need
to
have
a
friend's
policy
for
b,
like
the
can
we
be
without
offense
policy,
as
well
like
for
the
symbol
scenarios
of
the
symbol,
cases.
B
D
B
So
I
think
ben
was
mentioning
that
so
in
in
that
simple
case,
would
it
mean
that
the
question
is
if
there
is
no
reference
policy,
does
it
mean
that
everyone
can
access
it,
or
does
it
mean
that
no
one
can
access
it
depending
on
the
answer
to
that
question,
I
think
it's
either
simple
or
hard.
So,
for
instance,
if
we
say
there's
no
reference
policy,
nobody
in
other
names
can
access
this
bucket
great.
So
that's
that's.
D
B
Okay,
all
right,
okay,
I'm
glad
so
I
mean
I'm
still
not
sure
of
what
we
decided
on.
What
are
we
gonna
decide
on,
but
what
I'll
do
is
I'll
come
up
with
a
bunch
of
slides,
like
I
used
to
do
way
back
to
come
up
with
like
different
possibilities
of
how
this
reference
policy
itself
will
look
and
let's
make
a
decision
on
what
how
we're
going
to
conversion
on
like
what
we're
going
to
call
like
what
it's
going
to
look
like.
B
Finally,
because
it
seems
like
as
of
right
now
we're
not
sure
between
regular
reference
policy
and
and
cluster
reference
policy,
we're
not
sure
of
how
it's
going
to
look
for
static
buckets
versus
buckets
created
in
a
namespace.
We
have
some
answers
to
some
questions
in
silos,
basically
like,
but
but
converging.
All
of
this
is
still
unclear
to
me.
It.
C
Said
is
this
going
to
be
a
completely
open
api
like
the
like
front
and
two
are
those
like
open?
You
can
define
any
api
group
kind.
B
B
A
generic
reference
policy,
we
could
start
out
with
something
like
a
bucket
reference
policy
and
then
use
that
to
create
the
final
kubernetes
level
api,
but
so
so
the
last
meeting
with
cigar.
This
is
what
we
said.
We
decided
that
both
cosy
and
gateway
api
will
be
the
test
bets
for
doing
something
like
this.
We
can
come
up
with
approaches,
separately
and
and
based
on
based
on
these
two
we're
going
to
come
up
with
the
come
with
something
for
you
know,
kubernetes
in
general.
B
So
so
we
have
a
lot
of
freedom
to
build
it
our
way
to
satisfy
our
needs,
and
I
would
rather
build
it
specifically
for
like
buckets
and
then
and
then
they
can.
They
can
extrapolate
it
and
create
something
generic
for
kubernetes
and
we
can
piggyback
on
it
when
it's
ready.
B
All
right
all
right,
so
so
I'm
gonna,
I'm
gonna,
write
that
down
and
bring
it
up
to
everyone
next
meeting
and-
and
let's
figure
this
out-
let's
let's
flush
this
out
in
the
meantime,
I'm
just
going
to
tell
tim
that
hey,
you
know
we,
we
we've
gone
down
this
path
of
reference
policy
and
for
alpha
our
stances.
It's
going
to
be
free
for
all.
Anyone
can
refer
to
a
bucket
created
outside
in
a
different
namespace
or
statically.
That's
our
alpha
way
and-
and
I
think
we
should
be
good
to
go.
A
B
B
All
right
I'll
go
and
update
the
document
with
some
of
the
notes
with
whatever
we
talked
about.
I
didn't
get
a
chance
to
take
them
down
as
we
spoke,
but
but
I
should
be
able
to
fill
that
in
it'll
help.
Others
also
other
members
who
join
this
group
to
know
what's
going
on
yeah
and
for
us
also
to
search
for
anything
we
discussed
previously
yeah,
that's
about
it.
Let's,
let's
talk
next
week,
everyone
thank
you.