►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket Provisioning Design Meeting - 28 October 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Sidhartha Mani (Minio)
A
I
think
we
can
get
started
all
right,
so
I
remember
a
few
weeks
back.
Someone
mentioned
that
we
should
take
notes,
so
I'm
gonna
ask
someone
here:
can
help
with
that.
A
A
Based
on
the
questions
we
ask,
because
that
should
give
us
enough
of
a
start
like
you
know,
that
should
be
enough
for
someone
to
go
back
and
then
search
and
maybe
go
using
the
using
keywords
they
find
out,
which
which
days
which
meeting
has
a
particular
topic
and
then
they
can
go
to
the
youtube
video
and
get
into
the
details.
A
Okay,
okay,
we'll
start
with
that,
then
thank
you
jiffin.
So
if
you
can
just
capture
like,
I
said
the
overall
topics
we
discuss
and
any
decisions
we
come
to.
That's
all
sure
thank
you
and
I
will
share
the
document
with
you.
So
the
document
that
we
use
is
the
pinned
document
on
six
storage,
cosy
slack,
I'm
gonna
share
it
on
this.
D
A
Sure
that'll
also
work
yes,
okay,
okay,
so
let's
continue
where
we
left
off
last
week,
we,
I
think
last
week
we
left
off
talking
about
workload,
identity
based
identity,
based
authentication
and
authorization.
A
So
we
were
talking
about
how
so
so
the
overall
concern
we
were
dealing
with
was
what
was
required.
What
was
left
to
be
addressed
in
the
kept
and
tim's
major
concern
seemed
to
be
how
we
were
going
to
solve
workload,
identity
based,
authentication
that
is
in
in
cloud
providers.
Ia
iam
allows
an
identity
to
be
attached
to
a
particular
workload.
A
So
if
a
particular
part
or
a
particular
deployment
or
a
particular
node,
is
making
a
request,
then
by
default
it's
assumed
to
be
authorized
as
a
particular
account
a
service
account,
and
we
wanted
to
figure
out
in
cosy
how
we,
how
we'd
enable
that
for
pods.
A
So
our
answer
so
far
has
been
there'll,
be
some
back-end
mechanism
for
cloud
providers
or
cozy
drivers
to
associate
a
particular
pod
with
a
particular
identity.
So
we
will
not
get
in
the
way
of
that.
We
will
just
say
you
know
the
driver
is
free
to
do
it.
Whichever
way
it
will
and
all
we'll
do
is
we
will
mount
a
particular
mount
a
token
associated
for
that
iam
account
or
either
a
token
or
you
know
some
other
some
other
thing.
B
B
B
You
know,
write
one
workload
that
sort
of
just
finds
out
based
on
where
it
is
what
it
should
be
doing
and
then
do
that
thing.
So
if
it's
in
the
cloud
and
it's
going
to
use
token-based
auth,
there
should
be
a.
We
should
have
a
way
of
signaling
from
cozy
down
to
the
workload
in
this
environment.
Use
the
token,
but
then,
when
the
very
same
workload
runs
in
like
an
on-prem
situation
that
doesn't
have
a
token
it's
just
access
key
secret
like
then,
there
should
be
another
way
to
signal
like
in
this
environment.
B
A
So
for
this
I
think
we
said
we'll
we'll
allow
the
workload
to
say
the
exact
kind
of
authentication
that
it
can
use
inside
the
bucket
request.
A
A
B
B
A
So
we
talked
about
this
last
week
and
and
personal
google
load
was
also
saying
this:
a
workload
yeah
the
sdks
currently
that
I
shipped
with
every
cloud
provider
pretty
much
every
object
service
provider
does
allow
for
multiple
styles
of
authentication,
just
just
by
default.
Yes,
but.
A
That
use
these
sdks
may
choose
a
particular
one,
and,
and
that
that
I
don't
know.
B
B
E
Yeah,
I
just
I
thought
first
and
let
me
know
just
correct
ben.
Our
definition
of
portable
means
it's
not
the
same
as
pvcs.
A
definition
of
portable
means
that
the
client
application
has
set
a
a
it's
bound
to
a
a
client
library.
To
communicate
with
a
specific
object
store.
Is
that
right.
B
For
something
very
similar
to
what
pvcs
give
you,
which
is,
it
should
be
possible
to
do.
Well,
I
I
don't.
I
don't
agree,
I
I
think
if
we
enumerate
a
list
of
authentication
schemes
that
cozy
may
give
you
and
you
have
a
client
library
that
can
consume
all
of
those,
then
it's
just
a
matter
of
telling
the
workload
at
runtime
which
one
it's
being
given
and
then.
E
That's
a
ask,
ask
first
and
and
then
it's
not
really
the
way
kubernetes
works.
E
A
A
Yeah
yeah,
so
we
we
specifically
choose
what
kind
of
authentication
model
we
want
and
if
you
know
the
admin
is
responsible
for
putting
us
in
a
different
cloud
that
also
supports
the
authentication
model
or
different
object
storage
system.
So
that's
what
is
expected
if
you're,
if
you're,
expecting
to
change
the
authentication
model
that
also
changes
guarantees
that
the
application
expects.
A
So
I
would
think
that's
that's
acceptable
where,
if
you
move
from
say
one
style
of
authentication
to
a
different
one,
the
application
should
know
about
it
and
application
should
particularly
ask
for
what
specific
authentication
model
at
once.
So
if
it
says
I
want
token
based,
then
I
can
move
you
know
between
two
providers.
B
A
E
So
the
stores
class
has
a
set
of
guaranteed
guarantees
and
in
them
it
has
a
set
of
of
approved
authentication
models.
The
driver
can
through
the
same
way,
csi
does
features
the
driver
can
say
these
are
the
authentication
models
that
I
support
right
exactly
and
then
the
the
requester
then
says
I
want
a
bucket
from
the
bucket
class
this
a
right
which
has
the
correct
authentication
model
that
I
want
right
and
then
and
then
that
bucket
is
then
provided
and
then
and
that's
that's
how
it
should
work.
E
In
other
words,
the
requester
knows
what
type
of
authentication
model
they
want.
The
admin
sets
that
authentication
model
through
the
the
bucket
class
and
according
to
the
driver,
spec
and
the
driver
can
then
identify
if
it
does
support
it
or
not
through
the
the
spec
itself.
In
the
grpc
communication.
A
We
had
defined
portability
as
if
you
have
the
same
data
protocol
between
two
providers,
then
I
should
just
be
able
to
take
my
definition,
like
bucket
request
definition
for
sure
to
you
know,
change
the
bucket
class
and-
and
it
should
just
work.
That
was
the
idea.
Yeah.
A
Yeah,
because
if
we,
if
we
define
the
authentication
method
in
in
the
class,
then
yeah
it
should
work.
Yeah.
D
D
B
If
we
define
as
part
of
our
downward
api,
some
information
that
gives
the
gives
the
pod,
you
know,
tells
you
which
one
you're
is
you're
working
with,
and
if
the,
if
the
s3
client
library
that
is
actually
going
to
do
the
heavy
lifting
just
supports
both,
then
then
you
really
don't
care
right.
It's
like
it's.
Just
you're
gonna
get
one
or
you're
gonna
get
the
other.
The
client
library
can
deal
with
with
both.
You
need
maybe
a
little
bit
of
handshaking
to
figure
out
which
one
you've
got.
E
A
B
A
B
E
B
E
B
D
B
So
it
could
be
a
feature
of
the
cluster
itself
that
there
are
no
tokens
there
are.
No,
you
know
I
forget
the
other
authentication
mechanisms,
but
you
know
you
might
be
in
a
situation
where
the
only
thing
available
to
you
is
access,
key
secret,
key
sure,
because
you're
in
some
on-prem
cloud
using
some
implementation,
that's
fairly
bare
bones.
D
A
A
B
A
A
Like
pvcs
and
pvs,
because
in
pvcs
and
pvs,
we
always
assume
it's
posix,
so
we
don't
care
about
the
contract.
It's
set
in
stone
so
so
coming
here.
When
what
all
options
can
someone
specify
in
a
pvc
definition
not
in
a
not
in
a
storage
class.
B
You
can
specify
the
access
mode,
which
is
a
list
of
potentially
our
rx
rox,
rwx,
rwo
and
rwp,
which
is
the
new,
the
fourth
new
one,
and
you
can
have
a
list
of
of
one
or
more
of
those.
But.
A
E
So
if
again,
I'm
going
back
to
the
application,
if
the,
if
the
request
from
a
ppc
request
a
raw
block
and
there's
no
raw
block
provider,
you
will
append
right
yeah
and
that's
what
I'm
trying
to
say.
There
is
a
request
from
the
application,
so
the
application
must
change.
There's
nobody
replying
providing
a
a
file
system
as
raw
block.
That's
that's
what
I'm
trying
to
avoid!
I'm
not
trying
I'm
trying
to
avoid
this
glue
in
between.
B
A
A
A
Work
hundred
percent
of
the
time
it's
it
doesn't,
even
if
it's
just
one
percent,
where
things
don't
go
right,
I
don't
think
we
we
can.
You
know
we
can
make
the
case
that
you
know
most
of
the
time
this
works.
So
that's,
okay,
but
not
here
so
so
coming
back
here,
a
guy
brought
up
something
interesting
on
the
chat
guy.
Do
you
want
to
say
it.
D
It
took
me
time
to
wind
up
back,
so
I
just
want
to
say
I
I
think
ben's
direction
makes
sense.
To
me
I
mean
the
if
there's
the
authentication
method,
which
is
what
what
you
guys
are.
I
think
you're
discussing
mostly
authentication
right,
you're,
not
talking
about
anything
else
at
this
point.
Yes,
for.
A
A
But
if
you
wanted
to
do
any
other
style
of
authentication
because
he
doesn't
have
support
for
it,
so
we're
talking
about
how
we
would
do
im
style,
authentication
and
what
ben
is
saying
is
you
know,
given
that
we
are
going
to
have
more
modes
of
authentication
and
and
the
contract
of
authentication
is
between
the
application
and
the
object
storage
provider.
A
So
so
we
have,
you
know
we're
trying
to
figure
out
who
specifies
what
kind
of
authentication
mode
they
want
and
who
says.
These
are
the
modes
that
are
allowed,
or
these
are
the
modes
that
I
support
and
then.
B
D
Well,
we're
not
inv
we're
not
inventing
it.
I
mean
we
just
look
at
the
sdk
right.
The
I
think
the
portability
that
ben's
mentioning
is
that
the
it's
not
that
the
application
has
to
be
aware.
It
doesn't
even
care,
because
what
it
does
usually
when
you
write
an
application
to
an
object
store.
You
just
take
the
sdk.
E
D
D
D
B
To
use
my
my
tokens
like,
we
could
view
that
as
a
purely
optional
thing
or
we
could,
we
could
treat
it
as
a
mandatory
thing.
We
could
say:
look
we're
gonna,
we're
gonna,
give
admins
the
option
to
to
require
that
and
we're
gonna
say
workloads
just
have
to
deal.
If,
if
that's
what
they're
given
and
then
and
we
could
sort
of
draw
the
line
there
and
say
that
for
a
minimum
bar,
you
have
to
be
able
to
accept
either
a
or
b
and
we
can
append
cde.
B
E
E
Wouldn't
we
just
say:
let
me
let
me
just
answer
that
one
when
you
mean
sdk,
do
you
mean
the
s3
sdk,
because
other
object
stores
like
let's
say
I
want
to
talk
to
ceph
back
end,
not
the
radar's
gateway?
That's
a
very
different
sdk.
E
E
A
Let's
simplify
for
a
second,
let
me
ask
you
a
very
simple
question:
first,
should
the
application
define
what
kind
of
authentication
mode
it
supports,
or
not,
I
think,
guy
and
and
ben
are
saying
it
it's
going
to
support
multiple
anyways,
so
the
application
never
has
to
specify
it
and
say
the
bucket
spec
bucket
bucket.
I
don't.
C
A
D
And
if
you
have
the
app
image
too
old,
to
support
something
new
right,
the
the
admin
enforces
that
should
break
that.
That
makes.
D
A
Fair
enough,
okay,
so
that
means
so
the
admin
needs
a
way
to
say
this
is
the
allowed
authentication
methods
and
the
application
doesn't
have
to
say
anything.
The
application
simply
just
starts
up
and
it
tries
to
do
things
the
way
it
knows
like.
Let's
say
it
tries
three
different
styles
of
authentication
and
if
one
of
it
works
sure
it
goes
ahead
and
works.
Otherwise
it
just
fails.
D
B
The
admin
can
can
choose
a
cozy
driver
based
on
what
authentication
mechanisms
the
kozu
driver
supports,
so
a
cozy
driver.
Excuse
me
that
has
very
minimum
authentication.
Styles
might
not
excuse,
me
might
not
be
very
popular
in
practice,
but
but
but
yeah.
It's
just
a
choice
that
the
developer
of
the
of
the
driver
makes
is
what
what
they
can
support
and
then
the
admin
chooses
it
knowing
what
it
can
support
and
then
the
workloads
are
forced
to
support
all
of
them,
so
it
just
works.
B
B
D
B
And
then,
but
when
what
I'm
trying
to
say
is
for
the
s3
protocol,
we
will
mandate,
you
know,
authentication
styles,
a
b
and
c,
or
a
and
b
or
whatever
some
minimum
that
are
required
for
s3.
And
then,
if
you
have
a
different
protocol
like
azure
blob,
it
might
be
a
different
set
and
it
might
only
be
one,
but
it
could
be
two
or
it
could
be
three.
B
But
but
the
reason
that
all
of
this
matters
for
us
is
because
we
have
at
the
end
of
the
day,
it's
our
job
to
marshal
the
credentials
into
the
pod
like
that's
something
we
have
to
do.
We
have
to
set
an
environment,
variable,
create
a
file,
add
a
parameter
to
do
something
to
get
it
in
there
and
we
have
to
write
down
in
very
explicit
terms
exactly
what
we're
going
to
do.
Where
we're.
E
B
E
F
F
F
Secondly,
there
is
an
issue
with
authorization,
because
all
of
a
sudden,
the
workload
is
tied
to
a
particular
key
pair
or
whatever
else,
but
it's
up
to
the
provisioner
to
make
sure
that
this
workload
that
key
pair
has
access
to
a
particular
bucket
where
that
keeper
has
not
been
created
by
this
provisioner.
So
how
does
the
provisioner
know,
which
user
or
which
key
pair
will
be
exposed
into
the
pod
in
which
the
application
will
run.
E
A
A
So
we're
going
to
support
the
access
key
secret
key
still
nicholas.
This
is
the
additional
mode
of
authentication
we're
talking
about,
and-
and
we
need
to
support
this,
for
you
know,
environments
where
higher
or
more
secure
styles
of
authentication
is
required.
A
Our
access
key
secret
key
is
not
going
away,
it's
going
to
be
there,
but
we
need
to
also
support
other
styles
of
authentication
now
now
the
second
question
was
about
how
workloads
simply
just
get
an
identity
and
authentication
or
authorization
just
based
on
you
know
like
a
like
a
metadata
service
like
you
were
mentioning,
even
even
in
that
case,
I
I
don't
think
we're
introducing
a
metadata
service,
what
what
cloud
providers
do
or
what?
A
A
Is
the
sdk
takes
a
token
from
the
local
file
system
and
then
talks
to
the
link
local
ip
address
with
that
as
the
identity,
and
then
the
link
local
ip
address,
based
on
whatever
token
is
presented
to
it
will
say
you
know
you
have
you've
been
authorized
to
do
this
this
and
that
so
there
is,
you
know
there
is
still
a
token
that
needs
to
be
present
into
the
pod.
B
B
Exactly
what
the
client
or
the
workload
should
observe
you
know
in
all
of
the
different
situations,
and
the
answer
can
be
that
you
know
you
need
to
go
talk
to
something
else,
but
then
we
need
to
specify
what
that
is
and
how
you
talk
to
it
and
what
and
what?
If
anything,
we're
providing
for
that
conversation,
because
because
there's
still
the
step
where
cozy
has
to
grant
you
access,
we
don't
want
to
have
a
situation
where
workloads
that
haven't
been
granted.
B
Access
can
still
somehow
get
at
the
bucket
because
they
know
how
to
talk
to
a
thing
right,
there's
still
something
we
have
to
provide
to
enable
the
access
with
a
given
bar
or
ba
or
whatever
we're
calling
it
that
that's
bound
to
a
bac
and
all
that
other
stuff
right,
because
we
want
to
have
read
only
access.
We
want
to
have
rewrite
access.
A
So,
let's
again
try
and
answer
this
question
of
who
gets
to
define
what
kind
of
access
they
want.
So
in
case
of
pvs
and
pvcs
in
the
pvc
definition
we
say
hey,
I
want
read
only
access
or
read,
write
access,
and
we
also
expect
that
well,
rather
than
even
read
only
a
read
write.
Let's
talk
about
the
read
write
many.
A
A
B
A
B
A
B
And
you're
right
right
and
how
to
define
it.
But
I
mean
if
we
want
to
give
the
admin
the
freedom
to
say
we're
not
doing
access
to
secret
key
here.
The
only
way
to
do
that
and
retain
portability
is
to
require
all
workloads
to
also
support
some
other
authentication
authentication
mechanisms,
which
is
where
I'm
trying
to
get
us
which.
E
No
yeah,
I
agree
with
that.
I
think
what
what
I'm
trying
to
say
is
that,
let
me
know
this
is
correct.
Ben
is
that
you,
the
the
admin,
can
say
this
supports.
E
And
then
the
and
that
forces
the
application
writer
to
to
understand
that.
But
if
we
and
we're
very
explicit
to
say
when
you
get
this,
this
model
of
authentication
in
the
class,
this
is
what
you're
going
to
get
in
the
pod
internally
is.
A
B
E
It's
is
it
if
what
is
the
benefit
of
cozy
doing
the
least
common,
if
the
admin
can
still
choose,
is
it
in
case
the
admin
doesn't
choose
anything.
B
B
E
I'm
sorry,
I'm
not
I'm
not
really
asking
I'm
asking
is
if
the
admin
is
in
the
middle
choosing
which
authentication
model
we're
going
to
choose,
is
it
that
if
they
don't
choose,
we
have
a
default?
Is
that
what
it
is.
B
Oh,
I
I
would
say
the
driver
would
get
to
choose
like
it.
It's
ultimately
up
to
the
driver
to
support
one
or
more
things,
and
it's
a
driver
configuration
question
of
what
you
actually
get.
Okay,.
D
A
A
B
B
D
B
Well,
for
a
particular
driver,
like
a
driver
that
supports
the
s3
protocol,
could
say
we're
only
supporting
token-based
authentication
and
if
and
if
the
workloads
are
following
the
minimum
standard.
Like
that
shouldn't
break
anybody,
and
then
another
driver
can
say
we're
only
going
to
support
access,
key
secret
key
and
then
the
third
driver
can
say
you
know
what
we're
gonna
support
both
and
let
the
admin
choose
which
one.
A
The
the
problem
is,
you
know
we
might
not
be
able
to
orchestrate
it.
You
know,
because
we
also
have
to
orchestrate
all
the
different
authentication
mechanisms.
Now
you
know.
B
We
have
to
support,
we
have
to
support
a
list
of
our
own
choosing.
That
is
wide
enough
to
give
people
prior
portability
that
we
get
to
define
the
list
and
we
can
make
it.
We
can
make
it
exactly
what
the
s3
sdk
supports.
If
we
want,
we
could
make
it.
E
E
I
just
want
to
ask
so
I
just
feel
sometimes
we're
going
round
and
round.
E
A
Yeah,
it's
probably
a
better
idea.
Let's
do
that.
Let
me
share
and
let's
write
down
a
simple
bucket
access.
Yammer,
let's
see
what
that
looks
like
so.
A
Yeah
yeah
and
let's
just
go
to
spec
directly
okay,
so
this
is
okay,
yeah
kind
matters
here,
so
we're
calling
this
bucket
access.
So
a
guy,
you
might
have
missed
this,
but
we're
moving
away
from
the
request
and
access
or
requests
and
and
equivalent
cluster
scope
resource.
A
Instead,
we're
calling
the
previous
bucket
access
the
one
that
was
used
to
request
a
bucket
we're
calling
that
bucket
claim
similar
to
possess
volume
claim
and
bucket
access
is
just
a
single
resource
that
doesn't
have
an
equivalent
in
the
cluster
scope,
and
this
is
a
namespace
scope
and-
and
this
is
this
is
to
request
credentials.
A
And
anything
else
that
need
to
be
specified
here.
So
this
is
what
goes
into
the
part
so
into
the
pod.
You'll
say
you
know,
let's
say
we're
introducing
a
new
field
or
say
for
now
it's
an
annotation,
you'll,
say
bucket
access
class
or
something
bucket
access
abc.
A
Some
mechanism-
let's
just
say
you,
know
bucket
this-
doesn't
matter
for
this
discussion.
Then
we
have
the
bucket
access
class.
A
And
this
will
have
name
it's
crazy,
and
so
so
what
ben
was
saying
is
ben?
Are
you
saying
that
here
we
specify
you
know,
authentication
models.
B
Driver
object
in
the
csi
land
is
not
defined
by
the
admin
it's
defined
by
the
driver
like
there
there's
always
some
driver
specific
configuration.
That's
part
of
the
when
you
install
the
driver,
you
tell
it
how
to
behave.
D
B
A
B
It
won't
be
a
list,
it'll
just
be
the
the
one
that
got
chosen
right.
How
do
they
choose
it?
So
so
somehow
the
driver
chooses
right
from
for
some
drivers.
It
could
be
hard
coded
for
other
drivers.
It
could
be
an
option,
but
it's
it's
it's
going
to
be
one
and
the
driver
is
going
to
tell
you
what
it's
going
to
give
you
at
run
time.
B
A
B
D
B
Okay,
let's
say
it's
the
net
outpoint
right.
I
know
more
about
netapp,
so
so
let's
say
netapp
releases.
Some
trident
driver
that
supports
cosy
when
you
set
up
your
driver,
configuration
in
trident
you'll,
say:
oh
I'm
going
to
choose
the
token
method
and
then
trident
will
begin
telling
the
kubernetes
or
the
cozy
sidecars
on
the
kubernetes
side,
hey
you're,
getting
tokens
and
if
I
select
access
key
secret
key,
then
it'll
tell
them
hey
I'm
giving
you
access
key
secret
key.
So.
A
Okay,
okay
and
then,
and
then
the
workload
does
not
specify
anything
about
what
it
wants
it.
Just
the
bucket
access
class
doesn't
have
any
specification
about
like
what,
among
these
it's
choosing
it's
just
implicit.
That's
what
we're
saying
right
throughout
the
process,
it's
implicit
which
one
you
get
and
the
expectation
is
the
application
has
to
allow
all
three.
D
G
B
It's
got
to
be
part
of
our
downward
api
that
we
we
tell
you
when
the
pod
starts
up.
Here's
your
bucket
here's,
the
kind
of
here's,
the
kind
of
authentication
information,
we're
giving
you
and
here's
the
information,
like
all
all
of
those
things
have
to
be
provided
in
our
downward
api
to
the
workload
and
that
that's
why
I'm
so
insistent
on
like
being
precise
about
this
is
because
that's
that's.
Our
biggest
job
is
defining
that
that
particular
api
that
the
workload
sees
from
us.
C
I
have
a
question
here
like
say:
if
we
are
trying
to
inject
everything
to
the
application
port
like
for
access
key
and
secret,
it's
just
a
file
right.
If
everything
is
filed,
then
it's
fine,
but
if
they
aren't
injured
something
else
or
something
like
some
ip
information
like
the
the
service
endpoint,
which
I
am
need
to
talk
to,
or
something
like
that
like.
If
everything
is
file
based,
then
it's
fine,
if
something
additionally
to
be
done,
that
it
may
affect
the
port
to
come
up
right
or
something
like
that.
B
Yeah
I
want
to
get
into
detail
and
like
for
like,
let's
do
some
examples
of
an
im
based
authentication
scheme,
because
I'm
not
too
familiar
with
how
that
actually
works
in
practice
I
mean
I
can
imagine
how
it
might
work,
but
we
should
go
through
a
very
specific
example
of
like
I'm
running
in
gke.
I
have
a
google,
you
know
account
token
it's
being
plumbed
into
my
pod
through
the
normal
mechanism,
and
how
do
I
take
that
and
turn
around
and
talk
to
a
gcs
service
with
it?
A
Someone
do
you
have
a
kubernetes
cluster
running
in
aws
right
now.
We
can
try
it
out
so,
okay,
so
this
is.
This
is
running
in
aws.
You
know
I
can.
I
can
log
into
one
of
these
nodes
and.
B
A
There
you
go
so
you
get
you
get,
this
is
the
metadata
you
get
local
ipv4,
public
keys,
reservation,
ids
and
so
on
and
so
forth.
This
is
the
metadata.
A
B
B
B
B
If,
if
the
admin
wants
to
install
a
cozy
driver,
that
does
the
im
based
authentication,
because
because
they
are
gke
and
they're
using
google
storage,
and
they
want
to
just
do
the
nice
thing,
then
it's
incumbent
on
them
to
sort
out
all
of
the
details
so
that
when
we
say
here's
your,
I
am
identity,
and
these
are
the
urls
you're
going
to
go
talk
to
that.
It
actually
works
right.
It's
not
our
problem.
A
B
D
B
Right
what
we
would
inject
is
like
the
the
authentication
type
is,
I
am,
and
then
maybe
some
additional
urls
that
like
here,
is
how
you
go,
get
your
im
stuff
and
like,
and
that
would
be
where
it
and
that's
just
a
proposal
like
I
don't
know
if
it's
the
best
way
to
do
it.
But
you
know
it's
our
job
to
just
give
you
something
that
is
going
to
be
consistent
across
every
possible
implementation
of
im
authentication.
B
That
has
to
be,
you
know,
compiled
with
microsoft
and
amazon
and
google
and
huawei
cloud,
or
I
don't
know
how
many
others
that
are
out
there.
But
you
know
we
want
to
have
a
scheme
that
is
flexible
enough,
that
it
works
everywhere,
but
at
the
same
time
workloads
know
exactly
what
they're
supposed
to
do
and
there's
never
any.
You
know
magical
incantation.
You
have
to
say
to
get
to
get
your
your
okay.
A
Let
me
ask
you:
should
should
a
workload
or
should
an
admin
be
able
to
so
with
the
current
model
that
you've
proposed
when
we
we
have
a
mechanism
for
the
admin
to
be
to
mandate
that
this
is
the
only
thing
that
I
want
so
so,
and
they
do
it
through
the
configuration
of
the
driver
itself.
That's
our
current
model.
So
far.
What
we've
spoken
is
that
a
little
restrictive.
A
A
A
B
B
A
Okay,
so,
okay,
I
think
I
know
what
you're
saying
so
so
in
that
case,
so
it's
I
think,
you're
saying
that
it's
okay,
if
it
you
know
whatever
ability
it
gives
flexibility
it
gives,
is
good
enough.
D
B
D
A
Okay,
so
so
we're
still
saying
so,
the
applications
contract
is
still
not
directly
with
cosy,
but
rather
with
with
the
object,
storage
or
the
driver
really.
A
Sure
that
we'll
say,
okay,
fair
enough,
okay,
so
I
think
this
would
work.
This
would
work.
So
I'm
I'm
just
trying
to
understand
so
portability
here
really
means
that
when
the
admin
moves
you
from
one
system
to
another,
that
you
don't
have
to
change
the
application
definition
whatsoever,
because
the
authentication
method
is
completely
transparent
or
it
is,
it
is
implicit
in
this
case,
and
you
know
the
definition
only
still
includes
just
the
protocol,
so
so
portability
will
be
maintained
as
long
as.
A
It
be
better,
okay,
so
here's
my
question,
so
it
wouldn't
be
better.
If
you
were
more
explicit
about
it,
saying
somehow
we
say
in
one
of
our
definitions:
either
the
class
or
the
access
object.
You
know
the
name,
space
object.
We
should
be
able
to
say-
or
let
me
not
not,
we
should
be.
Wouldn't
it
be
more
explicit
and
less
likely
to
end
up
in
a
you
know:
error
situation.
B
B
Add
another
source
of
truth
and
it
doesn't
agree
with
the
first
source
of
truth,
then,
which
one
is
correct.
I
say
the
driver
is
always
going
to
win,
and
so
why?
Why
write
it
down
a
second
time
I
mean
we
could
have
a
situation
where
the
sidecar
queries
the
driver.
What
do
you
support
and
then
it
reflects
that
back
into
the
kubernetes
api
so
that
you
can
see
the
status
that
says
this
driver
is
using
xsq
secret
key
and
now
you
can
see
it,
but
the
source
of
truth
is
coming
from
the
driver.
A
A
A
Okay,
so
I
okay,
I
think
I
know
where
you're
coming
from
ben,
so
you
know
we're
out
of
time.
Let's
continue
next
week,
but
yeah
we
should.
We
should
figure
this
out.
We
should
figure
out
who
gets
to.
I
mean
the
open
question.
Right
now
is
pretty
simple:
we
have
not
all
of
us
agreed
on
who
who
gets
to
decide,
or
I
think
okay.
Actually,
I
understand
what
you're
saying
then,
which
is
how
we're
doing
portability
it's
implicit
as
long
as
the
driver
supports
what
the
application
expects.
It's.
B
Well
and
the
other
thing
that
we
didn't
talk
about
a
lot
today
is
protocols
right,
luis
raised
the
question
of
what,
if
it's
not
s3
and
it's
like
well,
then
then
it's
a
whole
other
ball
game.
So
we
should
go
back
and
sit
and
spell
out.
You
know
how
you
say:
you
won
s3
versus
gcs
or
azure
blob
or
a
different,
entirely
different
protocol.
B
A
B
A
So
so
yeah,
let's
okay!
So
let's
continue
next
week
and
I
want
to
I
want
to
figure
out
yeah.
I
want
to
figure
out
what
are
the
indications
like.
I
want
to
see
if
we
can,
if
we
can
keep
our
authentication
mechanisms
abstracted
away
from
particular
data
protocols,
if
that's
even
possible,
I'm
I'm
worried
about
implementation
complexity.
Now.