►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 25 February 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
All
right,
so
so
so
to
so
so
the
discussion,
ben
and
I
are
having
is
about
whether
we
should
have
a
new
api
called
cozy
driver
or
cozy
provisional
and
the
idea
behind
that
api
is,
you
know
it?
It
represents.
A
The
name
alone
of
a
particular
cozy
driver
for
now,
so
what
ben
is
saying
makes
sense
to
me
that
is
he's
saying
it
is
not
necessarily
required.
I
had
some
slides
prepared
for
this.
I'm
looking
for
he's.
B
Saying
it's
not
necessarily
required.
You
need
a
new.
A
Okay
and
that
might
work,
but
if
you
had
this
object,
you
can
make
sure
that
there's
only
one
provisional
registered
by
a
particular
name.
D
Yeah,
so
the
way
that
we
handled
this
on
the
csi
side
was
just
in
the
spec
say
that
when
you
create
a
name,
it
must
be
a
fully
qualified
name
and
include
kind
of
the
domain
of
your
company
and
everything,
and
therefore
it
just
naturally
dedupes,
and
so
you
have
something
like
efs
dot.
You
know
I
forget
it
was
like
efs.aws.io
or
something
like
that,
and
so
that
that
in
itself
is
how
we
handle
the
deduplication.
It
hasn't
really
been
a
concern.
D
D
Since
it's
optional,
it
doesn't
necessarily
handle
the
collision
case,
even
though
I
mean
it
could.
If
you
know,
two
drivers
ended
up,
creating
the
same
object,
but
more
so
it
was
just
hey.
I
have
a
driver
that
wants
to
customize
how
kubernetes
interacts
with
it
when
it
is
installed.
It
creates
this
object
and
says
I
wanted
to
tweak
such
such,
such
and
such
behavior
from
default
to
something
new.
D
A
So
my
original
idea
behind
this
was
more
like
register.
A
driver
know
that
it's
there
and-
and
I
was
thinking
we'd-
do
it
automatically
not
not
not
via
the
the
user,
but
when
the
when
the
plug-in
registers
we
would
just
go.
D
D
You
could
have
a
controller
that,
like
watches
for
new
plugins,
when
it
sees
a
new
one,
it
registers
it
creates
this
crd
object
and
it
probes
the
capabilities
of
the
driver
and
then
populates
the
appropriate
fields
in
the
crd
object,
yeah,
and
that
way
it
makes
it
more
accessible
to
kubernetes
controllers
right.
That
was
the
idea
yeah.
A
Fair
enough
that
would
work
yeah.
No,
that
would
work
yeah,
we'll
just
I
don't
think
we'll
forget
it.
So
yeah
should
be
fine.
A
If
we
were
to
do
this,
we'll
also
have
to
think
about
unregistration
or
deregistration,
but
but
if,
if
we
were
to
automatically
register
it,
how
would
we
automatically
be
registered
becomes
a
question?
A
D
Yeah,
the
life
cycle
of
registration
and
unregistration
at
the
cluster
level
gets
tricky
at
the
kind
of
node
level
it's
trivial,
because
you
know
you
could
have
like
a
socket
that
the
driver
has
to
call
into
at
the
cluster
level.
It
definitely
gets
more
tricky,
so
you'll
have
to
think
about
that.
A
little
bit.
B
Right
exactly,
how
do
you
detect
it's
gone?
Yeah,
yeah,
yeah!
Wait
what
happened?
I
don't
have
a
solution
either.
Let's
see,
where
did
it
go.
A
Yeah
yeah,
it
gets
tricky,
so
this
is
good
to
know.
I
think
I
think
in
that
case,
like
you,
said,
we'll
put
a
pin
on
it.
I
think
right
now,
if
two
different
provisioners
for
different
cloud
providers
end
up
registering
with
the
same
name,
both
would
get
this
request
and
they
both
might
end
up
provisioning
a
bucket.
A
But
but
you
know
that's
kind
of
a
unique
scenario.
That's
one
of
the
scenarios
where
we
call
it
user
error,
because
the
bucket
creation
can
only
succeed
for
one
of
them.
A
A
Let's
say
you
use
some
name
like
test
cluster
or
something
like
that,
and
you
end
up
having
two
different
instances
of
test
cluster
one
one
installed
by
a
different
person,
the
same
team
as
you,
and
then
you
just
end
up
with
two.
So
when
a
bucket
request
is
made
pointing
to
a
bucket
class
that
that
wants
a
bucket
of
type,
you
know
from
the
provisional
test
cluster
provisional,
our
central
controller
would
create
a
bucket
object
and
the
two
different
side
cars
would
respond
to
that
bucket
object.
A
E
A
B
A
I
I
think
taking
on
this
complexity
is
worse
than
worse
than
yeah.
I
don't
know
how
to
unregister
driver.
That's
my
main
problem
with
this
so
yeah.
I
think
it's
fair
to
call
it
a
user
error
at
that
point.
What
do
you
mean?
A
Unregister
a
driver,
oh
okay,
so
earlier
I
was
just
saying
one
way
to
prevent
that
race
from
happening
is,
if
you
were
to
have
a
unique
driver
registered
per
side
car
that
that
or
create
a
kubernetes
object
by
the
provisional
name
for
for
each
provisional
that
comes
up,
and
then
it
will
be
automatically
created
by
cosy
based
on
the
identity
of
the
actual
driver.
A
The
problem
is:
how
do
we
unregister
like
like
if
we
automatically
registered,
how
do
we
get
rid
of
it
when
the
driver
goes
down?
Oh.
E
E
So
so,
on
upgrades
like
most
of
the
objects
stay
the
same.
You
just
basically
stick
in
new
bits,
so
you
you
know
you
tear
down
the
deployment
and
update
the
image
name
or
you
update
the
image
name
of
the
deployment.
It
kills
all
the
pods
and
new
pods
pop
up,
but
any
operations
that
were
in
flight
at
the
time
just
get
aborted
and
retried.
E
No,
no,
you
can
never.
You
can
never
change
a
provisioner
name
like
that.
That
would
that
would
cause
huge
problems
in
csi
right,
because
prison
will
be
in
cozy
too
so
yeah.
Once
vendors
need
to
be
aware
that,
like
this
string
that
you
pick
is
set
for
all
time
and
if
you
ever,
if
you
ever
change
it,
you've
basically
made
a
new
driver
and
orphaned
your
old
driver.
A
A
We
have
sahaja
yoga
okay,
so
I
want
to
continue
the
discussion
that
we
left
off
last
week
south
and
we
did
continue
it
on
monday
as
well.
I
didn't
have
a
chance
to
look
at
the
recording
did
you
I
did
not
now
was
andrew
and
tim
part
of
that
discussion.
D
A
Yeah,
so
last
we
left
off.
We
were,
we
were
questioning
if
mutation
at
all
should
be
should
be
supported
and.
A
And
and
it
seemed
like
mutation
may
not
actually,
mutation
may
not
actually
be
be
a
regular
use
case.
If,
if,
if
at
all,
it
were
to,
it
was
needed,
it
was
a,
it
was
a
rare
event
and
and
but
still
we
wanted
to,
we
wanted
to
see.
If
you
know,
let's
say
it
does
come
up
as
a
requirement
in
the
future.
You
know
we
wanted
to
know
that
there
would
be
an
approach
to
you
know
to
take
care
of
it
if
needed.
A
So
so
that's
where
we
left
off
last
week,
we
had
a
discussion
on
monday.
Continuing
that
conversation
and.
A
The
people
that
were
there
on
the
call
we
we
I
mean-
I
don't
wanna,
we
didn't
explicitly-
do
a
vote
or
anything,
but
we
pretty
much
all
agreed
that
this
is.
This
is
indeed
a
rare
event,
but
ben
did
bring
up
that.
We
should
still
have
a
solution
in
case
in
case
this
becomes
a
this
book.
This
becomes
an
absolutely
required
feature
and.
E
A
Request,
yeah
yeah;
no,
it
was
a
valid
thing
ben
you
reminded
us
of
it.
A
I
would
say
so
so,
following
that
one
thing
we
said
was
we
could
have
the
concept
of
a
bucket
mutation
policy
again,
we
will
only
do
it
when
this
requirement,
but
we
can
have
the
concept
of
a
bucket
mutation
policy
and
that
would
that
would
be
set
on
the
bucket
itself
and
only
the
buckets
that
have
the
bucket
mutation
policy
can
be
edited
by
the
admin,
and
we
will
respond
to
that
edit
event
through
the
controller
and
call
a
driver
function
that
will
go
mutate.
The
bucket.
D
And
just
to
make
sure
I
understand
that
so
effectively
the
cluster
admin
controls
whether
mutations
allowed
or
not.
By
default,
it's
not
allowed.
They
can
choose
to
allow
it
by
setting
a
bit
on
the
bucket
object
and
if
they
choose.
E
A
No,
so
if
they
choose
to
allow
it
so
so
you
know
if
you
were
to
go
through
like
the
actual
workflow,
let's
say
it's
not
allowed
by
default
and
then
the
admin
copies
the
bucket
for
another
namespace
and
in
that
copy.
The
admin
sets
the
bucket
mutation
policy
to
allow
the
bucket
mutation
policy.
A
Bucket
itself,
okay,
okay
and
then
the
cluster
admin
would
be
able
to
go
mutate
that
bucket
later
on,
let's
see
when
the
mutations
required
and
and
cozy
would
respond
to
that-
and
I
love
you
know,
call
the
driver
and
sorry
I
forget:
did
we
do
a
one-to-one.
D
D
D
D
If
I
provision
a
greenfield
bucket
being
able
to
not
switch,
for
example,
the
access
modes
of
that
bucket
in
the
future
would
be
limiting,
and
so
I
guess
this
would
allow
that
through
setting
a
bucket
class
with
mutation
allowed
and
then
the
who,
whoever
the
application
developer,
is,
can
use
that
bucket
class
to
provision
a
new
bucket
and
they
will
have
permission
to
mutate
it
as
they
wish
in
the
future.
D
A
Change
that
part,
so
we
don't
have
separate
apis
as
such.
We
have
separate
workflows.
What
I
mean
by
that
is
when
we
create
a
greenfield
bucket
using
a
bucket
request,
we
don't
specify
the
bucket
name,
but
when
we
create
a
brownfield
bucket
using
a
bucket
request,
you
specify
the
name
of
the
bucket
that
the
admin
gave
you.
D
Yeah,
I
think
that
makes
sense
to
me.
I
I
don't
personally
understand
the
reason
for
having
separate
api.
I
think,
if
at
all
possible
we
should
have
the
same
api.
A
D
He
had
was
along
the
lines
of
there's
all
you
know:
non-name
only
namespace
objects
for
buckets
and
they
live
inside
of
a
namespace
that
namespace
owns
them.
If
somebody
else
wants
access
to
it,
they
can
get
a
pointer,
but
if
they
have
a
pointer
they're
not
allowed
to
mutate,
you
have
to
have
the
actual
object
in
order
to
mutate,
something
like
that.
A
So
this
is
what
tim
explained
it
on
the
call
with
just
me
tim
and
a
few
others
like
jeff
and
others.
I
think
others
are
invited
too,
but
I
don't
know
if
you
can
make
it.
A
He
said
he
said
in
case
of
gateway
at
google
and
correct
me
if
I'm
wrong,
there's
a
central
team
that
manages
a
particular
kind
of
gateway
and
then
per
team
or
say
one
of
the
infrastructure
teams
gets
to
manage
their
own
gateway
in
in
their
own
way,
where
the
central
gateway
team
has
no
clue
about
as
long
as
some
set
of
policies
are
followed
and
and
so
they
have
the
concept
of
both
cluster
gateway
and
a
namespace
gateway.
A
We
have
a
similar
kind
of
dichotomy
going
on
there
as
well,
where
you'll
have
bucket
requests
and
buckets
that
are
purely
namespace
alone,
and
there
are
bucket
requests
and
buckets
that
are
purely
clustered
alone,
but
I
don't
know
how
they
interact
or
anything.
But
but
the
idea
is
they're
separate.
I
think
to
allow
two
different
kinds
of
users
to
work
with
them.
C
We
still
need
to
have
the
power
to
actually
explain
to
us
how
that
works
and
then
kind
of
try
to
do
something
similar
here
or
are
we
because
it
seems
like
we're
still
not
not
knowing
exactly
what.
C
They
actually
even
have
like
a
document
or
something
is
that
that's
not
that's,
not
public,
that's
not
it's
in
inside
google
or
something
or
is
it
oh?
No
already
out
there.
C
There's
a
link:
maybe
we
can
even
take
a
look
if
you
know,
if
they
can't
present,
we
can
at
least
take
a
look
of
that.
You
see,
I
heard
them
talking
about
this,
not
clear
to
me
exactly
what
we.
A
Yeah,
so
so
the
the
reason
tim
proposed
this
was
to
allow
self-service,
but
it
adds
other
complexity
at
the
cost
of
I
mean
in
order
to
provide
self-service.
A
So
let
me
see
so
it
is
called
gateway.
A
A
It's
definitely
not
cubed
by
adm.
It
must
have
something
to
do
with
the
oh
sig
network.
Dual
stack
interface
name
gateway
next
protocol,
not
this
because
in
that
case,
they're
talking
about
like
a
network
gateway
to
talk
to
a
different
network
like
the
public
cloud,
I
think
it's
probably
this
service
lb
class
field,
no
not
c
clock
writer.
It
should
be
in
sig
network.
C
Yeah
I
was
searching,
that's
not
clear
to
me
exactly,
but
of
course
I
don't
really
know
network
that
it
not
clearly
says
the
gateway
in
the
in
the
proposal.
At
least
I
couldn't
find
one
yeah.
I
saw
that
that
one
you
were
looking
at
two,
I'm
not,
but
I'm
not
100
sure,
that's
the
one.
We
can
probably
even
just
ask
them
in
that
email
thread
at
so
if
they
can't
come,
we
can't
at
least
take
a
look
of
the
proposal
and
see
what
that
means,
because
otherwise,
I
you
know,
don't
get
what
they're
talking
about.
A
Yeah
yeah,
to
be
honest,
yeah
I
was,
I
was
hoping
they
would
join
too
yeah.
I
don't
know,
let's:
let's
do
that,
we'll
ask
them,
but,
but
even
if
they
don't
respond,
we
do
have
a
path
forward.
I
think
all
right,
so
I
I
think
this
is
good,
so
I
want
to
take
care
of
some
kind
of
logistical
things.
While
I
have
everyone
here
so
sad
you,
you
asked
a
bunch
of
questions
on
the
respectful
request.
I
think
this
is
a
good
time
to
address
them.
D
A
Okay,
we
took
care
of
that.
We
moved
this
to
an
identity
service.
How's
it
different
from
screen.
Have
you
added
comment?
A
Explain
the
name
for
bucket
name:
okay,
yeah!
This
is
one
you
asked
if
deletion
does
require
opaque
parameters
and
our
answer
was
at
first,
I
didn't
think
it
needed
the
opaque
parameters
themselves
and
and
later
on.
A
When
I
thought
about
it,
I
can
see
it
needing
the
same
parameters
that
would
be
needed
by
you
know
for,
for,
like
create
bucket,
say,
there's
a
vendor
specific
parameter,
that's
needed
for,
for
whatever
reason
it's
hard
to
predict
that
we'll
never
need
something
like
that,
especially
given
that
protocol
is
a
restrictive
for
a
good
reason,
but
it's
restrictive.
A
D
Yeah,
so
I
think
I
would
special
case
deletion
all
right.
We
want
to
be
as
kind
of
protective
of
deletion
as
possible
so
that
you
never
end
up
in
a
state
where
kubernetes
can't
do
a
cleanup,
and
for
that
reason
I
would
say,
let's
start
with
the
bare
minimum,
that
we
need
and
then
add
to
it
as
needed
in
general.
The
idea
is
that
the
unique
identifier
for
the
bucket
id
should
be
sufficient
to
identify
it
like.
You
should
not
need
anything
beyond
that
bucket
id
to
be.
D
A
So
we
can
set
up
like
lambda
triggers
for
buckets
something
like
on
every
object,
create
call
this
lambda
function.
Stuff
like
that
is
something
you'd
want
to
delete.
A
So
so
in
so
with
min
io
android
s3,
what
you
can
do
is
you
can
you
can
set
up
triggers
on
events
on
the
bucket
on
a
particular
bucket,
so
say,
for
instance,
you
set
up
a
trigger
for
a
bucket
creation
or
sorry
the
object,
creation
or
say
object
deletion.
A
D
And
how
would
the
ceo
know
that
this
feature
is
enabled
and
how
would
it
be
set.
D
I
mean
but
kubernetes
needs
to
get
it
from
somewhere.
Is
it
stored
in
the
storage
class?
Is
it
stored
somewhere
else
right
right.
A
So
this
would
come
from
so
whatever
parameters
we
stored
in
the
bucket
object,
so
whatever
parameters
we
send
for
the
create
bucket,
we
would
send
the
same
thing
over
here.
D
So
what
that
sounds
like
to
me
is
you're
using
kubernetes
as
a
place
to
store
state
and
then
passing
it
back
in
at
a
later
point,
so
we
should
avoid
that
and
instead
say
okay,
you
know
this
is
something
that
you
can
configure
on
the
bucket.
Whatever
the
deletion
policy
should
be,
you
know
you
can
do
that
at
creation
time
if
you
like,
and
then
the
bucket
needs
to
remember
that
so
when
the
deletion
is
called,
it
will
go
and
execute
it.
A
Okay,
in
that
case,
we're
asking
the
driver
to
hold
the
state
somehow
right-
yes,
okay,
I
mean
both
would
work.
This
would
make
the
driver's
implementation
simpler,
but.
D
D
Kind
of
back
and
forth
on
csi
ben-
I
don't
know
if
you
remember
this
on
how
much
state
we
wanna.
We
want
kubernetes
to
carry
versus
the
driver
and
I
think
in
general
what
we
pushed
towards
was
don't
use
kubernetes
to
carry
arbitrary
state.
D
A
That
makes
sense
that
yeah,
if
it
was
transient
state
that
would
that
would
be
a
problem,
but
this
is
state
that's
set
during
the
creation,
and
you
know
it's
not.
It's
not
considered
immutable.
A
D
That's
worse
right,
like
you,
don't
want
kubernetes
to
lose
its
mind
and
then
forget
what
the
policy
for
deletion
of
these
lambda
functions.
For
example,
is
you
know,
we've
have
cases
where
api
object
gets
deleted
for
some
reason
right
and
you
recreate
a
object
to
represent
that
bucket.
A
D
A
Yeah,
you
know
it's
not
coming
back
from
the
driver.
This
is
this
is
coming
from
the
user
when
it
was
set
the
first
time,
it's
not
really
state
as
much
as
it's
it's
spec.
A
A
Well,
let
me
put
it
differently,
so
it's
not
okay,
so
it's
not
okay.
Maybe
the
lambda
example
wasn't
the
best
one.
So
parameters
exist
specifically
to
to
allow
vendors
to
to
configure
you
know
vendor
specific
values
and-
and
I
had
an
example
here,
what
did
I
call
it?
A
Yeah
yeah
so
like
you
want
to
set
the
the
encryption
key
store
in
case
you're
on
self,
and
you
say
you
know
we're
using
walt
versus
some
other
key
store
and
and
if
you're
on
aws
this
doesn't
apply
because
aws
has
its
own.
D
So
that
makes
sense
like
you
set
that
up
front
on
your
creation
side.
Why
must
that
be
passed
in
at
deletion
time
right?
The
once
the
bucket
is
provisioned.
The
vendor
should
know
everything
about
it.
F
If
a
user
is
generated
on
the
fly
as
part
of
greenfield,
how?
How
is
the
provisioner
supposed
to
remember
that
I
mean
it
seems
like
we're
putting
I
understand,
philosophically
what
you're
saying
soda
and
I
agree
with
it,
but
it
seems
what
the
difference
that
that
sid's
bringing
up
is
that
this
is
static
information.
It's
not
transcendence,
not
current
state
of
the
world.
It's
just
some
pieces
of
information
that
the
delete
interface
needs
so
that
we
can
so
a
provisioner
can
delete
a
bucket
like
a
generated
user
name
which
isn't
known
in
advance.
F
D
Effectively,
what
that
looks
like
is
like
a
cookie
right,
you're
passing
a
cookie
back
to
the
user
and
saying
please
pass
this
information
back
in
at
the
future
and
and
that's
just
a
model
that
we
try
and
avoid
right.
It's
just
you're
using
kubernetes
and
you're,
using
the
end
user
to
hold
state
and
we're
saying
don't
do
that
if
you
have
something
that
you
need
to
persist,
persisted
on
the
driver
side,
don't
try
to
use
kubernetes
or
the
user
as
a
way
to
you
know,
pass
information
back
to
yourself
at
the
in
the
future.
F
And
that
breaks
that
breaks
the
declarative
api
philosophy
in
in
some
way.
D
It's
not
necessarily
the
declarative
api
philosophy.
I
think
it's
just
a
like
abstraction
layer
thing.
Why
are
you
pushing
this
out
to
the
user
and
back
in
like
just
persisted
internally
and
then,
when
you
have
the
deletion
request
or
any
other
life
cycle
event?
That
happens?
You
have
all
the
complete
information
you
need.
A
Okay,
so
so
on
on
bucket
creation
in
the
grpc
spec
for
provisional
create
bucket
request,
we
pass
in
a
protocol
structure
and
we
pass
an
additional
opaque
set
of
parameters
yeah
now.
The
question
is:
are
these
parameters
required
during
deletion
as
well?
E
A
A
Abstraction
problems,
so
so
it's
not
a
it's,
not
a
problem
with.
So
we
were.
We
were
more
arguing
from
the
idea
of
you
know
this.
It's
symmetrical
and
what
you're
doing
is
not
really
technically
breaking
any
conventions
and-
and
we
just
assumed,
if
it's
needed,
you
know
it
should
be
there,
but
but
you're
right.
If
parameters
are
there
specifically
to
for
for
creation
alone,
then
then
they
shouldn't
be
needed
for
deletion.
E
E
We
should
go
through
like
how
should
that
be
handled,
because
in
general
it's
assumed
that
when,
when
the
create
call
comes
in,
if
you
generate
any
any
information
on
this
on
the
you
know
the
cozy
side,
you
store
that
with
the
bucket
you
create
so
the
next
time
you
get
a
request
to
do
something
with
that
bucket.
You
can
just
pull
it
back
out
of
wherever
you
stored.
It.
A
Yeah,
so
we
just
considered
so
yeah.
One
of
the
ways
we
were
looking
at
parameters
is
not
just
as
some
set
of
parameters
for
the
bucket
creation,
but
more
like
some
set
of
parameters
that
help
you
communicate
with
the
with
the
driver.
But
that
doesn't
make
sense.
I
think
if
you
were
to
look
at
it
that
way,
because.
A
Don't
we
have
like
in
csi
like
a
parameterized
like
map
string,
where
you
know,
if
you
give
a
certain
key.
E
E
A
couple
different
calls
and
then
controller
publish
volume
also
gets
to
generate
another
opaque
string,
app
called
the
publish
context
or
right
and
then
that
similarly
gets
stored
on
the
co
and
then
passed
down.
But
it's
like
those
are
two
very
specific
calls
that
can
return
very
specific
maps
with
limited
size
and
all
that
stuff,
and
we
know
when
kubernetes
exactly
where
we're
going
to
store
them
and
then,
where
we're
going
to
supply
them
back,
they're
not
general
use
there.
A
Yeah,
so
if
you
look
at
in
in
csi
that
in
in
unpublished,
volume
request
other
than
volume
id,
we
pass
a
set
of
secrets.
A
A
So
you're
saying
for
specific
fields
we
can,
we
can
actually
have
them,
but,
but
I
think
sadhus
was
saying
that
earlier
just
about
this
in
this
conversation,
but
opaque
set
of
parameters
may
not
be
needed.
That's
what
that's!
What
we're
saying.
E
Well,
the
the
the
create
parameters
I
think
are
intended
just
for
create
and
and
delete
in
particular,
should
be
able
to
function
without
any
information
from
the
ceo,
because
delete
can
be
called
under
emergency
circumstances,
where
you
don't
have
any
information
right,
you're
just
trying
to
clean
up.
I.
F
C
F
E
See
and
in
other
situations.
E
Yeah
like
if
you
definitely
need
something,
that's
gonna
that
can
only
have
come
from
thus
the
cozy
plug-in,
then
you
either
put
the
burden
on
the
cozy
plug-in
to
communicate
itself
internally
or
if
you
have
the
you
know
like
the
csi,
with
the
node
controller
split.
If
information
has
to
get
from
the
controller
to
the
node,
then
the
ceo
becomes
responsible
for
communicating
that
specific
information.
A
I
mean
like
if,
if
the
the
driver
wanted
to
you
know,
hold
some
state
when
it
you
know
in
case
of
csi,
it
could
always
put
it
in
a
custom
resource.
B
A
E
So
I
mean
you
can
write
a
csi
plug-in
that
only
works
with
kubernetes,
but
then
it's
not
a
csi
plug-in,
because
if
you
try
to
run
it
without
kubernetes,
it's
not
going
to
work
yeah
so
that
that's
the
bad
model
to
assume
something
like
kubernetes,
underneath
your
cozy
plug-in
or
your
csi
plug-in.
A
I
mean
yeah
that
makes
sense
now
that
makes
sense.
Okay,
so
anyways,
that's
that's
we're
getting
sidetracked
there.
I
I
think
I
understand
where
you're
coming
from
so
we're
saying
if
there
is
something
like
secrets
which
we
know
is
utilized
by
the
driver
to
communicate
with
the
back-end
stuff,
like
that,
they
should
be
explicit
rather
than
you
know,
be
combined
into
the
parameters
field.
E
E
A
Yeah,
it
makes
sense
all
right,
so
I
think
I
understand,
I
think
I
think
if,
if
we
were
to
be
clear
about
our
definition
of
parameters,
that
would
that
would
clear
a
lot
of
things.
I
think
we
should
add
a
comment.
We
should
update
the
the
spec
and
add
a
comment
in
parameters,
and
we
should
say
that
parameters
are
meant
for
plug-in
or
driver,
specific
values,
for
creation
of
the
bucket
itself,
and-
and
that
will
clear
up
this
this
this
thing
with
having
parameters
and
delete.
A
Sounds
good,
yeah,
yeah,
so
sad,
we'll
make
a
pr
with
with
that
one
change.
Yep
sounds
good
to
me,
yeah
and
okay,
so
we
have.
Similarly,
we
have
parameters
for
grant
bucket
access
and
I
think
we
have
parameters
in
revoked
bucket
access.
Also,
would
this
apply
would
parameters
apply
here,
or
would
this
be
similar
to
create
and
delete
bucket.
E
F
C
A
Yeah
makes
sense:
okay,
so
yeah
I'll
also
make
this
change,
then
we'll
remove
parameters
from
a
revoke
as
well
and
and
update
the
comment
on
the
the
parameters
field
to
specify
that
their
vendor-specific
fields
for
for
creating
a
bucket,
and
you
know
creating
credentials
for
the
bucket
or
granting
access
to
that
bucket.
A
D
Yeah,
I
think
the
other
comment
was
around
the
naming,
so
there's
a
bucket
name,
I
believe,
or
bucket
id
that's
defined,
but
not
both.
So
you
pass
in.
So
I
think
my
expectation
was
kind
of
what
we
have
on
the
csi
side,
which
is
volume
name
passed
in
on
the
create
call
and
then
on
the
create
response.
D
You
get
a
volume
id
and
then
all
future
requests
use
the
volume
id
it
sounds
like
instead
of
that
for
cozy,
the
proposal
is
to
just
have
a
single
bucket
name
and
that's
used
everywhere.
There's
no
idea,
no
concept
of
a
bucket
id
right.
A
Our
reasoning
for
there
was
an
explicit
position.
We
we
said
or
the
reason
we
made
it.
That
way
is
because
I
think
it's
and
and
again
this
is
open
discussion,
but
I
think
it's
safe
to
say
that
bucket
names
are
globally
unique
and
I
say
globally
unique
for
that
provider
for
a
particular
provider.
A
So
bucket
name
is
you
know,
just
by
its
nature,
is,
is
actually
unique.
Id.
D
So
I
I
guess,
what's
the
drawback
of
letting
the
driver
declare
what
the
actual
bucket
bucket's
unique
identifier
is.
E
A
E
F
A
A
No,
no!
It's
not
that
we
didn't
find
the
problem.
I'm
saying
the
problem
cannot
occur
because
the
name
itself
is
the
id
like
like
if.
A
Because
one
of
the
things
we
in
our
architecture,
one
of
the
things
we
we
said
was
the
the
provisioner
or
the
provisional
site
car
would
only
be
able
to
read
buckets
but
not
write
to
it,
because
we
just
didn't,
have
wait,
no,
never
mind.
I
don't
think
we
said
that
let
me
yeah,
so
the
idea
was
at
least
the
way
we've
looked
at
the
grpc
api.
So
far
we
don't
use
the
responses
to
fill
values
back
into
the
bucket.
A
Mean
we
say
bucket
available
to
true,
but
that's
not
a
value
that
comes
back
from
the
grpc
spec
or
in
a
response,
not
that
it's
not
it's
not
possible
to
do.
It
was
more
like
like
if
you
look
at
any
of
the
io
calls
like,
like
you
know,
create
an
object
or
list
objects,
or
whatever
the
bucket
name
is,
is
the
unique
id
they
said.
A
So
so
the
bucket
naming
is,
is
you
know
it's
a
dns
name,
so
the
region
and
zone
gets
factored
into
the
name
so
aws
s3
bucket,
it
looks
like
you
know,
a
bucket
name.
Dot
used
one
dot,
amazon,
aws
s3.
E
B
A
Yeah
ben
ben
you're
right
yep,
yeah,
so
yeah.
We
can't
expect
the
site
card
to
generate
for
every
driver,
so.
F
C
A
A
E
E
A
Yeah
yeah,
so
it
would
send
just
the
bucket
name
and
say:
create
this
bucket
name
in
region,
usc,
1
or
whatever,
and
then
the
unique
id
will
be
returned
to
us
by
the
driver,
so
amazon's
driver
will
return
it
so
we'll
need
the
will.
You
know
like
like
sadhan
banner
saying
I
think
I
think,
and
I
think
I
think
that
that
field
should
be
popular
back
into
the
bucket
and
that
should
be
used
for
future
requests.
B
A
That's
exactly
how
csi
works
and
it's
been.
It's
been
a
great
model
yeah
I
just
I
just
didn't
see
a
need
for
it
and
I
kind
of
just
thought
this
would
work.
But
yes,
the
question
of
how
would
we
construct
that
unique
idea
is
not
something
I
mean
we
should
not
be
doing
it
because
you
should
not
do
it
because
because
it
changes
per
per
driver
and
if
you
get
into
that
business,
then
then
it'll
become
a
problem.
E
F
E
D
A
A
Prefix
has
to
be
valid
for
that
driver,
because,
if
you
put
in
a
bunch
of
hashes
and
and
you
know,
characters
that
that
the
driver
cannot
accept,
that's
not
okay,
and
the
second
thing
is
the
length
of
the
bucket
prefix
should
not
exceed
you,
know
eight
bytes
or
how
what's
the
length
of
your
80
16,
bytes
right
so
16
by
or
the
maximum
length
of
a
bucket
name,
minus
16
bytes.
A
If
it
exceeds
that
value,
then
you
know
we
will
have
a
bucket
prefix,
that's
too
long
and
we
won't
be
able
to
create
a
bucket
yeah.
So
I
don't
think
we've
addressed
this
very
well
yet,
but
maybe
we
can
talk
about
we're
out
of
time.
What.
A
Yeah,
maybe
we
addressed
it
on
monday,
but
I
think
I
think
this
is
good.
I
think
at
a
good
discussion.
I
think.
F
F
Yeah,
because
at
one
point
we
said,
cozy
was
going
to
generate
the
bucket
name,
not
the
driver.
It's
it's
still
the
case
jiff.
If
that-
and
that's
still
the
case,
so
you
could
argue,
cozy
shouldn't
need
shouldn't,
know
any
rules
about
a
physical
bucket
name
and
the
dry
and
the
provisioner.
The
driver
just
fails,
creating
an
illegal
bucket
name
and,
and
we
log
the
air.
E
E
They
consider
to
be
a
good
way
of
dealing
with
it
but
yeah
the
spec
needs
to
have
you
know
this
is
what's
allowed
and
then,
if
drivers
have
looser
limits,
they
can
just
accept
it,
and
if
they
have
tighter
limits,
they
have
to
do
more
work,
because
we
can't
know
what
the
limits
of
every
driver
are
going
to
be
before
we
write
the
spec.
F
Yeah,
so
unless
we
get
that
information
from
a
get
info
call
or
something
up
front,
but
right,
but
it's
gonna
be
better
to
me
if
cozy
knows
less
about
the
rules
of
a
back-end
bucket
name
and
there's
more
flexibility
for
changes,
and
so
could
change
for
different
back-end
buckets.
So
so.
A
Yeah
all
right
so
so
jeff,
I'm
sorry
to
cut
you
off,
but
without
a
time
I
will
we'll
bring
up
this
discussion
on
monday,
but
in
the
meantime,
I'll
make
the
updates
to
spec
and
make
a
new
pull
request.
So
please
review
and
you
get
a
chance
sounds.