►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 12 November 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
B
Don't
you
need
to
name
the
bucket
instance,
for
instance
yeah,
when
the
central
controller
creates
a
bucket
instance,
it
has
to
have
a
name
and
then
and-
and
we
don't
know
the
name
of
the
bucket
yet
for
greenfield.
We
only
have
a
prefix
at
most
and
that's
optional.
So
I
don't
know
how
you
can
create
a
bucket
instance
that
the
sidecar
uses
as
a
trigger
to
call
create
bucket
rpc
call
when
the
bucket
instant's
name
it's
a
catch-22.
A
B
You're
saying
cozy
now
generates
the
bucket
name:
yeah
physical
bucket
name,
whereas
previously
we
were
saying
the
driver
can
do
it,
because
the
driver
we're
empowering
a
driver
to
ignore
prefix
that
the
driver
wants
we're.
Empowering
the
driver
to
use
names
that
comply
with
the
underlying
storage,
but
you're
saying
now
cozy's
going
to
generate
the
full
bucket
name.
C
B
C
Like
under
under
any
kind
of
failure
circumstance
you
can
reliably
retry
until
you
succeed
or
clean
up
and
two
it's
also
serves
as
the
suggested
name
down
to
the
lower
layer.
If
it
wants
to
respect
the
user's
suggestion.
D
Yeah,
it
becomes
a
trade-off
for
the
cozy
driver
to
decide
do
they.
You
know
care
about
this
user
experience
where
you
have
identifiable
usernames,
that
the
user
requested,
or
is
that
infeasible
and
are
they
going
to
optimize
for
just
having
randomly
generated
names
that
make
sense
for
their
storage
system
and
that
decision
is
left
up
to
the
driver,
but
the
system
allows
for
it.
B
So
the
purpose
of
making
the
bucket
instance
name
sort
of
match
or
likely
match
the
actual
bucket
name
is
a
usability.
It's
a
ux
idea
that
the
admin
when
they're
listing
bucket
instances
can
sort
of
see
a
visual
connection
between
the
bucket
instance
name
and
the
underlying
bucket's
name.
C
A
C
B
C
As
long
as
as
long
as
it's
always
unique,
that's
the
requirement
for
item
potency
you're
right.
You
could
have
a
different
prefix
for
the
purpose
of
the
name
that
you
get
passed
in
for
item
potency.
But
why
not?
If
we
have
something,
that's
already
guaranteed
to
be
unique.
Use
that,
as
the
item
potency
key.
E
A
All
right,
okay,
so
so
is,
is
the
is
the
overall
conclusion
more
or
less
clear
to
everyone.
Any
more
questions.
C
A
A
And
the
expectation
on
the
driver
is
for
the
same
prefix.
The
driver
should
always
for
the
same.
You
know
input
name.
The
driver
should
always
generate
an
id.
You
know
should
then
generate
deterministically.
C
E
A
That
would
work
too
okay,
so
this
is
clear.
The
next
thing
is
in
the
same
set
of
objects:
the
bucket
equation
bucket
class,
one
of
the
things
we're
facing
is
adding
more
and
more
protocol
specific
fields
into
these
objects.
A
A
So
we
were
thinking
and-
and
I
want
everyone's
input
here-
even
if
there's
a
better
way
to
lose,
one
which
is
is,
it
seems
like
we
should
be
using
map
string,
string
structures,
a
generic
structure
for
holding
protocol
specific
information,
rather
than
a
type
structure
where
we
have
fields
for
a
different.
You
know
different
information
in
the
protocol.
What
do
you
all
think.
C
Yeah
yeah
I
mean
for
things
that
are
effectively
opaque
to
kubernetes
or
to
the
co
string
maps
work
well.
A
Yeah
and
so
so,
let's
say
we
call
the
parameters
like
here,
we
already
have
a
parameter
section
in
the
bucket
class,
which
is
outside
of
the
protocol
structure,
and
one
of
the
things
we've
we
were
talking
about
was
is
that
parameters
still
needed
because
we
have
a
protocol
specific
ground
issue,
and
we
think
it
might
be
needed
again
open
to
suggestions
here
or
there's
a
better
way
to
do
this.
We
want
to
know
which
is
then
for
protocol
specific
information.
F
F
A
There
is
a
conceptual
difference
between
protocol,
specific
parameters
and
just
parameters,
and
our
question
is
really
yeah,
like
you're
saying:
should
we
should
we
have
two
specific
fields,
or
does
it
make
sense
to
to
have
them
as
one
one
field,
one
one
string
map
with
all
the
protocol
and
provide
a
specific
information
mashed
in.
A
Like
like
right
here,
region
now,
say
usc
1,
it's
protocol
specific,
but
then
like
if
you're
running,
you
know,
if
you're
doing
ceph
with
the
s3
api,
you
have
to
choose
a
storage
pool
and
say
you've
chosen
the
storage
pool
one
and
and
that
would
go
into
the
parameters
that's
outside
of
the
protocol.
I'm.
F
C
F
C
Not
convinced
that
these
protocol,
specific
things
are
opaque
to
kubernetes
like
if,
if
they're
s3,
specific
and
every
s3
driver
needs
to
or
every
driver
that
purports
to
support,
s3
has
to
support
this
parameter.
Then
it's
not
really
opaque
and
it's
part
of
the
spec
and
we
might
validate
it
or
we
might
do
things
to
it.
A
I
don't
believe
other
than
something
like
bucket
name.
There
are
many
fields,
any
fields
really
that
have
to
be
supported
by
all
of
them.
Even.
C
What
we're
concerned
about
is
portability
right
like
like.
If
we
want
to
advertise
like
this,
is
an
s3
compatible
bucket
type,
then
the
idea
is,
I
should
be
able
to
go
out
and
invent
a
new
storage
product
that
implements
that
protocol
and
expect
that
everyone
who
has,
who
has
you
know
coded
their
kubernetes
workload
to
to
run
on
top
of
these
s3
buckets,
should
be
compatible
with
mine
right
that
so
that's.
A
Right
portability,
yeah
yeah,
that's
a
good
argument.
So
that's
one
of
the
main
reasons
you
want
to
have
two
separate
parameters:
field.
If
you
see
there's
one
inside
protocol
and
one
at
the
bottom,
which
is
at
the
same
level.
F
A
Because
so
so
that's
a
good
question.
So
the
the
issue
is,
there
are
a
lot
of
protocol,
specific
features,
a
ton
of
them
and
if,
if
aws
comes
up
with
new
set
of
parameters
or
some
other
vendor
comes
up
with
a
new
set
of
parameters
for
that
protocol
in
order,
but.
F
C
So
so
the
generalized
parameters
down
at
the
bottom
of
the
bucket
class
make
sense
because
those
are
truly
opaque,
but
I
don't
believe
that
the
parameters
under
the
protocol
are
opaque.
I
think
that,
like
things
like
region,
while
they
might
have
a
little
bit
fuzzy
meaning
like
they're,
it's
not
an
opaque
field.
It's
it's
a
field
that
we
understand
what
it
means,
and
it
should
mean
something
similar
across
implementations
of
s3.
A
Okay,
so
I'm
what
I'm
concerned
about
is
just
like
what
happened
with
cloud
providers.
We
we.
We
could
not
quickly
enough
move
along
with
the
requirements
of
the
cloud
vendor
when
they
had
to
make
a
change,
so
we
ended
up
moving.
C
And
and
a
vendor
right,
not
there's,
no
end
user
interaction.
There
is
there
or
am
I
missing,
I'm
not
familiar
with
cloud.
D
D
And
think
about
why
you
have
first
class
fields
and
why
you
have
opaque
list
of
key
value
pairs
and
the
reason
that
we
ever
do
opaque
key
value
pairs
is
to
allow
for
customization
of
the
the
resource
being
created.
A
D
D
C
A
Well,
we're
trying
to
avoid
you
know
user
error
based
on
what
you're
saying.
So,
if,
if
a
user
writes
the
parameters
in
such
a
way
that
it's
specific
to
whatever
the
provider
is
then
yeah,
but
it
is
also
possible
to
write
parameters
in
such
a
way
that
it's
portable,
given
this
structure.
C
They
need
a
bucket
to
store
things
on,
like
I
have
to
code
my
application
to
read
these
files
and
understand
what's
in
them,
so
I
can
consume
buckets
that
kubernetes
gives
me
and
if
there's
no
documentation
anywhere,
that
says
what
is
going
to
be
in
that
file
like
what
am
I
going
to
do?
No,
the
documentation
comes
from
the
driver.
What
fields
are
under.
D
Right,
but
I
I
think
what
ben's
getting
at
is:
how
do
you
enforce
that
contract
effectively?
If
you
make
this
a
pass-through,
then
what
you're
saying
is
that
the
driver
gets
to
determine
what
an
s3
protocol
looks
like,
and
I
think
what
ben
is
arguing
is
like.
If
you
have
three
sets
of
drivers
that
implement
the
s3
protocol,
they
all
choose
to
expose
a
different
set
of
parameters
as
a
consumer.
D
C
D
C
Yeah,
I
think
I
think
that
the
key
here
is
that
for
for
bucket
protocols
that
are
not
s3
that
are
basically
only
implemented
by
one
implementation
in
the
real
world
like
this
is
less
of
a
problem,
because
then
you're
you're
coding
to
a
very
specific
implementation,
but
s3
has
become
a
de
facto
standard
and
there
are
dozens
of
interoperable
implementations
and
there
are
features
that
are
common
to
all
of
those.
Whether
or
not
they're
documented.
I
mean
that's
amazon's
fault,
I
guess
for
not
sort
of
making
it
a
standard.
But
like
there's
a
de.
C
That
that
just
have
to
be
there,
because
otherwise
it's
not
s3
and
like
those
are
the
fields
that
we
should.
We
should
make
them
top
level
fields
and
document
what
they
mean
and
say
everything
that
purports
to
be
s3
has
to
fill
these
in
and
then
the
guy
that
wants
to
consume.
It
knows
that
he'll
at
least
get
that
it
might
get
more
stuff
with
extra
fancy
things
but
like
they
don't
have
to
depend
on
the
fancy
things
they
can
depend
on.
What's
documented.
A
C
I
think
so
I
think
I
like
I
I
have
I
haven't
implemented,
you
know
s3
clients
and
servers
and,
like
there's,
there's
basically
like
five
things
that
you
always
need,
and
that's
you
know
and
that
you
can
tease
it
out
of
the
s3
spec
and
and
like
the
region
is,
is
one
of
them
and
the
end
point
and
the
bucket
name
and
then
there's
like
and
then
the
access
key
and
the
secret.
I
think
like
it's
something
like
those
five
things
are.
C
Be
there
and
of
course
we
don't
want
to
have
secrets
in
here,
because
we
have
special
handling
for
those
but
like
when
it
comes
to
defining
like
what
shows
up
inside
the
bucket.
I
think
we
can
be
very
specific
about
that,
and
then
for
for
the
parts
of
that
information
that
come
from
the
bucket
class.
I
say
it's
a
first
level
field
because
it
has
to
be
there.
A
Yeah
I'm
saying
even
in
that
case,
could
we
could
we
use
do
that
using
well-defined
keys
for
the
map
itself
rather
than
first
yeah?
Again,
I'm
not
I'm
not
for
one
way
or
the
other
asking
questions
here,
because
we
could
achieve
that.
That
way.
What's
would
that
work.
C
G
C
I
understand
that
the
reason
that
the
parameters
down
at
the
bottom
aren't
enough
is
because
those
aren't
going
to
get
sent
through
to
the
pods
that
eventually
consume
the
bucket
those
only
get
sent
to
the
provisioner,
the
ones
that
are
in
the
protocol
field
will
get
sent
to
the
pods
and
that's
why
you
need
them
up
there.
Okay,
I.
C
A
Yeah,
so
we're
almost
out
of
time,
but
if
we
can
quickly
kind
of
wrap
up
this
one
conversation,
which
is
for
the
sake
of
keeping
the
struct
simple,
the
protocol
struck
itself
simple.
A
A
What's
the
best
way
to
enable
different
vendors
to
add
new
new
fuels
without
having
to
go
through
the
kubernetes
development
life
cycle?.
C
Great
so
so
I
I
think
that
I,
I
don't
think,
that's
a
concern.
I
think
that,
for
the
things
that
we're
arguing
should
be
first
class
fields
like
there's
something
that
we
have
to
get
right
period
before
we
introduce
the
protocol,
because
once
once
you
define
a
protocol,
you
can't
really
change
it
unless
there's
a
versioning
mechanism,
because
people
will
start
consuming
that
and
writing
pods.
That
expect
to
you
know.
A
A
There
is
a
versioning
mechanism
and
we
want
to
upgrade
the
version.
So
there
is
a
important
security
fix
that
comes
in.
If
we
don't
have,
you
know
if,
if,
if
some
field
needs
to
be
added,
that's
definitely
required
and
it
needs
to
go
through
the
kubernetes
lifecycle.
We
are
we're
effectively,
you
know,
holding
them
back
from
pushing
the
security
fix.
C
Thinking,
I
don't
know
sidewalk
what
do
you
think
about
the
just
letting
this
putting
these
be
opaque
even
for
things
that,
like
you,
definitely
have
to
have.
A
A
Time,
yeah:
let's,
let's
bring
it
up
with
him
around
say
on
monday,
so
shin
will
be.
Will
we
be
meeting
next
week
on
monday,
as
was
thursday.
F
Next
week,
so
the
meeting
is
still
on.
I
don't
thursday,
I
I
don't
know
if
the
community
is
going
to
cancel
some
meetings
next
year.
I
haven't
seen
anything
because
next
week
is
actually
kubecon
right.
So
what
she
could
come
don't
know,
but
I
haven't
seen
any
kinds
of
things
so
right
now
those
meetings
are
still.
A
E
C
F
F
Of
canceling
meetings
is
a
technical,
send
email
right.
You
can
send
an
email,
monday
saying,
meeting
cancel.
Then
people
will
get
that.
I
think
you
send
out
to
the
you.
Probably
have
everybody
if
you,
if
you
send
the
email,
but
I
wouldn't
get
that
so
yeah
I'll.
Ask
that
I
don't
know
if
what
you
want
to
do,
because
we
do
have
some
other
meetings.
F
F
Oh
yeah,
sorry,
I
think
I
I
forgot
to
record
in
the
earlier
part,
so
I
think
I
only
recorded
half
of
the
meeting.
A
Oh
okay,
it's
okay!
I
think
yeah,
the
good
part
of
the
discussion
you
got
there.
A
Okay,
so
so
then,
let's,
let's
continue
this
on
monday.
There
are
a
few
other
concerns,
but
we're
definitely
heading
in
the
right
direction.
A
Oh
that's
good
yeah!
If
anyone
else
has
any
questions,
now's
a
good
time
to
ask:
if
not
we
can.
We
can
wind
up
for
today.