►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket Standup Meeting - 16 November 2020
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
I
want
to
quickly
give
an
update
on
where
we
are
in
terms
of
development
and
find
out
from
the
rest
of
the
team,
and
also
I
want
to
continue
conversation
about
the
parameters
list
that
we
started
last
week.
So
I
have
the
task
list
here.
A
lot
of
work
this
week
or
last
week
went
into
the
sample.
Provisioner
sajin
has
worked
on
implementing
bucket,
delete
and
bucket
access,
delete,
so
remote
credentials
and
delete
the
bucket
sergeant.
Do
you
want
to
quickly
give
us
an
update
on
that?
B
A
Okay
and
they
currently
revoke
credentials
only
of
one
type
right,
which
is
the
tokens
which
is
access
key
and
secret.
Key,
not
service
account.
A
And
do
they
also
delete
the
role
that
we
create
associated
with
this
user.
B
A
So
one
access
credential
would
be
for
one
specific
user,
correct,
yeah,
okay
and
the
the
role
that
is
the
where
we
say
that
user
gets
access
to
s3
buckets.
That's
that's
a
separate
object,
correct.
A
B
Why
we
will
delete
the
policy
because
it
policy
will
be
common
among
multiple
users
right.
A
Think
of
it,
policy
will
not
be
common
among
multiple
users.
Policy
is
for.
How
do
I
put
this?
So
a
policy
is
for
a
particular
user
for
a
particular
bucket.
So
if
you
create
a
policy,
it's
specific
to
a
bucket,
correct
yeah.
A
So
when
you,
when
you
delete
the
credentials
of
that
user
for
the
bucket,
actually,
policy
is
for
a
bucket
and
a
bucket
class,
it's
a
bucket
access
class.
B
A
It
might
be
better
if
we
delete
the
actually.
The
right
thing
to
do
here
would
be
to
delete
or
create
a
policy,
a
separate
policy
for
each
bucket
access
that
we
create.
So
each
time
grant
access
comes
in.
I
think
it's
best
to
create
a
new
user
and
then
create
a
new
policy.
Then,
when
we
do
revoke,
we
remove
both.
A
Yeah
yeah:
that's
that
that'll
be
the
correct
way
to
do
it:
okay,
yeah
all
right!
So
moving
on
hey
krish!
I
know
you've
been
out
last
week,
so
I
wanted
to
catch
up
on
where
we
are
in
the
development
of
the
node
adapter.
C
Yeah,
so
I'm
a
little
out
of
the
loop
on
what
happened
over
the
last
week,
so
I'll
have
to
review
the
meeting
minutes
and
notes
and
also
the
slack
just
to
get
caught
up.
C
But
if
I
remember
correctly
last
or
I
guess
two
weeks
ago,
there
was
some
discussion
about
like
topology
and
different
ways
of
providing
like
credential
authorization
like
for
alternative
forms
of
authentication.
C
I'm
not
sure
what
the
like
end
result
of
that
discussion
was
or
if
it's
still
ongoing,
do
you
have
any
updates
on
that.
A
Yeah
yeah,
so
I
think
you're
talking
about
how
the
credentials
would
be
put
into
the
container
correct.
A
Okay,
okay,
so
what
we've
decided
is
for
each
bucket,
that's
getting
mounted
into
a
part
or
that's
being
provided
to
a
part,
we're
going
to
put
a
bunch
of
files
pertinent
to
that
bucket
in
into
into
its
its
own
directory
in
the
pod,
so
each
bucket
gets
its
own
directory
and
inside
of
it
you'll
have
a
you
know,
a
bucket.json
file
which
has
a
standard
format
and
the
contents
of
that
file
will
include
things
like
the
region,
the
endpoint
and
and
other
bucket-related
metadata
you'll
have
the
credentials
file
and
then
a
bunch
of
files
for
the
certificate
authorization.
A
A
Sounds
good
yeah:
let's
do
that
and
rob
jonah
quickly
give
us
an
update
on
site
car.
D
So
not
too
much
has
moved
inside
car
we've
got
this
kep
update
that
we
need
to
finish
the
review
on
and
get
merged
so
that
we
can
make
the
appropriate
changes
into
the
code
repos
so
that
we
can
get
into
the
official
repos.
A
Yeah,
let's,
let's
quickly
go
over
that
shing
is
also
here.
Maybe
we
can
just
bring
it
up
right
now,.
A
This
is
the
oh
yeah
yeah
yeah.
So
let
me
let
me
actually
pull
the.
A
C
C
A
Okay,
so
this
is
all
okay.
This
is
structural.
I'm
not
gonna.
Look
at
that,
so
so,
oh
yeah.
So
this
is
the
proposal
to
add
parameters
into
the
you
know
bucket.
D
Style
objects;
well,
most
of
them
already
have
it's
really.
Basically,
adding
parameters
into
protocol
because
bucket
already
had
parameters
bucket
class
already
had
parameters
right.
A
So
what
we're
doing
is
we're
taking
out
the
protocol
specific
fields
and
instead
of
putting
in
key
value
pairs
or
of
string
string
types,
that'll
be
opaque,
set
of
protocol
specific
parameters,
correct.
D
Yeah,
okay,
removing
all
the
protocol
specific
stuff
and
adding
just
common
ones
that
we
know
and
then
a
parameters
field
right
for
various
parameters
related
to
that
protocol.
A
Yeah,
that
sounds
good.
I
think
we
had
a
conversation
about
what
do
we
do
if,
okay,
so
this
parameter
is
only
going
to
be
in
bucket
class
right,
not
in
the
bucket
itself?
Sorry,
not
in
the
bucket
request,
correct
yeah.
D
A
D
E
But
I
I
thought,
as
if
I
thought
there
was
a
desire
to
give
the
user
some
ability
to
influence
the
provisioning
of
a
new
bucket
through
like
the
argot
parameters.
I
thought
that
was
sort
of
what
we
were
thinking.
E
A
while
two
weeks
ago,
say.
A
Yeah
yeah,
I
remember
that
to
jeff,
I
think
we
were
saying
there
might
be
a
case
where
user
would
have
to
be
able
to
provide
some
of
these
parameters
in
the
bucket
request.
E
D
Clusters
yeah,
so
we've
talked
about
that.
I
wasn't
implementing
that
in
this,
but
we
have
talked
about
adding
a
parameters
to
br
to
allow,
as
you
say,
influencing
the
bucket
and
if
there's
a
conflict
between
the
br
parameters
and
say
the
bc
parameters,
then
we
just
bail.
We
don't
try
to
reconcile
it.
A
E
A
Even
in
the
in
the
future,
so
so
where
I'm
coming
from
is
it
is
still
possible
so
thinking
about
the
structure
of
an
organization
and
rob
might
be
able
to
speak
more
to
this.
I
think
the
the
admin
should
be
well
equipped
to
create
a
set
of
access
classes
or
bucket
classes
for
for
the
different
combination
parameters,
from
at
least
my
experience
and-
and
I
worked
a
lot
of
customers,
what
I
found
is
they
have
a
limited
set
of
types
of
buckets.
A
You
know
I
would
say
each
type
would
correspond
to
one
set
of
parameters
like
region
plus
some
bucket
options.
So
so,
and-
and
these
you
know,
the
types
of
buckets
are
generally
pretty.
You
know
well
contained
sense.
They
don't.
They
don't
have
too
many
combinations
of
that,
because,
because
if
a
company
has
a
policy
to
have
some
sort
of
security
policy
on
the
you
know,
the
buckets
is
generally
across
the
board
or
most
parameters
will
work.
That
way.
A
If
someone-
if,
if,
if
you
want
to
easily
enable
that
self-serve
use
case
where
you
know
an
engineer,
not
not
a
devops
engineer,
just
like
a
software
engineer-
wants
to
be
able
to
provision
buckets
on
the
fly
just
as
and
when
they
please,
then,
depending
on
how
important
that
specific
use
case
is
for
us,
we,
you
know
we,
you
know,
that's
the
one
place
where
this
model
breaks
down,
where
br
does
not
have
parameters
and
bc
only
has
parameters.
E
Right
there's
some
I
mean
I
when
you
were
mentioning
that
said,
I
was
thinking
of
use
case
of
developers,
you
know
it's
the
developer,
clustering
and
the
admin.
You
know
delegates
more
responsibility
to
individuals
and
that
are.
F
B
F
The
developer
may
be
an
admin
and
may
be
empowered
to
create
his
bucket
classes
because
he
knows
what
the
driver
is
and
he
can
get
his
job
done.
But
then,
when
you
go
to
a
more
standardized,
you
know
you're,
just
a
consumer
of
a
cluster
you're,
not
the
admin,
you
don't
know
what
driver
is
there
and
you
shouldn't
care.
A
Agreed
yeah
agreed,
so
that
brings
me
back
to
the
the
the
current
implementation
of
the
current
way.
We're
thinking
about
it
is
is,
you
know,
seems
solid
to
me
any
other
thoughts
on
this.
A
Okay,
so
rob,
I
think
there
is
a.
There
is
a
script
on
this
on
this
repository
under
the
directory
hack,
which
does
a
grammatical
check
edit.
It.
D
D
A
Rob,
I
think,
I
think
we're
there
in
in
the
sense
that
to
me
at
least
I'm
not
going
through
it
completely
thoroughly,
but
from
from
from
initial
review,
the
overall
design
seems
right
to
me
and-
and
you
know
obviously
I'd
like
ben
or
jing
to
take
a
look
at
this
and
I'm
gonna
paste
the
link
to
this
on
our
chat,
assuming
that
it's
correct
the
smoothest
way
to
get
this
through
is
to
have
that
green.
So
so,
whenever
shingle
bend
reviews
it,
it's
ready
to
go.
D
G
So
last
time
in
the
cersei's
meeting,
we
still
haven't
drawn
the
conclusion
on
that
change
with
regard
to
adding
parameters
under
protocol
right,
so
I
think
we
probably
still
need
to
bring
it
up.
A
G
A
Week
the
question
was
around
yeah.
We
were
talking
about
this
one.
Last
week
we
were
talking
about,
should
we
have
parameters
in
the
bucket
request
and
the
bucket
class,
or
you
know
just
here,
because
if
we
were
to
have
a
parameters
in
both
the
bucket
request
and
bucket
class,
we
end
up
with
a
conflict
issue.
A
So
this
week.
One
thing
one
thing
we
realized
was
thinking
about
how
it's
going
to
be
used.
You
know,
parameters
specific
to
a
provisioner
cannot
possibly
go
on
the
bucket
request.
A
This
should
be
completely
without
provisional,
specific
fields,
so
it
makes
the
design
simpler
and-
and
I
think
we
have
overall
consensus
on
how
we
want
to
move
forward
with
this
zing.
I
think
I
think
you
can
give
us
a
review
on
that,
and
maybe
we
can
ping
saad
or
someone.
You
know,
I'm
sorry,
it's
not
this
one.
This
one
and
you
know
have
him
also
take
a
review,
but
I
think
this
is
this
is
ready
to
move
forward.
F
F
The
protocol
parameters
were
with
the
issue
of
just
of
discussion
last
week.
Right
and
those
are
unless
I'm
horribly
mistaken.
I
thought
those
were
populated
by
the
provisioner.
G
G
F
Okay,
on
thursday,
we
were
talking
about
like
the
the
driver,
filling
in
protocol
parameters
and
including
things
like,
potentially
endpoint
or
regen,
or,
and
that's
where
we
got
into
actually
yeah
here
it
is
the
one
you're
showing
here,
but
you
know,
this
is
bucket
class.
This.
G
Yeah,
I
think
this
is
the
place
right,
so
why
we
have
parameters
in
both
place
now,
like
under
protocol,
and
also
it's
a
like
outside
it's
a
direct
field.
A
Yeah,
that
was
a
good
thing.
I
think
I
think
we
agreed
on
this
also,
so
there
are
some
fields
so
stuff,
like
you
know,
things
that
are
related
to
the
protocol
should
go
into
the
parameters
field
inside
the
protocol.
However,
there
are
I'm
trying
to
remember
what
those
fields
were
actually
ben
gave
an
example
of
those
fields.
A
We
just
look
back
at
the
recording
you'll
be
able
to
tell,
but
there
are
fields
that
are
outside
of
the
protocol
that
are
specific
to
the
bucket
class
that
need
to
go
in
the
in
this
parameters
field.
So.
F
So
so
I
would
dispute
that.
I
guess
so
so
there's
there
are
fields
that
are
that
are
protocol,
specific,
like
like
say
an
s3
endpoint
or
an
s3
region.
Right,
like
those
are
only
meaningful
in
the
context
of
s3.
F
Potentially
I
mean
other
other
protocols
may
have
similar
notions,
but
their
notion
might
you
know,
mean
something
different
and
so,
like
those
things
need
to
get
communicated
from
the
actual
provisioner
through
to
the
to
the
to
the
pod
right.
They
have
to
make
it
all
the
way
through
to
the
pod.
So
when
the
pod
opens
up
its
bucket
credentials
or
it's
bucket
info
like
it,
can
see
those
fields
like
the
endpoint,
the
region,
they
have
to
make
it
all
the
way
in
right.
F
So
I
don't
like
the
idea
of
including
them
as
parameters
here,
because
that
implies
that
they're,
somehow
opaque
and
like
we
know
that
there
are
certain
fields
that
are
necessary
for
s3,
and
then
there
are
other
fields
that
are
optional
and
just
having
them.
Maybe
a
random
string
map
doesn't
give
us
a
way
to
to
do
any
kind.
F
Ensure
that
they're
always
present
or
or
allow
clients
to
rely
on
them
right,
because,
if
they're
just
parameters,
then
they
could
all
be
missing
and
then,
if
you
need
one
of
them,
what
are
you
going
to
do?
I
think
it
should
come
from
the
provisioner.
Don't
you
think
yeah?
F
A
Yeah,
I
think
I
think
we
talked
about
this
yeah
now
so
yeah
we
said
we
said
a
set
of
well-defined
keys
is
what's
needed.
There.
F
Yes,
as
opposed
as
opposed
to
just
a
string
up
and
the
counter
argument
was
well
what,
if
a
particular
s3
provisioner
has
some
extension,
that
is,
that
does
s3
plus
extra
magic
and
they
want
to
communicate
that
extra
information
through
all
the
way
through
to
the
pod
to
say,
hey
by
the
way
this
extension
is
available,
then
they
were
like
well
we'll
use
parameters,
so
the
driver
could
potentially
put
stuff
in.
That
would
work
its
way
back,
and
I
say
what
was
that
I
didn't
follow,
so
I
no
it
didn't
make
any
sense.
F
I'm
sorry,
I'm
kind
of
I'm
halfway
thinking
out
loud
that
there
were
there
was
this
idea
that,
like
the
protocols
can't
be
fixed
because
they
might
change
over
time-
and
we
might
have
extensions
and
and
as
we
add
them,
we
don't
want
to
have
to
change
this
api
object.
A
F
Yes,
yeah,
I
mean
that
that's
that's
fundamentally.
What
the
issue
is.
Is
that
like
if
we
pick
a
set
of
fields
and
then
later
we
want
to
add
one,
it
takes
a
long
time
to
add
the
new
field
and,
like
I'm,
I
buy
that
argument,
and
you
know
if,
if
you
can
convince
me
that
we
will
need
to
add
new
fields,
but
I,
where
I
want
to
push
back
is
like
I
hope
we
can
get
it
right,
such
that
we
don't
need
to
add
new
fields.
I
guess
that's.
A
That's
my
concern
with
s3
too.
So
there
are
a
lot
of
s3
vendors
coming
out
and
amazon
to
stay,
competitive
and
relevant
they're,
going
to
add
new
things.
So
recently,
actually,
amazon
added
object,
locking
where
you
make
some
objects
read
only
and
you
make
others
read,
write
and,
and
you
need
to
pass
in
for
when
you
create
the
object.
When
you
create
the
bucket.
You
say
this
is
a
worm
bucket
or
right
ones.
Read
money!
You
don't
you
don't
overwrite
anything!
So
that's
how
you
make
that
bucket
a
lot
bucket
so
stuff.
F
A
F
The
protocol
specific
parameter
s3,
but
the
protocol
specific
piece
here,
or
at
least
the
protocol
specific
piece
that
needs
to
show
up
in
our
downward
api
that
faces
the
pod.
All
that
that
protocol,
the
only
information
near
there
is
like
how
do
I
access
the
bucket
right.
It's
like
I
need
to
set
up
my
s3
client
to
to
be
able
to
log
in
and
authenticate
and
read
and
write
information
and
like
at
that
stage
like.
I
don't
need
to
know
whether
it's
worm
or
not,
because
I'm
just
reading
or
I'm
just
writing
and
like.
A
Yeah,
that's
true!
So
so
what
you're
saying
is
inside
of
the
parameters
field
in
the
protocol?
We
should.
We
should
keep
that
to
just
the
things
needed
needed
for
the
pod
to
access
this.
This
bucket.
B
F
A
A
Tell
you
my
only
only
reason,
for
you
know
being
apprehensive
about
doing
that.
We're
trying
to
abstract
access
models
for
different
provisioners.
F
But
I
mean-
and
we
should
do
that
so
like
if,
if
there's
a
case
where,
like
someone
is
doing
something
weird
enough-
that
we
have
to
adjust
like
I'd
like
to
know
what
those
cases
are,
but
like
my
understanding
of
the
s3
protocol,
is
it's
it's.
It's
ridiculously
simple.
True.
A
F
So
so
just
and
I
unfortunately
have
a
hard
stop
at
2
30,
so
I'm
gonna
have
to
drop
off
after
this,
but
like
it's,
it's
basically
https
put
and
get
operations
with
like
a
special
header
that
is
used
to
authenticate
the
request
and
like
and
that's
it
that's.
A
For
s3,
okay,
that's
a
that's
a
good
way
to
look
at
it.
I
I
might
again
one
thing
I
want
to
make
sure
of
I'm
not
against
this.
I
just
want
to
make
sure
that
other
providers-
you
know
I
don't
want
just
s3-
to
be
capable
right
at
the
outset.
A
So
you
know
just
I
think.
A
tiny
exercise
that
we
need
to
go
through
is
make
sure
that
it
works
for
other
protocols
too.
F
Why
I
think
each
protocol
should
have
its
own
set
of
fields
like
for
s3?
I
would
propose
we'd
have
endpoint
we'd
have
region,
we'd
have
bucket
name,
of
course,
that
wouldn't
be
a
storage
class
thing.
F
That
would
be
a
downward
api
thing
and
you
might
have
a
port
number
in
case
you're
running
on
a
non-standard
http
port,
but
like
between
those
four
things
and
your
secret
key
and
your
access
key
like
we
could
say,
that's
all
you're
ever
going
to
need
to
do
access
an
s3
bucket
and
then,
of
course,
all
the
other
stuff
can
be
parameter.
Specific
extensions
to
do
weird
things
when
you,
you
know
like
worm,
buckets
or
whatever
and
then,
but
then
you
come
to
like
gcs.
F
You
know
the
google
version
you're
like
okay,
what
what
are
the?
What
are
the
fields
for
google-
and
I
know
less
about
it,
so
I
can't
speak
to
it,
but
like
I,
I
hope
that
we
can
figure
out.
You
know
these
are
the
google,
the
fields
the
gcs
needs,
and
then
we
put
those
there
and
then
for
azure
blobs,
and
you
know,
and
you
can
go
down
the
list
for
each
protocol.
There
is
some
set
of
fields
that
clients
should
be
able
to
rely
on
always
receiving.
A
So
so
I
I
I
get
what
you're
saying
there
are.
There
are
a
few
other
things
that
we
need
to
consider
ben
again,
coming
from
experience
generally,
when
someone
is
in
a
field
too
long,
not
too
long,
but
you
know
they
they
they
get
kind
of.
You
know
too
into
it
and
they
can't
think
from.
You
know
a
larger
perspective.
A
So
I'm
saying
that
as
a
disclaimer
when
I
say
this
because
I
don't
want
to
be
holding
this
back,
but
there
are
things
like
you
know,
encryption
that
needs
to
be
enabled,
and
for
that
you
need
to
talk
to
a
key
store.
You
know,
and
this
needs
to
be
done
while
creating
the
bucket.
You
know,
and
there
are
different
access
models,
say,
say:
amazon
comes
with
a
new
access
model.
You
know
it
needs
to
fit
in
with
this.
With
the
with
this
bucket
that
json
we're
trying.
F
To
create
so
so
a
new
access
model.
Yes,
but
like
they've
already
done
that
a
couple
of
times
right,
we
had
s3
v1,
s3
v2.
I
don't
know.
A
If
there
wasn't
across
aws
so
so
you
know,
they
might
say,
it's
going
to
be
two
factor
out
with
with
your
phone
being
the
second
device
or
whatever,
whatever.
F
A
H
A
So
so
shane,
that's
why
we
did
the
cloud
provider
work
in
the
cloud
provider
work
we
completely
don't
manage
like
in
csi.
We
try
to
have
every
field,
and-
and
you
know
today,
we
don't
even
use
all
the
different
providers
that
are
there,
but
but
in
the
cloud
provider.
The
main
thing
that
I
did
was
take
out
anything
that
is
protocol
specific
or
cloud
fourier
specific
out
of
kubernetes
and
that's
what
has
you
know
made
it
move
forward
this
much.
E
Yeah
xing
and
rob
you
know,
I
think
ben.
We
agreed,
philosophically
that
we
don't
want
object,
store
vendors
to
be
locked
into
kubernetes
release,
cadence,
that's
sort
of
one
of
the
main
motivations
of
removing
all
the
plug-in
storage
plug-ins.
So.
F
So
so,
for
all
the
I
mean
for
creation
and
deletion
and
all
the
interactions
with
the
provisioner,
I
think
you
have
a
lot
of
flexibility
to
you
know
to
rev
quickly
and
add
new
features
and
and
stuff,
because
that's
all
that's
all
stuff
that
the
provisioner
is
involved
in
that
the
problem
is:
is
that
we're
trying
to
create
a
common
api
for
the
the
end
users?
Who
are
writing
the
workloads
and,
like
those
guys,
just
move
a
lot
slower
right?
A
G
F
Yeah
I
mean
like,
like
the
whole,
the
whole
point
of
like
having
a
mechanism
for
injecting
like
the
the
bucket
details
into
the
pod
is
because
we
don't
like
the
situation
we're
in
today,
where,
like
you,
have
to
basically
communicate
the
the
bucket
details
to
the
pod
out
of
band
like
in
environment
variables,
or
something
like
like.
No
we're.
A
Trying
what
we're
trying
to
do
we're
still
doing
that
with
the
opaque
set
of
parameters?
The
question
is:
should
we
have
a
pixel
of
parameters
or
type
fields
here
again,
I'm
not
completely
opposed
to
having
type
fields.
Here,
I'm
simply
just
bringing
up
some
of
the
challenges
we
might
face.
We
can
go
either
way
because
again,
it's
just
type
fields
and
the
parameters
we're
having
no.
A
H
A
When
that's
not
going
to
happen,
no
I'm
saying
we'll
definitely
come
to
a
conclusion.
We'll
come
to
an
agreement.
I
I
see
the
thing
is,
unless
everyone's
happy
with
how
we
move
forward
we're
not
really
moving
forward.
That's
that's
how
I
look
at
it
and
we
all
should
feel
like
you
know
we're
successful
here.
So.
D
So
I
thought
maybe
I'm
misunderstanding
like
the
discussion
in
its
entirety
here,
but
I
thought,
if
you
go
up
to
the
bucket
object,
sid
yeah
in
this
cap,
yeah.
B
D
Thought
what
you
were
talking
about
ben
is
what
we
were
trying
to
do,
so
we
have
in
the
protocol
field
there
we
have
things
bucket
name,
endpoint
and
the
parameters.
D
D
And
then
everything
else
is
in
the
parameters
field
because
to
to
you
know
if
there's
any
specific,
as
you
say,
like
extensions
or
anything
like
that,
but
like
a
bucket
name
and
endpoint,
you
know
and
maybe
like,
as
you
said,
you
know
credential
fields
or
something
and
and
that
would
be
common
for
all
providers
and
then
any
other
data
that
comes
back
from
from
the
the
driver
right
would
throw
it
into
the
parameters
field
and
that
could
that
would
be
something
that
your
workload
would
have
to
know.
D
F
I
think
that
is
the
problem,
and
I
think
my
stance
is
just
that.
That
last
part
should
not
be
a
thing
that
can
happen
right.
We
should.
We
should
have
all
of
the
common
things
defined
and
then
everything
else
should
have
to
go
through
a
standards
rev
to
get
a
new
field
in
because
because
it
in
order
for
it
to
be
consumed
by
workloads,
it
has
to
be
something
that
workloads
can
assume
will
always
exist,
and-
and
this
this
whole
it's
opaque.
F
It's
just
something
that
my
driver
happens
to
to
know
about,
creates
the
lack
of
portability
right,
because
now,
if
I
create
a
workload
that
depends
on
that
field
being
present,
and
then
I
move
to
a
different
cloud
that
has
a
different
cozy
provider,
the
field
isn't
there
anymore
and
I
break
and
that's
exactly
what
we're
trying
to
avoid.
Is
this.
You
know
tying
workloads
to
implementations
of
provisioners.
F
You
know
we
want.
When
I
asked
for
an
s3
bucket
to
kubernetes,
I
should
get
an
s3
bucket
period
and
like
I
should
always
get
the
same
thing
every
time
and
and
there
shouldn't
be
any
variability
and
that
that's
sort
of
how
it
is
with
with
pvs.
Today
and
pvc
is,
you
know,
you
create
a
volume
and
you
get
a
volume
and
and
there's
a
certain
minimum
set
of
things
that
you'll
that
you
can
assume
are
always
there
and
then
anything
else
is
just
sort
of.
F
F
A
A
So,
to
conclude
on
that,
I
think
ben
has
a
good
point.
I
think
my
name
is
really
good
point,
which
is
as
someone
who's
writing
an
application.
I
don't
want
the
parameters
field
to
to
change
willy-nilly.
Just
because
I
say
I
upgraded
the
version
of
the
provider
or
something.
D
D
A
On
a
tangent,
maybe
shin
can
help
answer
this
so
shane
in
this
csi
world,
where
we
have
specific
fields
for
different
providers,
a
lot
of
times
with
a
lot
of
customers
that
that
we
work
with,
they
seem
to
use
the
generic
csi
specification
for
requesting
a
volume
rather
than
specifying
precisely
you
know
a
provider
of
a
particular
type.
So
say
you
know
they
don't
choose
something
like
fiber
channel.
A
Rather,
even
if
it's
fiber
channel
they,
they,
the
set
of
parameters,
are
specified
in
the
pvc
for
for
a
generic
csi
driver.
Would
you
like
is?
Is
there
a
reason
again?
Okay,
first
of
all,
do
you
see
more
people
going
towards
that
model
where
they
don't
use?
The
type
explain.
I
A
G
G
Yeah,
but
I
mean
every
driver
so
yeah,
so
that's
that
parameters
feel
right.
So
if
you,
if
you
go
down,
you
know
not
not
under
protocol,
but
we
do
have
this
parameters
field.
Each
driver
has
it's.
Every
storage
system
is
different.
They
do
have
something
that
is
opaque
so
that
it's
hidden
under
the
parameters
right.
So
I
think
so
I
I
was
thinking
that
this
should
be
similar
to
that
we
shouldn't
have
another
parameters
under
protocol.
So
that's
you
know.
That's,
let's
see,
yeah.
A
So
one
last
question
about
csi
and
then
so
the
last
question
is
so
there
is
a
csi
driver
which
is
just
generic.
That
is,
you
can
put
in
the
name
of
any
storage
class
in
there
and
the
parameter
is
only
opaque,
correct.
A
Yeah
and-
and
there
are
other
types
csi
drivers
like
you
know
like
ebs,
csi
driver
is,
is
a
type
and
well.
G
That's
the
same
right,
it's
just
you
know
the
they
have
their
own
parameters
that
are
required,
but
they
are
driver,
but
everything
else.
The
common
field,
the
first
field,
first
class
field,
should
be
the
same
right.
A
So
if
they
want
to
make
a
change
to
the
api
like
like
here,
let's
say
for
eb
ebs,
so
yeah.
G
No,
you
can't
it's.
Actually,
that
is
true.
It
is
difficult
to
make
a
change,
but
that
is
the
principle
right.
That's
the
you
use
this
common
api,
so
you're
bound
by
whatever
that
is
in
that
api.
So
you
can't
just
go
you.
So
if
you
want
to
require
some
change,
then
you
have
to
have
like
a
valid
use
case
right
then
we
have
to
see.
Does
that
really?
Is
that
required
by
everybody?
Can
you
just
hide
this
under
parameters
right
so
most
likely?
It's
probably
okay,
just
to
have
that
under
parameters.
A
So
another
question
I
have
is
like:
are
there
any
changes
that
were
required
that
were
absolutely
needed
right
away,
like
I
can
imagine
like
say,
there's
a
there's,
a
security
fix
right
for
that?
Let's
say
you
need
to
add
a
field.
Does
this
like,
I
feel
like
this
might
hold
hold
it
back
right.
G
A
Right
right,
so
csi
driver
is
only
one
so
and
that
one
is
completely
opaque.
Correct.
G
G
A
Yeah
and
fs
type
yeah.
We
also
have
some
common
names.
Like
you
know,
the
driver
name
in
our
case
is
the
protocol
name.
We
don't
have
a
read-only
option,
but
we
do
have
a
version
and
we
have
attributes,
we
call
it
parameters,
so
this
is
kind
of
where
I
was
going
for
because,
like
you
said,
the
entry
is
completely
moving
away
and
we
are
only
having
this
what
what
ben
is
suggesting
is.
We
should
have
entry
for
for
object,
storage
and
that's
what
I'm
concerned
about,
like.
A
I
think
entry
for
object.
Storage
will
lead
to
the
same
thing
again
where
we
will
move
away
and
we'll
just
do
parameters
like
this
later
on.
What
do
you
think.
A
So
this
this
one's
going
to
be
here
right
right,
this
one
is
going
to
be
here,
but
what
I
mean
is
we
stopped
using
say,
for
instance,
there's
an
example
here
I
saw
like
iscsi
and
stuff
earlier,
like
yeah
storage,
os
storage
os
is
out
of
business
right
now.
Are
you
sure
I
mean
I
storage
os?
A
Is
those
guys
and
tell
me
if
I'm
wrong,
but
those
are
the
guys
that
came
up
with
a
machine
that
they
give
to
free
for
others,
they
give
it
as
a
heater
for
the
home
and
they're
on
blockchain
mining
and,
and
they
came
up
with
some
storage
system
for
it
and
they
call
it
storage
os.
G
A
Yeah
so
so
my
question
here
is:
are
people
using
this
or
are
people
mostly
using
csi.
G
A
A
A
So
so
that's
my
that's
the
proposal
here.
What
we're
saying
is,
instead
of
having
you
know,
s3
azure
and
google
cloud
here,
we'll
inevitably
end
up
at
that
point
where
we'll
have
to
move
to
parameters,
so
I
would
rather
avoid
this
because
we'll
then
have
to
have
account
so.
G
G
G
Every
time
you
add
a
new,
whatever
the
provider,
then
you
have
to
add
a
field
here.
Every.
D
D
C
A
D
G
D
D
D
D
A
I'm
confused
that.
A
What
we
talked
about
hold
on
so
we
said
that
driver
might
return
new
fields
that
are
not
a
part
of
protocol,
so,
for
instance,
if
you
don't
specify
a
region,
the
driver
will
choose
a
default
region
for
you
that
absolutely
goes
back
into
the
protocol
you're
right
right.
However,
I
don't
see
why
it
should
overwrite
an
existing
field.
That
sounds
wrong
to
me
so,
like
it's
always.
A
And
when
you
say
overwrite,
what
it
sounds
like
to
me
is
you
specify:
a
region
is
u.s
east
one,
but
then
the
driver
only
provisions
in
usbs
one
and
then
it
provisions
anyways
and
then
returns
and
says
usbest
one.
Now
that's
a
terrible
user
experience
and
you
know
if
you
can
destroy
companies
with
the
aws
bill.
A
Yeah,
but
but
this
this
should
I
so
I
think
this
should
be
input.
I
don't
think
there
should
be
output
as
much
anything
that
again.
I
I
if
there
are
defaults
sure
there
are
defaults,
but
I
don't
think
we
should
have
that
form
of
a
design
where
the
driver
returns,
something
we
overwrite
parameters
set
by
the
user
like
this
is
the
input
field,
and
I
think
we
should
stick
to
that.
There
should
be
a
strict
input
field.
D
B
D
We
would
have
to,
as
you
say,
if
there's
like
a
default
region
in
that
example,
right
for
the
user-
account
that's
creating
it
and
if
region
is
not
passed
in
the
driver
would
return.
This
is
the
region
it
was
get
created
in.
So
in
that
case,
we
would
allow
adding
to
the
parameters
we
would
not
allow
overwriting
is
that
is
that
what
we're
saying
we
want,
then.
A
I
mean,
to
be
honest,
the
best
case
scenario
is,
there
are
no
defaults,
and
you
know
these
are
all
required
fields
and
we
expect
the
parameters
to
already
have
them.
Otherwise,
we
error
out.
D
D
A
A
D
A
Values
that
are
already
conversation
started
along
the
lines
of
there
are
some
fields
that
we
may
not
know
up
front,
but
but
I
think
I
think
it's
it's
it's
safe
to
say
the
provider
is
the
one
that
that
gets
to
validate.
If
there
are
fields
missing
or
not
right,
we
keep
it
opaque.
I
think
I
think
we
we
create
an
environment
for
for
provider
writers
to
to
get
more
consistent,
behavior.
D
A
Okay
yeah
anyone
else
starts.
G
A
Yeah
yeah
the
the
provider
will
decide
that
right,
yeah
that
makes
sense.
Okay,
so
shing.
I
think
one
thing
we
can
do
is
so
so
rob
the
changes
that
you
talked
about.
We
don't
need
any
change
to
the
cap
based
on
this
discussion
about
parameters
right.
D
Well,
we
might
need
to
add
some
top
level
ones
like
access,
keys
and
stuff
like
that
right.
A
So
there
was
one
reason
to
keep
it
inside
shing
one
was
we
want
to
remove
this
and
we
need
a
way
to
specify
stuff
that
are
specific
to
one
protocol,
say
s3,
but
there.
A
It
will
still
support
multiple,
actually,
that's
a
good
question
you
asked
so
so
everyone
else
also
can
pitch
in
on
this.
Given
that
we're
going
to
have
only
a
predefined
set
of
well-defined
fields
here,
a
tiny
amount
of
fields
do
we
still
need
a
protocol
parameters
here.
That's.
A
A
D
So
from
from
the
sidecar
perspective
right,
the
sidecar
needs
to
be
able
to
get
the
parameters
somewhere
now,
so
we
had
talked
about
this
right.
We
had
said
there
may
be,
and
maybe
what
ben
was
saying
is
this
is
misunderstanding-
is
that
there
may
be
protocol
specific
parameters
as
well
as
non-protocol
specific
parameters,
which
is
why
we
originally
had
a
protocol
out
parameters
and
a
bucket.parameters
right
and
that's
what
we
added
into
the
bucket
class.
The
bucket
class
has
a
protocol.parameters
and
a
bucket
class.parameters
you're.
G
So
if
you
think
in
protocol,
you
also
need
the
parameters
you
probably
should
give
some
like
concrete
example
why
you
need
to.
I
just.
A
Yeah
so
say
we
want
s3
field
for,
for,
for
specifying,
let's
say,
object,
locking
or
encryption
some
new
form
of
encryption.
They
support
who's,
whose
parameters
are
very
new
that
we've,
not
you
know
nobody
has
seen
so
far
is
so
you
know
in
such
a
case,
you
know.
Parameters
is
needed
in
the
protocol
specific
to
the
protocol
and
it
is
it
is,
you
know
it's
an
opaque
field.
We
we
don't
know
it
up
front.
A
G
A
D
I
think
I
think
a
key
point
of
this
is
that
the
protocol
will
kind
of,
as
I
see
it,
the
protocol
spec
at
this
point
is
being
double
used
right
in
the
bucket
the
protocol.
This
information,
the
key
the
clearly
defined
fields,
go
into
the
bucket
or
into
the
pod
right,
is
information
about
how
to
access
the
bucket
that
was
created.
B
A
True
rob
yeah.
A
Yeah
yeah,
I
don't
want
to
keep
others
for
too
long,
but
but
let's
continue
discussing
this
throughout
the
week
and
thursday
we'll
try
and
make
a
decision.
Thank
you
everyone.
It
was
a
good
good
discussion.
This
kanye
on
thursday
bye.