►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket Standup Meeting - 14 December 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
So
for
those
of
you
who
couldn't
make
it
last
week,
I
want
to
quickly
go
over
the
changes
that
we
brought
about,
since
this
is
the
last
week
before
we
end
for
this
year.
I
wanted
to
make
sure
we
leave
the
project
on
a
positive
note
and
to
that
end
we
started
we,
we
started
moving
towards
a
a
goal
that
is
easily
achievable,
which
is
changing
the
way
we
do
the
project
management.
B
Until
this
point,
we
were
tracking
the
project,
as
things
came
along
until
the
cap
was
merged,
kept
was
merged
early
last
month
or
so,
and
after
that,
we've
been
looking
into
using
more
standard
practices
for
managing
the
project,
so
we've
moved
to
using
github
projects
under
the
kubernetes
six
organization.
There's
a
project
named
contain
object,
storage,
where
we're
tracking
all
the
issues,
milestones
and
tasks
that
are
being
worked
on
this.
B
Help
others
easily
on
board
to
the
to
our
project
and
and
quickly
start
contributing.
We
we
did
this
last
tuesday
and
after
that,
we've
actually
got
two
new
contributors
contributors
that
we
haven't
spoken
to.
I
haven't
seen
the
meetings
either,
but
they
were
able
to
start
helping
out.
B
Yeah
manjana
k,
so
this
form
of
project
management
is
definitely
working
and
I
want
to
quickly
go
over
where
we
are
at
in
terms
of
what
we
planned
for
this
week
so
between
at
the
beginning
of
last
week,
and
now
for
each
of
the
repositories,
you
can
see
the
number
of
pull
requests
made
and
pull
requests
merged.
B
I'm
using
pull
requests
as
the
metric
here,
because
the
in
generally
in
open
source,
the
the
biggest
bottleneck,
is
going
to
be
the
review
process
even
more
than
writing
code
and
and
adding
tests,
and
also
the
response
to
the
review
process
was
going
to
be
slow.
So
having
pull
requests
as
a
metric,
especially
the
number
of
pull
requests
merged,
is,
is
a
good
way
to
tell
how
the
progress
is
happening.
So
this
is
what
the
statistics
look
like
in
comparison
to.
B
B
Here
are
the
goals
we
laid
out.
We
want
to
have
very
basic
documentation,
something
that
people
can
just
you
know
just
updated
readme.md,
which
the
community
has
contributed
to
us
and
we've
got
it
now.
They
just
have
to
be
merged
by
our
ci.
B
Here
shing
I
had
a
question
for
you,
so
I
was
reviewing
this
pull
request
in
the
spec
repo.
There
is
spec
yeah
here
and
the
the
change
looks
good
and
I
know
we
talked
about
having
having
privileges
given
you
know
in
a
specific
way
for
the
spec
repo.
However,
it's
good
that
I
have
merged
requests.
I
just
wanted
to
be
upfront
about
it
understand
if
this
is
oversight
or
if
this
is
intended.
D
B
D
B
Can
hear
me
we
can
still
hear
you
yeah,
so
I'll
I'll
follow
up
outside
outside
of
this
meeting.
Okay,
so
the
other
thing
we
had
in
mind
was
setting
up
container
repositories.
B
C
Yeah
for
the
image
repositories
we
discussed
last
week
that
we
once
we
cut
a
release,
it
should
automatically
persist.
Until
then,
we
are
going
to
use
the
the
key
dot
io.
C
I
can
add
that
to
to
one
of
the
readmes,
I
guess
I
I
think
we
can
like
the
current
pr
that
is
merged.
We
should
have
the
general
information
under
the
spec
reaper
I
can.
I
can
update
it
okay,
so
now
I
can
post
that
where
it
is
for
now.
I
think
I
posted
it
last
time.
So,
okay.
B
So
at
this
point,
before
we
get
into
naming,
I
want
to
quickly
get
an
update
from
everyone.
Who's
been
working
on
the
different
components.
D
Yeah,
I'm
here
sid.
B
Hey,
do
you
want
to
give
a
quick
update
on
the
things
you
made
last
week.
D
Yeah,
so
we
got
the
we
migrated.
The
customized
template
got
got
those
merged.
There's
an
issue
open
on
the
changes
that
we
need
to
do
for
that
and
nicholas
has
added
more
details.
So
looking
at
that
and
I'll
update
customize
based
on
that.
B
Okay,
so
there
are
so
based
on
nicholas's
comments.
We
need
to
make
some
changes
to
customize
yeah.
D
Yeah
we
we,
we
need
to
kind
of
do
it.
The
right
way,
have
the
overlays
and
have
have
customized
work
in
different
environments,
so
yeah
it's
like
next
step.
Okay,.
B
Nicholas
so
hey,
so
you
said:
you'd
have
some
time
to
help
out
this
week.
Right,
yep,
yeah
plea,
please
coordinate
with
pages.
I
can
introduce
the
two
of
you
on
slack.
You
know
to
finish
this
customized
part
that'll
be
okay.
Thank
you.
B
F
Right,
no,
I
just
been
reviewing.
I
did
review
a
ket
pr.
I
think
we
need
to
create
another
kept
pr
as
we're
learning.
It
might
be
a
bit
ambiguous
how
cozy
works
in
certain
situations.
We
learn
this
as
we're
as
the
team's
writing
code
and
I
think
we
need
to
to
make
sure
it's
defined
in
the
cap
as
well.
F
I
think
yeah
I
want
to
touch
base
with
rob,
but
yeah
I'm
happy
to
create
the
pr
for
the
cap.
I
just
want
to
get
some
more
information.
First
got
it
got
it.
What
was
the
ambiguity?
F
You
know?
That's
what
I'm
trying
to
remember
now.
I
have
to
go
back
to
last
week
and
look
at
our
our
slacking
there's
something
we
both.
You
know
several
people
sort
of
did
a
thumb
on
the
dialogue
that
yeah.
This
was
something
that
should
be
done,
but
I've
got
to
go
back
and
refresh
my
memory
now.
Yeah
no
worries
is
christian
on
the
call.
H
Yeah
sure
so
my
pr
with
some
of
the
initial
boilerplate
for
the
csi
adapter
was
opened
and
merged
in
last
week,
and
so
now
I'm
just
working
on
some
further
prs
to
get
the
rest
of
the
code
moved
over
from
the
container
object,
storage
interface
or
to
the
kubernetes
repo.
B
That
so
to
everyone
in
the
community,
all
of
these
this
activity
is
open
and
available
for
everyone
to
see
in
the
individual
repositories,
you
can
go
to
github.com
kubernetes.
B
6
go
under
projects
and
look
here,
and
you
should
be
able
to
see
the
different
things
that
we're
working
on
everyone's
review
is
welcome,
and
similarly,
everyone's
contribution
is
also
welcome
here.
Please,
if
you
get
a
chance,
please
look
at
some
of
the
prs
and
and
leave
your
reviews
there.
It
will
help
you
to
follow
the
project
and
also,
you
know,
will
improve
the
project
and,
at
the
same
time,
it
will
set
you
up
to
contribute
in
the
future.
If
you
haven't
already
done
so.
B
So
so
there's
two
things
left
that
I
want
to
talk
about.
One
is:
I
want
to
revisit
the
naming
changes
that
we
talked
about
last
week
and
two
is
we
have
someone
from
pure
storage
here?
I
believe
adam
is
that
right.
B
Hi
adam
adam,
reached
out
to
us
on
our
slack
channel
adam.
Do
you
wanna
give
us
before
I
go
into
naming?
I
I
think
it's
it's
good
to
have
you
introduce
yourself
and
also
talk
about
the
questions.
G
You
had
sure
so
yeah
my
name
is
adam,
I'm
from
pure
storage,
basically
someone
reached
out
to
me
and
wanted
me
to
give
a
summary
presentation
of
what
cozy
is
to
one
of
our
v
teams.
So
I
just
threw
a
presentation
together
and
wanted
to
just
do.
Maybe
a
quick
fact
check
to
see
if
I
missed
anything
obvious.
B
So
he
had
one
specific
question
and
it
also
raised
a
more
important
issue,
which
is
documentation
so
give
me
one
second,
okay.
So
when
nicholas
raised
an
issue
about
three
weeks
ago
how
to
get
onboarded,
we
we
we
understood
that
we
needed
to
improve
project
management,
and
now,
when
adam
came
up
and
asked
how
cozy
works,
we
realized
that
we
should
improve
documentation
and
we've
already
started
work
on
that
and
we're
definitely
on
the
right
path.
B
So,
as
a
part
of
today's
meeting,
I
want
to
quickly
go
over
how
credentials
are
passed
into
workloads,
which
is
the
specific
question
that
adam
had
is.
Am
I
right
adam.
B
Okay,
so
we'll
quickly
go
over
it
and
it'll
also
be
a
refresher
for
others,
and
if
I've
missed
anything,
feel
free
to
correct
me,
okay,
so
I've
called
it
credential
minting.
B
B
When
you
have
multiple
buckets
used
by
a
single
workload,
a
single
environment
variable
would
not
do,
and
you
could
say
that
you'll
have
multiple
environment
variables.
However,
it
becomes
cumbersome
once
we
look
into
what
kind
of
information
needs
to
be
passed
in,
so
for
a
workload
to
access
a
bucket.
B
The
workload
needs
information
about
the
name
of
the
bucket.
The
end
point
for
the
bucket,
the
http,
https
endpoint
credentials
and
any
other
information,
that's
pertinent
to
talking
to
the
backend.
B
So
in
case
of
s3,
for
we
we
need
to
know
the
region,
we
need
to
know
the
signature
version
and
so
on
and
so
forth
for
the
other
providers.
B
B
So
in
the
pod
spec,
the
user
would
create
a
volume
of
our
type,
we'll
have
to
come
up
with
a
name
for
that.
But
let's
just
call
it
object,
storage
interface
and
one
that
volume
would
have
to
be
mounted
at
a
particular
location,
which
is
what
we
would
use
as
the
bucket
directory
under
the
bucket
directory.
We'll
have
credentials.
That
is
the
credentials
needed
to
access
the
bucket
a
file
called
bucket.json
I'll
go
into
what
it
includes
and
then
a
bunch
of
certs.
B
G
Somewhat
yes,
so
I
guess
where
more
I'm
coming
from
so
I'll
admit,
I'm
not
a
common
user
of
like
buckets
and
object
storage,
but
from
what
I've
seen
of
apps
that
do
use
it.
They
usually
have
them
passed
in
either
as
environment
variables
or
as
part
of
a
configurable.
G
G
G
B
So
here
is
what
here's:
what
happens
if
there
are
multiple
buckets
for
the
same
workload,
each
bucket
would
get
its
own
directory
bucket
directory
and
you'd
have
the
same
files
put
into
one
each
of
the
bucket
directories.
B
I
mean
you'd,
have
the
same
kinds
of
files
put
into
each
of
the
bucket
directory
for
the
respective
buckets
okay,
we'll
go
into
what
bucket.json
includes,
so
the
bucket.json
is
meant
to
serve
as
an
api
between
the
work
that
we're
doing
and
the
workload
so
the
way
we've
defined
it
right
now
is
the
same
field.
So
so
the
bucket
class
and
the
bucket
resource
has
a
protocol
field,
and
the
contents
of
the
protocol
field
is
what
will
be
put
into
the
bucket.json
as
well.
B
B
And
we
don't
have
to
deal
with
updates
during
the
life
cycle
of
the
bucket
itself.
Now
each
protocol
will
have
its
own
set
of
fields.
So
I've
taken
an
example
of
s3.
Here
we
have
a
signature
version,
endpoint
region
bucket
name
for
s3.
B
So
that's
what
the
bucket
well.
I've
shown
a
yaml
file
here,
but
the
equivalent
json
was
what
you
would
use.
Call
it
bucket.ammo.
B
Yeah,
that's
about
it
for
the
credential
provisioning.
Did
anyone
have
any
questions
so
far.
E
Yes,
we've
been
going
over
this
quite
a
bit,
so
maybe
I
lost
track
at
some
point.
Weren't.
We
also
going
to
expose
things
using
the
sdk
standards
files,
yeah.
B
All
right,
so
the
current
name
is
container
object.
Storage
interface.
I
brought
up
last
week
that
the
work
that
we're
doing
unlike
csi
or
container
storage
interface
or
cni
container
network
interface,
we
do
not
integrate
with
a
container
we
integrate
at
two
levels.
One
is
with
the
application
using
the
bucket.json
and
and
the
associated
files
and
other
with
kubernetes
itself.
B
Where
we
integrate
using
the
grpc
api,
what
we're
doing
is
has
little
to
do
with
containers
actually
and
it's
more
of
just
an
object,
storage
interface
and
additionally,
the
name
container,
object.
Storage
interface,
you
know
ends
up
the
acronym
if
it
ends
up
being
c-o-s-I
or
cozy.
Cosy
sounds.
B
So
I've
been
thinking
about
proposing
or
we
need
to
actually
work
with
the
name
that
is
more
accurate,
firstly
and-
and
my
inclination
right
now
is
to
go
towards
object,
storage
interface.
B
I
know
what
we
spoke
as
as
we
left
off
last
week.
We
were
leaning
towards
this,
and
I
believe
there
are
also
some
points
against
this,
so
I
would
like
to
hear
them
out
hear
thoughts
on
what
do
you
think
about
this
name
and
see
if
we
can
make
a
decision
today
or
by
the
end
of
the
week.
I
Object:
storage
interface
instead
of
cozy
container
object.
Storage
is
this
for
the
for
the
rpc.
I
Okay,
that
that's
my
two
senses:
okay,.
I
The
rpc
interface,
okay,
so
which
could
be
objects
that
doesn't
take
place.
J
I
mean
for
the
top
part.
Well
I
guess
I
I
don't
remember
if
you
were
actually
at
the
meeting
where
this
part
of
it
was
covered,
said
that
we
were
saying
that,
like
the
kubernetes
part
of
it,
it
would
be
ideal
if
it
wasn't
viewed
as
separate
from
kubernetes.
But
just
this
is
the
kubernetes
object,
storage,
interface.
J
And
and
to
brand
it
as
such,
so
that
it's
viewed
as
you
know,
this
is
just
the
way
it
is
done
in
kubernetes
and
we
would
want
buy-in
from
the
rest
of
sig
storage,
but
I
can't
imagine
any
resistance
in
that
area,
but
but
then
the
once
you
get
down
to
the
rpc
interface
there
is
this
belief
that
you
know
it
will
be
useful
outside
of
kubernetes.
Therefore,.
I
J
B
Objection
is
it's,
it's
a
it's
there's
already
an
osi
right.
B
I
Do
we
see
if
we
search
for
kubernetes
osi
the
open,
open
source
initiative,
I
think,
is
the
big
one.
A
B
B
I
think
I
think
osi
is
being
redefined.
I
mean
it's
getting
kind
of
overused
almost.
Is
that
what
you're
saying.
B
Because
this
is
a
whole
new
definition
of
what
say
right
here,
the
first
article
and
we
know
the
standard
osi,
which
is
from
operating
system
from
standpoint
and,
I
guess,
open
source
initiative.
I
haven't
seen
that
open
source
osi,
open
source
initiatives.
J
B
You
know
overlapping
with
someone
else's.
We
just
have
to
make
sure
it's
different
enough
that
it
makes
sense
to
reuse
it.
You
know.
J
B
No,
in
addition
also,
you
know
it
should
be
easy
to
say
and
express
csi
got
that
right
with,
especially
with
consumers
of
csi.
That
is
when
I,
when
I
speak
with
customers
of
min
io
managers
and
and
directors,
and
vice
presidents
of
different
enterprises,
they
ask:
do
you
have
a
csi
driver?
B
I
almost
never
hear
if
you
have
an
oci
compliant
runtime,
so
the
naming
matters
I
think
osi
is
a
good
pick.
I'm
open
to
new
ideas,
different
ideas
too,
I
think
kubernetes
osi
is,
is
good
too.
I
I
really
do
like
that.
J
B
J
J
I
I
know
it
is,
and
I
I
admit
that
I'm
just
saying
that
it's
close
enough
and
it
has
all
the
other
benefits-
that
a
four
or
four
letter
acronym
is
better
than
three
and
you
can't
use
kubernetes
down
this
layer
because
the
rpc
layer
is
not
intended
to
be
tied
to
kubernetes.
B
J
B
E
E
E
B
J
So
so
that
that's
not
actually
true,
I
think
if
you
read
the
the
kubernetes
or
the
csi
spec,
they
do
refer
to
the
thing
called
the
co,
the
so-called
container
orchestrator.
But
then,
when
they
talk
about,
you
know,
publishing
volumes
and
staging
volumes
and
and
consuming
volumes.
They're,
always
talking
about
like
a
workload
consuming
a
volume
and
they're
talking
about
a
mount
point
or
a
device
they're
not
talking
about
pods
or
containers
or
name
spaces.
It's
it's
at
the
you
know.
B
B
Right
right
and
but
but
the
definition
of
a
container
orchestrator
is
very
minimal.
In
that
case,
all
they
expect
you
to
do
is
have
a
mechanism
to
call
the
appropriate
grpc
api
is
all
is
required
of
the
container
orchestrator.
J
B
A
I
don't
like
is.
F
B
C
J
I
J
B
Object:
styles,
interface:
I'm
I'm
still
for
just
object,
storage
interface.
We
don't
even
have
to
abbreviate,
we
don't
even
have
to
call
it
osa.
B
F
You
know:
there's
container
foundations,
container
storage
container,
no,
it's
cloud
native
foundation.
Containerization
is
a
popular
activity.
These
days.
B
Yes,
I
hear
you
okay,
I
I
agree
jeff
to
yeah
containerization.
Well,
it's
come
and
gone
now,
but
yeah
it
is.
It
is
the
container
words
I
would
say
are
over
right
now.
It's
kubernetes
adoption,
that's
going
on
back
in
2015,
you
know
rocket
had
just
come
out
and
there
was
no
oci
at
that
point
and
and
docker
was
raining
big
back
then
I
would
say:
containerization
was
big
right
now,
though
it's
it's.
People
are
moving
to
kubernetes
and
I
think
I
think
kubernetes
objects.
K
Sid,
can
I
add
one
thought
I
think
I
hear
what
you're
trying
to
do
is
break
the
pattern
right
mostly,
but
to
make
it
more
unique
in
that
sense,
and
I
think
that's
kind
of
the
the
question
is:
is
there
and
more
appreciation
around
the
people
we're
targeting
with
you
know
more
more
of
the
same
pattern
for
this.
You
know
and
keeping
the
pattern,
and
you
know
making
it
easy
to
find
or
expect
what
to
find
right,
both
in
naming
and
terms
terminology
or
kind
of
looking
at
it
for
a
more
gen.
K
I
think
what
you're
trying
to
do
is
suggest
something
that
sounds
a
little
bit
more
generic
sounds
a
little
bit
more.
You
know
holistic,
and
I
I
to
me
I
I
favor
the
first
I
think
just
because
I
it's
not
that
we're
not
trying
to
create
something
very
unique,
but
I'm
not
sure
if
just
breaking
the
name
pattern
really
makes
such
a
big
difference
around
it
right.
I
think
yeah.
G
E
Plus,
what
some
things
I
saw
or
heard
from
the
heard
from
the
field
is
that
customers
are
looking
for
container
containerized
object,
storage
for
containers
all
that
kind
of
stuff.
So,
even
though,
technically
we
may
not
be
tied
to
containers
from
a
marketing
point
of
view,
you'll
have
a
it'll
be
easier
to
sell.
When
you
say
this
thing
is
an
interface
for
object,
storage
in
container
environments,
because
people
are
looking
for
it.
Whether
there
is
technical
merit
in
it
or
not,
is
a
different
question,
but.
B
I
would
I
would
so
so
what
what
people
are
looking
for
on
in
the
in
the
field
is,
is
some
way
to
utilize
object,
storage,
natively
in
kubernetes,
not
not
in
containers,
and
they
specifically
asked
this
question.
You
know,
as
I'm
sure,
we're
all
in
the
same
field.
B
What
they
ask
for
is
first
questions
they
ask
for
is:
does
your
object,
storage
work
with
csi,
so
people
are
misguided
and
they
believe
the
way
object.
Storage
interacts
with
kubernetes
is
through
csi.
Now,
if
we
said
no,
you
have
to
use
something
called
cosi.
B
E
Because
most
customers,
kubernetes
environment,
comes
with
a
cni
system
integrated,
it's
not
something,
they
see,
it's
not
something
they
need
to
integrate
with
the
rest
of
their
environment.
What
if
they
have
a
kubernetes
cluster
which
comes
with
the
cni
plug-in,
and
they
have
an
external
storage
system,
they
do
need
to
integrate.
B
They
still
need
to
choose,
and
most
people
just
say
is
that
a
calico,
you
know
that's
that's
kind
of
how
it
goes
and
and
the
rest
of
the
networking
vendors
unless
they're
bundled
in
are
lost.
B
I
think
I
think,
for
all
of
us.
Every
one
of
the
vendors
here
having
having
an
easy
to
you
know,
relate
easy
to
say.
Kind
of
abbreviation
will
really
help.
B
Rather
than
rather
than
especially,
not
not
cozy,
because
the.
J
How
does
hold
on
how
does
how
does
changing
it
from
cozy
to
osi
help
with
this
particular
concern?
If
people
are
asking
like,
does
it
do
csi
and
we're
like
you're
asking
the
wrong
question?
How
does
how
does
just
reducing
the
acronym
length
by
one
improve
that
situation?
I'm
not
following
that
step.
B
Yeah,
so
no
that's
a
good
question,
so
so
we're
not
just
simply
just
reducing
the
acronym
length
by
one
we're
saying
the
way
to
integrate
with
object,
storage
is
a
completely
different
way
and
saying
cosi,
or
or
instead
of
csi
or
cozy
you'll
have
to
explain
that
as
cosi,
it's
not
different
enough.
It
literally
feels.
D
You
know,
I
think,
scores
courses.
B
Yeah
yeah
koza
is
definitely
an
option
for
the
for
people
who
write
anyway.
So
this
is
a
discussion
we
don't
we
don't
if
we
can.
K
Can
I
also
ask
you,
maybe
just
to
clarify
so
you
feel
like
making
it
more
generic
reduces
the
the
overall
vagueness
of
it,
because
to
me
that
doesn't.
F
J
J
From
because
that's
actually
one
of
my
concerns
with
just
calling
it
osi
is
it,
it
presumes
that
this
is
the
only
object,
storage
interface
that
will
ever
exist
and
that
we're
sort
of
staking
our
flag
our
flag
on
you,
know,
object
storage
for
all
time
by
not
qualifying
in
any
way
saying
object.
Storage
interface
period
is
a
very
bold
claim
to
make,
and
I
don't
know.
K
B
No-
and
another
thing
is,
I
think
I
think
having
a
three
letter
is
also
important.
I
think
see
naming
is
very
important,
because
when
we,
when
we
get
it
right,
you
don't
really
notice
much,
but
when
you
get
it
wrong,
you
know
it's
it's
even
hard
to
pinpoint
why
something
is
going
wrong
like
are.
There
are
some
terrible
names
and,
and
simply
because
of
that
things
don't
get
adopted.
B
K
B
Right,
let's
change
that
we
can't
call
ourselves
s3i,
though.
K
B
B
I'm
open
to
new
suggestions.
I
still
want
to
really
explore
a
better
name
for
what
we're
doing,
and
we
should
we
should,
if
you're
changing
the
name,
we
should
do
it
now,
rather
than
later,
where
the
changes
will
be
more
complex
and
will
require
more
effort.
K
You
know
it
still
makes
sense
to
be
named
cozy
I
mean
you
know
if
you
just
name
things,
but
you
know
I
I
to
me
it
maybe
sounds
like
it's.
Unless
we
have
a
better
name
to
it
like
saying
we're,
not
dealing
with
object,
storage,
now
we're
dealing
with
buckets
and
suddenly
buckets
is
a
you
know
is
a
term
that
everybody
can
recognize
exactly
what
it
means
and
why
we
are
saying
that
we
are,
you
know,
exposing
buckets
rather
than
you
know,
specific.
B
B
K
Well,
yeah,
it's
not
it's
not
really
looking
at
the
same,
so
I
think
we're
really
trying
to
generalize
like
google
is
a
you
know,
is
the
most
specific
naming
kind
of
thing
and
right
here
we're
trying
to
say
it's
an
interface
to
something
it's
something
we
are
generalizing
something.
So
it's
not
it's
not
about.
You
know,
picking
the.
B
Acronym
is
needed,
cozy.
I
think
it's
a
good
name
for
sure.
So
it's
a
great
working
name.
We
chose
it
just
for
the
convenience
when
we
started
and
and
even
the
repository
names
right
now
are
completely
expanded
versions
of
the
word.
Of
course,
you
know
container
objects,
dash
storage,
dash
interface,
csi
repositories
are
named,
csi
dash,
something
I
think
I.
J
Think
well,
the
the
side
car
repos
are,
the
actual
repo
is
container
dash.
Storage
dash
interface
spelled
out
for
the
main
rpc
thing.
J
B
Makes
sense
yeah,
I
think
I
think
our
rpc
thing
we
should
we
should
call
it
whatever
we
decided
to
be
either
cozy
or
osi
or
kubernetes
osi.
J
B
E
That's
the
thing
people
in
this
group
are
only
integrating
with
kubernetes
on
the
the
user-facing
api.
Yes,
and
there
we
don't.
Have
I
mean
we
don't
really
talk
about
the
kubernetes
persistent
volume,
api,
it
exists,
kind
of
but
kubernetes
apis
are
just
the
kubernetes
api
as
a
whole,
while
csi,
cozy,
etc.
They
are
not
kubernetes
specific
and
then
really,
I
see
use
cases
for
the
grpc
api
to
be
used
in
other
environments
as
well.
Even
though
this
group
may
not
develop
those.
B
So
csi
is
not
a
good
analogy
here.
I
think
csi
came
about
a
time
when
we
had
different
container
runtimes
and
you
know
we
wanted
to
integrate
it
with
the
different
container
runtimes.
B
Right
now
the
integration
point
is
oci.
We
we
don't
have
to
deal
with
different
container
runtimes
as
long
as
they're
oci
compliant
we
work
with
them.
So
so
really,
I
think
I
keep
coming
back
to
this
because
it
seems
to
make
the
most
sense
when
someone's
writing
an
application.
B
That's
going
to
utilize
object,
storage
in
a
generic
fashion.
What
they're
utilizing
is
an
interface
to
object,
storage
or
you
know,
osi,
if,
if
it,
if
your
pigeon
holding
it
into
kubernetes
and
being
opinionated
by
calling
it
kubernetes
that
I
show
aside,
I
don't
think
we're
making
it
too
generic
by
calling
it
just
osi.
B
E
B
E
Part
of
the
manifest
you
will
say
I
want
to
part
that
has
a
csi
a
cosy,
csi
volume
to
expose
stuff
about
the
bucket.
I
have
a
bucket
access
request.
I
have
this.
I
have
that.
So
as
a
from
a
deployment
point
of
view,
you
do
care
about
the
fact
it's
running
in
kubernetes
and
the
bucket
access
request,
api
and
the
bucket
api
and
whatnot
are
kubernetes
apis.
B
B
An
example,
so,
let's
say
there's
a
front-end
developer,
writing
javascript
and
they
want
to
utilize
object,
storage
to
pull
down
their
javascript.
You
know,
resources,
say
images
or
videos
or
whatever,
and
that
developer
doesn't
have
to
know
anything
about
containers
or
kubernetes
they're,
simply
just
integrating
with
object,
storage
and
and
generally
in
a
team
structure.
B
K
Right,
I
think
when
do
you
actually
get
to
use
this?
Is
it
when
you
write
your
own?
You
know
web
application
locally
and
you
run
it
locally.
You
know
it
runs
locally.
You
don't
need
to
configure
it.
You
configure
it
locally,
you
don't
configure
it
through
object,
storage
interface,
you
just
you
know,
set
the
configuration
within
local
environment
variables
or
local
end
files
or
whatever
right.
K
K
K
B
B
You
say
so
where
I'm
coming
from
is
the
way
you
pull
the
data
for
the
buckets
has
to
be
in
the
code:
it's
not
like
a
different
flag
or
a
different
environment,
variable
name
or
another.
You
know
version
of
the
same
of
an
existing.
You
know
way
to
pass
in
data
passing
passing
parameters.
K
B
K
B
It's
insignificant,
to
be
honest,
I
I
get
where
you're
coming
from.
However,
do
you
really
think
it's
a
question
for
everyone
even
like
when
you
have
to
change
your
application,
to
interact
with
object
storage
in
the
way
that
we're
defining
where
they
read
bucket.json?
B
They
read
a
bucket
information
from
their
credential
information,
from
from
whatever
file
we
define
and
same
with.
The
search
is
that
is
that
not
a
significant
enough
change
for
a
developer.
K
B
J
B
J
Right
but
like
there's,
there's
a
way
in
which
the
the
the
relevant
bucket
details
get
passed
into
the
application
and
as
long
as
the
kubernetes,
when
the
application
gets
thrown
into
kubernetes,
it
gets
married
to
that
mechanism.
It's
no
big
deal
I
mean
like
with
csi.
You
know
you
have
a
bunch
of
data,
you
put
it
in
a
directory.
So
when
you
put
your
application
into
kubernetes,
you
make
sure
you
set
up
your
pod
with
a
with
a
volume
that
mounts
something
into
that
directory.
J
C
J
I
I
really
want
to
want
to
push
on
the
this
whole
idea
of
the
that
part
of
the
api.
Like
I
said
we
should
that
doesn't
need
a
name
other
than
just
the
kubernetes
object.
You
know
api
or
whatever
you
want
to
call
that,
but
it.
But
it's
important
to
realize
that,
like
once
that
becomes
standardized
as
like
the
way
kubernetes
does
objects.
You
don't
have
to
implement
that
using
this
rpc
interface
or
these
sidecars
or
these
drivers
right
it
yeah.
C
J
Could
one
could
vend
that
interface
through
an
entirely
different
mechanism?
If
you
wanted
to
do
the
heavy
lifting
like
that's,
why
I
see
them
as
separable
things
like
there's
we're
defining
an
object,
interface
that
faces
outward
to
the
developer
into
the
user,
and
we
plan
on
developing
an
implementation
of
that
that
layers
on
top
of
this
rpc
that
we're
trying
to
name
right
now.
J
B
I
mean
that
the
format
of
the
credentials
file
is
is
defined,
is
expected
to
be
a
certain
way
from
the
grpc
api.
They
are
pretty.
I
mean
they're
not
tied
to
kubernetes
but
they're
tied
to
each
other.
E
E
You
would
indeed
use
either
an
entry
point
in
the
container
or
in
it
container
or
whatnot,
to
parse
this
bucket.json
spit
out
a
configuration
file
or
potentially
environment
variables
that
are
just
the
ones
the
application
expects
today,
not
knowing
anything
about
cosi,
about
kubernetes,
about
what
not
you
you
transform
them
into
something
that
application
can
use
and
the
application
takes
it
from
there.
It
should
not
ever
know
about
the
existence
of
bucket.json.
B
I
think
I
think
a
painting
are
too
simplistic
a
scenario
as
as,
first
of
all,
having
this
step
as
a
part
of
the
deployment
is,
is
going
to
make
production
more
flaky
that
that's
going
to
be
the
main
concern
for
using
something
like
a
shell
script
for
going
to
production,
where
it's
not
the
development
process
doesn't
doesn't,
doesn't
you
know,
work
the
same
way?
The
second
thing
is
we
have
more
information
than
can
be
put
into
a
few
flags
or
a
few
environment
variables.
B
B
J
J
B
Yeah,
I
think
I
think,
that's
why
I
wanted
to
keep
this
for
the
end,
we'll
keep
talking
about
this
and
you
know
we'll
figure
out
one
way
or
the
other,
I'm
still
leaning
towards
just
object,
storage
interface.
I
think
I
think
that's
what
is
going
to
be
the
clearest
for
consumers,
both
developers
and
enterprises,
so
I'm
open
to
new
ideas.
Again,
I'm
not
stuck
on
this,
but
we'll
see.
B
That
that's
it
from
me.
If
anyone
has
any
questions,
please
ask
we
have
maybe
a
minute
or
two
to
answer
them.
Otherwise
we
can
reconvene
on
thursday.