►
Description
Kubernetes Storage Special-Interest-Group (SIG) Bucket Object API Standup Meeting - 05 April 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
B
It's
8
p.m.
Oh
wow
good
evening,
then
thank
you
good
morning.
Thank
you
and
and
hi
hi
stages.
How
are
you
I'm
good,
sir?
How
are
you
good
as
well?
So
so
they
just
let's
start
with
the
pr
and
then
we'll
go
from
there.
So
I
want
to
prioritize
you
know
getting
that
pr
through.
I
haven't
had
a
chance
to
look
at
all
the
comments,
so
I
want
to.
B
B
B
You
know
for
this
pr
to
be
merged,
so
so
I
want
to
understand
what
is
needed
and-
and
you
know
if
this
is
in
a
good
shape
to
be
merged
or
if
we
need
you
know,
if
I
need
to
do
something
before
we
can
get
go
forward
at
this.
So
I'm
looking
at
all
the
comments
jeff,
you
made
a
lot
of
good
comments,
but
is
there
something
I
did
not
address.
B
B
C
B
B
C
Kind
of
of
what
so,
can
you
maybe
just
walk
us
through
the
api
changes
in
that
inside
this
pr?
Maybe
that
will
be.
You
know
sufficient.
I,
I
suppose
I
mean
most
of
the
people.
Would
you
know,
get
into
the
refactoring
pieces
and
you
know
technical
details
only
when
they
actually
go
through
debugging,
or
you
know
things
like
that,
but
perhaps
api,
for
me,
at
least,
is
is
more
that's.
That's
a.
B
Good
solution,
yeah,
so
one
of
the
main
api
changes
was
in
the
bucket
controller.
The
bucket
controller
is
the
one
that
listens
for
bucket
events,
so
just
to
go
through
the
life
cycle
of
cozy
objects.
A
user
creates
a
bucket
request
and
points
it
to
a
bucket
class,
and
the
central
controller
puts
them
together
into
a
bucket
object.
When
the
bucket
object
is
created,
the
cyca
provisioner
gets
the
event
and
cycle
provisioner
checks.
B
If
the
event
is
for
a
bucket,
that's
managed
by
the
current
driver,
whatever
the
driver
is
say,
s3
or
mini
or
whatever,
and
it
then
puts
together
a
grpc
request
to
the
driver
to
create
the
bucket
earlier.
We
were
passing
in
a
bunch
of
information
through
the
protocol
structure,
which
had
name
and
version
and
and
those
two
fields
have
been
removed.
B
C
B
B
B
How
do
I
change
the
view?
Okay
anyways?
So
this
is
the
protobuf
definition,
so
the
main
changes
that
were
done
was
the
name
of
the
parameters.
Change
is
just
as
three
azure
blob.
That's
that's
a
simple
change,
so
the
name
of
the
field
changes
yeah.
The
second
change
is
when,
when
the
response
to
create
bucket
itself
I'll
get
into
the
changes
here
also,
but
the
response
to
create
bucket
itself
returns
a
bucket
id
and
then
the
bucket
id
is
used
as
the
handle
for
subsequent
operations
involving
the
bucket.
C
C
A
A
A
F
C
B
B
A
C
B
B
Yeah,
so
so
that's
how
the
bucket
id
is
utilized.
Now,
if
the
cloud
like,
if
it's,
if
it's
google
cloud
where
you
know,
there's
a
globally
unique
name
space,
there's
no
well,
I'm
not
I'm
not
entirely
sure.
But
let's
say
there
was
a
global,
unique
name
space
where,
if
you
got
a
bucket
you
own
it
and
and
like
like
amazon-
and
you
know
it's
globally
unique
in
that
case,
you
know
the
bucket
id
can
just
be
the
name
right.
That's
up
to
the
driver
right.
B
B
B
Yeah
yeah,
that's
that's
mostly.
You
know
the
changes.
The
other
thing
is,
you
know
we
respond
with
the
account
id
on
on
grand
bucket
access
response
and
account
id
is,
is
analogous
to
bucket
id
as
in
it's
it's.
It's
say
the
arn
number
in
amazon
amazon
resource
number
for
for
a
particular
account
so
that
in
subsequent
calls
so
say
revoke
bucket
access.
B
C
B
Awesome
all
right
so
that
you
know
in
order
to
make
this
happen,
we
had
to
add
the
you
know,
fields
the
bucket
id
field
and
account
id
field
inside
of
the
api
resources,
obviously,
and
yeah
this.
This
shows
the
same
thing
we're
looking
at.
We
go
back
here,
yeah,
so
so
over
here
in
the
earlier
implementation.
B
Anyways,
so
what
we
had
was,
you
know
a
bunch
of
code
to
work
with
one,
the
you
know,
name
and
version
in
the
in
the
protocol
structure
and
two
was
we
didn't,
have
the
bucket
id
there
and
the
logic
of
updates
was
wrong,
so,
for
instance,
at
any
step
you
know
you
need
to
be.
You
should
expect
the
controller
to
be
able
to
fail,
and
you
know
when
the
controller
comes
back
up.
Eventually,
it
should
be
able
to.
B
B
C
B
B
B
Line
139,
so
what
we
do
first
is
so
we
we
we
grant
access
to
the
bucket
and-
and
we
we
put
a
you-
know-
requirement
on
that.
Provisional
grant
bucket
access
call
that
for
a
given
request,
which
has
the
bucket
id
and
account
name
unique
values,
I
should
get
back
the
same
credentials
each
time.
That's
that's
the
first
thing
that
needs
to
be
enforced.
B
B
B
Let's
say
it
fails
after
this
point
before
bucket
access,
dot
update
is
called
with
access
granted,
you
know
set.
This
is
set
to
true.
Where
access
is
going
to
be
true,
then
we,
then
you
know
on
the
next
iteration
or
on
the
next
sync
call.
When
this
whole
function
gets
called
again,
we'll
go
through
the
same
set
of
steps.
Provisional
grant,
bucket
access,
assuming
it's
very
important,
has
to
be.
C
B
C
Does
this
leave
sorry
for?
Does
this
secret?
This
secret
lives
in
the
driver's
name,
space
driver's
name
driving
this
phase
and
and
the
the
sort
of
cross
name
space
operation
that
the
information
that
moves
is
that
there's
the
node
adapter,
which
is
able
to
read
that
information,
yeah
csn
order
app
will
have
access
to
all
namespaces.
C
I
see
so
that's
the
kind
of
cross
namespace
access
that
allows
it
to
get
this
information
right
from
the
driver
directly
right,
there's
only
one
csn
or
adapter
for
all
drivers.
I
see.
Okay,
I
see
yes
yeah.
This
works.
Okay
sounds
good.
I
think
it's
good
that
to
have
the
fixed
name
makes
sense
as
well.
Yeah.
B
B
B
A
data
structure,
a
data
structure
that
is
empty
and,
and
they
call
it,
they
call
it
the
current
state
of
the
world
or
yeah
current
state
of
the
world,
and
and
in
comparison
to
that,
in
contrast
to
that,
the
the
set
of
objects
in
hcd
is
called
as
the
desired
state
of
the
world.
So
as
soon
as
the
controller
starts
up
the
controller's
job
throughout
it.
Let
me
go
back
once
not
always
throughout
this.
B
Entire
lifecycle
is
to
bring
the
current
state
of
the
world
to
the
desired
state
of
the
world.
It
needs
to
keep
reconciling
now
when
the
controller
starts
up
because
it's
empty
when
it
pulls
when
it
using
the
informa
when
it
lists
all
the
all
the
objects
from
hcd
and
it
starts
filling
in
the
the
local
data
structure.
It's
actually
an
ad
event,
because
it's
adding
it
to
the
local
data
structure.
B
B
B
B
C
F
C
B
E
B
B
B
B
D
A
A
A
D
B
B
Yeah,
the
infos
is
the
structure
rather
than
yeah
yeah
anyway.
So
yeah
plea,
please
take
a
look
at
the
pr,
I'm
glad
I
got
a
chance
to
explain
what's
going
on
here
and,
and
I
want
to
get
this
merged
so
that
we
can
move
forward
to
the
next
steps.
That's
it
on
this
pr.
I
don't
want
to
spend
any
more
time
on
this,
because
I
think
we
should
get
into
the
cap
now.
B
I
think
this
is
the
pr
and
and
ben
last
week.
I
think
you
missed
the
meetings.
I
want
to
give
you
a
quick
update
on
what
we
talked
about.
We
talked
about
a
use
case
where
we
want
to
change
the
type
of
access
after
it's
provisioned
so
say.
For
instance,
user
gets
read-only
access
on
a
bucket
and
then
later
on
they
decide
they
need
rewrite
access.
D
B
B
B
Okay,
so
so
there
were
two
things
we
talked
about:
one
is
a
bucket
access
request.
One
one
approach
we
discussed
was
a
bucket
access
request,
say
points
to
bucket
access
class
one.
We
change
that
to
bucket
access
class
two
and
the
expectation
is
the
bucket
access
that
was
originally
created
with
data
from
bucket
access
class
1
now
needs
to
be
now
needs
to
use,
use
either
new
credentials
or
have
the
existing
account
that
that
that
was
created
as
a
result
of
the
of
the
bucket
access.
The
first
time.
D
Hold
on,
I
I'm
hung
up
on
so
so
is
it
always
the
case
that
bucket
access
classes
are
always
compatible
with
each
other,
and
you
can
never
have
two
bucket
access
classes
that
are
mutually
incompatible.
That
is
possible
actually.
Well,
then,
what
if
you
change
it
to
one?
That's
not
compatible
like
the
the
whole
point
of
only
looking
at
it
at
creation
time
is,
is
to
avoid
any
kinds
of
issues
where
you
know
after
it
exists.
D
Then
you
sidestep
all
the
issues
with
you
know
what?
If
what,
if
they
ask
for
something
that
I
that
that's
not
compatible,
what
you're
saying
here
is
well
now
you
can
change
it,
which,
which
implies
basically
you're
implici
you're
implying
you
can
mutate
anything
that
could
have
been
set
by
the
bucket
access
class,
because
you
can
just
change
the
bucket
access
class
to
a
new
one
and
that's
supposed
to
do
something
right.
D
B
Yeah
yeah,
like
so
yeah
I'll,
get
into
that,
so
so,
okay,
so
before
we
get
into
that,
I
think
one
important
question
we
need
to
all,
or
one
important
thing
we
all
need
to
agree
on
is
now
is
this?
Is
this
an
important
use
case
or
or
is
it
say
you
know
what
delete
delete
the
workload
or
you
know
it's
it's,
okay
to
you
know
we.
We
expect
that
you
restart
the
workload.
D
Yeah
I
mean
we
know
that
today
you
could
always
just
delete
your
pod
delete
your
bar,
create
a
new
bar,
create
a
new
pod,
and
you
would
have
what
you
wanted
right
right.
That's
going
to
work
today,
so
so
the
only
thing
to
be
gained
here
is
the
ability
to
maybe
mutate
your
bucket
access,
while
the
pot
is
still
using
it
right,
and
the
question
is:
is
that
valuable
enough
to
implement
mutations
of
bas
right.
F
A
E
A
B
B
E
Yeah
so
let's
say
somebody
changes
the
packet
access
request
such
as
such
that
the
credentials
change
the
access
needs
to
change.
Then
the
bucket
access,
reque
controller
updates,
the
the
var
controller
updates,
the
ba
and
then
ba
controller
will
do
this
switch
over
from
the
old
credentials
to
the
new
credentials.
B
E
A
E
We
should
do
instead
is
we
should
relax
this
one
to
one
mapping
and
create
a
new
ba
for
the
new
credentials,
and
then
the
old
ba
can
be
deleted
whenever
there
is
no
more
pot
using
it
and,
of
course,
depending
on
whether
we
implement
this
live
update
of
the
credentials
within
the
pod.
This
will
be
will
happen
fairly
quickly
or.
B
Okay,
so
I
want
to
set
some
context
here.
So
again,
one
is
yes
bucket.
You
know,
credential
rotation
is
important,
but
but
there's
two
things
I
want
to
explain.
Actually
the
first
thing
is,
even
though
you
know,
credential
rotation
is
important.
We
they're
all
moving
towards
the
future,
where
I
am
style,
access
or
service
account
style
access
is
really
the
right
way.
I
don't
think
it
is.
B
It
is
a.
It
is
a
bad
decision
to
say
that
you
know
we
expect
people
to
or
more
advanced
things
like
credential
rotation
is
only
supported
in
in
the
service
account
style
of
access
and,
and
that
is
more
secure
and
and
even
amazon
started
deprecating
credential
tokens
they
they
ask
you
to
use
service
account
style,
style,
access.
D
D
B
D
B
E
E
So
with
that
with
what
I
proposed,
I
think
it's
pretty
easy
to
start
with
saying
that
we
do
not
support
it
and
we
can
still
support
it
later.
So
in
in
my
proposal,
the
credentials
in
the
ba
don't
change,
because
you
simply
create
a
new
ba
and
for
the
bar
bucket
access
request.
You
don't
need
to
implement
it
now
you
can
in
the
first
prototype
you
can
you
can
do
it
later,
so
the
idea
would
be
that
if
we
want
to
support
this
live
update
of
credentials
for
pods
in
the
future.
E
The
pod,
of
course,
references
a
bucket
access
request
and
it
will
always,
throughout
its
lifetime
reference
the
same
bucket
access
request,
but
transitively.
The
bucket
access
request
then
might
be
updated
to
reference
a
new
ba
if
the
credentials
change
and
then
the
the
the
actual
sandbox
can
be
changed
updated
accordingly.
B
So
even
without
going
there,
I
would
you
know
if
you
really
wanted
to
go
down
this
route
and
I'm
not
sure
you
know
we
want
to
do
this,
okay,
but,
but
if
you
really
want
to
go
down
this
road,
I
would
rather
prefer
something
like
a
credential
rotation
request
or
bucket
access
rotation.
Credential
rotation
request
as
a
separate,
separate
crd.
D
B
D
D
D
Published
things
you
know,
it's
really
it's
pretty
simple,
maybe
that's
the
right
approach
so,
but
we
would
want
to
figure
out
like
what
do
we
need
to
present
in
the
downward
facing
api
to
the
pod,
like
what
does
that
need
to
look
like
yeah
and
start
from
there
and
then
say:
okay,
given
that
that's
what
it
needs
to
look
like,
how
do
we?
How
do
we
get
that
behavior
with
as
little
machinery
as
possible
in
the
middle
right,
because
we.
D
The
initial
attach
to
like
ever
go
back
and
and
check
up
on
you
know
or
update
anything,
and
so
a
new
mechanism
is
being
added.
I
think
it's
an
alpha
right
now
for
csi
to
do
like
periodic
updates
that
just
runs
on
some
sort
of
a
schedule
such
that.
If,
if
something
like
an
encryption
key
did
change,
you
could
notice
that
and
inject
the
new
one
and
I'm
just
thinking
it's
got
to
be
something
similar.
D
D
All
right,
that's
what
I
was
saying:
that's
where
you
start.
You
start
with
the
downward
facing
interface
figure
out
what
that
needs
to
look
like,
because
that
that's
our
customer,
in
this
case
the
guy,
who
needs
to
know
that
his
key
changed
we'd
solve
that
and
then
work
backwards
and
the
rest
of
it
is
implementation
details.
But
I
don't
like
the
idea
of
like
making
new
bas
and
I
don't
like
the
idea.
I.
C
Think
I
think
it
makes
sense
as
a
you
know,
so
I
think
both
ways
work
right.
It's
just
a
matter
of
you
know
having
having
a
simpler
way
for
administrators
to
do
this
without
so
the
point
about
having
two
bas
is
that
suddenly
it
becomes
the
user's
namespace
perspective
of
knowing
what
changed
or
something
like
that.
So
something
needs
to
run
there
or
I
don't
know
something.
F
D
B
E
D
C
I
don't
think
it
means
that
there's
two,
I
think
it
the
meaning.
Is
that
the
previous
one
is
not
you
know
it:
it's
not
expired
yet
the
old
one
I
mean,
but
it
doesn't
mean
that
the
ba
needs
to
keep
track
of
the
old
one
in
any
way.
It
might
be
that
just
the
driver
keeps
track
of
that
right
right.
No,
I'm
saying
I'm
saying
that
that
the
maybe
cozy
is
agnostic
to
that
fact.
Today,
right.
B
E
C
We
delegated
to
the
driver
to
do
whatever
it
needs
to
do,
and
if,
if
we
need
more,
you
know
passing
more
information,
we
will
figure
it
out,
but
you
know
for
now:
it's
not
necessary
that
there's
more
information
needed
here
and
you
know
the
driver-
could
go
and
check
for
the
for
the
rest
of
the
information.
That's
needed
for
the
decision
when
to
you
know
to
recycle
these
keys
or
whatever
right
delete
them.
E
What,
if
like
and
now
we
are
in
a
situation
where
the
driver
still
needs
to
update
the
old
credentials,
but
at
a
later
point
in
time,
so
the
old
ones
needs
to
be
deleted
after
they
expire,
because
maybe
not
for
all
cloud
providers.
Also,
they
are
deleted
after
expiry.
So
the
driver
still
needs
to
delete
them
after
expiry
in
order
to
not
leak
them
and.
E
B
C
Actually,
but
I
I
agree,
I
mean
I
think,
for
for
starters,
we
just
need
to
be
able
to.
You
know,
have
somebody
represent
the
owner
of
that
task,
and
that
will
be
the
driver
at
first,
and
I
would
so
I
don't
know
if
this
is
close
to
being
what
we
are
suggesting
in
the
pr,
but
in
the
kip.
But
we
could.
C
We
could
imagine
how
the
driver
itself
is
the
one
providing
an
expiry
time
for
any
of
these
credentials,
and
you
know
all
the
stack
inside
both
cosy
and
even
the
user
application
like
the
pod
itself
and
the
sdk
or
whether,
whatever
is
running
there.
The
libraries
could
could
understand
this
expiry
time
and
to
to
you
know,
understand
that
they
need
to
reread
their
cache
or
something,
but.
B
One
thing
we
have:
we
have
only
about
three
or
four
minutes
left.
I
have
a
heart
stop
at
12..
Let's
continue
this
discussion
on
thursday,
but
in
the
meantime
I
don't
think
we
need
to
address
this
for
alpha
and-
and
you
know
we
should-
we
should
start
doing
the
api
review
before
you
know
as
soon
as
possible.
So
just
like
sebastian
has
been
reviewing
this
cap.
I
would
like
others
also
to
take
a
look
at
it,
review
it
and
leave
your
comments.
D
C
C
B
I
feel
the
same
as
said
in
this
case
yeah.
It's
really
important
that
we
move
forward
with,
with
the
with
the
whole
development
life
cycle
working
with
the
community,
because
these
these
these
deadlines
are
hard.
Like
you
know,
if
we
miss
this
opportunity,
you'll
have
to
wait
basically
three
to
four
more
months
and
yeah.