►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Workgroup for Object Bucket API Review - 16 July 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
B
A
Okay,
so
let's
see
how
we're
doing
on
we've
got
nine
people
here
and
it's
1004,
so
I
think
we
should
start
and
Sheen.
You
said
it
is
being
recorded.
Yes,
I've
already
started,
recording!
Thank
you,
okay,
so
this
is
so
so
this
meeting
will
be
a
little
bit
rough
for
two
reasons:
one
John
isn't
leading
the
meetings
any
any
more.
A
But
another
opportunity
came
up
doing
some
edge
edge
work
and
he's
really
excited
about
that,
and
the
only
way
to
really
allow
him
to
be
successful
at
the
new
work
is
to
let
go
of
this
of
this
kept
work,
and
so
that's
what
we've
done
at
Red,
Hat
and
he's
gonna
be
missed.
I
I
know
we
all
appreciate
the
work
he
put
in
there,
so
his
roles
been
divided
and
I'll
just
go
through
a
few
of
those
things.
Right
now,.
A
Sid
who's
run
a
couple
of
these
meetings
already
and
has
been
contributing
code
and
design.
Sid
will
take
over
technical
leadership
of
this
cat.
All
technical
aspects,
unresolved
issues,
were
figuring
out
resolution
to
issues
and
the
communication
of
that
will
be
on
stood
and
and
people
that
will
assist
him
with
that
Aaron
Boyd
and
myself
and
I.
Don't
have
mice
from
me,
so
I
don't
know
if
Aaron
Aaron
has
made
it
to
the
meeting.
Yet
we
will
deal
with
the
administrative
aspects
of
the
cap,
and
that
means
running
these
meetings.
A
Making
sure
recording
is
uploaded,
notes
are
uploaded
and
me
personally,
I'll
be
updating
to
cap.
I
went
through
about
a
third
of
it.
Last
night,
I
made
comments,
sort
of
as
reminders
to
myself
for
what
to
address
when
I,
when
I
create
a
another
commit
for
the
cap,
there's
inconsistencies
there's
some
stale
information
in
there.
A
A
I,
don't
know
if
we're
gonna
have
anyone
who
will
have
a
role
of
being
a
note-taker
or
not
the
last
person
who's
committed
to
working
on
this
is
Rob
rowdy,
our
ATI
he's
working
on
the
controller
sidecar,
and
we
we
are
definitely
looking
for
any
extra
help
we
can
get.
We
we
have
momentum
and
my
my
goal
and
I
think
I
speak
for
everyone.
Who's
hung
in
here
as
long
as
we
all
have
right
now.
A
We'd
really
like
to
take
this
to
the
finish
line
and
sod,
maybe
I'm
looking
at
notes
instead
of
mine,
scream
sod
I,
don't
know
if
you're
on
eating,
but
maybe
you
can
help
us
understand
what
are
the
last
steps
we
need
to
do
to
get
this
PR
merged
if
it's
merged,
it's
not
static
and
stuff
like
that,
we
can
do
other
PRS
against
it,
but
we
need
this
main
PR
merged.
I.
Think
sooner
is
definitely
better
than
later
and
I
think
to
get
it
merged
from
a
community
point
of
view.
A
We
just
need
to
have
I
two
things:
community
agrees
with
our
use
cases
and
two.
They
agree
community
feels
confidence
that
we
can
deliver
on
on
on
meeting
those
use
cases.
We
have
a
solution
that
will
work
and
some
of
the
details
don't
need
to
be
completely
fleshed
out
in
order
to
merge
the
PR.
That's
my
understanding
saw.
Do
you
do
you
agree,
yeah?
That
makes.
C
D
C
Think
that
this
capita
is
ready
to
kind
of
get
to
a
point:
where
can
we
merged
we're
gonna
present
it
to
the
wider
community?
Anybody
who's
interested
please
attend
this
meeting
at
this
date
is
effectively
the
next
meeting.
Okay
and
then,
if
anybody
has
concerns,
they
can
raise
it
in
that
meeting
as
well
as
offline,
and
if
there's
no
concerns,
we
can
go
ahead
and
get
that
urge
that,
for
that
and.
C
A
C
Maybe
a
couple
days
before
that
next
meeting
send
out
a
message
to
community
six
Lords
and
say:
hey
we're
gonna
have
the
fourth
lunch
kept
review
if
you're
interested
in
this
at
all
now's
the
time
to
kind
of
jump
in
okay.
If
you
look
and
if
you
have
any
feedback,
you
know
you
can
provide
it
in
the
meeting
or
offline.
C
A
Sounds
great
to
me
so
in
terms
of
the
rest
of
this
meeting,
I
had
hoped
to
get
a
few
more
administrative
aspects
related
to
this
cap
done
last
night
and
I
didn't
get
to
him.
So
all
I've
done
is
taken.
Some
notes
didn't
I
met
yesterday
to
just
go
over
how
rules
were
who's
doing
what
kind
of
right
now
Syd
wanted
to
make
sure
it
was
really
clear.
There's
no
hierarchy
in
this
role.
Obviously
I
mean
standard,
good,
kubernetes,
open
source
practices.
Everyone's
opinion
matters
here
it
doesn't
matter
as
SIDS
technical
lead.
A
A
I
think
we
got
some
feet,
there's
a
repo
issue,
sort
of
as
if
I
kind
of
wrap
up
some
administrative
sides.
We
have
this
repo
or
an
organization
and
github
container
optic
storage
interface,
but
the
feedback
we
got
was.
We
should
be
using
personal
repos
and
and
then,
when
the
caps
merged,
we
would
do
PRS
out
of
them.
I
don't
know
Syd
and
I
thought
we
should
just
use
this
container
object,
storage,
interface
organization
as
it
is,
and
it's
just
kind
of
a
shared
personal
repo-
is
that
okay
Saunders?
C
Why,
though,
I
think
there's
just
weirdness
around
potential
legal
issues?
If
you
have
something
that's
been,
I
was
like
a
trademark
on
it
potentially,
so
I
would
just
just
to
avoid
all
of
that,
like
the
way
that
we've
been
doing
it
classically,
which
is
you
fertility
poison
in
the
arts
against
the
official
replays
I'm,
not
a
lawyer,
though,
so,
if
we
really
want
dig
into
it,
we
can
reject
Chris
again
well,.
A
A
Right
I
mean
that's
why
it
makes
some
of
you
probably
heard
of
this
repo
that
we
have
that
red
hat
called
yard
Turkey,
and
it's
for
just
like
it's
just
an
unofficial
name.
In
fact,
it's
a
weird
name:
no,
whatever
mistake
it
for
something
official
and
it's
a
shared
collaborative
repo
and
that's
all
we
were
looking
for
with
this
one.
C
A
A
C
I
think
that's
fine
to
do
on
the
official
repo,
because
what
we're
going
to
do
their
official
repo
is
you're.
Gonna
have
multiple
branches
right
then
you'll
have
the
master
branch,
where
you
guys,
can
collaborate
and
get
stuff
merged
and
get
your
fruits
of
concept
going.
You
can
iterate
on
that,
get
it
into
a
quality
that
you
think
is
ready
for
some
sort
of
you
know
0.1
release
and
when
you're
ready
for
that,
you
can
cut
a
branch
off
call
that
0.1
create
an
official
release.
C
B
D
A
A
C
B
C
B
Is
the
CSA
adapter
right,
cine
right?
Yes,
okay,
so
see
a
doctor
is
responsible
for
taking
the
credentials
from
the
bucket
and
bucket
axis
objects
and
presenting
them
to
the
part.
That's
going
to
consume
it.
The
component
that
creates
the
bucket
in
bucket
axis
objects
is
called
the
cosy
controller,
the
controller.
So
we
need
one
for
that.
B
C
Okay,
so
it
sounds
like
two
more
one
for
the
controller
one
for
the
sidecar
I
think
it
makes
sense
to
have
one
common
controller
that
you
put
everything
into
yeah.
No
objection
to
that
I
think
if
you
want
to
go
ahead
and
start
a
opening
issue
to
get
that
created,
I
will
run
you
for
the
sidecars,
given
how
we
ended
up
with
multiple
sight:
cars
on
the
CSI
side,
I'm,
okay,
with
us,
creating
a
sidecar,
but
let's
make
sure
that
the
name
is
kind
of
a
little
bit
more
descriptive.
C
A
C
So
I
need
to
go
back
and
check.
Maybe
she
knows,
but
there
is
a
status
field
on
the
template
and
that
status
says
whether
it's
implementable
really
quickly,
but
I
believe
what
we
could
do
is
not
set
the
status
to
implementable,
and
that
gives
us
a
little
bit
more
leniency
to
say:
hey
the
cap
is
kind
of
in
progress.
It's
not
final
yet,
and
so
we
get
a
initial
revision
of
the
cap
in
and
then
we
revise,
revise,
revise
until
we
say:
okay,
it
is
implementable
as
alpha
I
think
that
should
be
sufficient.
D
C
Mean
ultimately,
you
know
this
is
with
it.
Sig
storage
and
the
six
storage
leads
are
the
ones
that
have
to
ultimately
approve
this
stuff,
and
so
we
can
to
some
extent,
come
up
with
our
own
rules
here
and
do
what
makes
sense
and
do
what
the
right
thing
is
to
do
like.
We
don't
want
process
to
get
in
the
way
of
progress
right,
and
so
the
right
thing
to
do
here
is:
let's
unblock
a
proof
of
concept
and
to
do
that.
C
I
think
what
makes
sense
is
let's
get
a
cap
merged
in
some
sort
of
preliminary
state
and
make
sure
the
status
is
not
saying
that
it's
implementable,
then
you
guys
can
start
your
POC
but
continue
to
work
on
the
cap
and
get
it
into
a
state
where
it
has
everything
required
for
alpha,
and
then
we
can
kind
of
flip
the
switch
and
get
it
to
an
alpha.
Does
that
folks
agree
with
that.
C
D
D
C
But
let's
do
this
so
I
think
all
of
that
is
required
for
an
alpha
right,
yeah,
an
official
API
review
and
everything
for
alpha.
We
need
a
fully
fleshed-out
kept
for
an
alpha,
but
it
shouldn't
block
a
proof
of
concept,
and
so
what
we
can
do
is
like
on
the
repos,
where
we
are
checking
in
these
early
drafts.
Put
a
repeat
that
says:
current
status
is
proof
of
concept.
C
If
this
is
not
yet
alpha
ready,
you
know
put
a
disclaimer
on
there
and
then
that
allows
us
to
unblock
the
proof
of
concept,
get
something
going
and
then
once
the
cap
gets
to
an
implementable
final
status
gets
official
approval
for
alpha
on
the
C
or
DS.
Then
we
can
get
that
official
enhancement
cap
merged,
and
then
we
can
come
back
and
create
revisions
to
our
repos
and
get
them
into
an
alpha
state
to
reflect.
F
C
It's
really
hard
to
write
a
fully
fleshed-out
cap
without
actually
writing
some
code.
And
realistically
what
happens?
Is
you
put
down
some
bots?
You
create
a
POC,
then
you
come
back
and
revise
it.
So
I
think,
let's
do
it
in
that
order.
Let's
get
a
cap
down
that
says.
You
know
this
is
for
the
initial
proof
of
concept
and
then
get
the
proof
of
concept
in
and
then
revise
the
cap
for
an
alpha
and
then
get
the
pulling
the
official
API
reviewers
and
all
of
that
to
get
get
a
more
a
thorough
review.
Okay,.
A
Great,
so
we're
we're
about
halfway
and
I
wanted
to
have
a
chance.
If
there's
some
technical
discussion,
he
wants
to
run
right
now,
but
before
we
get
there
and
since
we
have
a
sort
of
momentum
on
the
administrative
aspects
of
things,
what
so
we're
going
to
do
a
review,
meaning
a
full
full
review,
meaning
of
the
cap
or
week
from
today
we'll
invite
six-story
and
let
them
know
about
that
meeting.
The
purpose
of
that
meeting
will
be
to
go
over
the
cap,
make
sure
there's
no
big
issues
and,
and
then
Mergent
it's
not
frozen.
A
It
can
still
change
code.
I
agree
with
you
saw
it
all
the
time.
That's
my
experience.
You
write
code
and
you
realize
oh
yeah.
We
didn't
think
about
that.
We
and
you
change
and
the
codes
right.
You
need
to
change
the
cap
to
reflect
the
code,
and
so
we
will
do
is
that.
Are
there
any
other
I'm
thinking
of
just
mine
and
Aaron's
role
as
administrative
leaves
here?
Are
there
any
other
thresholds
or
roadblocks
you
see
ahead
of
us
that
we
need
to
start
paying
attention
to
to
get
it
merged.
C
A
A
D
So
for
the
for
the
recording
yeah,
so
I
can
help
with
recruiting
apart
my
think
in
the
past
John
to
record
and
send
it
to
me
and
then
upload
it,
but
that's:
okay,
I
can
record
it
and
upload
it.
He
to
our
playlist,
so
I
wonder
if
sad
shoo-ee
product
creator
seperate
the
playlist
just
for
this
one,
because
this
one
has
the
regular
meetings
right
now.
I
added
this
to
you,
the
owner
is
a
general
place
for
everything
part
you
create
one
for
this.
Just
for.
D
C
B
A
A
B
C
F
C
D
D
D
C
A
Okay
yeah
there
so
I
will
keep
this
there's
some
thoughts
from
Johnson
API
stuff
he's
got
a
he's,
got
a
directory
or
folder
for
meeting
notes,
but
it's
just
links
so
yeah.
It
doesn't
look
like
it's
active
right
now.
The
most
recent
date
is
June.
15
Iran
said
who
posted
some
API,
spec,
okay,
I,
think
that
can
wrap
up
the
admin
side
of
things
for
now
feel
feel
free
to
add
anything
to
chat.
If
you
think
about
it,
Syd
do
you
wanna
yeah,.
F
B
So
the
first
thing
I
want
to
talk
about
is
who's
contributing.
What
are
you
working
on
and
what
our
goals
are?
So
John
took
care
of
a
lot
of
this
and
pretty
much
solidified
the
architects
of
the
topology
of
the
different
components
after
John
John
actually
went
ahead
and
implemented
the
API
spec
and
the
API
generated
all
the
code
that
can
be
done
for
it,
the
controllers
and
the
Lister's
Informers
and
such
so
I
first
go
into.
Who
is
working
on
writing
code
right
now,
so
we've
got
like
Jeff
mentioned
earlier.
B
F
There
is
I'm
testing
the
paper
hit,
so
there
is
a
driver
library
which
ICM
is
required
just
like
the
CSI
has
to
to
do.
The
GRC
falls
over
and
that
would
probably
become
a
library
or
a
sidecar
that
gets
attached
to
the
driver
side
of
things
so
and
currently
we
also
need
to
develop
some
at
least
test
or
mock
driver
ability
to.
F
B
So
you're
talking
about
the
controller
that
would
work
with
the
provisional
to
provision
the
bucket
right,
all
right,
okay
and
you're
building
the
framework
for
it
right
got
it.
So
the
third
person
that
I
had
just
invited
today
is
a
person
named
registry.
She
was
on
the
call
until
10:30,
but
she
had
to
hop
off
at
10:30.
So
as
of
now
srini
and
Rob
and
Roger,
she
also
has
given
me
a
commitment
of
something
like
four
to
eight
hours
a
week.
So
so
we
can
say,
we've
got
three
people
working
on
it,
including
me.
B
C
In
my
head,
you
got
to
start
with
the
spec
right
if
you
can
get
some
really
early
version
of
the
spec
out
that
everybody
kind
of
agrees
on
that's
a
good
place
to
start
and
build
off
of,
because
every
other
component
that
you
build
is
likely
going
to
depend
on
that
stack
right,
maybe
focus
on
getting
back.
Getting
the
go,
builds
going
getting
that
old
structure
laid
out,
I
think
that'll
be
a
significant
effort.
B
B
F
So
I
talked
to
rob
and
then
what
we
decided
is
create
bucket
requires
just
a
bucket
name
and
Driver
parameters
where
we
will
have
other
details
like
GCS
needs,
a
project
name
and
whatnot.
The
different
details
will
be
in
there,
but
the
main
question
was
how
we
send
the
often
auth
token
and/or
other
credentials
to
connect
and
make
a
actual
provider
call
to
create
the
bucket
I.
F
Think
we
sorted
that
out.
We
will
follow
the
same
way
like
a
probationer
secret
or
something
that
that
will
have
the
details
on
the
on
the
on
how
we
we
read
the
token
and
and
pass
it
on
to
the
driver
to
make
the
external
call.
We
are
only
concentrating
on
the
create
bucket.
We
haven't
talked
about
the
little
bucket.
That
has
some
other
lifecycle
issues
associated
with
it.
I
guess-
and
this
is
for
Greenfield
only
so
we
still
haven't,
talked
about
the
brownfield
case.
B
Yeah,
so
in
terms
of
what
would
you
know
extrapolating
that
we
would
need
create
bucket
delete
bucket,
possibly
some
form
of
grant
permission
as
bucket
gets
shared
between
multiple
consumers,
and
obviously
this
would
have
to
work
for
both
greenfield
and
brownfield,
at
which
point
I
think
we
can
call
it
MVP.
What
does
everyone
think
about
that?
Whoa.
F
B
C
Yeah,
that's
a
good
question:
what
what
is
MVP
in
your
head,
alpha
yeah,
so
alpha
requires
API
approval.
We
need
to
kind
of
get
that
reviewed
by
official
API
reviewers
and
have
them
say:
okay,
this
looks
legitimate.
This
looks
fine
before
that.
I
think
for
a
and
I
mean
in
my
head
and
MVP
is
more
kind
of
like
a
POC
yeah,
its
internal
consensus.
It's
the
cap
that
we're
gonna
do
next
week.
C
I
I
would
expect
you
guys
to
kind
of
present
what
you're
thinking
these
calls
would
look
like
and
shake
that
out
there
and
make
sure
there's
agreement
within
you
know
within
sig
storage
to
say:
oh
yeah.
This
looks
fine,
let's
go
ahead
and
you
know
implement
a
early
notice,
but
do
you
mean
the
kubernetes
api
expects?
No.
B
C
B
C
B
So
so
the
other
thing
that
I
wanted
to
do
today
was
kind
of
get
a
consensus
on
just
following
up
on
last
week's
meeting.
I
think
John
and
the
rest
of
us
were
talking
about
delete
bucket
I,
couldn't
I
wasn't
available
for
the
whole
meeting,
so
I
actually
lost
track
halfway
through.
But
if
someone
can
update
me
on
what
the
final
resolution
was,
if
you
know,
or
did
we
even
reach
a
resolution
about
three
buckets
whatever
the
discussion
was
I.
C
C
A
A
C
Alright,
but
then
I
think
been
raised,
some
questions
around
user
experience
and
if
you
did
that
it
would
fill
up
the
error
logs
and
that's
not
the
most
ideal
user
experience
so
how
about
in
the
status?
You
have
an
official
response
which
says
this
is
in
progress.
You
know
try
again
and
that
way
it's
not
logged
as
an
official
error,
but
you
know
you
can
log
it
as
a
warning
or
something
on
the
client-side
or
gonna.
A
A
Great
John
and
I
had
a
bet
that
remind
John
and
I
did
have
a
brief
discussion
last
week
on
that,
and
we
were
because
you
know
the
the
the
status
of
returning
non-nil
sets
up
everything
in
controller
runtime
for
kubernetes
to
keep
retrying
with.
However,
the
smart
people
decided
that
stuff
should
be
retried
exponential,
back-off,
whatever
it
is,
and
so
that
mechanism
is
all
in
place.
We
don't
want
to
reinvent
anything
like
that.
A
So
if,
if
there
was
a
way
to
know
that
the
return
from
the
provisioner
was
a
non
Mill
status
but
was
just
informational,
then
we
can
use
the
mechanism
I,
think
that's
what
John
and
I
were
worth
were
aiming
for.
Last
time
we
talked
about
it
does.
Does
that
make
sense
to
you
guys
and
and
the
folks
on
the
call
yeah.
C
C
A
C
C
G
A
G
D
D
C
H
D
C
So
I
think
the
easiest
thing
to
do
is
have
all
the
call.
All
the
other
calls
be
synchronous
for
the
delete.
What
we're
doing
is
a
sink,
but
it's
kind
of
it's
not
like
a
full-fledged
async
protocol
right,
we're
not
going
to
return
an
operation
ID.
That
was
the
simplification
that
been
raised
last
time.
All
we're
doing
is
just
doing
the
same
kind
of
synchronous,
call
that
will
immediately
return
and
it
will
have
a
boolean
that
will
say
I'm
not
done
yet.
D
B
C
Way
so
that's
the
nice
thing
about
having
the
sidecar
is
that
we
we
write
the
sidecar
we
created
and
so
will
give
an
opinionated
sidecar.
That
does
the
right
thing,
and
so,
as
a
plug-in
author
Cosi
plugin
author,
I
don't
have
to
worry
about
those
details.
I
will
just
take
the
sidecar
that
we
created
and
then.
D
A
G
B
And
they
expect
you
to
be
an
important
okay,
yeah,
that's
fair,
we're
good,
okay,
I!
Think
that
clears
up
that.
So
so,
just
to
summarize
we're
saying
that,
because
the
list
can
take
a
long
time,
we
want
to
make
sure
that
it
doesn't
become
a
blocking
operation.
So
we're
going
to
do
it
in
asynchronous
way
and
as
far
as
the
plugin
author
is
concerned,
they
can
just
implement
it
like
usual
and
our
GRDC
time,
or
it
will
naturally
time
it
out
and
put
it
at
the
back
of
the
queue.
C
Yeah
I
think
you
know
on
the
like,
like
been
said
as
a
plugin
author,
it's
up
to
you.
You
can
decide
to
immediately
return
if
you
choose
to
or
if
you
think
it's
gonna
be
relatively
quick,
you
can
spend
another
5-10
seconds
or
whatever
the
client
side,
we
should
be
able
to
handle
both
of
those
cases.
As
long
as
we
get
a
response
within
a
reasonable
amount
of
time.
It's
a
valid
response.
If
it
says
it's
still
in
progress,
we
handle
that.
You
know
just
like
exponential
back-off.
Your
pc
time
out
has
to
be
treated.
H
C
So
if
you,
if
you
create
a
bucket
initially
the
status,
is
that
it's
pending
provisioning
and
until
the
bucket
is
officially
confirmed
to
be
provisioned,
that
status
will
remain
that
way
and
then
on
the
deleting
side.
You
know
your
status
or
main
deleting
until
you've
actually
deleted
the
underlying
resource.
C
What
it
actually
means
in
practice
for
deletion
is
that
there
is
a
deletion,
timestamp,
that's
put
on
the
object
and
the
object
is
not
actually
deleted
until
the
underlying
resources
deleted,
there's
a
finalizer
on
there
and
that
finalizer
is
not
removed
until
the
object
is
actually
physically
deleted.
The
bucket
is.
C
Yeah
so
basically
give
up
would
be
kubernetes
doesn't
give
up
until
you
know
somebody
forces
it
or
tells
it
to
stop
and
say
if
you're
trying
to
delete-
and
you
know
it's
taking
days
and
it
has
been
deleted,
the
force
option
is
that
a
kubernetes
user
could
go
in
and
force
remove
that
finalizar
and
then
the
kubernetes
system
will
say:
okay,
there's
no
finalizar
I'll
go
ahead
and
delete
this
object.
When
the
object
is
gone,
then
our
controllers
look
at
that
and
stop
trying
there's
no
more
object.
No
more
retries.
B
H
C
H
C
A
B
A
I
B
I
B
I
E
C
A
A
Okay,
going
once
no
okay,
so
Sid,
do
you
have
anything
any
short,
other
technical
thing,
I
think
that's
it
from
me.
Okay,
I've,
taken
some
notes,
I
work,
seeing
I
will
contact
you
and
figure
out
what
I,
what
role
I
might
have
or
action
I
need
to
do
to
get
this,
the
notes
and
the
recording
upload
to
the
correct
location
and
will
sure
we'll
call
it
good.
Yeah
I
appreciate
just
hang
with
us
a
little
bit.
The
the
transition
is
just
going
to
be
a
little
rough.