►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 07 October 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
All
right
good
morning,
everyone
good
afternoon
to
those
of
you
in
the
east
coast
and
different
good
evening.
Okay,
so
exciting
day,
today,
last
night,
after
quite
a
bit
of
pinging
tim,
he
he
reviewed
the
cap
again
and
let's
go
over
it
together.
A
So
so
the
good
news
is.
He
said
that
it
is
okay
to
move
forward
with
what
we
have
today.
A
But
I
mostly
think
it's
okay
to
proceed
in
this.
That's
what
he
said.
So
he
still
has
a
bunch
of
concerns.
Some
are
big
access,
control,
cardinality
and
etc,
but
mostly,
I
think
it's
okay
to
proceed.
I
think
there's
a
ton
of
work
to
be
done
between
alpha
and
beta,
which,
which
we
expected
especially
reference
policy
access,
control,
workload,
identity,
based
access
control
that
is,
and.
A
So
he
says
the
one
thing
that
is
that
is
blocking
this.
Is
this
some
of
the
open
comments
that
he
has
so
so
we
addressed
the
open
comments
that
we
had
that
he
had
last
time
and
he
he
kind
of
divided
them
into
six
broad
topics,
some
of
them
overlapping,
so
I'll,
just
I'll
just
go
over
the
ones
that
are
I'll.
A
Just
tell
you
the
the
non-overlapping
ones,
so
this
is
the
three
of
them,
so
one
was
flattening
the
bar
and
ba
one
was
sharing
buckets
between
different
name
spaces,
and
one
is
you
know
what
should
be
in
the
protocol?
What
should
be
in
the
bucket
class
was
the
bucket
request.
A
So
so,
overall,
it
was
like
about
naming
and
what
goes
where
in
the
api
and
also
you
know
flattening
and
oh
and
mentioned
I
didn't
mention
the
access
control
around
who
gets
to
use
what
bucket
so
there's
two
layers
to
access
control.
Let
me
let
me
put
it
that
way:
one
is
who
gets
to
use
what
bucket,
which
we
solved
with
reference
policy?
One
more
is:
how
do
we
know
or
or
how
do
they
get
the
access
like?
A
So
this
was
25
days
ago
where
we
had
left
off,
we
said
back,
then
we
were
saying
that
we,
you
know
we
we
we
will
allow
bucket,
sharing
to
be
free
for
all,
and
reference
policy
would
be
something
for
the
future
that
is
beta
and
and
that's
where
I've
left
the
cap,
where
we,
where
we
last
spoke,
but
I
think
some
of
the
questions
she's
brought
up
here
are
really
asking
us
to
flush
out
reference
policy
stuff.
A
A
What's
on
my
screen,
yeah
yeah,
okay
zoom
in
a
little
bit,
okay,
I'll,
probably
comment
more
as
I
get
there
and
acknowledge
my
bias,
but
given
how
much
effort
has
been
missing
secret,
less
authentication
not
having
something
in
place
where
it
feels
like
a
grave
or
mission,
I'm
not
saying
because
he
needs
to
make
it
work
on
blasphemous,
don't
support
it!
I'm
saying
that
those
problem
which
you
support
should
not
be
dumbed
down
yeah.
We
said
we'll
get
to
it
so.
A
B
A
No,
it's
not
that
he's,
not
okay
with
that
the
the
he
just
forgot
what
we
talked
about,
because
last
time
I
said
this.
Yes,
he
was
fine.
It's
been
25
days
since
his
last
review.
C
B
C
A
Fair
enough,
fair
enough,
we
we
haven't
flushed
it
out,
then
so
we
have
to
sit
and
do
that
if
you're
going
to
add
stuff
here
but
but
definitely
I
don't
see
a
reason
why
we
can't
have
have
cozy
tie
the
pods
identity
or
parts
from
a
certain
name.
Space
identity
too.
B
It
quickly
gets
challenging
to
sort
of
have
a
negotiation
between
the
pod
and
the
co
right,
because
if
the
pod,
like
two
things,
have
to
support
the
secretless
authentication
right,
the
the
underlying
object
storage
system
needs
to
and
the
pod
the
pods
object
object.
Bucket
client
needs
to
support
it,
and
if
either
of
those
doesn't
support
it,
you
need
a
way
to
fall
back
and-
and
so
you
have
basically
have
a
three-way
negotiation
and
we
we
talked
about
what
that
might
look
like,
and
we
said
that's
really
hard.
B
B
But
if
we
wanted
to
allow
workloads
to
fall
back
to
access
key
secret
key
if
they
can't
support
the
secretless
authentication,
then
like
there
has
to
be
a
way
to
tell
kubernetes.
That's
what
you
want
before
you
create
your
bucket
access
right,
because
the
bucket
access
is
the
thing
that
would
mint
a
credential.
B
If
you
need
one
or
do
something
else,
if
you
don't
need
one,
and
so
that
it
needs
to
be
a
point
in
the
workflow
where
the
user
says
hey,
I
I
need
a
bucket
access
and
it
has
to
be
secret
key,
because
my
workload
doesn't
support
secret
list
authentication
or
I
need
a.
I
need
access
and
my
workload
does
support
sequence
authentication
and
I
prefer
it.
So
let
me
give
me
that
you
know
something
along
those
lines
we
just
you
know
in
order
for
kubernetes
to
arrange
for
the
right
thing
to
happen.
A
I
mean
that
I
I
don't
know
if
I
see
a
big
problem
there,
because
you
have
the
concept
for
bucket
x
class
and
the
idea
is,
you
know
the
user
is
requesting
something
from
a
particular
bucket
access
class
and
that.
B
Right,
but
if
we
decided
the
bucket
access
class
is
the
right
way
to
do
this,
then
we
need
a
first
class
field
in
the
bucket
access
class.
That
is
understood
to
mean
that
to
have
a
specific
impact
on
the
downward
api.
So
you
know
if
this
field
is
true
in
the
bucket
access
class,
then
the
thing
that
injects
your
credential
your
credentials
will
definitely
behave
this
way
and
if
it's
false,
it
will
definitely
behave
that
way
right.
You
gotta
document
it
and
it
can't
be
opaque
or
anything.
B
A
Yeah,
so
so
ben.
I
think
I
think,
in
the
goals
what
what
tim
is
saying
here
is.
We
should
say
that
we
will.
We
will
support
workload
elementary
based
authentication.
I
think
that's
what
we
need
to
say
he's
again
talking
about
the
goals
here
and
he
wants
to
know
that
that's
something
along
the
way,
because,
with
everything
that
we
just
talked
about,
I
don't
see
what's
hard,
I
don't
know
what
is.
A
I
think
when
we
start
working
on
it
we
might
see
more
issues,
but
but
yeah
we
could
write
a
section
about
how
we
can
enable
that
shirt.
B
When
we
were
talking
about
the
downward
api
that
this
this
was,
the
concern
was
just
that
there's
two
different
ways
to
do
it
and
we
don't.
We
didn't,
want
to
put
pods
in
a
position
of
having
to
support
both,
but
we
didn't
have
an
idea
about
how
we,
how
you
could
express
your
preference,
and
so
it's
just
an
exercise.
We
need
to
go
through
to
write
down
a
way
to
do
it
like
I.
I
agree
that
there's
probably
a
way
to
do
it.
B
A
Yeah,
that's
my
worry,
okay
fat
enough!
So,
okay,
let's
flush
that
out,
okay,
so
we'll
actually
follow
like
a
depth.
First
approach:
if
that's
okay
with
everyone,
let's
get
into
how
that
vector,
identity
based
authentication
looks
like.
A
Actually,
let's
go
over
the
comments.
It's
like
only
a
few
comments.
Let's,
let's
just
go
over
the
comments
quickly
and
then
we'll
use
the
highest
priority
and
do
that,
okay,
so
the
other
one.
Is
I
encourage
you
to
talk
to
gateway
folks,
that's
realizing
api,
versioning
and
evolution
here,
and
I'm
right
now,
they're
figuring
out
we're
already
talking
to
them.
How
do
I
let
them
know
that
we're
already
talking
to
them
we're
already
basing
our
api
based
off
of
gateway
api.
A
B
E
E
A
What
was
this
protocol
support
in
the
class
now?
Is
it
just
informational?
A
A
Remind
me
why
parents
is
a
map
rather
than
a
reference
to
typed
object.
Okay,
so
this
is
in
bucket
bucket
object,
the
bucket
itself.
So
his
question
is:
why
is
parameters
a
map
rather
than
a
typed
object?
This
is
because
we
can't
anticipate
parameters
that
are
windows,
specific
right.
B
Oh,
this
is
because
we
did.
We
want
to
copy
the
opaque
params
from
the
bucket
class
to
the
object
for
for
future
reference
right
right.
Yes,
okay,
we
just
need
to
write
that
down.
I
guess
and
say
this
is
just
a
copy
of
what
was
in
the
bucket
class,
because
we
want
to
remember
what
the
values
were,
even
if
the
bucket
class
is
modified
or
deleted.
B
A
B
Oh
well,
I
mean
it
in
the
bucket
class.
The
reason
it's
opaque
is
because
these
are
intended
for
for
vendor
specific
options
that
are
that
are
opaque
to
kubernetes,
and
we
can
point
to
storage
class
and
snapshot
classes.
A
Okay,
that's
good,
so
search
lessons
natural
classes
very
good
to
know
that'll
be
a
strong
argument:
okay,
okay!
This
is
just
this
is
just
artifact
of
editing,
since
we
don't
have
a
compiler
that
tells
me
I've
got
the
wrong
reference
here,
yeah,
so
so
quick
update.
A
A
A
access
request,
so
it's
so
that
is
more
congruent
with
the
persistent
volume
claim.
B
G
B
A
B
A
I
don't
know
if
that's
the
reason,
because
we
we
can,
we
do
have
one
to
many
in
volumes
and
where
I'm
coming
from
is
isn't
it
more.
So
bucket
request
is
more
like
a
request
to
create
a
bucket.
A
bucket
claim
is
a
claim
to
use
it
bucket.
Access
claim
was
that
would
that
be
more
more
cleaner
here.
B
I
mean
I,
I
agree
if
we
rename
one
we
should
consider
renaming
both,
but
the
the
raw
bucket
claim
seems
to
be
the
thing.
If
you're
going
for
symmetry
with
pvcs,
then
it's
the
br
that
that
should
be
become
a
claim,
because
the
there
is
no
analog
of
the
bar
in
in
volumes,
because
we
don't
you
don't
mind
credentials
for
access
to
them.
You
just
you
just
tell
tell
cubelet
to
mount
it.
D
A
Can
remind
me
who
he's
like
explicit
by
writing
here,
who
decides
whether
to
allow
a
random
claim
to
be
random
claim
to
access
a
given
bucket
reference
policy.
A
Yeah
we
can
right
now
it's
free
for
all
in
this
current
cap,
but
eventually
reference
policy,
so
so
yeah,
let's,
let's
go
through
the
rest
of
the
comments
and
then
we'll
get
back
to
the
ones
that
we
still
need
to
talk
about.
One
of
them
is
this:
do
we
want
another
claim
object,
or
can
we
just
make
do
with
request
objects?
A
Okay,
it's
not
clear
to
me
how
reference
policy
applies
to
this,
about
namespace
name
says
access
or
is
it
is
the
thinking
that
I
have
a
claim
in
my
name,
space,
that
references,
a
br
and
other
namespace
or
something
else
I'm
trying
to
get
the
cardinality
straight?
Yes,
he
actually,
you
know
he
figure.
A
I
think
he's
looking
at
reference
policy
as
like
a
cluster
scoped
object.
That
says
these
are
the
references
you're
allowed
to
make,
but
the
way
we
are
looking
at
reference
policy
is
the
creator
of
the
bucket
in
the
namespace,
where
the
bucket
is
owned,
gets
to
set
the
reference
policy
for
that
bucket
and
the
way
it's
set.
Is
it
points
to
another
br
in
a
different
name
space?
A
A
Okay,
we
can.
I
can
you
know
again.
This
was
written
before
we
discussed
all
that,
so
I
have
to
rewrite
this
can
bucket
ready
ever
flick,
but
oh
yeah.
What
happens
then
yeah
we
talked
about
this.
Someone
else
can
take
ownership.
That
is
a
race
condition,
but
it's
not
very
different
from
pvc's
mpv,
where,
if
a
pv
is
unbound,
some
other
pvc
can
go
and
bind
to
it,
but
there's
a
race
condition.
You
don't
know
which
one's
going
to
bind,
but
it's
a
risk
we
have
chosen
to
take.
A
Does
anyone
hear
from
from
the
pvcp
world
know
if
that's
a
reasonable
design
choice
to
make
where
currently,
if
pvc,
and
if
there
is
a
pv
that
is
unbound
a
pvc
can
bind
to
it,
but
there's
no
guarantee
that
will
bind
to
it,
because
some
other
p
c
could
also
bind
to
it.
So
there's
like
the
race
conditions,
if
we
introduce
a
similar
design
with
the
bucket
requests
and
buckets
and
can.
A
Can
is,
is
that
okay,
like
yeah,
I
I
think
it's.
H
Yeah,
I'm
just
going
to
say
that
I
it's
from
the
point
of
view
of
the
user
they're
looking
for
I'm
talking
about
pvc
issue,
it's
just
a
location
of
storage
and
the
user
doesn't
care
as
long
as
they
get
satisfied
of
the
amount
of
storage
that
they're
looking
for.
Wouldn't
that
be
the
same
as
a
bucket,
they
would
just
get
a
here's
the
bucket
for
you
and
that
will
get
satisfied
and
I'm
just
saying
if,
if
we're
comparing
them
to,
I'm
not
saying
we
should
go
one
way
or
the
other.
B
F
B
So
so
the
situation
with
volumes
is
if,
if,
if
the
pv
is
totally
unbound,
yes,
it's
a
first
come
first
serve.
Whoever
knows
the
name
of
the
pv
can
just
bind
to
it,
and
the
bind
controller
will
will
honor
that
bind,
but
you
can
have
a
situation
where
you
have
a
half
bound
pv,
where
the
pv
points
to
a
to
a
volume
that
your
pvc
that
doesn't
exist.
In
that
case,
only
creation
of
that
particular
pvc
would
be
allowed
to
bind.
B
H
H
B
B
Under
that
situation
may
actually
fully
remove
the
claim,
but
you
can
go
back
in
and
half
bind
it
yourself.
You
know
in
the
same
way
that
you
change
the
the
retention
policy
by
just
editing
the
pv
object.
B
H
B
B
A
B
H
But
but
the
they're
changing
it
from
from:
what's
it
called
released,.
B
H
A
Yes,
oh,
that's,
absolutely
beautiful,
always
be
unbound.
You
can
create.
You
know
dangling
pvs,
that's
that's
fair
game
in
kubernetes
and
that's
how
we
did
initially
when
we
had
to
create
volumes
before
1,
13
or
very
early
on.
A
A
Yeah
still
remember
anyways,
so
so
that's
that's
possible
and
in
that
case
too,
if
you
know
two
different
claims
are
trying
to
bind
to
it.
You
have
this
same
issue.
So
the
reason
I
asked
the
question
of
that's
okay
is
what
are
people
like?
Did
we
face
any
issues
that
you
know
of
from
from
that
kind
of
model?
Is
there
any
good
reason
that
we
should
be
aware
of
to
avoid
that
that
you
might
know
of.
B
B
In
fact,
I
know
for
certain
that
there
are
some
behaviors
of
the
pvc
and
pv
that
are
that
are
only
done
the
way
they
are
for
backwards
compatibility,
but
but
I
I
don't
think
it's
I
don't
think
the
status
quo
with
pvs
and
pvcs
is
is
broken
or
bad.
It's
just
maybe
a
little
sub-optimal.
B
A
Okay,
so
so
then
we
can
go
back.
We
can
answer
with.
If
a
bucket
becomes
a
dangling
bucket,
we
can
we
can
we
can.
We
can
have
someone
own
it
again,
even
though
this
question
is
specific
to
the
bucket
claim
and
access
it's,
it
still
makes
sense.
So
this
question
is
specifically:
if
there
is
a
pocket
access
or
bucket
claim
that
that
is,
that
is
pointing
to
a
bucket
and
the
buckets
bucket
ready
status
is
false.
A
What
happens
then?
You
know,
then
access
is
not
granted.
It's
it's
a
simple,
I
think,
or
maybe
he's
asking
if
it
was
first
ready
and
then
afterwards
it
becomes
not
ready.
Do
we
do
something?
We
don't
we
just
we
just
let
it
be
so
yeah,
that's
a
good
question.
A
So
so,
if
a
bucket
is
alive
or
we
created
it
and
then
say,
someone
goes
and
turns
off
the
the
internet
gateway
on
on
on
one
of
the
on
the
cloud
they're
on
so
so
the
part,
let's
say,
which
is
talking
to
a
remote
bucket
over
the
internet,
suddenly
can't
talk
to
it
anymore.
So
the
bucket
ready
gets
set
to
false
and
let's
say
in
this
bucket
ready
set
to
falls.
What
do
we
do
to
the
access
that
pods
have.
B
H
B
A
A
Should
we
maybe
set
something
in
the
yeah?
We
don't
have
to
mark
it
as
messed
up.
We
don't
have
to
we.
We
could
potentially
mark
the
you
know
the
claim
object
to
say
that
access
granted
is
no.
That's
not
true.
E
As
long
as
long
as
it
being
missing
or
broken,
wouldn't
affect
removing
it
at
removing
the
requests
or
anything
right
anything
associated
with
it.
So
if
anybody,
if,
if
somebody
dropped
a
bucket
out
from
underneath
us,
make
sure
that
we
can
still
clean
up
afterwards
like
that,
would
be
the
only
consideration
for
being
wanting
to
market.
I
H
A
A
We
don't
have
to
go
there
all
right,
let's
go
to
the
next
one.
Could
this
be
a
list
so
he's
talking
about
providers
that
support
multiple
protocols
like
gce,
that
supports
both
google
cloud
protocol
for
talking
to
buckets
and
s3.
Our
stance
has
always
been
create
multiple
bucket
classes.
We
can
stick
with
that.
H
G
E
J
So
too
does
google,
for
example,
allow
both
s3
and
google
protocol
access
to
the
same
bucket,
essentially
the
same
data?
It
does
yes
because
in
that
case,
you
may
have
two
applications,
one
speaking
as
three
one
speaking
google
protocol
that
one
access
to
a
shared
data
set
where
they
need
to
bucket.
Well,
let
me
call
it
bars
or
bucket
access
claims
bucket
claims
to
get
the
corresponding
authentication
credentials,
but
still
reference
one
bucket
away.
B
B
E
A
E
B
J
A
Okay,
exactly
thanks;
okay,
so
the
next
one
is.
Should
this
be
a
reference
to
a
provided,
specific
custom
resource?
It
goes
back
to
the
parameters
question.
Why
is
it
a
map
string
string
and
why
not
provide
a
specific
custom
resource
so
what
we
just
point
to
a
uuid
and
type
or
something
here.
A
You
know,
I
think,
I
think
what
we
talked
about
was
you.
We
went
down
that
path
of
seeing,
if
you
can
do
you
know,
s3
specific
parameters,
ccs,
specific
parameters,
but.
B
We
need
this
would
be
like
this
would
be
like.
I
create
a
storage
class
for
for
a
netapp,
netapp
volume
provisioner,
and
instead
of
just
putting
all
the
netapp
specific
parameters
as
string
maps
in
the
storage
class,
I
would
have
a
pointer
to
a
netapp
storage
class
object
that
was
typed
and
then
like.
B
So
we
we
could
go
that
way
like
on
the
volume
side,
but
we
haven't
done
so.
I
think
the
proposal
here
is:
maybe
that
would
be
better
class
or
like
say
nvme
storage
class,
something
I
I
guess.
I
guess
the
the
challenge
is
at
the
end
of
the
day,
like
the
the
side,
the
provisioner
sidecar
has
to
marshal
that
object
across
the
the
grpc
socket
and
hand
it
to
the
handed
to
the
actual
driver
and
a
map.
A
string
map
is
really
easy
to
marshal
over
the
wire.
G
Agree
with
that
observation,
ben
one,
interesting
thing
I
just
thought
about
was
if,
in
support
of
tim's
idea
there
is,
it
could
separate
lines
of
concern
roles.
It
can
separate
the
admin
of
a
cluster
role
from
a
storage
admin
role.
The
storage
admin
manages
this
cr
that
has
all
the
parameters
for
the
type
of
object
store,
whereas
the
cluster
admin
just
points
to
it
in
when
they
create
the
bucket
class.
That's
kind
of
interesting
to
me.
Otherwise,
I
think
parameters
is
just
simpler,
but
but
that
one
idea
is
kind
of
interesting.
A
I
think
this
okay,
so,
for
the
sake
of
simplicity,
we're
saying
we're
going
with
being
a
map
string
string,
nothing
provided.
No,
I
mean,
I
don't
think
we
can.
We
can
say
we'll
start
with
this
and
then
we'll
change
later.
I
think
we
should
take
a
strong
stance.
We
think.
A
Storage
class:
that's
a
good
escape
hatch
for
driver
specific
parameters
right
like
csi.
They
have
specific
parameters.
A
Okay,
so
we're
just
going
to
go
with
a
map
string
string
because
it's
very
similar
to
storage
class-
and
I
I
still
don't
know,
what's
the
east,
it
will
point
to
any
crd.
I
don't
know
if
that
adds
much
value
either
like.
B
I
mean
we
could
have
a
field
on
the
class
called
like
param
or
parameters
reference.
That
could
just
be
an
object
graph
and
it
could
point
to
anything
and-
and
then
you
know,
as
far
as
kubernetes
was
concerned,
there'd
still
be
no
type.
Checking
you'd
still
just
point
to
anything.
But
then
the
question
is:
how
do
you
marshal
it
over
the
wire
to
the
to
the
to
the
client
if
it's
anything
other
than
a
flat
object
with
you
know,
string
values
or
string,
keys
and
string
values?
A
Yeah,
my
currency,
okay,
so
let's
move
forward.
This
doesn't
add
any
value
to
have
a
special
provider,
specifically
other
sort
of
thing.
Okay,
so
his
other
question
was
this
was
moved
to
a
class.
Yes,
protocol
is
going
to
be
in
a
class.
I
have
to
update
the
cap.
I
have
to
do
a
clean
job
of
it.
That's
that's
what
it
is.
A
Yeah
and
we
were
kind
of
in
a
rush
and-
and
we
kind
of
addressed
the
comments,
but
I
guess
not
everywhere.
There
were
some
points
that
were
missed.
Okay,
so
let's
get
back
to
the
two
unanswered
questions.
One
is
workload,
identity
based,
authentication
and
one
more
is.
A
Pr
and
claim,
let's
work
on
this
claim
thing:
first,
because
it's
simpler
and
we
can
probably
decide
during
the
course
of
this
meeting,
maybe
not,
but
maybe
yeah.
So
before
we
start
the
discussion
who,
who
from
here
is
going
to
be
at
coupon
next
week.
A
Oh
okay,
great
so
I'll
also
be
there
saying.
C
Yeah,
let's
sync
up.
A
So
next
next
week's
meeting,
I
don't
think
we'll
have
next
week's
meeting
it's
cancelled.
A
All
right,
okay,
will
also
be
there.
C
No,
unfortunately,
right
now
I
only
know
you
and
me:
there
are
a
couple
of
folks
from
data
protection
going
group
side.
So
I
don't
know
anyone
else
luis,
I'm
not
doing.
C
Okay,
yeah
yeah
for
some
reason
this
time
there
won't
be
a
lot
of
people
so
see
that
believe
you'll
be
there
for
on
for
the
tuesday's
event
right
yeah,
I
will
be
there
so
we
probably
well
yeah
we'll
meet
up.
We
can
probably
meet
on
tuesday.
A
Yeah,
let's
yeah:
let's
do
that
yeah,
I'm
gonna,
be
there
all
four
days
mostly
because
and
there's
just
two
people
from
midnight
are
coming
and
you
know
we'll
have
to
do
that.
Oh
you
have
only
two.
C
A
Anyway,
so,
okay,
so
that,
outside
that
out
of
the
way
yeah,
I
just
figured,
we
might
not
get
a
chance
to
discuss
this
while
we're
discussing
the
topic,
and
so
I
just
wanted
to
get
it
out
of
the
way.
Back
to
the
topic,
I
thought
we
had
designed
a
way.
One
tim
says
one
of
br
and
claim:
why
do
we
need
both?
Can
you
remind
me
who
decides
whether
to
allow
a
random
claim
to
access
a
given
bucket.
B
A
One
is
why
do
we
have
a
br
okay,
he's
similar
to
what
you
are
saying,
which
is
bucket
claim,
should
be
the
equivalent
of
br
and
not
the
equivalent
of
bar.
G
Long
ago,
in
this
kep
process,
we
got
input
from,
I
believe,
assad
of,
of
being
cleaner
to
separate
bucket
provisioning
from
credential
provisioning
and.
G
A
Okay,
okay.
Now,
so
I
think
this
is
the
right
model
where
we
have
a
separate
bar,
a
separate
way
to
provision
credentials
from
provisioning
the
bucket
itself,
because
you
can
have
multiple
credentials
with
entirely
different
life
cycles
from
the
bucket
itself.
So
I
think
that
that
was
the
right
thing
to
do.
I
think
the
question
here
is
tim
is
wondering
why
the
claim
refers
to
the
bar,
or
this
is
the
is
the
replacement
or
is
the
new
name
for
the
bar
rather
than
for
the
br.
A
The
the
whole
conversation
is
is
based
on
this
idea
that
we
want
to
look
and
sound
more
like
persistent
volumes,
and
pvcs
and
processing
volumes
stand
for
creation
of
the
persistent
volume
and
they
don't
have
this
concept
of
creation
of
access,
so
shouldn't
buckets
a
bucket
claim,
the
equivalent
of
that
in
buckets
also
stand
for
creation
of
bucket
or
a
request
for
the
bucket
itself
rather
than
for
the
access
to
market.
I
think
that's
it.
B
C
C
Now
we
have
so
many
different
naming
conventions.
C
A
I
see
so
so
what
you
said
ben,
but
doesn't
it
make
things
simpler
rather
than
more
complicated,
because.
A
Automatic
input
volume
changing.
Let
me
see.
A
The
two
things
yeah
yeah
and
the
hey
so
somewhere
else
issues
my
audio.
Let
me
let
me
rejoin.
A
Okay,
that
was
very
weird
all
right.
Thank
you,
luis
luis
had
to
drop
off
okay,
so
yeah.
My
proposal
was,
we
should
have
both
the
br
and
the
bucket
claim
bucket
claim.
Referring
is
you
know
it's
like
the
new
bar
and
bucket
request
is
going
to
remain
as
it
is
today.
B
E
G
I'll
just
throw
my
vote
out
there,
so
it's
recorded
is,
I
think,
bar
bucket
access
request
is
more
act.
It's
it's
more
descriptive
of
what
the
resource
is.
A
bucket
claim,
in
my
view,
is
more
ambiguous
because
you
don't
know
if
it's
a
like
a
pvc
claim
and
you're
going
to
provision
storage,
which
you
aren't
you're
you're
only
creating
credentials.
So,
in
my
view,
this
change
makes
the
resource
a
little
less
clear.
What
it
is
you
have
to
read
about
it
now.
That's
all.
A
A
His
words
were:
why
do
why
invent
something?
You
know,
why
invent
something
that
that
sounds
and
looks
new
rather
than
something
people
are
already
familiar
with.
G
A
Well,
no
right,
it's
the
opposite
right,
because
the
the
pvc
is
really
a
request
for
the
pv.
It's
a
claim
to
get
the
pv.
It's
not
a
claim
to
create
the
pv
that
just
ends
up
being
a
side
effect.
I
would
say
of
the
pvc
today.
B
A
Stances
and-
and
we
can
back
it-
I
can
see
both
kind
of
working
out.
Let's
go
one
once
announced.
Is
we
don't?
I
don't
go
well.
A
A
What
do
we
call
that
claim
inside
the
pod,
rather
than
the
objects
can
remain
as
they
are
br
and
bar
it's
just
the
way
we
request
buckets
is
through
a
bucket
claim
in
the
pod
in
the
part
spec.
What
if
we
pick
that.
A
A
B
Okay,
so
so
I
think
we
should
reject
the
suggestion
to
use
bucket
claim
unless,
unless
it's
explained
more
in
a
way
that
makes
sense.
Okay,.
A
Let
me
let
me
go
over
the
comments
again
and
see
what
his
reasons
were,
but
I
like
that,
the
most
to
be
honest,
let's
keep
it
as
they
are.
Markets
are
different
from
volumes.
I
guess
it's!
Okay,
too,
so
it's
okay,
it's
okay!
To
keep
it!
This
way.
A
It's
okay
to
come
up
with
new
names.
I
mean
yeah,
okay,
let's,
let's
take
the
stance
that
we're
gonna
go
ahead
and
you
know
name
I'll
fix
the
cap
and
we'll
see
we'll
go
from
there
I'll
I'll
I'll.
Also
try
to
go
back
and
find
out.
Why
we,
what
his
reason
was
behind
not
wanting
it
to
be
bucket
access,
request
and
and
I'll
post
it
on
the
cozy
slack
channel,
and
we
can
have
further
discussion
there.
A
We're
almost
out
of
time
or
we're
actually
out
of
time.
So
next
week
we
won't
be
meeting
so
happy
kubecon
if
you're
gonna
attend
either
online
or
in
person
and
yeah.
Let's
meet
in
two
weeks.
K
Sit
just
before
winding
up
so
is
such
a
good
time
to
update
my
driver.
Like
do
you
feel
like
that?
Neither
changes
are
the
controller
and
or
spotlight
or
like.
Should
I
wait
to
the
cape
to
be
merged
or
something
like
that?
I.
A
And
you
know
push
this
through,
just
assume
that
it's
going
to
take
about
at
least
two
weeks,
so
if
by
the
next
meeting,
they'll
have
a
more
definite
answer
for
you.
A
All
right,
thank
you.
Thank
you,
everyone
that,
that's
all
it's
it's
good,
that
we
came
forward.