►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 27 May 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
All
right,
okay,
so
okay,
there's
a
few
things
we
were
talking
about
last
week.
We
should
continue
them,
but
to
begin
with,
I
want
to
give
a
quick
update
on
the
cap
and
then
and
then,
let's
talk
about
the
sample
drive
that
nicholas
has
been
implementing
and
then
we'll
get
into
the
discussion
we're
having
last
week.
So
to
start
off
with
about
the
cap,
let
me
let
me
share
my
screen,
so
I've
started
making
changes
to
the
cap
to
make
it
really
really
simple.
A
B
A
The
apis,
I
I
just
simply
just
paste
the
go
structure
like
tim
asked.
I
think
if
we
have
enough
comments
here,
it
clearly
denotes
what
it's
supposed
to
do
same
thing
with
the
rest
of
the
apis.
I
haven't
pasted
the
access
apis
yet,
but
it's
just
a
matter
of
copy
pasting
and
then
getting
into
things
like
application,
pods
and
download
apis.
I
think
download
is
what
we'll
be
discussing
today,
we're
still
figuring
that
out.
Did
you
make.
A
Yeah
we
talked
about
azure
if
either
guy
or
vyani
yeah,
the
two
of
them
we're
gonna,
come
back
with
a
proposal
for
what
azure
should
look
like
yeah,
we'll
get
we'll
use.
B
A
Yeah,
so
that's
where
we
are,
I
think
one
thing
we
can
do
to
make
this
easier
for
anyone
who's
reading.
This
is
to
just
have
a
bunch
of
diagrams
just
a
bunch
of
block
diagrams.
That
just
simply
say:
what's
the
order
of
operations
like
what
does
the
user
do
and
where
does
it
go
from?
A
A
Okay,
let's
get
to
the
sample
driver,
there's
a
pr
for
the
sample
driver
and-
and
I
believe
there
are
some
comments
on
it.
I
feel
like
it's
been.
It's
been
sitting
there
for
a
while,
so
I
just
want
to
figure
14
days
now,
so
I
just
want
to
figure
out
what's
needed
to
move
this
along.
A
So
so
nicholas.
Christians
left
some
comments
on
this,
like
what
like,
what's
going
on,
I'm
trying
to
understand
why
it's
taking
so
long.
C
Well,
those
comments,
and,
and
also
some
of
them
like
related
to
ci,
etc.
Let's
please
use
when
reviewing
pr
etc.
Look
at.
Does
this
make
an
improvement?
It's
not
necessarily
perfect,
as
in
I
know,
this,
for
example,
does
not
include
pro
integration,
but
I
don't
think
it
requires
I'm
not
even
familiar
with
pro
myself,
so
so,
integrating
it
with.
It
could
be
quite
difficult.
B
It's
a
christian
is
the
one
who
worked
on
that.
It's
already
in
other
cozy
repos
already
have
those.
I
think.
B
Oh
yeah,
this
one
is
new.
It's
brand
new,
if
you
can,
maybe
you
can
take
a
look
of
other
cozy
repos
and
see
what
it
is.
C
C
And
then
we
can
remove
things
and
add
things
in
in
follow-ups.
But.
A
I
feel
like
okay,
so
let's
go
into
the
comments
I
like
I
don't
know.
If
he's
asking
you
to,
I
looked
at
them
earlier.
Does
it
really
say
that
we
should,
I
don't
think,
he's
asking
for
more
scope
right,
like
krish,
like
I'm
trying
to
understand
so
are
these
asking
for
changes
or
are
we
adding
more
features.
A
D
I
think
I
was
using
the
wrong
mic,
so
I
was
just
talking
it
wasn't
going
through,
but
yeah.
I
I
wouldn't
say
to
add
the
proud
stuff
in
this
pr.
I
would
just
say
to
remove
the
github
ci
stuff
right.
That's
basically
like
dead
code
right
now,
because
we
can't
use
github
get
up
ci
with
the
current
setup
yeah.
We
can
always
add
the
proud
stuff
in
a
later
pr.
I
agree
with
you
on
that.
D
A
So
is
github
ci.
Does
it
doesn't
work
with
kubernetes
repose
right
because
it
uses
pro.
B
Github
engineers,
one
project,
uses
that
there's
a
windows
project
actually
uses
that
one.
But
if
you
look
at
all
the
other
kubernetes
css
that
use
pro,
so
we
should
use
that.
I
thought
is
that
srini
actually,
who
did
some
initial
work,
but
I
kind
of
crossed
the
track.
B
You
know
I'm
just
thinking
like
this
should
follow
this
other
cozy
ripples
doing
the
same
thing.
Instead
of.
B
A
different
set
of
cia.
A
Yeah
just
remove
the
ca
stuff
yeah
and
I
think
if
there,
whatever
comments,
take
care
of
those
two
but
yeah.
Don't
you
don't
have
to
add,
like
you
said,
let's,
let's
move
forward
with
something
that
works
move
the
needle
forward.
But
if
it's
a
simple
comment,
I
think
I
think
you
can
quickly
take
care
of
that
like
it
seems
to
be
something
about.
C
C
A
Yeah,
let's
go
into
them
now.
I
was
looking
for
other
comments,
but
here's
the
driver
name.
I
guess.
D
I
could
explain
my
rationale
for
wanting
the
change
there
so
like
the
csi
host
path
sample
like
driver
right
that
one's
under
the
csi
like
group
right
csi.kids.io,
so
I
proposed
that
the
sample
driver
should
be
under
the
object,
storage
dedicates
dot,
io
group
that
we've
been
using
for
the
other
projects
right.
So
that's.
Basically
the
change
here.
A
Fair
enough
shouldn't
you
shouldn't,
we
be
just
you
know,
symmetric
with
csi,
I
I
don't
mind
as
long
as
it
works.
It's
okay,
but
I
mean
isn't
that
how
we
have
always
been
doing
things
shouldn't
we.
I
know
it's
a
terrible
argument
to
say:
that's
why
we've
always
been
doing
things,
but
this
is
the
problem.
G
F
D
D
A
A
A
Yes,
okay,
all
right
all
right
I'll
leave
it
up
to
you
nicholas.
May
you
I'll
leave
the
edition
up
here.
I
think
it
makes
sense,
but
I
think
it's
okay
and
keep
this
as
simple
as
yeah.
Why
don't
we
use
cobra
cobra
is
what
we've
been
using
everywhere
else
and
like
pretty
much
all
of
kubernetes
use
cobra.
A
Again,
I
don't
know,
there's
no
right
answer
here
either,
but
to
move
this
along.
What
do
you
think
nicholas.
A
So
so
this
is
going
to
serve
as
the
example
for
others
to
write
drivers
shouldn't.
We
use
a
framework,
that's
more
flexible
if
they're
going
to
just
copy
paste,
the
code
wouldn't
cobra
make
it
easier
for
them
to
add
more
flags
as
needed.
Instead
of
having
to
you
know,
they'll
probably
start
with
this
flag
framework.
Now.
B
E
Maybe
we
can
just
make
this
comment
like
convert
this
comment
to
an
issue
and
then
merge
it.
This
way.
E
G
A
A
C
Well,
the
the
issue
for
that
should
be
created
once
we
have
ci
the
the
problem
is
that
well
problem
the
original
code,
which
gets
which
is
in
this
pr
worked
when
it
was
written.
In
the
meantime,
this
one
field
has
been
removed
in
the
api,
I
believe,
but
others
may
have
been
removed
as
well,
etc.
So
so
as
long
as
we
don't
have
ci,
as
long
as
we
don't
are
not
running
the
tests,
then
there
can
be
other
breakage.
A
Naturally,
can
you
repeat
that
please.
C
C
So
from
my
point
of
view,
we
should
not.
We
shouldn't
even
create
an
issue
right
now
to
remove
bar
namespace,
but
when
actual
ci
is
in
place
and
this
thing
gets
tested
again
because
it
was
tested
in
in
in
my
in
the
source
repository,
but
it's
not
yet
tested
in
the
target
repository,
then
tests
may
fail,
tests
will
likely
fail
and
they
would
need
to
be
fixed.
But
as
long
as
we
don't
run
tests,
then
there
is.
I
mean
chris
now
notice
that
bar
namespace
is
no
longer
required.
C
E
Maybe
the
issue
should
be
to
just
integrate
with
the
pro
right
that
that's
the
issue
right.
C
A
A
C
A
E
C
Yeah
sorry
go
ahead
note
because
of
the
fact
no
tests
are
being
executed
right
now.
This
whole
thing
could
be
broken.
The
fact
that
bar
namespace
is
there,
maybe
one
cause
of
breakage.
If
you
now
say
we
have
to
remove
it,
because
people
may
look
at
this
and
hence
believe
that
this
thing
works
well,
we
can't
assert
that,
because,
even
if
we
remove
this,
there
may
be
other.
A
E
F
There
I
think
visual
inspection
is
a
pretty
good
approximation
of
of
knowing,
if
it's
right
or
wrong
and
you're
right.
It's
not
a
hundred
percent
like
testing
would
be,
but
if
we,
if
we
can
visually,
determine
that
something
is
incorrect,
we
would
fix
it
and
then
you're
there's
a
small
chance
for
missing
something
that
the
test
would
turn
up.
But
it's
not
an
argument
not
to
fix
the
things
that
we
know
are
wrong.
B
F
A
Unrelated
all
right,
I
think
this
looks
pretty
straightforward.
Just
make
the
tiny
changes
and
please
re-review
once
that's
done
and
yep.
D
A
Yeah,
okay,
yeah!
Please
please,
work
together
and
you
know
help
move
this
forward.
A
All
right!
That's
it!
That's
it
on
this!
I
don't
want
to
spend
any
more
time.
We've
already
spent
a
lot
of
time
on
this,
let's
get
into
let's
get
into
the
next
thing,
which
is
which
is
which
is
the
api
for
the
downward
api.
So,
as
of
last
week,
we
discussed
how
the
download
api
should
look
for
s3
and
then
we
got
into
how
it
should
look
for
azure,
and
so
we
call
the
api
bucket
access
info,
and
this
is
what
the
structure
is
going
to.
A
So
we're
talking
about
azure
and
vyani
and
guy
we're
going
to
go
figure
out
what
this
structure
should
look
like.
So
I'll
give
it
up
to
you
guys.
F
A
F
A
It's
just
it's
just
friendly
to
how
we
do
things,
what
we
need
in
the
future,
instead
of
having
them
be,
you
know
fields
here
we
could.
We
could
always
expand
on
this.
F
G
F
Okay
yeah
as
long
as
it's
as
long
as
it's
clear
in
the
in
the
because
this
is
an
api
contract.
So
as
long
as
it's
clear
that
they're
definitely
going
to
be
non-null
and
there's
definitely
not
going
to
be
anything
else,
then
then
then
you're,
fine
and
then
you're
right
over
time.
You
could
in
principle,
evolve
it
with
new
fields.
F
If
we
came
up
with
a
design
that
allowed
that
so
the
well
I
want
to
skip
over
certificates
because
that's
the
hard
one
signature
version
did
we
convince
ourselves
that
this
is
absolutely
necessary
and
useful.
A
E
A
F
Right
but
I'm
saying
like
like
by
default,
we
should
have
a
sensible
default.
I
guess
that's
just
where
I'm
going
with
this.
Is
that
like?
If
I,
if
I
don't
say
I,
if
I
don't
ask
for
specific
version,
is
it
possible
that
I'll
get
something
other
than
v4,
because
if
so,
then
that
sort
of
suggests,
I
must
always
put
v4
in
my
bucket
classes?
If,
if
my
client
refuses
to
speak
v2
right.
F
F
Mean
we
need
to
talk
about
the
today
and
and
the
tomorrow,
so
I'm
saying
like
today,
if
they
don't
specify
it
is
the
server
free
to
give
me
an
s3
v2
only
bucket,
if
that's
what
it
has
available
to
it
or
or
would
would
it
be
like
s3v2,
be
an
opt-in
thing
where
I
could
only
get
it
if
I
explicitly
asked
for
it
and
and
it
you'd
be
surprised
to
get
anything
other
than
the
default,
because
I'm
just
I
mean
I'm,
I'm
assuming
that
you're
like
yeah.
F
We
should
support
s3v2
for
those
who
really
want
it,
but
we
should
like.
We
don't
want
anyone
to
fall
into
that
into
that
trap
by
accident
right.
You
would
you
really
want
to
say
I
I
want
s3,
v2
or
or
at
least
at
least
assert,
that
I
am
willing
to
accept
s3v2
if
that's
the
best
you've
got
so
that
the
server
can
you
know,
look
at
its
potential
places
that
it
might
put
the
bucket
and
pick
pick
one
that
has
because
the
goal
of
the
end
user
is
like.
F
I
know
what
my
workload
can
and
can't
do,
and
I
I
want
to
request
buckets
that
will
work
with
my
workload
and
so
maybe
I
happen
to
know
that
I'm
running
in
a
private
cloud
that
only
has
s3
v2
support
and
therefore
I've
set
up
my
my
workloads
to
be
compatible
with
s3
v2,
and
I
you
know,
make
the
right
the
right,
storage
or
bucket
class
parameters,
and
then
I
get
it
but
like
the
guy
who
doesn't
do
that
and
just
wants
to
adhere
to
the
standard
of
v4
should
be
able
to
say
that's
what
I
want
so
so
maybe
the
answer
is
you
just
always
put
s3v4
in
your
bucket
class
and
then
you're
guaranteed
to
always
get
it
here.
F
But
then
the
next
question
is
imagine
a
future
where
there
is
an
s3
v5
like
okay.
So
presumably
what
will
happen
is
all
the
implementations
will
continue
supporting
v4,
while
people
gradually
migrate
to
v5,
and
so
in
that
transitional
period
you
can
keep
asking
for
v4
and
keep
obtaining
it.
Even
though
the
server
could
have
given
you
v5
and
then
as.
F
E
F
F
F
F
E
F
F
Only
this
other
bucket
access
class
is
s3v5
only
and
maybe
this
third
bucket
access
class
is
isn't
either
or
and
then
I
can
choose
based
on
it,
you're
right
that
like
if,
if
there
isn't
a
bucket
access
class
that
expresses
what
you
want,
you
have
to
go
to
an
admin
and
say:
please
create
it,
but
like
that,
that's
that's
a
better
situation
than
having
people
do
one-off
requests
in
there
in
their
bars
that
are
override
things,
because
the
admin
should
have
veto
power
over
those
kinds
of
things.
F
E
F
E
It's
not
concrete
right,
it
doesn't
mean
so
what
I'm
saying
that
by
choosing
a
bucket
access
class,
I'm
not
I'm
not
concise,
about
which
version
my
workload
is
compiled
to
support
right,
for
example.
Well,.
F
F
Consumer
because
it
actually
affects
the
the
pod
spec
and
and
the
how
you
specify
your
pod,
but
but
most
other
sort
of
you
know
subtle
features
of
a
of
a
volume
you
would
just
specify
in
your
storage
class
and
then
those
workloads
that
care
would
go,
look
at
the
storage
class
and
and
and
choose
a
storage
class
that
has
what
they
need
or,
if
or,
if
not,
then
get
an
admin
to
create
a
storage
class.
And
that's
that's
not
viewed
as
a
problem
over
on
the
volume
side.
F
F
I
mean
the
the
specific
exceptions
are
things
that
affect
the
api,
like
volume
mode
like
access
modes,
there's
a
few
things
that
do
show
up
in
in
the
in
the
pvc,
but
those
don't
show
up
in
the
storage
class.
So
it's
like
they
made
the
decision.
Some
things
are
storage
class.
Some
things
are
pvc,
nothing
is
nothing
is
both,
and
this
feels
like
a
bucket
access
class
thing,
but
but
yeah.
A
A
That
we
have
as
first
class
fields,
protocol
specific
fields.
F
Well,
yeah:
we
need
to
fix
that,
but
like
we
need
to
define
this
first,
because
this
informs
how
we
fix
that.
I
think
like
once.
We
know
what
what
we
are
responsible
for
delivering
to
the
workloads.
Then
we
can
figure
out
like
what
is
the
right
way
for
the
user
to
tell
us
what
they
want
or
or
for
the
admin
to
give
you
there's
a
menu
of
choices
that
they
can
pick
from.
A
Yeah
this
is
this.
Is
this
is
kind
of
an
internal
question
like
what
nega
you
know
what
what
signature
version
you
use?
It's.
Okay
to
say
you
know
you,
you
make
the
assumption
that
if
the
driver
supports
v4,
you
get
v4,
it's
it's!
It's
a
it's
a
contract
between
the
driver
and
and
the
actual
workload.
F
F
Between
the
the
driver
and
the
workload
well,
it's
I
mean
I
imagine
that
we
didn't
have
this
field
right.
Then
that's
what
I'm
saying
then
what
you're
gonna
get
is
is
the
the
workload
is
gonna
have
to
presume
v4
but
like
if
that
fails,
for
whatever
reason
is
it
supposed
to
try
v2?
Is
it
supposed
to
try
v5
like
or
or
imagine,
a
future
where
v5
exists
but,
like
most
people
are
still
using
v4
like?
Is
it
okay
for
workloads
to
just
attempt,
v5
and
negotiate
down
to
v4
when
it
doesn't
work?
F
E
I
think
this
field
right
here
the
the
downward
api
of
it
at
least
leave
aside
for
a
second,
the
the
class
field.
But
but
this
field
is,
is,
is
the
communication
channel
between
the
driver
saying
this
is
what
you
should
be
using,
because
that's
what
what
I
allocated
for
you
and
it
doesn't
really
matter
after
we
got
to
this
point
where
I'm
telling
you
use
v2,
you
cannot
use
v4.
E
It
doesn't
make
sense,
because
I'm
asking
you
use
v2
right
and
we
we
should
assume
here,
at
least
that
that
you
know
the
workloads
at
least
are
capable.
E
I
think
that
that's
the
current
situation,
I
don't
know
if
we
can
assume
it,
but
that's
the
current
situation
that
most
workflows
are
capable
of
using
both,
but
sometimes
servers
would
like
to
ask
because
they
they
are.
You
know
like
to
take,
for
example,
the
aws
regions
which
used
to
have
v2
before
right,
and
they
didn't
support
it
yet
before
etc.
Right
so
these
servers
would
would
tell
you
by
documentation,
go
and
use
v2
with
us
with
these
regions
right
so
same
way.
E
Here
we're
trying
to
say
when
you
got
from
me
this
bucket
access,
you
should
use
this
one,
because
that's
what
I
you
know,
this
is
how
I
hooked
it
up
together
for
you.
This
is
what
I
have
for
you,
but
now
the
the
second
question
is:
do
we
need
also
the
you
know
upward
api
from
the
workload
back
to
the
to
to
cozy
to
say
what?
What
should
the
workload?
What
what
is
the
workload
expecting?
E
F
E
Impossible,
I
think,
is
it
I
mean
I
mean
what
I
mean
is
possible.
It's
always
possible
to
make
some
heuristic,
but
I
don't
it's
not
that
impossible,
but
I
I
don't
think
any
worker
does
that
so.
A
They
make
assumptions
about
what's
supported
by
the
back
end.
I
I
think,
if
you
want
to
keep
things
portable,
we'll
need
to
have
this,
because
you
know,
let's
say
you
move
from
something
that
supports
v4
or
something
that
doesn't
and
suddenly
your
workload
stops
working.
That's
not!
Okay,
it's
not
portable!
Then.
F
But
I
guess
I'm
also
having
a
hard
time
imagining
a
world
where,
like
v5,
doesn't
seamlessly
negotiate
down
to
v4,
just
given
the
massive
adoption
of
s3
v4.
You
know
when
s3v5
turns
up,
there's
going
to
be
this
huge
there.
If
and
when
I
should
say
it's
not
it's
not
a
sure
thing,
it
will
happen,
but
if
it
did,
if.
E
H
A
F
But,
but
what
I
mean,
what
I
mean
by
backward
compatible
is
like
you
still
you're,
still
sending
http
requests
with
some
some
headers
twiddled
and
you
could.
You
could
try
if
you
know
a
v2
style
and
a
v4
style
and
a
v5
style
as
like
three
separate
requests,
and
and
and
you
could
pick
some
benign
requests
that
just
like
lists
the
the
root
object
or
something,
and
then
you
know
and
see
which
one
succeeds
and
then
go
with
the
one
that
works
the
highest
one
that
that
doesn't
fail.
You
know,
does.
A
F
E
Yes,
no,
no,
that
was
a
lot
of
hassle.
Okay,
okay,
it
created
it
created
a
lot
of
hassle,
but
I
think
to
your
point:
if,
if
this
is
what
you're
saying
we
could
also,
instead
of
putting
this
effort
on
the
workloads
and
say
yeah,
your
workloads
should
auto
detect.
Let's
say
the
driver
will
auto,
detect
and
then
teleworkload.
F
F
Then
the
question
is:
is
this
a
is
this
a
single
value,
or
is
this
a
list
of
of
supported
values
because
I'm
still
confused
about
you
know
if
the
server
allows
both
v4
and
v5,
and
it
really
doesn't
care?
How
do
you
communicate
that
to
the
workload
that
you
know,
because
some
workloads
might
be
only
support
v4
and
they
need
to
know
that
v4
is
still
okay,
while
other
workloads
may
support
both
and
prefer
v5,
and
so
they
need
to
know
that
you
know
I
can
use
v5.
E
So
I
think
this
like
the
downward
api
should
be.
Like
should
be
decisive,
say.
This
is
what
you
know.
We've
set
up
for
for
this
workload,
but
if
you,
if
you
want
to
have
a
preferred,
you
know
whatever
preferences
and
negotiations
that
should
start
from
the
workload
side
or
the
class
side
like
either
the
request
side
say
these
are
the
list
of
versions.
I
would
be
able
to
use
right.
Give
me
one
of
the
one
of
those
or
I'm.
F
F
F
But
but
in
that
world,
then
then,
if
I'm
in
a
world
where
I
don't
know
what
the
server
supports
and-
and
I
just
want-
I
just
want
a
bucket
that
works,
I'm
always
going
to
stick
with
v4.
Then,
because
I
mean
I
know,
that's
the
only
thing
that
I
can
rely
on
to
to
successfully
create
a
bucket
and
then
no
one
will
ever
move
to
v5.
E
F
If,
if
you
can
only
specify
one,
then
people
are
always
going
to
choose
the
v4
one
because
to
choose
the
v5
one
might
might
fail,
whereas
to
choose
the
v4
one
will
never
fail
and
it
would
be
better
to
have
a
way
to
say,
prefer
v5
but
accept
v4
and
then
have
the
server
be
able
to
say.
You
know
what
I
can
only
do
v4.
So
don't
try
v5
with
me
and
have
another.
E
F
E
Don't
tell
it,
why
not
tell
it.
This
is
what
you
got
right.
This
is,
I
mean
the
client
can
support.
Also
other
features
that
on
top
of
what
we
have
here
right,
but
you
know
we
need
to
tell
it
what
to
use
from
like
for
from
from
the
class
that
we
use
here.
So
if
the
class
represents
you
know,
I
prefer
v5,
but
give
me
v4.
If
you
don't
have
it
and
then
the
driver
takes
this
as
a
request
for
v5,
if
possible
and
answers
okay,
here
you
go
v5
access.
E
Why
do
what
do
you
think
the
server
should
represent
a
choice,
a
menu
to
the
to
the
workload
at
this
downward
api?
Why
not
give
it
one
after
I
told
you
what
it
can
use.
F
F
F
But
if
the
server
can
support
both,
therefore,
a
workload
that
only
supports
v4
would
work
in
a
workload
that
prefers
v5
could
also
work.
How
do
you
communicate
that
fact
to
the
end
user
right
to
the
individual
pod
right,
because
because
the
the
user
didn't
care
he
he
picked,
you
know
either
one,
and
so
the
server
had
to
put
it
on
something,
and
then
the
workload
is
is
a
third
variable
which
may
or
may
not
support
both,
and
if
it-
and
you
know
you
know,
you
need.
B
F
F
So
it
feels
like
a
list
to
me,
but
but
we're
getting
pretty
deep
into
this
one
specific
parameter
and
not
making
progress.
B
F
I
I
don't
know
how
to
how
to
wrap
this
up,
but
but
I
I
think
we
need
to
put
a
a
pin
in
it
to
say
that.
F
F
What
to
do
with
these
with
these
signature
versions,.
F
E
It
really
that
difference
then
different
than
sorry
different
than
the
the
fact
that
I'm
choosing
s3
versus
azure,
for
example,
like
the
workload
from
the
workload
perspective,
I
can
have
a
workload
that
supports
both
right
technically
speaking
right.
I
can
write
it,
but
do
I.
F
Like
do
I
even
care
about
these
things,
but
but
you're
guaranteed
when
you
get
this
bucket
access
info,
that
only
one
of
the
of
this
of
the
members
will
be
populated
so
like,
if
you're
the
guy
parsing
the
file
that
we
inject,
you
know
what
what
keys
to
look
for
and
then,
if
it's
s3,
you
know
what
sub
keys
to
look
for.
No.
E
F
F
E
E
H
E
H
E
No,
but
I
mean
at
this
like
at
that
time
right
when
both
versions
are
still
valid
in
the
standard
and
some
workloads
are,
you
know
were
not
were
not
rebuilt
to
support
it.
H
E
E
A
A
Adds
more
so
the
whole
point
of
specifying
is
it's
so
that
that
you
know
we're
perceiving
or
we're
thinking
that
by
specifying
we're
going
to
make
the
life
easier
for
for
the
applications
to
stay
compatible
with
the
object
storage
provider?
But
it
seems
to
add
more
complex.
E
No,
no,
we
won't
make
it
compatible.
We
will
make
it
deterministically,
you
know
fail
if
it
doesn't.
If
it
doesn't
say
if
the
synchronization
didn't
didn't
occur,
right.
F
Yeah,
that's
my
worry
is
that,
in
order
to
get
this
right,
we
would
need
a.
We
would
need
a
list.
I
think
to
get
it
really
right
and
it's
hard
to
understand
what's
going
on,
because
the
list
would
have
to
appear
in
in
the
bucket
class
or
the
bucket
access
class
and
the
bucket
access
object
and
the
downward
api
right,
and
it's
like
you,
have
all.
F
Hold
on
so
the
the
thought
that
popped
into
my
mind
is
if
this
is
a
problem
in
practice
for
somebody
like
like.
Let's
imagine
we
leave
the
field
out
and
then
and
when
we
reach
beta
or
hga
or
whatever,
and
then
the
next
week,
amazon
announces
v5
support
and
v4
is
deprecated
in
a
year
and
so
over
the
course
of
the
next
year,
like
everything's,
going
to
be
moving
over.
F
What
you
could
do
is
is
a
you
know,
for
the
for
the
workloads
that
you
know
haven't
been
recompiled
for
v5,
yet
you
could
use
opaque
parameters
in
your
bucket
access
class
to
say
you
know
what
this
application
needs.
The
old
protocol,
because
I
haven't
recompiled
it
yet
and
just
treat
it
as
an
opaque
thing.
F
The
driver
could
say:
okay,
you
know
only
give
him
a
bucket
that
supports
v4
and
then
and
but
but
it
would
be
a
temporary
situation
right
because,
after
the
end
of
a
year,
you'd
know
that
v4
was
was
was
dead,
anyways
and
and
if
the
applications
hadn't
been
recompiled
by
that
point,
they're
just
doomed.
So
so
it's
still
the
solvable
problem
using
opaque
params.
E
It
right
just
to
I
think
I
agree,
but
because
I
just
understood
like
what
you
said
that
basically
what
you're
saying
is
that
we
don't
need
the
field
and
the
reason
why
we
don't
need
it
is
that
the
only
usage
of
it
at
this
point
is
to
go
back
to,
like
the
previous
version,
tell
the
workload
use
a
previous
version
and
you're
saying
for
that.
You
know
just
the
admin
will
just
restrict
the
bucket
access
class
or
restrict
the
class
to
do
that
and
that's
it
and
it
will
be
assumed
by.
H
B
F
Negotiate
its
way
down,
but
but
as
long
as
as
long
as
that's
possible
yeah,
we
can
stay
out
of
the
way
and
just
let
let
things
work
and
and
for
the
vast
majority
of
things
it'll
probably
be
v4
only
and
they
won't
try
negotiating
and
you
don't
have
any
problems
right.
H
F
A
H
A
Okay,
so
I
made
it
a
map
string
byte
because
just
the
file
name
for
the
certificate
and
and
actually
no
okay,
it's
a
kind.
H
F
What
it
means
in
practice
is
that,
like,
if
you're,
if
you're
in
a
private
private
cloud
situation
or
in
your
object,
storage,
is,
is
like
using
some
self-signed
certificate
that
it
will
be
incumbent
on
the
the
guy
pressing
the
images
to
embed
the
appropriate
search
in
his
images,
so
that
his
workloads
can
trust
the
s3
server.
That
they're
talking
to
right.
That.
E
F
E
Also
mount
it,
I
mean
there's
plenty
of
ways
where
you
can
inject
ca:
certificates
to
a
pod
right
or.
H
F
F
You
know
private
kubernetes
clusters
with
self-signed
certs
running
everywhere,
and
you
want
your
workloads
to
be
able
to
trust
your
object,
storage
which,
which
means
that
the
ca
does
need
to
get
in
there
somehow
and
that's
how
the
idea
came
up
but
yeah.
I
like
the
idea
of
saying
you
know
what
there
are
other
ways
to
do
that
in
kubernetes
yeah
and
we
don't
want
to
make
it
cozy's
job
to
be
schlepping
certificates
around.
You
know
you
just
have
to
figure
that
out
how
to
band
or.
C
Because
all
of
a
sudden
you
have
to
you,
have
to
create
a
config
map
or
a
secret
in
which
you
then
have
the
the
cser,
and
you
have
to
change
your
fault
spec
to
actually
mount
that
at
a
particular
location.
So
you
can't
take
the
same
pulse
back
and
move
it
across
clusters.
F
C
A
Mean
we're
relying
on
a
lot
of
different
things
not
to
be
portable
right
like
like
even
the
ip
addresses.
I
mean
the
whole
cni
infrastructure
that
we're
relying
on.
If,
if
that
didn't
do
its
job,
it
wouldn't
be
portable
either.
I
I
don't
think
we
need
to
worry
about
that,
because
certificates
are
not
something
that
it's
required
to
talk
to
an
object,
search
provider,
but
it's
not
really
an
authentication
mechanism
primarily
used
in
object,
storage.
C
F
F
Right,
it
doesn't
seem
like
a
show-stopper
to
me.
I
I
cuz,
because
so
so
on.
The
flip
side
is
my
worry
is
if
we
do
just
give
you
a
bundle
of
search
like
it's
get
it's
going
to
be
very
hard
for
some
some
applications
to
figure
out
what
to
do
with
those,
because
a
lot
of
things
you
know
either
use
the
built-in
ca
store
of
the
operating
system
that
they're
running
in
and
so.
F
F
F
I'd
rather
start
from
a
position
of
leaving
it
out
and
having
it
being
more
simple
and
then,
if
someone
comes
to
us
with
a
you
know,
with
a
sob
story
of
why
it's
so
hard
to
to
to
get
this
right
and
they
they
convince
us
that
we
really
need
it.
Then
we
can
say:
okay,
you
know
invade
your
alpha
2
we're
going
to
add
certificate.
Support
to
this
thing,.