►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 11 February 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
Okay,
so
the
last
two
weeks
we've
been
we've
been
talking
about
a
few
changes
to
our
api.
After
the
api
review.
Again,
we
have
to
set
the
context
there.
The
person
who's
reviewing
does
not
know
everything
that
we've
been
working
on
and
how
we
made
many
of
the
decisions.
A
I
think
the
cap
itself
needs
to
be
improved
to
reflect,
how
we've
been
thinking
and-
and
that's
one
of
the
reasons,
we're
getting
questions,
so
we
need
to
fix
that
problem
first
and
then
look
into
how
we
go
ahead
and
change
the
api
itself,
because,
if
our,
if
our
mistake
was
if
we
did
make
that
mistake
of-
let
me
not
even
call
it
a
mistake
if,
if
we
haven't
done
all
the
edits,
all
the
changes
that
we
had
discussed
in
during
the
meetings
in
the
past
few
months
and
if
that's
not
reflected
in
the
cap,
it's
easy
for
someone
to
be
misled
and
think
that
we're
missing
some
pieces,
so
that
needs
to
be
addressed
in
the
cap
itself.
A
Secondly,
assuming
this,
this
thing
is
done.
If
there
are
any
other
questions
that
come
up
that
require
us
to
look
at
the
you
know,
take
a
look
at
the
api
again
make
changes.
We
should
obviously
do
that.
D
So
he
said
it
seems
now
kind
of
difficult
for
tim
to
do
the
review
because
everything's
merged-
I
see
he
just
have
this
long
reviews
and
then
you
reply.
It
was
not
that
easy.
Does
it
make
sense
to
put
everything
in
google
doc?
Maybe
you
can
ask
him,
I'm
not
sure
what
is
the
best.
I
just
like
this.
I.
A
Think
I
think
many
of
the
questions
that
are
coming
up
shing
are
simply
because
the
cap
is
not
the
kept,
doesn't
have
the
information
given
there.
That's
all
it's
okay.
Questions
are
not
something
is
wrong.
The
questions
are
more
like.
How
does
this
work
or
have
you
thought
about
this
and
and
many
times
we
have
thought
about
it?
It's
just
the
cap
doesn't
reflect
it
and
and
for
the
there
were
some
questions
there
were
good
ones,
but
but
the
solutions
so
there's
two
things.
Tim
is
doing.
A
That
one
is
he's
asking
the
questions.
How
do
you
do
something
which
is
which
is
good?
The
second
is
he's
proposing
solutions.
That's
why
I
I've
been
saying
that
we
haven't
done
a
good
enough
job
in
the
camp,
because
you
know
he
thinks
we
haven't
thought
this
through.
So
he's
giving
us
solutions
which
is
not
true
and
and
his
solutions
are,
I
would
say
you
know
it's
it's
exactly
like
how
ours
were
when
we
first
started
thinking
about
it.
So
it's
still,
I
would
say
naive,
but
but
obviously
that's
the
way
things
go.
A
You
have
more
discussions,
you
flush
out
the
solutions
more
so
so
we
have
to
show
him
that
that
that
we've
actually
thought
all
of
this
through
and
then
we
have
to
show
him
what
solution
we
have
rather
right
now
he
thinks
we
don't
we
haven't
thought
about
it
and
we
don't
have
a
solution
either.
A
So
so
I've
asked
him
for
another
meeting
and-
and
we
need
to
get
that
across-
that's
that's
our
job
to
make
sure
that
the
tim
is
on
the
same
page
as
us,
because
he's
doing
the
api
review
and
and
finally,
we
did
expect
some
changes
to
happen
in
the
api
review
and-
and
you
know
that's
what
we're
going
to
be
talking
about
today
as
well
and
and
it's
okay,
it's
okay.
A
If
we
have
to
make
some
changes
to
the
api
review
like,
I
don't
think
the
changes
are
going
to
be
major
because
we
have
done
a
good
job
before
even
this
api
review-
and
you
know
as
changes
or
as
feature
requests
come
in.
If,
if
we
have
a
good
foundation,
the
changes
will
be
manageable.
A
Hiding
those
features
will
be
very
manageable
and
I
think
that's
the
position
we're
in
so
let's
actually
go
over
and
and
look
at
the
big
picture
of
what
our
priorities
are
and
and
how
we
move
forward.
So
again
we
have
demo,
we
have
api
review
and
alpha.
I
think
we
can
proceed
with
the
demo.
A
Even
though
we're
proposing
some
changes
to
the
api,
we
can
proceed
with
the
demo
without
the
changes
to
the
api
because,
again,
like
I
said
we're
not
looking
at
fundamental
changes
to
api
we're
looking
at
yeah,
I
like
I'll,
show
you
in
a
little
bit
how
the
changes
would
be
very
manageable.
A
There
is
one
thing
that
we
were
stuck
on
with
the
demo:
we
we've
done
development,
we
have
things
working
and
we
where
we
can
create
bucket,
grant
access
to
that
bucket
and
provision
the
bucket
into
a
pod.
But,
but
here
is
where
you
know
we
we
are
having
we're
stuck
right
now
and
saying.
Let
me
let
me
show
you
kubernetes
six
spec
and
pull
requests
so
shing.
I
I
have
to
say
at
this
point
you
know
we're
being
held
back.
A
A
No,
no,
no,
the
thing
is
the
team
is
held
back,
the
team
is
really
held
back.
We
we
could
have
moved
forward,
we've
lost
two
three
weeks
of
work
and,
and
just
because
has
not
attended
the
meetings
either
like
we
need
to.
We
need
to
do
something
about
this
thing.
We're
not
able
to
move
forward
like
this.
A
D
D
A
Yeah,
okay,
okay,
that
will
be
good
yeah.
Thank
you,
yeah,
please.
The
thing
is,
you
know
everyone's
been
waiting
for
this,
because
this
is
one
of
the.
This
is
one
of
the
central
pieces
that
changes
that
touches
a
lot
of
the
code.
So
you
know
that's
why
I'm
asking
yeah
yeah
all
right.
I
look
forward
to
that
that
this
is.
This
is
good
now
now
moving
forward
to
what
tim
was
talking
about,
so
so
in
the
api
review.
A
The
core
of
you
know
his
questions
and
and
the
answers
that
the
solutions
he
was
trying
to
provide
on
top
of
his
own
questions
were
about
bucket
mutation.
A
We
we
started
with
bucket
mutation,
but
before
we
even
addressed
it,
we
talked
about
self-service
for
mutation.
Now
again,
we
should
treat
these
as
just
conversations
and
ideas
rather
than
this
is
the
definitive
word,
and
this
is
absolutely
required.
So
first
thing
I
want
to
talk
about
is
is
bucket.
How
important
is
bucket
mutation
itself?
A
A
Is
it
even
fair
to
say
that
that
we
we
put
out
what
we
have
during
mvp
and
then
and
then
get
people
to
use
it
and
then
see
look
for
feature
requests?
E
A
Okay
and
okay,
I
think
that's
a
fair
answer
to
be
honest.
Now:
okay,
how
let's
say
we
do
say
that
let's
say
we
just
say
you
do
it
out
of
band.
I
think
I
think
I'm
just
thinking
this
through
so
let's
say:
let's
say
we
tell
them
to
do
it
out
of
band.
That's
not
very
different
from
persistent
volumes,
correct.
E
E
Later
well,
like
maybe.
A
E
And
and
you're
saying:
that's
why
it's
still
in
beta
yeah
yeah,
there's
just
a
long
list
of
corner
cases
that
never
really
got
sorted
out
and
we've
been
dragging
our
feet
to
actually
fix
them
all,
and
then
we're
not
going
to
declare
a
ga
until
there
are
no
more
corner
cases.
A
Yeah
yeah,
that's
true,
that's
the
responsible
thing
to
do.
Okay,
so
I
think,
as
our
first
step,
just
as
a
first
step,
I
think
it's
okay
to
say,
bucket
mutation
is
not
required
for
mvp
and
our
stance
could
be
the
admin
handles
it
out
of
band
again.
This
is
this
is
not
a
very
you
know
everyday
operation.
A
This
is
something
that
happens
rarely
generally,
the
requirements
are
known
up
front
and
we've
talked
about
this
before
of
six
months
ago
or
so,
and
then
we
consciously
made
the
decision
that
it's
it's
it's
not
something
that's
going
to
be
very
important
or
or
very
frequent.
I
would
say
there
might
be
a
few
cases
very,
very
few
cases
where
that
might
be
needed,
but
it's
not
something
that
can't
be
handled
by
an
admin,
doing
things
that
are
banned.
E
I
think
a
good
way
to
look
at
it
is
that
we're
not
trying
to
design
cozy
to
be
like
a
human-facing
management
interface,
we're
trying
to
design
it
to
be
a
machine-facing
management
interface,
where
you
have
automation,
workflows
that
need
to
just
be
able
to
do
their
thing
and
do
them
repeatedly
right
and
and
and
you
have
to
be
able
to
imagine
a
situation
where
the
machine
wants
to
create
a
bucket
and
then
wants
to
change
something
about
that
bucket
after
it's
created
and
ask
yourself.
Why
would
the
machine
need
that
ability
right.
E
No,
I
mean
like,
like
I
think,
resize
was,
it
was
a
situation
where
you
know
you.
Sometimes
you
make
it
small
and
then
it
needs
to
be
bigger
later
so,
but
in
general,
like
you
said,
you
know
what
you
want
up
front.
Yeah.
F
F
F
But
ben,
when
you
think
of
access
patterns
for
buckets,
you
could
start
off
with
a
bucket
that
you
want
private
or
restricted,
and
now
winds
have
settled
down
or
they're,
more
well
thought
out
in
your
the
day
in
the
bucket
the
objects
in
the,
then
you
want
to
share
it
or
make
it
public,
and
so
that's
a
change
that
would
naturally
evolve
over
time
as
data
matured
say.
F
A
F
It's
a
field
supported
in
cozy
today
and
and
what
and
you're
saying
the
change
to
that,
which
I
think's
a
reasonable
use
case
would
be
done
out
of
band
and
then
so,
if
that's
the
case,
then
you
have
to
decide
if
cozy
reflects
that
changed
or
not,
but
I
just
wanted.
I
just
wanted,
even
with
a
machine
facing
focus,
and
I
like
that.
I,
like
that
concept
ben,
that's
a
nice
way
of
saying
it
or
it
makes
me
think
about
it,
a
little
differently.
I
like
it,
even
with
that.
E
Well,
but
the
way
I
think
about
it
is
like
the
vast.
The
value
of
cozy
is
not
for
these,
like
long-lived
buckets
that
have
been
around
since
you
know
three
years
ago
and
they're
being
used
for
multiple
purposes.
It's
for
when
you
programmatically
need
to
be
able
to
create
buckets
for
some
workflow
and
destroy
them
when
you're
done
or
you
know,
or
or
use
them
across
some
there's
some
workflow
that
involves
creation
and
destruction
and
usage
of
buckets.
E
E
As
long
as
cozy
can
do
everything
that
workflow
requires,
then
then,
if
a
human
wants
to
change
his
mind
about
something,
he
just
changes
the
workflow
and
starts
over.
That's
how
I
think
about
it.
Do
you
see
brownfield
use
cases
ben,
that's
primarily
for
sort
of
bootstrapping?
I
I
imagine
that
in
the
in
the
medium
to
long
term
those
will
go
away,
I
think,
or
their
value
will
be
vastly
diminished
yeah.
You
know,
I,
I
think
that
it's
to
get
people
started.
E
Brownfield
is
valuable
because
you
have
a
bunch
of
stuff
in
buckets,
maybe
that
you
want
to
and
you're
trying
to
get
yourself
onto
a
cozy
workflow
without
losing
all
your
data.
So
you've
got
to,
you
know,
do
a
one-time
import,
but
then
I
hope
that
going
forward
everything
is
greenfield.
I
mean
I
don't
think,
there's
very
many
cases
where
people
do
like
the
brownfield
pv
thing
where
I
have
some
data
outside
kubernetes
and
I
create
a
pv
and
then
I
pull
it
into
kubernetes.
That
way,
that's
that's
extremely
rare
now.
A
Okay,
okay,
all
right,
so
I
think
that
should
be
our
official
stance
and-
and
I
think
we
should
continue
going
the
way
we
are
for
mvp
and
alpha-
and
I
think,
like
ben
is
suggesting
it's
not
going
to
be
a
common
use
case.
A
We
will
open
ourselves
up
to
you,
know
new
feature
requests
from
from
users
and
if
we
have
enough
interest
in
something
like
market
mutation
and
and
something
that
needs
to
be
supported
by
cosy
rather
than
something
they
can
just
do
on
their
own
out
of
band.
If
the
value
that
cozy
ads
is
significant
enough,
then
we
should.
We
should
definitely
approach
this
problem,
but
I
think
we
we
had
a
good
reason
for
not
for
not
going
down
this
route.
Last
time.
B
A
Think
we
should
document
why
we
didn't
go
into
mutation
or
what
the
purpose
of
cozy
is.
You
know,
I
think
it's
it's
a
good
way
to
put
it
to
say:
cozy
is
automation
to
create
and
tear
down
buckets
for
a
workload.
B
Yeah
and
but
the
point
is,
should
this
be
specked
out
clearly
in
the
cap
or.
B
F
F
F
In
that
case,
we
should
does
that
change,
some
of
our
fields
to
be
moved
out
of
spec
and
into
status.
A
I
don't
I
don't
see,
no
it.
Those
are
the
those
are
the
fields
that
are
that
are
filled
in
by
the
the
controller
when
requesting
the
bucket,
so
they're,
not
status
fields.
A
A
Yeah,
I
think
I
think,
that's
that's
the
way
we
move
forward,
because
it's
yeah,
it's
always
important
to
take
a
step
back
and
ask
if
what
we're
going
down
is
even
worth
it
yeah
and-
and
I
think
this
is
what
we
should-
we
should
go
and
inform
inform
tim
and
whoever
else
is
there's
a
person
named
solomon
who's
reviewing
the
api.
Both
of
them
should
know
that
that
you
know,
along
with
everyone
in
the
community.
A
This
is
this
is
how
we've
decided
to
move
forward
and
again,
as
always,
we
say
we're
open
to
changes
or
new
requests
as
as
needed
all
right.
So.
A
A
Okay,
if
not,
I
want
to
go
into,
I
want
to
go
into
figuring
out
where
we
are
in
terms
of
development,
because
I
think
the
last
two
weeks
have
been
a
slump
for
development.
A
We've
been
waiting
on
that
pr
to
be
merged,
but
now
that
that's
going
to
be
unblocked,
we
should
we
should,
you
know,
start
focusing
on
development
again.
So
I
just
want
to
get
a
quick
update
from
I.
You
know
there
are
a
bunch
of
people
here.
I
don't
know
who
all
are
here.
A
So
if,
if
you're
working
on
something
just
go
ahead
and-
and
just
you
know,
speak
about
what
what
you're
working
on
and
then
right
after
that,
we'll
we'll
go
into
deletion
and
finalize
us
one
more
time,
because
we
didn't,
we
didn't
close.
That
topic
out.
A
So
so,
who
here
is
working
on
some
part
of
either
the
code
or
documentation.
G
Sid
yeah,
let's
be
honest,
so
yeah,
I'm
just
still
finding
my
way
around
the
how
the
all
the
pieces
work,
I'm,
I
think
I'm
ready
to
to
start
contributing
on
the
on
the
controller,
have
a
better
understanding,
and
so
basically,
what
I'm
trying
to
do
is
just
try
to
bring
up
the
site
the
sample
driver
and
see
it
working
and
in
this
process.
I
think
I
discovered
one
two
issues
that
I
reported.
G
I
did
some
small
pr
on
the
on
the
side
car
for
the
permissions,
especially
for
the
sample
driver
for
the
permissions
on
the
guns,
yeah,
I'm
still
exploring
the
whole.
It's
a
it's
a
lot
of
code
that
I
need
to
familiarize
myself
with,
but
at
least
through
the
controller,
I
should
be
able
to
have
some
early
some
input
early
early,
the
coming
week
along
the
under
me
on
the
rhythm.
A
G
Sure
that
it,
you
know
it
works,
that
it's
something
that
we
can
show
to
the
community
and
start
implementing
for
the
different
providers.
Vendors.
A
Yeah
yeah,
that's
good
yeah,
so
we've
got
janice
here
from
ibm.
Who
is
going
so?
Are
you
gonna
implement
this
for
software
or.
G
So
it's
for
for
the
ibm
cloud
right
for
the
cause
and
the
ibm
calls
right.
So
it's
not
it's
on
my
intentions
right.
It's
not!
I
know.
Maybe
we
coordinate
with
three
with
cine
as
well
too,
where
so
yeah,
but
it's
yeah,
it's
my
intention
at
least
to
contribute
to
that.
I
don't
know
who
else
is
interested
in
that
yeah?
I
I
guess
that
the
for
the
ibm
cloud
it
would
be.
A
E
Oh
yes,
yes,
I
I
have
been
pushing
for
that
to
occur,
it's
not
going
to
be
on
my
plate.
I
don't
think,
but
I
am
trying
to
find
the
person
who
will.
A
Do
it?
Okay,
yeah
yeah,
get
them
on
board,
because
I
think
if
a
lot
of
people
like
if,
if
all
of
us
come
together
right
in
the
beginning
and
start
working
on
things,
you
know,
I
think
I
think
we'll
we'll
end
up
with
something
we
all.
You
know
we
all
feel
like.
We
have
a.
We
have
a.
We
have
a
design
that
that
that
works
for
us,
yeah,
you're
gonna,
be
working
on
a
safe
one
as
well.
A
H
Hey
yeah,
sorry
for
being
so
so
much
time
away.
So
yes,
I
yeah,
I
I
don't
know
about
the
the
actual
plan,
but
I
I
was
trying
to
follow
up
and
see.
What's
the
right
time
and
if,
if
possible,
I
I
would
be
happy
to
you
know,
take
a
look,
take
the
first
stab
and
then
you
know
see
who
can
pick
it
up
from
the
the
nougat
team
and
okay.
D
A
It
is,
it
is
so
it's
still
early
in
the
sense
that
you
know
we
have.
We
have
a
a
framework.
We
have
a
skeleton
for
people
to
get
started
with
and
we
have
a
sample
very,
very,
very
crude
sample
driver
written,
but
but
it's
enough
for
people
to
start
con.
You
know
writing
their
own
drivers,
because
that's
one
of
the
ways
the
framework
will
also
improve.
H
And
there's
there's
no!
So
if,
if
that's
going
to
land
in
somewhere
like
in
in
another
project,
is
there
is
there
any
way
to
consume
it
from
from
kubernetes
builds
already?
Or
is
it
all
just
manual
sort
of.
A
Yeah
we
have,
we
have
deployment
docs,
even
even
we
we've
written
it
down
I'll
show
you
content,
object,
storage!
Sorry,
if,
if
you
already
covered
it,
this
is
so
so
we've
added
good
docs
now,
so
everything
that
we've
been
doing
is
is
much
better
documented.
So
if
you
were
to
go
to
the
api
repository
you'll
see
our
documentation
and
if
you
go
into
deployment
guide
here,
you'll
see
how
we
can
deploy
it.
A
So
we
we've
used
customize
and
to
set
up
the
whole
project
as
it
is
today.
With
the
you
know,
the
only
sample
driver
that
we
have.
This
is
what
this
is.
What
is
the
set
of
commands
now,
ideally
yeah?
Ideally,
what
I'd
like
to
have
is
multiple
sample
drivers
or
multiple
drivers
and,
and
you
choose
which
driver
you
want
by
setting
an
environment
variable
here.
So
if
you
want
to
say
minio
driver
you'd,
say
driver
equals
min
io.
A
A
Actually,
no,
you
know,
and
none
of
this
well,
you
know
113,
because
csi
came
in
only
at
113,
but
other
than
that.
No
okay,
good.
F
A
All
right,
so
I
want
to
get
a
quick
update
from
tejus
he's
on
the
call
tejas
has
been
working
on
well.
This
was
the
one
who
added
the
deployment
guide.
Yeah
has
been
an
admin
for
a
long
time
and-
and
you
know,
he's
added
it
from
the
perspective
of
an
admin.
A
That's
going
to
consume
this
document,
which
is,
which
is
how
we
want
it
to
be,
so
they
just
what's
the
what's
the
status
hey,
I
I
don't
have
the
draft
for
writing
the
driver,
but
I'm
I'm
currently
working
on
that,
like
okay,
how
to
write
a
cozy
driver
doc
right
got
it
okay.
So
that's
what
you're
working
on
how
to
write
a
cozy
driver
right?
Yes,
okay,
sounds
good.
H
I
see
also
the
application
side
like
the
the
usage
and
not
just
deployment
right.
There's.
A
How
to
make
your
application
cozy
compatible?
We
need
someone
to
take
this
task.
So
if
I
understand
correctly,
janus
is
going
to
progress
from
writing
the
the
readme
to
writing
code
is
that
right,
giannis.
G
So
for
the
for
the
controller
or
the
driver
for
for
the
sample
driver
yeah
yeah,
I
kind
of
can
take
that
yeah.
A
Yeah
yeah
so
and
then,
and
then
will
you
so
you
mean
this,
you
you
can
take
up
application
documentation
or
where
you're
saying
you'll
take
up
the
coding
job.
So.
G
A
Okay,
yeah
sounds
good
yeah
yeah.
We,
this
is
still
an
open
task:
how
to
write
your
own
application
cozy
how
to
make
your
own
application
cozy
compatible.
You
know
this
has
to
go
into
the
bucket.yaml
that
will
be
presented
into
the
part,
and
you
know
how
we
should
also
probably
give
sdks
in
in
go
at
least
or
or
use
open
api
to
auto
generate
a
bunch
of
sdks
or
something
that
people
can
just
import
and
just
use.
What
do
you
all
think.
G
Yeah,
like
helpers
like
yeah,
I
mean.
A
Yeah
yeah
automated
sdks.
That
will
just
tell
you
you
know
that'll
just
give
you
all
the
all
the
different
calls.
So
so
so
you
know
you
use
the
import,
the
library
and
then
you
can
just
call
get
bucket
or
whatever.
G
I
operations
like
yeah.
A
Like
get
get
object,
put
object
and
you
know
delete,
and
all
that
I
mean
we
need
to
define
the
scope
of
that
I
think.
But
what
is
the
question
is.
Would
that
is?
Is
that
sdk
something
we
should
even
think
about
providing.
G
I
think
I
mean,
if
you
have
like
I
mean
they
can
people
can
use
like
you
know
the
the
sdk
that
there
is
for
aws
or
min
io
right
under
go
code?
Do
you
think
they
need
something?
More
than
that
I
mean
I
I'm
guessing
that
the
application
starts
working
with
the
cozy
bucket
after
its
provision.
So
it's
or
do
you
suggest
that
the
application
should
also
create
the
bucket
and.
G
A
Said
when
I
said
sd
when
I
said
sdk,
what
I
meant
was
an
sdk
to
pass
the
bucket.yaml,
so
so
the
the
first
step
that
someone
has
to
do
who's.
Writing
a
you
know.
Who's,
making
their
application
cozy
compatible,
is
to
change
how
they
retrieve
the
bucket
name
and
the
end
point
for
the
bucket
and
the
access
key
and
secret
key.
A
We
can
automate
that
I
mean
we
can
give
an
sdk
that
people
can
use,
and
maybe
we
just
start
with
go.
I
think
just
go
is
enough.
We
don't
even
have
to
do
many
languages
that
people.
E
Can
use
what
would
you
want
to
do
on
top
of
just
like
generating
client
go
bindings
and
put
putting
them
in
a
well
well-known
location?
Yeah?
That's
it!
That's
it!
That's
what
I
meant:
okay,
so
yeah,
so
yeah
once
you
have
the
client
go
bindings,
you
can
interact
with
the
kubernetes
crds
and
then
everything
else
is
what
you're
already
doing
today
to
do
bucket
stuff.
H
H
Configuration
yeah
to
have
some
instead
of
just
a
a
recipe
by
the
documentation.
You
wanted
to
have
some
like
ready-made
code
for
pulling
and
having,
let's
say
your
aws,
s3,
client
configured
or
created
for
your
configuration
object
or
something
right.
Having
that
ready
exactly
yeah,
I
think
I
mean
I
think
it
makes
sense
even
to
go
like
that.
That
sounds
like
a
good
step.
Like
that's
the
first
step,
it
might
even
make
sense
to
go
further.
H
Well,
I
I
mean,
I
think
we
all
had
that
thought
eventually
to
have
something
in
in
cozy
that
will
have
the
protocol
side
as
well,
and
some
in
some
form
right
to
have
at
least
a
basic
protocol
for
for
io
or,
but
I
I
think
your
your
approach
is
good.
I
mean
you
just
starting
off
from
reading.
A
Lower
the
bar-
that's
right,
exactly
yeah.
I
think
I
think
no,
I
think
it's
all
it's
actually
needed
because
right
now,
our
first
step
is
adoption
like
we
want,
like
all
of
the
vendors,
can
go
and
write
cozy
drivers,
but
but
we
need
applications
to
start
using
them
for
for
cozy
to
become.
You
know
like
like
the
new
way
of
of
consuming
object,
storage,
and
so
I
think
I
think
we
should
have
the
sdks
so.
H
Another
question
for
you-
maybe
maybe
that's
off
topic,
but
I
also
know
that
the
mean
io
has
its
own
sidecar
for
for
performance
reasons
and
these
things
right,
yeah,
but
but
that
so
configuration
is
nice,
but
it's
it
still
makes
it
rather
difficult
to
consume.
Because
when,
when
you
need
to
read
the
configuration,
you
also
need
to
interject
into
the
application
very
tightly
and
the
application
has
to
be.
H
You
know
recompiled
or
repackaged,
or
something
like
that
right,
but
with
a
if
you
take
the
approach
of
you
know
providing
the
end
point
as
a
car
like
like
I've,
seen
mineio
do
for
other
reasons
that
that
might
you
know
get
get
the
application
sort
of.
You
know
ignorant
to
that
configuration
to
the
change
in,
like
the
part
yeah.
A
Okay,
so
you're
saying
the
sidecar
would
take
care
of
all
sorts
of
communication
with
the
back
end
and
all
applications
just
have
to
talk
to
the
you
know
the
sidecar.
F
H
A
Okay,
so
first
I'll
explain
to
everyone
what
the
sidecar
approach
that
nyo
is
doing
is
and
then
and
then
I
think
I
think
this
is
definitely
open
to
discussion,
so
so
what
mineo
does
and
why
it
uses
sidecar.
So
when
we
we
call
our
sidecar
sidekick,
the
idea
behind
sidekick
is
it's.
A
It's
it's
a
it's
a
reverse
proxy
to
to
talk
to
a
remote,
mineo
server
and
the
way
it's
done
is
an
application
which
already
somehow
has
the
credentials
to
talk
to
manio
would
would
would
simply
always
connect
to
the
local
ip
address,
which
is
the
sidecars
ip
and
sitecar
always
listens
on
a
particular
port
and
and
the
application
does
not
need
to
figure
out
how
to
talk
to
minio
or
it
does
not
need
to
figure
out
which
endpoint
of
miner
to
talk
to
for,
say,
geographical
dns
routing
and
all
that
is
taken
care
of
by
the
sidecar.
H
We
can
generalize
it
and
say
that
the
application
doesn't
even
have
to
provide
credentials
exactly
so
that's
the
extension
of
it
to
the
cozy
world,
where,
like
the
credentials,
can
be
handled
by
the
side.
You
know
sidecar
sidekick
container
and
you
know
what,
whatever
the
the
the
credentials
that
the
application
chooses
to
pass.
It
really
doesn't
matter
much
because
you
know
the
sidekick
will
have
its
own
set
of
credentials
to
talk
to
the
rest
of
the
system.
A
Yeah,
what
we're
talking
about
is
really
a
server
that
that
we'll
maintain
that
the
application
can
talk
to
and
just
assume
that
it
has.
You
know,
access
to
whatever
bucket
that
is
interested
in.
E
So
so
I'm
not
I'm
not
opposed
to
any
of
this
sidekick
stuff.
It
sounds
great,
I
think,
for
for
achieving
our
goal
of
adoption
on
the
application
side,
it's
really
important
that
we
illustrate
how
like
a
non-coder,
can
take
an
existing
application
and
adapt
it
to
just
run
on
cozy.
So
like
say,
here's
how
you
take
the
pods.
You
already
have
with
the
code
that
you
can't
modify
and
here's
the
yaml
that
you
add
and
the
in
the
init
container
whatever
it
is
that
you
have
to
do
to
glue
something.
E
That's
already
compiled
and
running
to
the
cozy
interface
that
that,
like
a
script
or
non-coder
type
person
could
manage
if
you
can
get
those
people
to
to
to
get
interested.
I
think
that
that's
where
you'll
get
your
adoption
from,
I
think
I
think
you
you
hit
the
nail.
G
On
the
head,
sid
sid
also,
I
I
think
my
suggestion
is
that
I
so
I
see
two
types
of
applications,
though,
that
we
nee
we
need
to
find
adoption
on.
So
one
is
the
you
know
the
regular,
the
users
that
you
know
on
their
pods.
They
just
want
to
consume,
read
or
write
data
to
the
s3
packets
right
and
the
second
category
I
think,
is
the
you
know
kubernetes
native
applications
that
would
access
the
buckets.
G
Maybe
you
know
on
the
on
the
on
the
level
of
the
of
the
object
itself
of
the
kubernetes
object
itself.
Right
doesn't
make
sense,
so
it's
it's
it's
important
to
have
adoption
in
both.
I
feel
right.
A
Okay,
so
you're
saying
applications
that
that
kind
of
consume
the
cosy
apis
and
then
applica
and
then
others
are
data
applications
that
are
going
to
consume
the
buckets.
That's
the
distinction
you're
making.
G
Right,
you
know
so
the
basically
other
kubernetes
services
that
can
be
on
that
can
be
built
on
top
of
of
cozy
packets.
Let's
say
right
that
are
not
interested
in.
G
You
know
accessing
the
credentials
themselves
or
just
work
with
a
packet
object
as
kubernetes
objects,
I
mean
right
and
the
other
is
the
users
applications
right
that
they
just
want
to
consume
packets
and
they
don't
care
for
the
internals
of
you
know
the
bucket
objects
itself-
or
you
know
this-
this
has
to
be
as
friendly
as
possible
right
as,
as
guy
said
something
on
the
environment
variables
or
something
pre-configured
for
them
to
domestic
s3
clients
to
work
as
out
of
the
box
as
possible.
G
A
Yeah
absolutely
yeah
one
sec,
one,
one
type
of
application,
you're
saying
is
what
we'll
talk
to
the
kubernetes
objects
like
buckets
and
bucket
requests
and
whatever
exactly
exactly
the.
A
G
About
it's,
it's
just
about
what
type
so
on
the
on
the
links
here
it
should
be.
You
know,
yeah.
We
I
think
we
just
need
to
address
the
date,
at
least
on
the
first.
On
the
day
of
day
one.
I
think
we
should
address
the
how
the
users
who
just
want
to
consume
the
data
should
work
with
with
cause,
and
then
they
do.
Maybe
you
know
how
to
build.
On
top
of
the
cozy.
A
Yeah
yeah,
I
see
what
you
mean.
Yes,
the
documentation.
Can
I
mean
yeah.
I
guess
I
guess
this.
This
kind
of
makes
that
distinction
anyways.
How
to
write
a
question
is
how
to
write
your
application
cozy
compatible.
I
guess
it
doesn't
address
quite
a
bit
how
to
write
a
framework
on
top
of
cozy
exactly
yeah,
but
I
don't
know
if
we
should
have
docs
for
something
like
that.
G
H
G
I
would
just
want
to
bring
up
that.
You
know
it
is
yeah.
It
is
something
that
could
be
interested
in
interesting
in
the
ecosystem
right.
It
would
be
nice
to
encourage
people
to
build,
who
build
kubernetes
services
to
build
on
top
of
cozy
right.
So
yeah.
A
A
In
the
future
right
sure,
yeah,
I'm
glad
we
brought
it
up
in
conversation
and
in
the
future.
Someone
is
going
to
bring
this
up
again.
We
brought
this
up
once
before.
I
think
ben
brought
it
up.
Even
the
the
thing
we
brought
up
was
you
know:
cozy
needs
to
be
implemented
in
such
a
way
that
you
know
others
can
build
on
top
of
it.
A
A
Okay,
so
so
good
that
we
talked
about
adoption,
so
one
thing
I
would
ask
all
of
you
is,
you
know:
you've
participated
in
in
the
entire
process
so
far.
I
think
I
think
you
know
all
of
you
each
and
every
one
of
you
should
go.
Look
at
the
cap,
the
enhancement
proposal
that
we
have
and
either
leave
your
feedback
respond
to
questions.
Others
have
asked
or
or
make
new
prs
to
to
either
augment
or
edit.
What's
there
does
that
make
sense.
A
See,
I
think
it
is
a
it
is
a
it
is
a.
It
is
a.
It
is
an
proposal
that
we've
all
come
together
to
make
and
the
people
who
are
reviewing
the
api
haven't
spent
the
amount
of
time
we
have.
So
it's
important
that
we
do
a
good
job
of
explaining
why
we
made
the
decisions
we
made
and
and
what
are
the
decisions
in
the
first
place
so.
A
F
I
they
kept
a
little
different
than
code,
that's
been
merged
and
then
we
learn
more
or
we
examine
it
more
closely
and
we
see
issues
and
the
kep,
I
view
is
the
same
and
although
historically
I've
been
the
owner
of
it,
I
certainly
don't
have
to
it's
a
community,
and
so
I
don't
want
the
fact
that
the
status
is
merged
to
to
cause
people
to
think
everything's
completed
exactly
just
right,
so
prs
are
very
valuable.
F
A
Yeah
yeah,
I
like
how
jeff?
Oh,
oh,
here's
your
spacer,
yes
guys!
That's
the
one,
two,
three,
four:
nine!
Yes,
yes
yeah!
So
so
please
read
the
cap
and
and
make
all
the
suggestions
that
you
think
are
needed,
and
you
know
respond
to
the
comments
here
and
ask
questions.
If
you
have
any,
you
know,
we've
done
everything
in
the
open,
so
we're
gonna.
A
Do
this
also
the
same
way,
because
this
skip
is
what
others
are
like
api
reviews
are
going
to
see
and
if
ap
reviewers
go
ahead
and
ask
for
changes
to
the
api,
because
the
cap
isn't
clear
in
every
part
of
it,
you
know:
that's
not
that
that
either
wastes
the
time
of
the
community
or
it
could
potentially,
you
know,
lead
us
in
the
wrong
way.
So
so
I
think
it's
important.
A
All
of
you
you've
contributed
to
this
project,
and
I
think
one
of
the
important
steps
is
also
presenting
it
well
to
the
rest
of
kubernetes
and
so,
and
so
I
think
you
should
participate
in
this
in
this
process
like
jeff
was
saying
it's
not
just
about
managing
it,
but
really
about
the
cap
reflects
what
we're
doing
to
the
rest
of
the
community.
A
We
don't
have
anything,
that's
you
know,
there's
no
hard
deadline
as
of
right
now,
the
api
review
is
planned.
It
has
to
be
done.
It
has
we've
already
started
it.
It
has
to
be
done
within
three
months:
okay,
yeah,
but
but
you
know,
if
you
start
reading
it
now,
the
the
bottleneck
in
this
api
review
process
is
going
to
be
the
time
that
api
reviewers
have
to
contribute
to
this.
This
you
know
this
kept.
A
That's
another
reason
we
need
to
make
sure
the
cap
is
kept
us
in
great
shape,
so
that's
so
that
we
save
their
time
and
also
we
save
our
time.
We
don't
have
to
go
back
and
forth,
try
and
explain
what
it
is
that
we're
trying
to
say.
D
A
Yeah
all
right
so
yeah
we
have,
we
have
10
minutes
left.
I
think
I
think,
unless
you
know,
does
anyone
want
to
bring
up
any
other
topics.
A
I
think
I
think,
as
long
as
as
soon
as
we
start
implementing
sample
drivers,
we
will
start
improving
the
existing
state
of
the
project
and
also
we'll
know
if,
if
any
new
features
are
needed
or
if
any
api
changes
need
to
be
made,
but
but
that
that
needs
to
start
right
now.
So
so
I'm
looking
forward
to
all
of
you
starting
work
on
that
and
and
xing
would
you
know
how
we
can
get
in
touch
with
the
google
cloud.
D
D
You
well,
you
can
ask
the
assad.
A
A
Okay
and
and
how
about
for
amazon,
would
you
know
who
to
contact
for
that.
C
A
D
D
Yeah,
I
don't
know
if
he's
like,
and
there
is
someone
actually
at
six
storage
meeting
today,
he
said
he's
familiar
with
ebs.
So
maybe
I
can
ask
him,
but
I
don't
know
if
they're
they
may
not
be
the
same
like
from
the
same
team,
but
maybe
I
can
just
check
that
as
well.
A
Please
yeah
yeah,
if
you,
if
you,
if
you
just
let
me
know
that
person's
name,
I
can
even
send
an
email
out
and
okay,
we
can
get
them
yeah,
you
know
we
can
get
them
started
and
the
final
one
is
azure.
Would
anyone
know
who
well?
Let
me
ask
this:
would
anyone
know
anyone
who's
from
azure?
That's
that's
been
contributing
to
kubernetes.
D
C
Jesse,
I
forgot
his
name.
D
Oh,
did
I
don't
know
if
a
string
is
working
with
someone.
D
Microsoft,
so
so,
but
I
do
know
someone
because
this
guy
was
actually
helping
me
with
their
like
snapshots
apis.
So
maybe
I
can
ask
I'm
not
sure
if
he
knows,
but
I
can
definitely
check.
A
Yeah,
please,
you
know
we
can,
we
can
send
out
an
email
and
the
thing
is:
if
you
send
an
email,
we
can
ask
them
to
forward
it
to
the
right
team.
D
D
A
Yeah
yeah,
so
so
let's
do
that.
I
think
we
should
get
the
conversation.
D
B
That's
that's.
That's
all
you
need
is
perfect.
One
thing
I
would
suggest
is
eventually
we
should
have
sub
items
on
the
spreadsheet
to
track
these,
and
so
so
people
can
pick
up
ownership.
That's
how
csi
does
so.
That's
a
good
idea,
yeah,
but
I'm
not
sure
whether
we
are
ready
for
that
yet.
But
at
some
point
in
time
we
should
do
that.
Okay
or
maybe
for
one
two,
two
planning
that
makes
sense.
B
Right,
we
have
one
item,
so
we
create
some
sub
items
underneath
it
one
for
the
driver
for
gc
or
you
know,
one
for
the
azure
and
so
on
and
so
forth
and
then
see
if
somebody
picks
up
as
as
an
owner.
So
yeah.
D
A
Okay,
I
see
what
you
mean:
okay,
so
srini.
How
do.
B
A
Okay,
so
shiny,
I
will.
I
will
defer
to
you
for,
for
making
that
happen.
A
Sure
yeah
all
right
so
so
I
think
we
have
a
good
plan
in
place.
The
next
important
thing
is,
you
know,
getting
the
cap
or
showing
to
the
kubernetes
the
rest
of
the
kubernetes
community
that
what
we're
doing
so
everyone
who's
been
contributing.
It's
important
that
that
you
go
and
and
make
the
changes
to
the
cap
and
or
see
the
changes
that
have
been
made
to
the
cap
and
fill
in
anything.
That's
missing
and
reword
anything
that
needs
to
be
reworded.
A
It's
going
to
be
important
to
take
this
project
to
the
next
step,
where
we
are
alpha,
and
you
know
we
are
api
reviewed,
and
you
know
it's
a
part
of
the
kubernetes
release
document
where
we
start,
we
can
start
talking
about
cosy
as
something
that's
alpha
status
and
and
something
that
others
can
try.
A
Perfect,
okay,
all
right,
so
I
think
we
can
end
the
meeting
now
we
have
five
minutes
left
again.
If
you
have
any
questions
right
now
is
a
good
time
to
ask
if
not,
let's
continue
this
discussion
on.