►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 31 March 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
Oh,
this
is
just
my
utility
that
checks.
The
internet
is
okay,
all
right.
So
after
after
our
last
meeting
two
weeks
ago,
we
we
talked
about,
I
think
four
open
questions.
A
I
didn't
really
get
a
chance
to
update
the
cap,
but
I
still
have
my
notes
on
what
we
decided
from
the
last
conversation
and
then
I
can
quickly
make
an
update
today,
based
on
you
know,
if
we
still
feel
like
the
answers
we
discussed
last
time
are
valid
and
you
know
we
can
proceed
from
there
other
than
that.
I
don't
think
there
is.
A
A
Sweet
was
about
protocol.
Last
time
we
were
talking
about
protocol,
which
is
currently
in
the
bucket
class,
we're
talking
about
moving
it
to
the
bucket
claim,
the
idea
being
that
it's
the
application.
That
knows
what
protocol
it
wants
to
talk
to,
and
so
there
should
be
some
mechanism
for
that's
running
the
application
say
using
a
bucket,
the
one
that
that
uses
the
bucket
claim
to
specify
what
protocol
bucket
should
support.
A
So
so
we
had
a
lengthy
discussion
last
time
I
just
went
over
the
video
from
the
last
meeting
and
we
decided
that
the
protocol
should
indeed
be
in
the
bucket
claim,
where
you
can,
you
can
specify
based
on
the
application.
What
protocol
you
want
this
bucket
to
talk
to
support,
and
we
we
decided
also
to
get
rid
of
the
class.
A
Let's
see
all
right
so
I'll
have
this
running
in
the
background
it
just
does
bings
regularly
and
just
measures
the
average
round
trip
time
and
loss
all
right.
This
should
yeah
it's
already
better.
A
Okay,
all
right!
So
let's
get
back
to
this.
So
so
is
my
audio
better.
Now
now
that
I'm
in
a
better
spot,
it's
perfect,
okay,
sweet
all
right.
So
my
question
was
about
oh
okay.
So
to
give
you
an
update,
then
after
last
week
I
started
on
my
travel,
so
I
didn't
really
get
a
chance
to
update
the
cap.
A
It's
been
two
weeks.
I
still
have
my
notes
on
what
we
discussed
last
time.
I
thought
we
would.
We
could
go
over
the
solutions.
We
came
up
with
last
time
and
just
see
if
we're
on
the
same
page
still
or
you
know
if,
if
maybe
some
questions
popped
up
based
on
the
decisions
we
made
and
then,
if
everything
looks
good,
I
can
go
and
update
the
kept
today.
A
That
was
that's
that's
kind
of
how
I
started
the
meeting
so
so
the
goal
here
today
is
just
to
go
over
the
solutions
we
discussed
last
time
and
and
see
if
we're
still
on
the
same
page,.
A
It
will
also
give
me
a
chance
to
kind
of
you
know
remind
myself
of
everything
that
we
talked
about,
so
that
I
can
update
the
cap
correctly
yeah.
So
the
first
question
is
about
protocol.
A
Last
time
we
talked
we,
we
said
that
we
can
actually
move
protocol
out
of
bucket
class,
since
it's
the
application
that
clearly
needs
to
specify
the
protocol
and
bucket
class
is
not
something
that
that
the
application
writer
ever
gets
to
control.
A
That
was
the
idea
behind
having
protocol.
You
know,
move
to
bucket
claim,
instead
of
having
it
in
bucket
class.
That's
that's
what
we
discussed
last
time
and
any
questions
on
that,
or
are
we
still
on
this?
You
know
with
the
same
same
idea
of
the
same
idea.
C
A
Yeah,
okay,
I
don't
think
that
I
don't
expect
there
to
be
much
changes
but
but
given
I
haven't
had
the
chance
really
to
update
the
cap,
I
figure
we
might
as
well.
Really
you
know,
go
over
the
decisions
again,
because
there's
only
four
questions
really
and
other
than
that.
If,
if
anyone
wants
to
discuss
anything
else,
we
can
talk
about
it,
but
but
yeah
we
go
the
questions
again.
This
should
be
quick.
A
There's
a
spelling
mistake
here,
I'll
fix
that,
but
coming
back
to
this
yeah,
so
so
the
second
question
was
in
the
bucket
access
class:
should
there
be
a
driver
name,
we
kind
of
went
back
and
forth
on
this?
I
think
I
was
saying
that
there
could
be
a
possible
mismatch
between
the
driver
name
in
bucket
and
the
bucket
access
class.
A
If,
if
there
was
this
provision,
but
but
that's
a
user
or
admin
error,
so
it's
okay,
you
know,
you
know
we
can.
We
can
throw
a
meaningful
error
message
and,
and
that's
what
that
should
do,
that's
so
that's
what
we
kind
of
decided
and
we
decided
to
get
you
know,
add
driver
name
in
bucket
access
class
as
well,
just
like
it
is
in
bucket
class.
A
Yeah,
I
don't
see
why
not,
okay,
just
just
opening
it
up
all
right.
The
next
one
is:
where
does
his
account
name
come
from?
This
was
more
of
a
just.
How
does
it
work
kind
of
question?
I
think
we
decided
we'll
change
the
name
of
this
field
from
account
name
to
account
id.
I
think.
A
And
that
way
you
know
it's
clear
so
so
account
name
is,
is
provided
in
the
response
to
grant
access,
which
is
a
grpc
call
to
the
actual
driver.
So
it's
supposed
to
return
an
account
account
id
or
a
unique
string.
A
That's
used
for
it.
Important
grpc
calls
so
so
that
if
you,
if
you
call
grant
access
twice
or
if
you,
if
you
call
you
know,
if
you
you
don't
want
to
end
up
creating
multiple
credentials
for
one
bucket
or
for
one
bucket
access,
that
was
a
private
potency.
C
A
A
If
we
were
to
do
that,
then
then
the
issue
is
if
the
driver
gets
restarted
or
if
the
client
gets
restarted,
needs
to
have
that
that
state
saved
somewhere
right.
It
has
to.
A
Right,
that's
how
it
is
with
csi
right
right
I
mean,
wouldn't
it
be
easier
so,
with
with
with
buckets
we
already
know,
the
access
pattern
is
to
have
an
identifier
for
the
accessor
like
in
like
an
access
id.
So
couldn't
we
just
use
that
which
is
you
know
which
can
be
expected
as
a
response
to
grand
taxes.
B
How
so
can
you
the
the
possibility
that
an
id
can
get
generated
and
then
lost
or
it
can
get
sent
and
then
forgotten
about
and
that
there
are
sequences
of
events
where,
like
the
client,
can
send
an
api
to
the
server
and
then
not
hang
around
for
the
response
and
then
later
come
back
and
not
remember
what
it
was
doing.
B
It
probably
could
be
worked
around.
I'm
just
saying,
like
csi
uses
stuff
that's
generated
on
the
client
side,
you
could
potentially
use
something
generated
on
the
server
side,
but
then
you
can
only
get
one
of
them
right
like
if
I
want
to
grant
access
on
the
same
bucket
to
like
three
different
clients.
A
A
B
B
B
At
it
and
try
to
break
it,
you're
probably.
A
A
Yeah,
I
think
so
I
mean
I'm
just
thinking
about
aws
and
and
menio
as
an
example
and
in
both
cases
there
is
a
unique
key
for
accessor
for
per
set
of
credentials,
which
is
the
user
id.
A
I
don't
even
think,
that's
possible
actually
actually
that
that
concern
doesn't
exist
if,
if
we
build
the
build
the
container
orchestrator
side
of
cosy
well,
actually
this
should
work
right
like
if
we
just
asked
for
the
item
point
sig
back
from
back
from
the
driver.
You
know
stuff
like
the
account
id
for
aws
and
menu
or
project
id
in
case
of
azure
and.
B
B
A
Know
no,
it
doesn't
matter
if
there's
an
error,
if
there's
an
error,
it's
the
same
as
it
never
got
provision.
That's
so
so
the
idea
is
the
the
driver
has
to
go
and
try
to
create
an
account
based
on
the
specifications
provided
and
if
it,
if
it
created
the
account
successfully,
then
it
sends
the
account
id
back
to
cosy,
which
just
persists
it
in
in
the
bucket
access
object
and
what,
if.
A
Number
here
then,
then
it
can
succeed.
Then
then
you
call
again
and
and
so
you're
saying
this-
there's
a
possibility
of
two
different
calls.
B
In
csi
the
concern
is
always
you,
you
send
a
request
to
create
an
object.
You
either
get
success
or
failure
or
timeout
in
the
success
case,
you're
good
in
the
failure
case,
you're
also
good
in
the
timeout
case,
you're
screwed,
because
now
you
may
or
may
not
have
created
something,
and
you
don't
know
how
to
refer
to
the
thing
you
created,
and
so
you
have
to
retry.
B
A
Still
pass
in
a
unique
key,
which
is
the
bucket
access
name
for
the
bucket
access
uuid,
it's
still
there,
it's
just
the
meaning
of
this
field
account
id.
C
Yeah
I
I
was
just
I
guess,
agreeing
with
ben.
We
actually
just
had
a
an
issue
that
I
was
looking
at
recently
in
rook
upstream,
where,
if
there
is
a
like,
quite
literally
a
timeout
creating
like
a
bucket
user,
it
ends
up
causing
some
problems
when
we
come
back
and
do
that
operation
again,
because
we
can
assume
that
that
operation
like
failed
because
of
the
timeout,
but
actually
the
underlying
system,
still
has
registered,
that
it
exists.
C
And
then
we
come
back
again,
the
next
time
with
a
different
id
and
then
have
like
the
deep
bucket
resource
ends
up
having
been
owned
by
the
previous
user.
Instead
of
the
like
newly
generated
user,
and
I
I
think
solving
this
issue
from
the
cosy
level
would
help
prevent
other
drivers
from
having
having
the
same
underlying
issue.
D
I
think
it's
not
possible
to
completely
get
rid
of
the
you
know
this
problem
just
from
cozy
level.
If
you
look
at
the
external
provisioner,
there
are
actually
fixes
to
prevent
leaking
resources,
but
then,
like
in
our
driver,
we
still
have
our
extra
code
just
to
make
sure
that
does
not
happen.
It
has
a
lot
to
do
with
your
driver
itself,
as
well
as
through
the.
B
B
The
weakness
of
csi
is
that,
although
we
have
proper
item
potency
keys
to
prevent
leaking
resources,
you
are
required
to
retry
your
creates
until
you
get
a
success
or
an
error
message.
And
then,
if
you
get
a
success,
you
have
to
delete
it
because
yeah,
if
you
get
a
timeout,
you
can't
just
walk
away.
D
D
D
A
A
A
I
see
in
this
case
right.
We
want
the
same
for
bucket
creation
and
and
also
for
access
creation,
so
blaine.
The
problem
you
brought
up
so
was
was
the
issue
that
you
know
the
timeout
eventually
succeeded,
but
you're
already
exited
from
the
time
out.
Is
it
okay
to
expect
the
driver
to
to
either
cancel
and
flight
requests
or
delete,
cancel
in-flight
requests?
A
What
I'm
trying
to
ask
is,
let's
say
you
know
the
timeout
elapsed
and
cozy
broke
the
connection,
the
the
jrpc
connection.
Is
it
reasonable
to
expect
the
driver
to
just
undo
whatever
it
started?.
D
I
think
don't
know
this,
you
still
try.
Should
you
still
keep
you
trying
cozy
level,
you
should
also
handle
item
potency.
Basically.
A
C
I
was
gonna
say
I.
I
think
it
could
be
a
kind
of
both
situation
where,
like
it,
it
seems
like
that's,
probably
not
an
uncommon
like
a
scenario
that
particular
one,
and
so
if
cozy
has
mechanisms
to
help
prevent
it
like
in.
In
the
specific
case
that
I
have
seen
if
cozy
was
like,
okay,
we're
just
gonna,
say
the
user
id
or
the
yeah,
the
user
id
for
this
bucket
is
going
to
be
x,
randomly
generated.
C
It
also
seems
totally
reasonable.
For
me,
you
know
because
the
user
id
in
some
ways
cozy
doesn't
care
about
if
cozy.
C
D
C
The
two
where,
where
cozy,
like
kind
of,
is
designed
to
help
the
underlying
system
avoid
this
particular
like
class
of
issue,
but
certainly
yes,
I
also
agree.
Every
driver
is
going
to
have
their
own
failure,
cases
that
they
do
have
to
deal
with,
and
you
know
because
he
can't
be
expected
to
handle
the
minutia
of
you
know
how
is
seth
different
from
aws
from
mineo.
A
Yeah,
I
think
I
think
that's
that's
a
very
well
thought
out
response.
Looking
at
the
driver
grant
bucket
access
call
a
little
bit
more.
We
do
pass
it
in
as
par
dash.
Uuid
of
the
bar
itself.
Sorry
bucket
access,
the
par.
Doesn't
it's
the
same.
The
bucket
access
request
doesn't
exist
anymore
anymore,
so
this
would
be
bucket
access,
dash,
uid
and
just
bucket
dash
uuid
here.
So,
given
that.
A
I
think
it
should
be
good
enough,
so
so
the
flow
we're
kind
of
hinting
at
here
is
we.
We
pass
in
the
bucket
access
uuid
as
the
as
the
uniqueness
key
as
the
importancy
key,
and
then
the
driver
itself
responds
with
an
account
id
which
could
be
potentially
different,
and
if
so,
we
pass
that.
A
Oh
actually,
no,
we
we,
okay,
here's
here's!
What's
going
on!
So
in
the
request
we
pass
in
an
account
name
and
then
the
response
you
expect
an
account
id
and
the
account
id
is
what
we
use
in
subsequent
calls
to
the
driver.
A
So
the
item
currency,
key
for
grant
access
is
account
name
which
is
a
uid
of
the
ba.
The
bucket
access
and
the
subsequent
add
importancy
key
for
all
access
related
operations
would
be
the
account
id.
I
think
that's
what
that's
what
we
had
decided
on.
That
would
work
right
right,
but
you
don't
have
to
store.
B
The
content
account
name:
oh
no,
okay,
right
right!
This
is
this.
Is
the
grpc
layer
right
at
the
kubernetes
layer?
There
is
no
field
called
account
name
because
it's
right,
it's
just
the
uuid.
Okay.
B
B
If
you
want
the
account
called,
you
know,
bar
dash
uid.
This
is
as
good
as
anything.
A
B
I
don't
know
no,
I
I
like
name
I
like
name
because
then
cozy
can
use
it,
for
you
can
do
it
like
this,
but
in
principle
some
other
client
of
this
grpc
could
have
a
different
scheme,
and
it's
it's
not
prescriptive
right.
It
says
give
me
a
string,
that's
going
to
be
used
for
item
potency
and
that
may
get
stamped
on
the
underlying
object,
depending
on
the
implementation
of
the
driver.
B
That's
right,
yeah
yeah,
but
but
I'm
saying
a
different
grpc
client
that
was
not
cozy
could
just
do
something
else
and
it
would
still
work
with
with
the
cozy
driver.
You
mean
right
and
again
I'm
thinking
you
know
when
csi
was
designed,
it
wasn't
designed
for
kubernetes
exclusively.
It
turned
out
that
no
one
else
has
written
csi
clients,
but
you
know
one
could
imagine
something
similar
with
cozy,
where
all
alternative
implementations
could
show
up
someday.
A
We
might
be
working
on
a
problem
that
that
is,
that
is
out
of
scope.
At
this
point,
the
reason
I
say
that
is,
I
think,
with
pocket
api
specifically,
we
said
this
is
just
for
kubernetes
and
not
for
all
container
orchestrators.
B
A
Okay,
I
think
I
think
the
confusion
of
the
account
name
is
people
start
wondering
where
it
comes
from.
Would
it
be
easier
to
I
mean
just
if
we
called
it
something
like
bucket
access
uuid,
just
that,
then
there's
no
there's
no
confusion.
Nobody.
A
Nobody
has
to
figure
out
where
this
field
came
from
what
it
means
we
could
even
call
it
item
potency
key.
A
Okay,
all
right,
so
so,
let's
just
decide
on
one
name
for
the
field
and
and
we'll
go
with
it.
Do
we
need
a
bucket
access
name?
Can
we
not
just
do
it
bucket
access
id.
D
D
A
Right
and
also
I,
the
other
concern
I
see
is
in
the
driver,
api
we're
really
exposing
implementation
detail
which
isn't
generally
good.
B
A
A
A
Okay,
I
I
want
a
big
deal.
I
understand
that
yeah.
I
I
think
I
think
we
can
go
with
account
name
then,
because,
because
you
know,
discussion
about
names
yeah,
they
can
take
a
long
time
and
we
might
end
up
nowhere.
A
Okay,
so
I
will
update
how
I
describe
what
this
field
is
supposed
to
all
right.
That
should
solve
the
problem.
I
think
there
was
a
question
about
quota
restriction
on
bucket
access
and
bucket
classes.
A
Okay,
I
think
that's
about
it.
That
was
the
last
one.
So
the
question
is
right:
so
what
about
new
features?
When
are
we
gonna?
A
A
Yeah,
I
think
I
think
it
looks
like
quota
and
restrictions
well
bucket
quota
itself.
That's
that
will
include
the
restrictions.
Part
seems
to
be
a
popular
request
for
a
feature.
A
Let's
get
this
kept
merged
and-
and
we
can
start
looking
at
that
yeah
it
has
to
be
designed
in
through
the
api.
The
admin
would
have
to
have
some
mechanism
to
enforce
it
or
specify
it
and,
of
course,
you'll
have
to
enforce
it.
I'm
okay
with
you
know
talking
about
this.
After
we
get
the
kept
merged
yeah.
We
don't
want
to
add
on
more
things
before
we.
It's
like
counting
the
chickens
before
they
hatch
kind
of
thing
yeah.
So
so
that's
all
was
in
my
mind.
A
Okay,
if
anyone's
trying
to
reach
me,
I
might
be
a
little
late
to
respond
because
I'm
traveling
but
I'll
definitely
get
back
to
you
within
a
day.
Yeah!
That's
that's
about
it!
From
for
myself,.