►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 15 July 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
All
right,
good
morning,
everyone
good
afternoon,
if
here
on
the
east
coast,
so
lately
what
we've
been
doing,
is
preparing
the
cap
to
to
get
it
reviewed
and
make
it
a
part
of
make
this
proposal
a
part
of
the
next
kubernetes
release.
When
I
say
this
proposal,
I
mean
the
the
bucket
api's
see
some
new
people
here,
so
I
figured
I'd,
give
a
quick
background
all
right,
so
I'm
sharing
my
screen.
A
What
I'm
showing
here
is
the
current
design,
so
the
current
cap-
this
is
this-
is
what's
there
in
the
pull
request
too,
and
as
I
was
writing
more
of
the
more
of
the
cap.
One
thing
I
realized
was
when
provisioning
buckets
into
pods
the
structure
that
goes
into
a
part
we
haven't.
We
haven't
completely
worked
out
yet
because
earlier
we
were
relying
on
this
structure
to
be
the
protocol
field.
C
A
For
yeah
for
bucket
request,
yeah
not
for
the
access.
A
B
That
comes
from
the
plug-in
back
to
the
sidecar
right,
so
the
so
you
you
created
an
s3
bucket
and
and
at
that
point
you
don't
know
how
to
connect
to
it,
because
no
one
has
access.
Then
you
create
an
access
request
and
you
go
down
to
the
sidecar
and
it
calls
grant
access
and
then
the
plug-in
returns
back
here
is
your
access
key!
Here's,
your
secret!
Here's,
your
endpoint,
here's
all
your
stuff
right
and
then
and
then
you
store
that
in
the
bucket
access
object
in
some
s3
specific
structure
and
then
that's.
B
And
that's
what
I've
been
trying
to
get
to
with
all
of
this
focus
on
the
download
api
is
getting
to
that.
A
Discussion
yeah,
so
so
here's
I
don't
know
if
it's
visual.
Let
me
let
me
go
to.
A
D
A
All
right
so
here
is
here
is
how
I've
written
it
right
now,
just
based
on
you
know
what
seems
most
logical.
I
think
at
some
point
we
were
deciding
we
should.
We
thought
we
should
call
it
bucket
info.
I
mean
it
doesn't
have
to
be
a
well-defined
resource,
though
it
is
preferable
to
have
it
that
way,
because
people
can't
read
the
definition
but
but
per
protocol.
It's
going
to
have
a
different
set
of
fields.
A
And
and-
and
I
agree
that
getting
these
fields
as
a
response
to
bucket
access
create,
makes
sense
now
earlier
we
had
this,
we
had
this
idea
where
we
would
have
a
bucket.json
on
a
separate
credentials.
File
and
the
reason
for
the
credentials
file
was
that
if
you
have
existing
clients
for
say
aws,
they
wouldn't,
and
if
you
put
the
credentials
file
in
a
standard
path,
they
wouldn't
have
to.
You
know,
learn
the
cozy
api
or
figure
out
how
to
read
from
cozy.
A
They
could,
just
you
know,
turn
key
start
using
cozy,
but
right
now,
since
you
introduced
bucket.json,
that's
that's
not
possible
anyways
because
they
have
to
read
bucket.json.
B
Well,
the
I
thought
that
the
theory
was
that,
no
matter
what
we
define
as
the
downward
interface,
you
could
use
something
like
an
init
container
to
to
handle
the
impedance
mismatch
of
converting
whatever
we
provide
to
a
standard
format,
so
that
the
application
running
in
the
real
container,
it
still
doesn't
need
to
change
right
yeah.
It
can
still
be
done
so.
C
B
A
B
A
That's
right,
yeah,
okay,
so
for
protocol.
We
I'm
thinking
we'll,
have
separate
structures.
I
don't
think
we
need
to
abstract
out
common
fields,
approximately
false,
we'll
just
we'll
just
leave
the
messages
inside
the
protocol
structure
show
things
like
endpoint
and
name.
B
A
Just
just
briefly,
you
went
out,
and
it
was
silent.
Oh
I
was
saying
I
was
saying
it's
better
to
have.
It
is
better
to
have
the
protocol
structure
just
have
its
own
feels
like
stuff,
like
name
and
endpoint,
or
bucket
id
an
endpoint
can
kind
of
be
extracted
out,
but
then,
as
we
saw
with
in
the
case
of
azure,
the
name
wasn't
as
simple
as
just
just
an
id.
It
seemed
to
have
two
different
components
in
it.
D
B
Right,
okay,
you
can
just
document
what
it
means
for
each
protocol
and
you
don't
have
to
try
to
come
up
with
something
that
works
for
everybody.
Okay
sounds
good,
and
it
also
saves
you
so
in
the
future.
When
someone
defines
a
new
protocol
that
doesn't
have
an
endpoint
at
all,
you
don't
have
to
special
case
that
one
leave
the
field
out
right
right.
A
Yeah,
so
so
I
like
the
idea
that
all
of
this
comes
from
the
bucket
access
grant
request.
You
know
bucket
access
bucket
closure,
grant
bucket
access
the
grpc
api,
so
that
would
mean
the
grpc
api
would
have
to
have
a
okay.
So
so
thinking
that
through
a
little
bit
more
should
we
have
well-defined
fields
for.
B
B
I
I
think
that
for
each
protocol
there
has
to
be
a
a
specific
set
of
of
outputs
from
grant
access
that
must
be
filled
in
and
if
they're,
not
it's
an
error
and
you
can't
specify
anything
extra
either.
So
you
always
know
exactly
what
you're
going
to
get
with
no
opportunity
for
opaque
parameters
to
go
either
direction
at
access
time.
No,
I'm
sorry,
I
shouldn't
say
either
direction
you
can
have
opaque
parameters.
C
A
Okay,
so
if
we
use
yeah,
if
you
use
this
bucket
info
object,
I
I
think
it
gets
pretty
clear
for
the
for
you
know
anyone
who's
trying
to
write
an
application
that
that
leverages
cozy.
You
know
pretty
clear
in
terms
of
what
they
need
to
read
what
they
need
to
support
and.
B
A
B
A
Okay,
we
will
ask
one,
so
we
need
some
sort
of
version
and
kubernetes
api
has
these
fields.
You
know
for
better
api
management,
sure
things
like
metadata
name
and
namespace-
don't
really
apply
but
yeah.
It's
it's
rich
and
people
understand
this.
B
Yeah,
I'm
just
I'm
trying
to
think
through,
like
does
this
put
any
requirements
on
consumers
of
cozy
that
are
superfluous,
like
import
like
like,
like,
let's
say
that
I
I
am
one
of
these
customers
has
an
existing
pod
that
just
consumes
buckets
to
the
standard
s3
interface,
and
I
don't
want
to
change
my
application
at
all.
So
I
need
to
have
an
init
container.
That's
going
to
do
the
translation
right
like
what
are
the
requirements
on
that
init
container?
Is
that
a
nick
container
need
to
like
import
to
kubernetes
libraries
to
parse
this
thing?
B
B
Parse
this
thing
I
mean
we
could
we
could
ship
the
library
separately?
Well,
that's
what
I'm
just
trying
to
think
through
in
my
head.
Like
could
I
just
have
like
a
little
python
implementation
that
does
parses
the
json
yeah
writes
out
some
files
and
it's
no
big
deal
yeah
python
just
spots
it
as
a
map,
so
yeah
right
but
like.
A
If,
if
they
don't,
if
they
don't
care
about
it
or
if
they
don't,
if
they
don't,
you
know,
if
we
don't
have
versioning
what
ends
up
happening,
is
our
api
might
evolve
and
their
clients
will
not
know
how
to
use
it.
B
Right
but
like
part
of
the
magic
of
api
versioning
with
kubernetes,
is
that,
like
the
server
can
support
multiple
versions
and
the
client
can
tell
the
server
hey,
I
speak
beta
v1,
and
so,
even
if
the
server
speaks
beta
v2,
the
server
knows
how
to
down
convert
to
beta
v1
for
the
sake
of
that
client.
In
this
context,
the
so-called
server,
which
is
the
thing
that's
injecting
this
json
file
in
there,
has
no
idea
what
the
client
supports.
It's
just
going
to
drop.
A
B
The
client
knows
how
to
parse
you're
screwed
right,
even
if
we
took
out
the
version
field.
That
still
is
a
problem
right
right,
but
I
guess
what
I'm
saying
is.
I
don't
think
that
we
actually
get
any
versioning
from
this
I
mean
we,
you
can
slap
a
version
on
it
and
say
this
is
what
it
is,
but
if
the
client
doesn't
support
that
version,
your
sol.
D
D
B
D
D
But
it's
like
the
same
thing
right.
It's
the
same
thing
of
the
same
problem,
but
what
happens
if
the
protocol
evolves?
What
happens
if.
B
This
is
what
happens
if
our
cozy
api
evolves
like
if
we,
if
we
ship,
beta,
v1
and
then
later,
we
we
realize
we
screwed
it
up,
and
we
want
to
add
a
new
field
or
take
out
a
field
to
rename
a
field
and
call
it
beta.
V2,
like
all
of
our
users
that
were
accustomed
to
the
beta
v1
api,
have
no
way
to
get
off
of
beta
v1
and
to
go
to
beta
v2.
A
B
Yeah,
that's
where
I'm
going
is,
if
we
think
it
all
the
way
through,
so
that
yeah,
the
the
guy
who
creates
the
pod,
can
tell
you
what
version
his
pod
is
expecting
and
that
we
can
translate
it.
If
the
version
we
actually
have
is
not
the
same
one,
then
you
have
a
story,
but
like
that's
a
lot
of
work
to
do
that
conversion
up
up
in
the
whatever
is
doing
the
injecting
of
the
this
information
is,
it
has
to
do.
I
don't
know
like
so.
The
thing
is:
if
you
have
a
conventional.
B
Right,
but
it
just
means
like
you,
you
have
to
have
you
have
to
be
able
to
like
have
a
table
of
known
versions
in
a
requested
version,
and
then
the
data
you
actually
have-
and
you
need
to
have
a
way
to
map
what
you
actually
have
to
all
the
versions
that
you
support
and
you
have
to
avoid
to
handle
versions
that
you
don't
support.
It's
just
it's
just
more
code.
I
mean
I'm
not
saying
it's
not.
A
That
much
more
complex
actually
because
you're
going
to
evolve
one
way
you're
only
going
to
add
fields
for
the
most
part,
you're,
not
deleting
fields
and-
and
you
know,
supporting
multiple
versions.
Just
it
gets,
it
gets
pretty
easy
and-
and
you
do
you
have
more
complexity,
as
you
add
more
versions,
and
it
doesn't
really
scale.
B
C
B
It
makes
sense
to
have
a
version
coming
down
and-
and
you
know
so,
you
know
what
you're
dealing
with.
What's
the
other
option
like,
what's
the
other
option
without
versioning,
how
would
that
be
yeah?
The
other
option
would
be
to
say
you
never
ever
change
you.
You
just
say
this
is
the
downward
api
and
we're
going
to
pour
the
concrete
on
it
and,
and
you
can't
change
it
in
the
future.
B
B
A
B
You
could
say
v2,
we
might
I
mean
it
can't
be
semantically
backwards.
It
has
to
be
convertible,
like
whatever
you,
whatever
the
difference
is
between
v1
beta
one
and
v,
one
beta
two.
You
have
to
be
able
to
two-way
convert
it
losslessly,
but
like
as
long
as
you
can
achieve
that
it
can
be
backwards
incompatible
because
you
can
losslessly
convert
it.
Both
directions
and.
A
B
But
this
is
how
the
kubernetes
version
apis
are
supposed
to
work
right.
Is
you
get
to
say
this
is
the
version
I
want.
The
server
knows
the
version
it
has
and
it's
supposed
to
be
able
to
do
the
impedance
mismatching
inside
api
server
and
there's
a
bunch
of
magic
to
enable
that
so
yeah.
So
the
api
server
doesn't
do
the
conversion.
A
A
Yeah,
so
I
can
see
these
things
evolving.
Let
me
show
you
so
these
are
s3
specific
parameters.
Yes,
max
concurrent
requests,
multiple
threshold,
multiple
chocolates
stuff.
Like
this,
you
know
these
are.
D
A
D
No,
no,
I'm
not
saying
that.
I
I'm
mainly
looking
at
like
the
differences
between
what
we
discussed
before
versus.
Like
are
these
evolutions
of
the
protocol.
Like
you
know
the
signature
version
like
we
discussed
or
anything
like
that,
and
then
all
workloads
should
somehow
understand
the
new.
A
You
know
so
so
those
fields
we
were
talking
about
in
terms
of
specification
in
the
sense
that
what
does
the
user
get
to
specify?
A
So
we
said
you
know,
signature
version
and-
and
you
know
specification
fields
would
be-
would
be
something
that
we
just
assumed
that
the
workload
understands
you
know
specifiable
field,
but
in
this,
in
this
case,
we're
talking
about
fields
that
that
come
back
from
the
driver
in
in
a
response,
object
right.
D
D
Right
so
I'm
trying
to
figure
out
like.
Are
we
talking
about
adding
more
fields
to
s3,
because
we
we
see
that
this
is
the
case
and
then
we're
gonna
bump
a
version
if
it's
incompatible
right.
So
if
there's
a
compatibility
issue,
we're
gonna
bump
this
version
and
then
these
workloads
would
have
to
specify.
I
would
like
to
get
the
previous
version,
for
example,
because
I
was
compiled
and
you
know
my
code
was
the
previous
one
and
then
cozy
would
have
to
be
able
to
to
build
the
previous
versions
of
all
of
these
options.
D
D
B
B
D
D
B
A
We
could
follow
a
discipline,
but
okay,
let's
yeah,
so
we
could
follow
a
discipline
there
or
you
know,
in
order
to
metadata,
is
a
standard
way
to
define
kubernetes
apis.
A
Yeah,
it
also
represents
like
a
resource
that
the
user
would
create
it's.
You
know,
there's
that
familiarity
there.
That
being
said,
we
don't
need
to
have
a
metadata
field
to
be
kubernetes
valid
object,
and
I
don't
even
know
if
we
need
to
be
a
kubernetes
valid
object
like
there's.
No
reason
this
is
constructed
on
the
fly
so
yeah
that.
B
A
A
Wanted
to
be,
I
just
wanted
to
have
some
sort
of
you
know.
The
api
has
to
be
defined,
that's
it
in
the
sense.
If
I
evolve
it,
there
should
be
a
way
for
us
to
tell
something
has
changed
and
it
and
it
can't
be
just
you
know,
we
added
a
field.
A
D
So
how
would
they
like,
if,
if
more
information
is
needed
right,
how
did
the
driver
represent
that
it
supports
this
version
and
not
like
a
newer
version
versus
an
older
version?
The
driver
also
should
have
this
version
somewhere.
B
So
so
the
the
grpc
version
is
separate
and
it
really
comes
down
to
like
what
version
of
the
of
the
protobuf
you
compiled
your
application
with,
because
we
have
this
with
csi
right.
We've
evolved
csi
numerous
times,
and
you
just
add
new.
You
can
just
add
new
stuff
to
your
grpc
api
and
grpc
is
backwards,
compatible.
B
D
B
B
B
You
can
add
new
methods
and
you
can
add
new
fields
but
like
if
an
old
client
is
talking
to
a
new,
a
new
server
and
the
server
sends
back
some
fields.
The
client
doesn't
understand,
they
just
get
dropped
and
if
the
client
is
newer
in
the
server's
order-
and
it
calls
a
method
that
the
server
doesn't
implement
it.
Just
you
just
get
an
error,
and
so.
B
We've
never
done
that
within
csi
and
csi
is
what
I'm
most
familiar
with.
Csi
is
infinitely
backwards
compatible
and
we
have
these
capability
right.
Queries
queries
that
you
can
make
from
the
from
the
the
the
co
queries
the
plugin
to
say
like
do
you?
Do
you
support
this
and
the
plugin
has
to
say?
Yes,
I
support
it
before
the
server
will
even
try
that
way.
When
you
add
a
new
feature,
there's
an
inline
negotiation
to
say
like
do
you
support
the
new
feature?
D
I
think
that's
when,
when
you
keep
backwards,
compatibility
like
you
said
in
concrete
right,
but
I
think
like
when
I
I
remember
that
grpc
services
can
somehow
represent
like
I
could.
I
could
create
a
new
version
of
a
message
or
a
new
version
of
a
protocol,
but
maybe
I'm
not
accurate
here,
but
in
any
case
I
think
my
question
is:
does
this
have
to
also
be
extended
to
the
drivers
api
in
this
case.
D
B
A
And
we're
saying
it:
it's
just
adding
fields
as
long
as
it's
backwards
compatible!
It's
okay,.
B
A
But
yeah
they're
going
to
lead
to
you,
know
adding
fields
into
the
request.
The
request
object
is,
is
compiled
and.
B
B
You
don't
have
to
implement
any
resize
functions,
but
if
the
if
the
plugins
say
that
they
support
resize,
then
then
the
co
will
call
the
resize
methods
and
expect
them
not
to
return
an
error.
You
know,
if
you
don't
have
the
capability,
you
don't
have
to
implement
the
methods
at
all.
So
things
like
that,
where
you
know
the
method
is
the
method
is
optional.
Unless
you
say
it's
that
you
have
it,
then
it's
not
optional.
A
D
I
get
I
mean,
I
said
also
you
mean
the
driver
right.
Did
you
mention
that,
because
yeah,
I
think
in
some
way
we,
the
first
party
that
needs
to
provide
this
information,
is
the
driver.
So
what
is
the?
What
is
that
communication
about
like?
What
are
we
gonna
tell
the
driver,
the
cozy
version
or
like
this,
I'm
not
sure,
and
also
I'm
quite
worried
that
this,
like
this
format,
is
too
identified
with
kubernetes
that
it
would
be
too
much
expected
to
be
a
cr
like
cid.
B
A
D
B
A
D
Right
but
the
cozy
does
have
like
we
do,
have
a
version
for
for
the
crds
right,
so
the
clds
for
for
the
cozy
controller
are
versions.
D
Can
can
then
be
instructed
like
have
a
new
version
and
then
get
more
information
or
return
more
information
like
that?
That's
okay,
and
do
we
have
anything
like
that
with
the
drivers?
Do
the
drivers
have
any
access
to
any
versioning
from
cozy
like
a
cozy.
A
B
A
B
I
don't
know
I,
I
don't
think
it
costs
us
anything
to
have
a
capabilities
api
like
csi
has
and
they
can
just
initially
return
like
an
empty
set
and
then
well.
The
problem
is,
if
you
add
it,
then
how
do
you
query
whether
it
exists
right?
You
need
a
way
to
bootstrap
your
mechanism,
just
to
be
able
to
start
negotiating
so
being
able
to
query
capabilities
right
and.
B
The
plug-in
say
I
don't
have
any
capabilities
is
at
least
the
beginning
of
that
conversation,
because
then
you
force
people
to
at
least
be
able
to
say
I
don't
have
any
capabilities
I
mean.
Maybe
you
could
achieve
the
same
effect
by
just
catching
the
error.
When
you
invoke
the
get
capabilities,
call
and
noticing.
B
D
Right
but-
and
then
this
is-
and
this
should
allow
us
like
the
gluteus
thing
is-
is
a
way
for
the
the
cozy
controllers
to
talk
to
the
driver
and-
and
you
know
be-
you
know-
be
not
being
knowledgeable
about
about
what
they
support
right,
yeah
when
as
cozy
evolves
and
the
drivers
might
still
be
lagging
or
something
like
that.
D
That's
kind
of
what
we're
saying
in
that
capabilities
aspect
right
or
is
it
also
about
the
matching
things
from
well?
It
should
should
be
able
to
match
things
from
the
request,
as
well
as
client
could
also
be
more
involved
than
the
driver
in
some
way,
but
yeah
now
and
now
we're
trying
to
get
the
answer
from
the
driver
back
to
the
workload
right
and
we're
asking.
What
should
we
communicate
back
to
the
workload.
D
D
C
B
D
And
now
there's
I
don't
know
the
change
like
I
don't
know
the
protocol
there's
another
field,
for
example
top
level.
Whatever
right
I
don't
know
or
something
within
the
protocol,
for
example
like
and
the
workload
doesn't
read
that
right
or
it's
a
change
of
structure
so
that
the
workload
needs
to
look
up
not
under
f3
but
under
s3.
Also
b4,
it's
something
like
that.
I
don't
know
and
then
well
partially
you
can
ignore
unknown
fields,
but
the
workload
is
older
right.
We're
talking
about
the
case
where
yeah
the.
D
D
A
B
A
Ignore
it
so
so
what
that
means
is
we
can
evolve
this
as
long
as
again
like
as
long
as
we're,
not
we're
not
deleting
fields
with
important
information,
we're
only
adding
fields
that
is,
we
are
always
backwards
compatible
either,
but.
D
Say,
user,
so
what
the
example
you
gave
before
a
path
stop
for
s3
right!
That's
like
a
breaking!
If
I
represent
the
path
style,
true
and
the
workload
doesn't
read
that
and
uses
a
bucket
style
domain,
I
don't
know.
Actually
we
talked
about
that.
This
will
be
the
the
end
point
url
will
include
whatever.
A
D
Something
that,
if
you,
if
you,
if
you
don't
use
the
right
value,
it
will
not
work.
That's
the
case
where
this
kind
of
breaks
down,
because
you
don't
support
this
version
like
the
workload,
doesn't
doesn't
read
this
new
value
and
you
and
it
just
fails,
might
might
be
okay
to
say,
okay,
this
workload
is
it's
not
good,
it's
not
compatible,
but
but
then,
what's
the
purpose
of
the
version,
what
would
the
workload
do.
B
B
D
Okay,
so
you're
saying
that,
for
this
example,
let's
say
it's
a
path
style
thing
just
for
the
example,
then
I
would
have
to
represent
this
somehow
as
an
option
in
the
bucket,
with
bucket
access
request,
for
example,
and
then
I
would
be
able
to
match
with
the
let's
say
this
or
always
like
unless
the
I
query,
the
workload
somehow
from
the
pods
back
and
know
that
it
supports
the
new
version.
I
couldn't
provide
this
new
behavior.
B
Right
that
would
be
one
way
is
to
make
you
specifically
ask
for
it
up
front
and
fail.
If
you
can't
have
it
or
you
could
just
require
that
you
continue
to
return
both
things
like
the
the
old
thing
that
used
to
work
plus
the
new
thing,
and
as
long
as
the
old
thing
that
used
to
work
continues
to
work,
even
in
the
presence
of
the
new
option,
then
you
have
no
problem.
A
Negotiation
genuine
exists,
so
so,
let's
right
now
we
don't
have
pastel
access.
Let's
say
we
go
ahead
with
this
and
then
and
then
we
find
that
someone's
trying
to
port
from
a
provider.
B
B
As
long
as
you
can
also
specify
the
old
field
and
the
bucket
is
still
usable,
then
old
clients
won't
care
that
they're
missing
out
on
some
new
feature,
that
that
would
be
the
key
right.
If
you
add
something
new,
you
have
to
add
it
in
a
way
that
old
clients
continue
to
get
the
behavior
they
used
to
get
and
nothing
breaks
and
new
clients
maybe
get
something
new
and
fancy.
B
D
This
change
means,
let's
say
accelerated
input.
I
don't
know,
I'm
just
throwing
things,
but
you
know
something
that
requires
more
provisioning
on
the
driver's
side
right
to
provision
something
different
or
additional
right.
So
you're
saying
always
provision
the
base
as
well,
because
your
client
might
be
older,
that's
one
option
and
then
this
is
by
comparable.
Oh,
we
can
somehow
communicate
the
client
version.
The
workload
version
back
to
that
to
that
flow
so
that
we
know
what
the
client
expects,
but
then
these
drivers
should
be
able
to
support
backwards.
B
So
like
it,
we
you
have
to
be
careful
about
deciding
what
is
in
and
what
is
out
because
stuff
that
is
in
you
can't
ever
remove
and
if,
if
like
the
the
endpoint
is
expected
to
be
a
you
know,
domain
style,
endpoint
and
people
are
expected
to
depend
on
that.
Then
you
can
never
take
that
away
from
anybody,
and
so
we
have
to
just
decide
like.
Is
that
how
we
want
to
make
it
or
or
do
you
want
to
require
path,
style,
endpoints
for
all
implementations
and
then
say?
B
Look
if
your
implementation
can't
support
that,
then
you
can't
support
cozy,
and
you
know
we
can
you
can
we
can
draw
the
line
wherever
we
want,
but
we
have
to
stick
with
it
forever
and
then
only
add
to
it
never
drop
things
that
are
in
the
standard.
B
But
so
so
this
is
we're
sort
of
off
the
the
original
path
of
you
know.
The
whole
purpose
of
defining
a
versioning
mechanism
is
we're
doing
a
favor
to
our
future
selves.
By
when,
when
we
come
up
with
an
idea
tomorrow
that
we
don't
have
today,
we
can
gracefully
add
it
without
having
to
jump
through
a
bunch
of
hoops
that
that's
the
whole
point
of
thinking
about
versioning
up
front.
B
C
A
A
It's
the
amount
of.
I
mean
the
amount
of
effort
that's
going
to
take
to
work
around.
It
is
much
higher
in
the
future.
It's
going
to
be
very
likely
much
higher
than
than
just
having
one
right
now
and
and
having
this
thing
think.
A
B
D
B
A
B
D
A
Line,
no,
it
has
to
be
here.
It
has
to
come
back
from
the
driver.
You
know
we
cannot
you,
you
can't
tell
the
driver,
give
me
like
s3,
amazon
s3
supports
both,
but
they
themselves
recommend
to
use
one
or
the
other.
I
believe
they
recommend
that
we
use
the
domain
style
access,
but
there
are,
you
know,
parts
for
vms
yeah,
it's
a
function
of
dns
that
you
have
running
and
if
you
don't
have
a
you
know
sufficiently
advanced
dns
server
that
can
they
can
translate
requests
for
you
hold.
B
B
A
Massive
access
just
means,
oh,
are
you
saying
you
can't
have
a
sub
domain?
If
you
have
that
ips.
B
B
A
B
I
I
don't
see
any
problem
yeah,
but
before
we
were
talking
about
it,
I
was
thinking
like
if
you
want
to
add
it
as
like
an
extension,
then
that
creates
problems.
If
we
make
it
part
of
the
core
and
just
say
everything
must
support
path,
style
access,
then
we're
done
right
because
then
we
then
clients
at
least
know
that
they
can
depend
on
that
and
servers
either
support
it
or
they
can't
do
cozy
and
that's
that's
a
fine
state
of
affairs.
D
I
don't
think
this
is
what
it
means.
It
means
that
the
driver
can
specify
to
the
client
how
it
should
address
the
it.
So
it's
not
that
the
driver
becomes
responsible
to
support
both,
because
we
didn't
add
it
to
the
request
object
by
the
worker
right.
We're
just
saying
that
the
driver
instructs
the
worker,
how
to
use
that
bucket
with
that
right.
B
D
D
A
A
D
It's
just
mirrors
from
the
sdk
things
right,
the
sdks
yeah,
but
but
there
are
some
quirks
from
the
sdk
parsing
of
this,
where
they
say
if
you
provide
like
like
we
said
before,
if
you
provide
past
times
false
you
provide
an
ip,
then
it
does
doesn't
make
any
sense
right.
So
there
are
things
that
we're
just
saying
that
we
we
are
ready
to.
You
know
accept
whatever.
C
D
B
D
Is
dealing
with
this
from
the
driver's
perspective,
like
the
driver
will
if
the
driver
pushes
an
ip
and
then
says,
I
won't
pass
that
off.
You
know
it
should
accept
whatever
the
sdk
is.
Gonna
do
in
some
way.
B
D
A
question
to
the
driver:
what
how
do
how
does
your
bucket
you
know
allow
addressing
yeah,
should
I
should
I,
should
I
prepend
the
bucket
name
to
to
the
domain.
A
D
You
provided,
or
should
I
append
it
to
the
to
the
path
as
another
path
path
component
right?
It's
like
it's
really
an
instruction
to
work
with
how
to
to
connect
and
and
you
you
can
have
it.
D
B
A
B
D
D
Why
is?
Why?
Isn't
that
enough?
Like
saying,
cozy
only
allows
you
to
provide
past
style
access
for,
because
amazon
wants
to
move
their
domain.
D
B
A
A
B
And
so
what
you're
saying
is
we
would
leave
it
unspecified
at
the
cozy
level
and
then,
if
a
driver
returned
an
endpoint
that
involved
a
domain
name
and
a
bucket
name
and
it
supported
domain
style
access,
then
you're
great
and
if
it
returns
an
ip
address,
then
you
just
kind
of
assume
that
it
supports
path,
style,
access
and
again
you're
great.
And
if
you
do
anything
wrong,
it's
not
our
fault.
C
B
B
B
Maybe
maybe
you
can
support
both
that
way
yeah,
but
it's.
B
A
Why
not
it's
basically
a
description
of
both
of
these
right
yeah
except
you
know.
Sometimes
the
endpoint
is
specified
as
s3a
column,
slash,
slash
or.
B
S3
common
slash,
slash,
okay!
Well,
that's
just
another
thing:
we
need
to
be
precise
about,
we
need
to
say,
like
the
endpoint
should
not
include
a
or
must
not
include
a
url
prefix,
and
you
know
if
you
want
tls,
you
set
this
field
to
true
and
if
you
don't
want
tls,
set
this
field
to
false
and
set
the
port
number
over
here,
etc.
D
B
D
A
A
B
A
B
A
B
A
At
that
point,
we're
expecting
the
client
to
pass
that
out.
The
the
thing
is,
you
know
it's.
It's
sdk
expects
it
to
be
a
separate
parameter.
Why.