►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Standup Meeting - 29 March 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
B
Eight
eight
okay
good
evening,
then
all
right,
so
so,
let's,
let's
get
started
so
one
of
the
things
that
I've
been
focusing
on
last
week
has
been
about
getting
the
code
base
to
a
position
where
others
can
start
consuming
it.
Chris
has
also
been
helping
with
that.
Chris
is
working
on
a
library
that
applications
can
use
a
go
library
that
applications
can
use
to
consume
cosy.
B
What
that
library
will
do
is
give
you
simple
functions
that
you
just
call
in
order
to
get
clients
or
credentials
to
talk
to
different
object,
storage
providers
and
and
in
terms
of
the
actual
code
base
there
was.
There
was
one
question
that
came
up
that
I
want
to
discuss
with
everyone
here,
so
in
our
api
in
our
cap
we
we've
had
this
concept
of
principle
I'll
show
you.
B
Okay,
this
is
a
this
is
a
protobuf
spec
and
when
you,
when
you
ask
access
to
be
granted
for
a
particular
bucket
and
when
you
revoke
access
for
a
bucket
the
way
we
the
response
to
grant
access,
gives
back
a
string
field
called
principle.
B
B
A
B
B
All
right
so,
when
we
ask
access
to
be
granted,
the
response
to
grant
access
is
the
request,
and
this
is
the
response.
The
response
returns,
something
called
as
a
principle,
so
this
principle
was
was
the
term
used
by
aws
for
the
account
id
of
whichever
account
was
created
as
an
im
account
or
some
other
form
of
you
know
token,
that's
provided
by
aws.
B
The
account
id
was
called
as
the
principle
or
is
called
as
a
principle.
Now
we
need
this
account
id
when
we
are
say
updating
credentials
and
when
we
are
say
revoking
them.
B
This
is
the
handle
which
you
use
to
specify
to
the
object,
storage
provider,
that
this
is
the
account
that
we're
working
with
so
account
id
or
our
principle
was-
is
kind
of
the
same,
as
is
the
same
as
a
username
or
like
an
account
id
and
and
talking
to
vendors.
I
ibm
specifically
janus
he
he
needed.
You
know
it
wasn't
intuitive
what
principle
meant,
and
I
think
I
think
I
think
what
janice
brought
up
was.
B
B
D
I
mean
sid
as
a
philosophy.
I
agree
with
what
you
just
said:
it's
better
to
use
the
more
generic
description
of
a
field
and
to
pick
something
that
maybe
is
popular
with
a
particular
vendor.
You
mean
as
a
principle.
You
agree
about
what
the
fields
is,
what
its
purpose
is
or
what
it
contains
so
account
id.
If
this
is
a
principle's,
an
account
id,
then
I
like
the
idea
account
id
okay.
B
B
A
B
B
B
So
I'm
just
thinking
it
through
and
seeing
if
there
is,
you
know
something
that
we
can't
represent
or
something
that
we
can't
update.
That's
there
and
as
of
right
now,
I
can't
think
of
anything.
So
if
you
were
to,
if
you
were
to
make
this
change
happen,
I'm
going
to
open
up
the.
B
C
I
think
initially
this
supports
mutable,
so
this
is
just
a
new
feature
that
you
can
actually
make
it
immutable
now.
D
Yeah,
okay,
so
there
was
a
need
for
that,
but
it's
interesting
sid
because
it
might
seem
like
if
I
change
my
config
map.
You
know
that
would
sort
of
percolate
through
them.
C
Right,
but
I
think
the
credential
change
actually
something
you
know
in
some
environment
is
actually
required,
so
I
mean
you
probably
want
to
support
both.
I
don't
think
this
should
be
always
fixed
or
something,
but
in
cases
that
you
probably
don't
want
it
to
be
changed
right.
That's
why
they
have
this
feature,
but
not
like.
It
has
to
always
be
like
that.
C
B
B
So
yeah
this
makes
sense.
So
so,
given
that
config
maps
have
their
property,
maybe
by
default,
we
can
make
the
config
maps
immutable.
B
How
how
do
we?
How
do
we
make
that
feature?
Hap?
First
of
all,
I
want
to
kind
of
understand
more
clearly.
Is
this
something
that
we
should?
We
should
support
being
so
so
again.
Think
of
it
as
we
have
the
ability
to
read,
write
first
or
we
have
the
ability
to
read
only
first
and
then
without
updating
without
changing
the
workload
or
without
having
to
you
know,
delete
the
workload
and
redeploy.
B
Do
we
want
do
we
want
to
have
the
ability
to
change
the
permissions
for
that
account,
and-
and
this
is
the
only
way
by
changing
the
bucket
access
class
or
is
there
some
other
way?
If,
if
we
do
decide
to
go
that
route.
B
So
so
for
the
first
question,
so
shing
what
if
we
said
you
can
still
do
it,
but
you
have
to
pull
the
workload
down
and
then
and
then
change
some
parameters
and
then
redeploy
it.
B
Yeah,
if
that's
the
case,
then
then
we
don't,
we
don't
have
to
update.
We
don't
have
to
make
this
bucket
access
class
or
the
policy
actions
conflict
map
mirrorable.
B
We
don't
have
to
deal
with
any
of
this.
We
just
we
just
say
use
a
new
bucket
access
or
new
bucket
access
request,
pointing
to
a
different
bucket
class
and
upgrade
so
so
does
that
mean
so
I
know
today,
if
you,
if,
let's
say
for
a
deployment,
if
you
call
the
you
know,
update
command,
does
it
does
it
up?
You
know
upgrade
command
and
does
it
upgrade
any
parameters?
B
B
Right
like
what,
if
I
updated
a
volume.
B
So
so,
let's
say:
there's
a
deployment
spec
and
when
you
call
cube
ctl
upgrade
on
a
deployment
spec
or
or
if
you,
if
you
go
and
update
the
deployment
spec
to
have
new
values,
and
then
you
do
a
cube
city
apply
on
that
spec,
it
kubernetes
some.
How
does
kubernetes
react?
Does
it?
Does
it
just
pull
things
down
and
redeploy,
or
does
it
just
change
the
parameters?
A
A
B
Okay,
okay
and
and
if
any
parameter
in
the
port
spec
changes.
This
gets
triggered
right.
A
A
B
Okay,
okay,
got
it
all
right
in
that
case,
I'm
thinking
through
the
scenario
where
someone
wants
new
credentials,
so
what
they
would
do
is
go
update
the
parts
back
to
point
to
a
different
bucket
access
request
and
that
would
trigger
the
deployment
to
redeploy
this
workload.
B
And
this
were
you
know,
provisioning
of
the
bucket
credentials
would
go
through
the
normal
life
cycle
of
cozy
and
it
would
get
provisioned
into
the
part.
So
yeah
that's
the
way
they
can
update
credentials
today.
A
Yes,
but
then
we
do
assume
that
all
the
applications
that
would
use
this
well,
that
would
use
cozy
are
built
such
that
they
can
be
easily
restarted
so
to
say,
and
don't
have
a
lot
of
state
that
gets
built
up
at
at
launch
time,
and
then
you
want
the
application
or
that
process
to
run
as
long
as
possible,
potentially
changing
the
keys.
The
the
access
keys
at
runtime.
B
A
My
point
is
today,
if
you
think
of
config
maps
and
secrets
which
you
mount,
which
you
can
mount
as
a
volume
when
the
config
map
or
the
secret
is
changed,
and
you
have
a
port
that
has
that
mounted,
then
the
files
so
to
say
that
paul
sees
on
its
filesys.
That
container
sees
on
its
file
system
will
change.
You
don't
know
exactly
when,
but
they
are
changed
in
place,
so
you
can
build
an
application
which
can,
by
itself
notice.
Oh,
my
secret.
My
credentials
file
has
changed.
A
B
Now
with
so,
if,
if
the
admin's
purpose
is
to
is
to
prevent
the
applications
from
writing
any
more
data,
but
just
allow
them
to
read
you're,
leaving
it
to
the
application
now
to
reload,
if
they
wanted
to.
A
Or
to
the
admin,
because
if
you
want
your
application
to
be
restarted,
when
the
credentials
change,
then
you
can
always
use
the
trick
of
having
a
hash
of
the
credentials
as
an
annotation
or
a
label
annotation.
I
guess
on
the
pod
spec
update
to
pulse
back
accordingly
and
everything
will
be
restarted
by
the
deployment
controller
or
just
restart
the
workload
yeah.
That's
basically
what
happens
at
that
point.
A
B
So
I'm
not
sure
that
being
said,
pretty
much
all
of
kubernetes
assumes
that
why
it
is
like
why
do
deployments
assume
that
the
only
way
to
upgrade
is
through
you
know,
restart,
and
it's
a
rolling
upgrade.
A
B
B
It's
not
it's,
not
a
special
type
of
volume.
It's
just
the
volume.
B
It's
it's
like
changing,
you
know,
say,
say
you
have
a
ebs
volume.
It's
like
it's
like
changing
that.
That
would
lead
to
a
that
would
lead
to
a
proper,
restart,
correct.
E
Are
you
sorry
for
jumping?
Are
you
guys
talking
about
taking
away
access,
yeah.
B
Let's
say
you're
taking
away
access,
we
have
one
one
model
where,
in
order
to
change
any
sort
of
access,
you
have
to
restart
the
workload
and
another
model.
Where
we're
saying
we
don't
restart
the
workload
we
go
update
some
files,
but
it's
up
to
the
actual
application
to
choose
to
use
the
new
credentials
or
not.
E
But
what
is
the
analogy?
Is
it
for
taking
access
from
a
volume?
Is
this
the
analogy
because
you're
talking
about
mounted
config
maps
but
mountain
coffin
maps,
we're
talking
about
updating
the
the
data
of
the
config
map
and
then
how
does
that
represent
inside
the
pod?
But
right
now
we're
talking
about
you
know
removing
access
to
something
yeah,
which
is
not.
B
B
Right,
nothing
changes
in
the
configmap
right;
nothing,
changes
in
the
actual
credentials
file
in
case
of
buckets
in
case
of
cozy.
If
you
were
to
update
access
nothing
changes
in
in
in
the
actual
credential
tokens
itself,
it's
the
it's
the
type
of
access
that
that
token
has
that
changes,
that's
completely
in
the
back
end.
E
A
E
E
A
So
if,
if
we
set
the
what
a
specific
access
key
key
pair
can
do
first,
it
can
read
and
write
the
application
is
running.
Now
we
decide
it
can
only
read
from
the
very
same
bucket,
then
either
we
say
we
want
to
the
application
to
restart,
but
then
afterwards
still
use
the
same
access
keys,
because
we
just
said
that
you
know
the
the
credentials
are
not
changing
or
the
application
just
keeps
running
still
consumed
or
uses
the
same
access
keys,
but
can
now
only
read
what
is
the
difference?
What
is
the
difference
between
those
two?
E
E
So,
if
that's
the
point,
then
it
could
be
done
without
cozy
all
together
right
right,
but
I
guess
the
question
is:
what
do
you
want
cause
it
to
do?
If
you
need
anything
so
with
volumes
and
and
if
you
have
a
volume
read
only
in
the
pod
spec
and
or
you
don't
have
a
read
only
when
you
change
to
read
only
you
have
to
remount
it
right.
E
You're
bypassing
at
least
the
pod.
In
that
sense,
you
don't
need
the
pod
to
be
in
the
loop.
That's
what
you're
saying
and
I
think
you're
right,
but
I'm
not
sure.
If
that's
if
we
need
to
do
something
very
special
there
I
mean.
E
The
question
is:
if
we
need
to
change
credentials
or
not
right,
one
option
is
that
the
back
end
will
update
the
for
the
same
credentials
that
now
these
credentials
have
read-only
access
to
some
to
this
bucket
right.
That's
kind
of
a
behind-the-scenes
update,
yes
right
and
the
you
know,
the
the
front
in
front
of
the
scenes
update
would
be,
let's
change
the
credentials
to
new
credentials
so
that
cosy
can
notice
that.
A
A
Can
do
it
that
way
if
an
application
is
not
designed
that
way,
then
it
is
likely
somewhat
likely
designed
to
basically
crash
when
it's
using
credentials
that
don't
work
after
which
the
port
will
be
restarted.
The
application
will
then,
when
the
pod
gets
restarted.
Well,
when
a
new
poll
gets
created,
see
the
fresh
credentials
start
with
them
and
happily
continue.
B
Otherwise
this
model
wouldn't
work,
because
if
you
didn't
say
that
let's
say
you,
you
want
the
part
to
use
new
credentials
or
new
types
of
access
and
the
application
itself
doesn't
reload.
It's
not
designed
to
reload.
It
just
works
with
it
reads
when
it
starts
up,
and
then
it
never
reads
again,
it
just
has
it
in
memory
and
just
uses
it,
which
is
what
most
applications
are
like
today.
So
if
it
continues
to
use
the
credentials
and
if
it
can
talk
to
the
object
storage
in
the
same
way,
it
always
could.
B
But
if
you
were
to
say
the
old
credentials
will
not
work
anymore,
then
you
can
reasonably
expect
the
application
to
crash
if
it
doesn't
know
how
to
reload
and
at
that
point,
when
it
when
it
does
restart
it,
when
it
restarts-
and
you
know,
reads
the
credentials.
The
next
time
it'll
have
it'll
have
the
new.
B
Yeah-
and
we
can
make
it
a
part
of
the
library
that
we
provide.
E
Know
how
exactly
it
may
do
that,
but
the
application
will
reference
the
the
bucket
the
bucket
access
request
right,
not
not
the
the
config
mac
directly.
I
think
she
means
credentials.
C
So
the
the
coming,
so
basically,
if
it's
for
the
configure
maps
or
secrets
right,
so
if
if
it
depends
on
whether
that
whether
it
is
immutable
or
mutable,
if
it's
immutable,
that
means
accumulator
will
not
be
watching,
but
if
it's
mutable,
then
people
will
be
watching
the
change.
So
it's
not
like
we
can
even
stop
that
from
happening.
So
that's
why
I'm
like.
I
don't
know
what
we
can
do
to
stop
that
if
that
can
be
changed.
B
We're
not
mounting
a
secret
directly
we're
actually
creating
a
files
based
on
the
secret,
so
as
a
response
to
create
access.
We
get
back
two
fields,
one
is
called
it's
here.
B
B
B
So
so
we
have
the
control
to
say
that
you
know
you
know
replace
this
file
or
we
can
make
it
a
memory
map
file.
We
can
do
a
lot
of
things
to
you
know
make
it
such
that
it
is.
It
has
new
credentials
if
needed
or
it
doesn't
update
on
its
own.
Whichever
way
we
want.
However,
our
question
is
now:
should
we
update
the
pod
while
it's
still
running
or
should
we
force
the
part
to
restart
and
then
update
it.
E
E
B
Yeah,
I
think
that's
fine,
but
we
can't
expect
the
application
itself
to
start
using
the
new
credentials
just
because
we
replaced
the
file
correct.
E
Side
effect
but
yeah,
but
but
perhaps
it
can
be
automated.
If
that's
the
desirable,
I
mean,
I
think
that
the
the
the
capability
of
of
you
using
a
file
within
a
pod
is
that
this
is
a
dynamic
content,
for
you
know
for
injecting
information
there
versus
an
environment
variable
which
you
can't
really
change,
and
if
you
do
change
that
the
the
intention
is
that
there
will.
There
will
be
some
some
form
of
restart.
E
That
the
environment
will
will
be
there
when
you
start
versus
files,
which
may
you
know
maybe
may
get
populated
later
on
or
changed.
B
Yeah
yeah
fair
point,
so,
okay,
so
let's
say
we
go
with
this
approach
where
we
update
the
file,
as
the
part
is
running.
How
do
we
facilitate
that
like?
How
do
we
allow
the
admin
or
user
to
say
that
hey
use
new
credentials
instead
of
hold.
B
B
I
mean
more
like
the
admin
when,
when
they
provision,
you
know
the
user,
when
they
ask
access
for
a
bucket,
they
create
a
bucket
access
request
that
points
to
bucket
access
class
and
that
ends
up
creating
a
bucket
access
object.
That
which
is
what
we
use
to
create
the
files
in
the
in
the
in
the
pod.
B
E
B
B
So
we
we
can
say
it's
the
user,
but
that
doesn't
make
much
sense
because
you
know
we're
expecting
the
user
to
not
have
you
know
to
exactly
behave
rationally
every
time,
so
you
know
you
can't
assume
malicious
users
in
this
case.
So
let's
say
admin
is
the
one
that
controls
this
and
the
admin
decides
that
they
want
to.
They
want
to
change
the
type
of
access
the
workload
has.
B
E
You
can
make
anything
mutable
in
the
pod
but
like
if
you
have
volumes
currently
volumes
are
not
mutable
in
the
pods,
so
I
would
expect
at
least
right
now
that
similarly,
the
the
bucket
access
will
be
immutable,
at
least
for
compatibility,
not
sure
if
it's
forever,
but
so,
if
you
created
a
pod,
that's
you're
you're
wired
to
some
bucket
access
request,
and
if
somebody
wants
to
you
know,
tear
down
this
workload
and
reconfigure
it
either
it's
an
admin
that
goes
directly
to
the
bucket
access
and
makes
changes.
A
A
Well,
if
there's
a
new
bucket
access
request-
and
indeed
there
will
likely
be
a
new
fault-
and
that
seems
kind
of
fine,
because
then
this
is
initiated
by
the
user
who
owns
the
application
in
the
first
place.
So
when
there's
like
down
time
to
be
expected
for
whatever
reason,
then
the
user
can
plan
this
accordingly,.
A
Yes,
but
in
case
it's
an
admin
who
wants
to
make
changes
for
whatever
reason
to
the
bucket
access.
Then
I
should
not
directly
impact
the
running
application,
because
the
admin
doesn't
own
that
one.
It
doesn't
manage
its
life
cycle,
but
it
could
make
changes
to
the
bucket
access,
which
can
then
be
reflected
to
the
backing
to
the
backing
object,
source
system.
B
Yeah,
I
could
see
this
being
an
actual
use
case.
Let's
say
if
there
is
an
application
that
uses
like
say,
10,
20,
different
buckets
and
you
know
different
users
have
on
in
that
one
application.
Different
users
have
different
accesses
to
the
same
bucket.
Then
you
might
want
to
revoke
some
users.
Privileges
rob
who
used
to
you
know
be
a
part.
You
know
used
to
be
at
the
meetings
earlier.
B
He
talked
about
workload
like
that.
He
he
was
the
admin
for
quad
or
io,
and
when
engineers
left-
or
you
know,
there
was
an
internal
red
hat
queer.io
apparently,
and
when
engineers
left
the
team
he
would
have
to
revoke
access
specifically
for
those
engineers
or
whatever
buckets
were
created
for
that
engineer,
but
not
not
tear
down
the
application
itself.
A
E
Where
is
it
in
the
bucket
access,
I
mean
so
that
I
understand,
if,
if
the
admin
wants
to
make
any
changes,
what
what
can
be
modified
right
here,
the
well
just
replace
it.
The
the
secret
name.
B
Well,
if
they
change
the
policy
actions
config
map
data,
then
we
know
the
access
itself
has
changed.
So
we'll
have
to
go
through
the
life
cycle
of
updating
the
created
secret
with
the
new
with
the
new.
Well,
maybe
we
could
keep
the
secret
as
it
is,
but
just
update
the
policy
actions
which,
which
is
what
states,
what
kind
of
access
the
user
gets.
The
account
gets.
B
B
Yeah,
it's
originally
a
config
map
and
then
it
gets
copied
over
to
the
bucket
axis,
because
the
idea
originally
was
this
is
not
mutable.
I
mean
we
can
still
say
that
it's
not
mutable
this
way
and
we
can
say
when
we,
when
we
end
up
adding
fields
in
the
pod
for
buckets
which
are
not
volumes,
but
you
know
actual
fields.
B
E
B
Yeah
I'll
I'll
show
you
I'll
just
open
up
aws
aws
s3.
B
Yeah
yeah,
it's
a
json,
jason,
yeah,
yeah,
yeah,
bucket
policy.
Examples.
B
B
B
E
B
Well
for
the
admin
itself
right
now
it
looks
like
this,
so
so
the
only
way
that
you
know
the
way
we
specify
the
access
policy
today
is
through
the
bucket
class,
so
bucket
class
has
a
field
for
the
config
map
that
points
to
the
policy.
Now,
once
a
bucket
access
is
provisioned
from
the
bucket
class.
This
policy
is
copied
over
to
the
bucket
access,
but
when
it's
copied
over,
it's
not
appointed
to
the
conflict
map
anymore,
it's
the
actual
data.
You
know
escaped
string
right,
so
it's
it's
copied
right.
So
we
have
a
clone.
E
Of
that
class
basically
yeah,
that's
fine
and
then,
if
I
do
want
to
make
that
mutable
for
for
whatever
reason,
because
I
want
to
to
make
an
actual
update
to
my
to
my
you
know-
access
credentials
right.
So
my
to
my
credential
actually,
but
basically
to
my
account,
then
I
would
go
and
make
an
update
to
this
field
and
expect
the
reconciliation
path
to
go
through
the
driver
and
update
the
the
account
policy
right.
Basically,.
B
Yeah
we
could
do
that.
We
could
actually
do
that,
but
the
admin
works
flow
itself.
They
would
have
to
create
an
escape
string
with
the
new
policy
actions
and
then
set
it,
which
is
that.
B
B
A
Yeah,
but
why
is
it
a
config
map
in
the
bucket.
B
A
B
I
need
to
I
need
to
check
with
this
again,
but
I
think
we
have
a
specific
key.
We
look
for
jeff.
Can
you
remind
me:
why
isn't
this
a
string
already
if
we
only.
A
No,
I'm
just
saying
that
there
is
this
separation
between
when
you're
doing
it
in
the
bucket
access
class.
Then
things
may
somewhat
be
fixed
up
for
you,
but
if
you're
acting
on
the
book
of
texas,
then
you're
on
your
own,
why
do
we
not
use
a
string
in
the
two
cases
because
to
me
now
it's
a
bit
weird
so
so.
E
B
A
Yeah,
yes,
I
don't
really
see
why
this
configmap
needs
to
be
in
between.
A
B
D
Yeah,
we
could
certainly
do
that.
I
think
the
reason
is,
as
you
explain
says,
that
we
just
thought
for
escaping
and
more
complex
values
for
the
access
policy.
The
configmat
might
be
nicer,
but
it
does
add
an
extra
resource
in
the
equation
and
brings
up
what
does
mutability
mean
you
know.
So
if
you
eliminate
config
map,
then
we
have
contained
it
better.
B
Right
so,
okay,
one
more
question,
then:
in
the
bucket
access
spec,
do
we
point
to
the
bucket
access
class
anywhere?
B
B
B
Okay,
great
so
so
yeah.
If
this
was
basics
for
encoded
string,
then
you
know
you
just
update
the
basics,
one
coded
string
here
and
we
should
be
good
to
go.
We
should
be
able
to
use
that
to
create
new
credentials
and
then
the
part
gets
to
use
the
new
credentials.
We
update
the
file
live
correct.
That's
what
we
said
right.
E
Basically,
this
is
the
the
the
main
access
class
right
that
that's
what
specifies
the
real
access.
B
Right
right,
this
is
the
main
access,
yes
or
actually.
B
Yeah.
I
like
it,
anyone
any
other
thoughts.
B
D
Yeah
easier
to
create
more
readable
human,
readable
but
yeah
a
base64
encoded
value
won't
be
readable,
but
maybe
we
don't
have
to
base
64
encoded,
but
then
we
have
to
deal
with
the
escaping.
B
B
E
That
the
the
benefit
of
of
of
making
the
first
level
visible
is
that
it
does
provide
some
visibility
rather
than
having
you
know
the
entire
string.
So
so
it
can.
You
show
back
the
the
aws
policy
for
a
second
just
that
we
look
at
the
same
thing,
maybe
well
yeah.
In
this
case,
it
won't
won't,
do
much
right.
The
version
and
statement
will
be.
The
top
level
doesn't
doesn't
make
much
true
yeah.
B
Well,
I
mean
you
could
say,
you'll
put
this
in,
but
not
at
that
point
we'll
do
conditional
processing
and
that's
not
that's
not
going
to
work
right,
yeah
just
basically
encode
it
and
if
they
want
to-
and
you
know
in
cube
ctl
describe,
we
could
we
could
decode
it
and
show
it.
You
know
if
they
really
wanted
to
see.
E
B
E
You
know
what
let
me
ask
you
something:
the
base64
encoding
is
is
just
a
way
of
making
it
opaque,
but
but
if
you,
if
you
just
drop
that
and
you
keep
it
just
an
opaque
string
without
encoding
right,
you
can
still
encode
in
json
any
string.
It's
json
will
that's
what
json
does
right.
Jason
can
encode
any
string
as
a
value.
That's
perfectly
fine!
You
don't
have
to
make
any
effort
for
that
for
jason.
To
do
that.
B
Yeah
I
mean
basic
civil
encoding
is.
E
E
E
B
E
So
when
you
mean
cube
ctl,
you
mean
when
I
write
a
yaml
right
and
I
I
want
to
encode
a
string
into
it.
I
can
I
can
use
yaml
tools
for
that
right
and
if
I
use
json,
I
need
to
use
json
tools
for
that,
but
but
there's
ways
to
encode
strings
into
like
complete
strings
into
yaml,
for
example.
Without
any
need,
for
you
know
too
many
hoops,
you
just
put
a
pipe
character
and
you
know
you
go
one
line
below
and
that's
it
you
can
paste
in
whatever
you
want.
E
B
E
E
B
B
Yeah
yeah
I
mean
I
prefer
base64,
but
but
you're
right
technically
you
don't
have
to
yeah.
It
would
just
work.
I
mean,
assuming
you
know
how
to
write.
Json.
A
A
B
B
I
mean
we
will
have
to
know
how
to
interpret
it
too,
because
you
know
if
you're
doing
something
like
cuba,
city
you'll
describe.
I
don't
want
to
just
throw
a
string
out
there.
That's
that's
not
easy
to
understand.
I
would
rather
like
I
really
don't
care
how
it's
shown
here,
but
I
care
more
about
like
how
it
is
presented
in
something
like
you
feel
described.
B
B
E
B
B
E
B
C
Yeah
just
haven't
seen
this
temp
double
pattern.
Oh
not
sure.
B
That's
fair,
I
mean.
B
A
And
value
in
it-
and
we
don't
mention
the
key-
you
have
the
same
with
config
maps,
where
the
value
can
only
be
a
string
anyway,.
B
B
B
The
whole
idea
behind
this
is
thing:
if
you,
if
you
want
to
be
able
to
update
credentials,
update
access
for
for
a
running
workload,
you
know
for
a
bucket
in
a
running
workload.
Then
how
do
you
do
it
and
based
on
the
entire
discussion,
it
seems
like
the
best
way
to
make
it
happen
is
if
this
field
was
not
a
pointer
to
a
config
map,
and
rather
it
was
just
a
string.
B
C
C
B
Yeah,
and
also
one
more
advantage
I
can
think
of,
is
you
know
there
is
a
possibility
here
of
deleting
the
config
map,
like
you
create
the
bucket
access
class,
but
before
the
pro
you
know
the
controller
reads
the
config
map.
Someone
goes
and
deletes
it.
So
you
know
it's
possible
like
it
when
they
got
through
that
mission
controller,
but
it
it
didn't
get
processed.
B
I
mean
it's
a
weird
case
and
it's
it's
a
user
error
kind
of
scenario.
What
can
happen?
I
don't
know
if
that's
even
meaningful.
C
Yeah
only
yeah-
I
probably
need
to
think
about
this
and
discuss
about
this
again.
B
Right,
I
think
so
I
think
that's
that's
important,
so
let's
bring
it
up
again
on
thursday,
because
yeah
you
know
like
I
was
saying.
I
think
everyone
needs
to
be
comfortable
with
this
before
we
go
forward,
but
but
this
doesn't,
you
know,
factor
into
our
api
review
or
cap
or
everything
else
that
we've
been
doing.
This
is
like
an
additional
feature.
We're
thinking
about
this
can
be
done.
B
You
know
it's,
it's
not
it's
not
a
stopper
or
blocker
in
any
sense,
so
we're
almost
out
of
time
we're
out
of
time
already
so
quickly.
I
want
to
say
a
few
things.
One
is
please
review
the
cap
I'll
ask
jeff
to
post
a
link
to
the
the
kep
pr
in
six
storage,
cozy
channel
yeah.
I
would
like
everyone
to
take
a
look
because
it's
a
summary
of
all
the
discussions
we've
had
and
you
might
have
missed
some
discussions
or
you
know
we
might
have
missed
some
points
in
the
cap.
B
We
need
your
feedback
on
it,
so
that
we
can.
We
can
speed
up
the
api
review
process.
The
other
is
that's
one
part
the
other
is
you
know.
I
would
like
all
of
you
to
speak
more
about
cozy,
wherever
you
can
so,
for
instance,
if
you're
going
to
a
meet-up,
if
you
want
to
give
a
talk,
please
apply
for
it.
Cubecon
is
coming
up.
The
the
the
call
for
proposals
is
open
right
now.
B
So
please,
you
know
if
you're
considering
you
know
speaking
there,
I
would
encourage
you
to
speak
about
cozy.
If
you
do,
you
know
decide
to
apply
talk
to
me
once
because
I
want
to
make
sure
two
people
aren't
applying
for
the
same
thing.
That's
the
one
reason
and
other
than
that,
if
you
want
to
tweet
about
it,
write
blogs
about
it
you're
all
you
know,
welcome
to
do
it
and-
and
I
would
like
someone
to
you-
know-
write
a
blog
in
kubernetes.io
about
cozy.
B
So
whoever
is
willing
and
interested
now
ping
me
directly
or
on
sixth
or
is
cozy
yeah,
that's
about
it.
We
will
talk
again
on
thursday.
Continue.
This
discussion.