►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review - 10 September 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
Okay,
so
since
we're
starting
the
recording,
now,
I'm
just
going
to
repeat
what
I
was
saying
earlier.
So
what
I
wanted
to
focus
on
mainly
today
is
the
planning
for
agenda
of
this
group.
B
So,
as
of
last
week,
we
left
off
at
a
point
where
we
all
were
more
or
less
comfortable
with
the
overall
design
of
cozy.
B
We
hashed
out
issues
around
deletion
of
buckets
and
how
buckets
bucket
deletion
will
behave
if
a
bar
is
using
that
bucket
and
after
that
discussion
we
went
into
discussing
what
are
the
steps
for
merging
the
cap
and
and
what
are
the
open
questions
left
on
that
one
of
the
things
that
was
brought
up
was
we
can
we
can
take
the
cap
forward
in
one
of
two
forms?
B
B
So
I
just
wanted
to
lay
out
the
timeline
and
and
make
a
decision
on
on
whether
we
should
go
the
provisional
route
or
the
implementable
route.
It's
it's
an
open
question
and
and
based
on
based
on
what
everyone
thinks
and
based
on
what
will
be
best
for
this
group.
I
want.
I
want
to
together,
decide
how
to
take
this
forward.
So
the
if
we're
going
the
provisional
route
we
can.
We
can
start
with
the
care
preview
right
now.
B
B
We
can
start
contributing
to
the
official
repos
right
away
and
I
think
it's
a
very
important
step
where,
when
we
can
start
contributing
to
the
official
reports,
one,
it
introduces
a
rigorous
process
of
review
instead
of
us
contributing
code
on
our
own
private
repos,
two,
the
the
people
who
review
it
are
going
to
stay
more
or
less
consistent,
so
the
code
quality
is
going
to
remain
consistent
as
well
and,
and
it
also
brings
visibility
into
the
project
I
mean
the
the
everyone
else.
B
Who's
interested
in
the
project
will
easily
be
able
to
find
out
where
this
project
resides
and
get
some
visibility
into.
What's
going
on,
and
then,
as
soon
as
we
start
contributing
to
official
reports,
I
think
we
can
start
aiming
for
alpha
and
and
when
we
start
aiming
for
alpha
that
at
that
point
will
be
taking
the
cap
from
this
provisional
form
to
the
next
form,
which
is
the
implementable.
B
Assuming
we
actually
started
with
the
trying
to
merge
the
campus
and
implementable
one
we'd
have
to
start
with
the
api
review
right
away
now,
as
per
my
understanding-
and
please
correct
me,
if
I'm
wrong,
the
api
approval
process
can
take
a
few
months,
given
people's
availability
and
and
also
considering
that
this
is
the
first
time
we're
going
through
an
api
review.
I
think
two
to
three
months
is
a
reasonable
estimate,
but
there
might
be
some
of
you
here,
who've
done
this
before
and
have
a
better
estimate.
B
If
so,
please
let
us
know
once
approval
is
done.
We
go
through
the
same,
merge
and
review
process
and
right
after
that,
we
can
start
contributing
to
official
reports.
If
you
have
gotten
anything
wrong
here,
please
do
let
me
know
so
so
this
is
what
it
looks
like
going:
either
provisional
or
or
implementable,
regardless
of
how
we
go,
my
estimate
is
it's
going
to
be
version
121
when
we
can
actually
have
the
alpha
release.
B
C
A
D
C
B
Yeah
yeah
it
would
it
would
so
it's
better
to
have.
Actually
so
are
you
saying
we
could
maybe
even
hit
120
if
we
go
this
route.
A
I
think
it's
a
if
you
look
at
the
timeline,
it's
it's
like
one
less
than
one
month,
one
month.
That's
basically
you
need
to
get
this
one
reviewed
by
api,
reviewers
and
approved
merged.
We
could
try,
but
I
think
it's
it's
tough.
I
just
look
at
the
you
know
the
time
look
at
when
that
is
right.
Yeah.
A
I
think
code
freeze,
we
have
more
time
actually,
because
this
is
out
of
tree
right.
So
we
can
actually
do
this
code
freeze.
We
can
do
this
after
november
12th,
but
I
think
the
the
cap
freeze
that
that
deadline
october
6th
that's
very
soon.
It's
roughly
one
month,
actually
a
little
bit
less
than
one
month
so
yeah.
It
will
usually
takes
pretty
long
for
the
api
review
to
go
through
for
something
so
so
big
and.
F
Right,
I
think
I
think
we
on
the
on
the
you
know.
Core
cap
team
are
assuming
that
a
provisional
approval
of
the
cap
and
the
ability
to
use
official
repos
will
encourage
contribution
and
will,
as
has
been
suggested,
make
the
api
review
that
we
need
down.
The
road
happen
a
little
quicker
because
we'll
have
working
code,
so
we
can
show
them
our
structures
and
the
api
and
so
forth,
schema
and
and
and
know
that
it
works.
F
Bill,
if
we
try
to
do
what's
the
most
expedient,
what's
not
compromising
quality,
we
can
go
provisional
coding
contribution
api.
You
know
in
parallel,
get
this
api
review
going
iterations,
probably
based
on
the
api
review
and
then
shoot
for
an
alpha,
or
we
can
do
the
api
review
now
get
that
set
up.
We
have
just
the
couple
of
people
coding
and
not
in
official
repos,
and
try
to
go
straight
for
a
alpha
or
implementable
approval
of
the
cap.
We're
proposing
the
former.
Is
there
any
input
to
say?
B
The
one
thing
is
having
code
for
api
review,
I
would
rather
have
code
in
you
know:
that's
gone
through
a
proper
review
process.
That
is
whose
quality
is
checked
for
every
comment
or
every
pull
request,
and-
and
I
think
it
will
also
give
more
confidence
to
people
that
are
reviewing
the
code
rather
than
having
it
outside
of
kubernetes.
B
G
Yeah,
I
agree,
I
think
I
mean
what
would
be
the
the
downfall
of
going
the
provisional
route
like
what
could
it
cause
a
I
mean
there
has
to
be
some
reason
why
you
wouldn't
want
to
go
that
direction
like
we
would
get
to
write
a
bunch
of
code.
I
guess
that's
the
risk
right.
You'd
write
a
bunch
of
code,
go
to
the
api
review
and
they'd
say
we're
never
going
to
approve.
This.
H
Yeah,
I
think
it's
exactly
what
sid
said,
which
is
you
know
you
can
when
you're
getting
code
merged
into
these
repos,
while
it's
provisional
effectively
it's
a
poc,
and
you
know
it
hasn't
gotten
gone
through
the
official
review
process,
and
so
every
commit
is
kind
of
just.
You
know.
We
think
it's
cool,
but
it
hasn't
gone
through
like
an
official
review
process.
H
B
Yeah,
I
I
think
provisional
does
seem
like
the
better
approach
assad.
You
mentioned
that
so
what?
If?
What?
If
we're
the
ones
that
are
actually
reviewing
the
code
in
the
sense
that
what
if
we
had
some
members
from
well,
it's
it'll
be
in
the
kubernetes
official
repos.
So
when,
whenever
a
pull
request
is
made,
if
some
of
us
are
the
ones
that
are
that
are
actually
reviewing
the
code
and
and
getting
it
merged
into
the
official
repos,
would
it
still
be
considered?
You
know
we
think
it's
cool
type
of
code.
H
I
think
technically,
yes,
because
we
haven't
gone
through
official
api
review.
Nobody
within
this
group
is
an
official
api
reviewer.
B
H
So
there
is
that,
but
I
I
you
know
I
I
don't
disagree-
that
this
might
be
the
better
approach.
I'm
just
calling
out
the
issue.
I
B
So,
knowing
that
and
knowing
that
upfront
that
that
there
is
a
possibility
that
we'll
have
to
change
the
api,
maybe
even
entirely
likely
not,
but
you
know
not
throwing
that
possibility
out
if
we
all
know
that
and
if
we
go
in
with
that
mindset,
I
think
you
know
the
mindset
where
we're
open
for
change,
we're
ready
to
come
back
to
the
drawing
board
if
needed
and
and
fix
it.
Would
it
would
that
be
okay
to
go
provisional.
B
Okay,
okay,
I
think.
H
I
mean
one
thing:
is
you
know,
will
we
have
to
be
open
to
changing
it
in
the
future?
If
api
reviewers
ask-
and
the
second
is
accepting
that
the
timeline
is
looking
like,
it
will
be
at
least
121
for
an
alpha
which
both
of
which
I'm
okay,
with.
B
Okay,
okay,
yeah!
So
let
let's
go
with
the
provisional
approach,
so
let
me
ask
srini
and
jeff:
what's
the
status
that
kept
now,
do
we
have
everything
needed
for
the
provisional
approach.
F
I'm
since
it's
it's
not
the
it's,
not
the
typical
workflow,
I
don't
know
what's
needed
for
provisional.
That's
what
we're
I
mean.
I
think
that's
kind
of
we
have
sad
shane
on
the
call
and-
and
I
think
we
need
their
guidance
on
what
are
the
requirements
for
provisional.
So
we
can
merge
the.
J
Cap
provisionally,
as
per
my
understanding,
it's
it's
a
pretty
well
understood,
requirement
right
for
provisional.
B
A
You
don't,
I
don't
think
you
have
to
fill
out
all
of
those.
You
know
what
production
readiness
those
type
of
things
right,
I
think
mainly
just
if
we
agree
with
the
design,
then
probably
it's
fine.
You
know
just
to
address
all
the
comments
and
making
sure
there's
no
major
objections.
I
B
I
H
E
B
All
right,
so,
let's,
let's
aim
for
that,
so
I
guess
what
I
would
request.
All
of
you
is
please
take
it
take
some
time
this
week
to
go
over
the
cap.
If
you,
if
you
get
a
chance
to
you,
know
even
if
you're,
just
looking
at
the
parts
that
are
most
relevant,
your
most
interesting
to
you,
the
combination
of
all
reviews
will
cover
the
entire
cap,
so.
B
Okay,
so
if,
if,
if
you
take
some
time
and
and
leave
us
your
comments,
that'll
help
a
lot
and-
and
we
can,
we
can
start
moving
forward
with
with
the
next
steps
quickly.
B
B
So
that's
that's
my
request
from
all
of
you,
so
today
my
main
agenda
was
the
planning.
I
I
wanted
to
simply
only
focus
on
this,
because
I
wasn't
first
of
all,
entirely
sure
how
long
it
would
take
to
consider
these
two
approaches
and
also
I
wanted
to
keep
the
focus
pretty
straightforward,
so
the
rest
of
the
time
either
we
can.
B
I
wanted
to
ask
you
if
any
of
you
have
any
concerns,
questions
or
suggestions.
If
not,
I
think
I
think
we
can.
We
can
end
the
meeting
once
once
we're
all.
You
know
there
are
no
more
concerns
left.
J
C
A
once
we
have
a
cap
provisionally
approved
and
we're
able
to
use
the
repos,
and
so
we're
writing
the
code.
Maybe
you
guys
have
talked
about
this
before
and
I
just
wasn't
there
do.
We
have
a
plan
to
like
have
a
an
open
source
reference,
implementation
and
any
kind
of
testing
to
test
conformance
and
to
develop
that
in
parallel
with
the
code
itself,
so
that
we
can
ensure
quality
and
no
regressions
as
we
go.
B
What
do
you
mean
by
open
source
reference
implementation.
C
I'm
thinking
of
some
sort
of
you
know
functional
tests
or
something
more
than
unit
tests
that
you
can
run
on
every
commit
to
make
sure
you
break
something
and
that
sort
of
implies
that
there's
a
reference
cozy
implement
like
so
for
csi.
We
had
the
csi
host
path,
driver
and
kubernetes
right
and
that's
just
like
an
open
source,
really
dumb
driver,
but
it
implements
the
standard,
and
so
you
can
make
changes
and
say
well.
Did
it
break
no?
Okay,
it's
a
good
change,
or
at
least
it's
not
a
horrible
change.
B
I'm
glad
you
brought
that
up.
Actually
so
so
so.
First
of
all
we
have
krish
on
the
call
krish
is
has
been
contributing
to
the
testing
and
he
started
mocking
the
driver
itself.
But
but
to
do
it
more
functionally,
it
might
be,
you
know,
minio
is
you
can
set
it
up
on-prem,
it's
it's
a
very
simple
tool
to
set
up,
and
you
know
it's
s3
compatible
in
terms
of
create
buckets
and
assigning
roles
and
and
credentials,
etc.
B
It
only
supports
the
sd
api.
It's
not
just
compatible
and-
and
you
know
you
can
switch
over
the
aws
s3
client
with
minion
client
and
vice
versa,
and
it
just
works
out
of
the
box
disclaimer.
I
work
for
mineo,
but
I
think
that
would
be
a
good
start
for
writing
functional
tests
where
we
we
deploy.
You
know
single
node
minio
and
write
our
tests
against
it.
H
Are
there
any
licensing
concerns
or
is
it
available
for
free?
It's.
K
Is
there
also
an
option
to
to
put
in
the
repo,
maybe
a
folder,
where
we
can
put
more
examples
for
for
how
you
know
starters
starter
drivers
like
that?
Yes,
so.
K
Maybe
run
it
like
through
some
like:
have
the
ci
run
all
these
examples?
That
would
be
like
a
very
nice
coverage
way.
H
So
where
would
I
find
that
ripple?
That
is
a
good.
E
Patrick
foley
is
working
on
that
right.
That's
the
one.
H
A
H
D
H
Yeah,
the
way
that
those
kubernetes
end-to-end
tests
are
designed
is
that
you
can
pull
those
out
and
kind
of
run
them
independently
against
a
specific
csi
driver,
and
we
we
do
exactly
that
for
for
testing.
So
I
think
that's
a
good
model
to
follow
and
it
looks
like
it's
under
kubernetes
kubernetes,
e2e.
K
H
C
D
A
H
Yeah,
I
think
the
host
path
driver
has
really
ended
up
becoming
our
mock
driver
for
csi
and
the
way
that
it
tends
to
work
is
whenever
a
new
piece
of
functionality
is
introduced
for
csi.
A
C
A
H
One
is
a
a
mock
driver
and
the
csi
sanity
test,
similar
to
that
which
is
basically
unit
tests
that
you
can
run
on
the
driver
itself
and
then
the
second
level
is
to
have
kind
of
a
dummy
driver
that
you
can
use
for
kind
of
integration
testing
and
whenever
you
add
a
new
feature,
you
extend
that
dummy
driver
and
then
the
third
level,
I
guess,
is
full
end-to-end
test
which
a
lot
allow
you
to
swap
out
the
driver.
L
Okay
tests
and
then
like
integration
tests
with
the
yeah,
the
basically.
L
H
For
unit
tests
there's
you
can
have
a
set
of
unit
tests,
plus
a
mock
driver
for
integration.
You
can
have
a
a
dummy
driver
and
for
end-to-end
tests
you
can
have
a
set
of
tests
that
allow
you
to
swap
out
the
driver.
B
H
So,
okay,
so
as
I
understand
it,
we
don't
actually
have
a
set
of
integration
tests.
We
just
have
a
dummy
driver
that
can
be
used
by
the
end
to
end
tests.
C
H
C
E
H
H
B
L
H
G
G
H
Okay,
so
one
thing
I
would
change
here
is
end-to-end
test
against
sample
driver
and
change
that
to
arbitrary
and
sample
driver.
B
All
right,
I'm
gonna,
write
this
as
alpha.
C
A
I
think
it's
not
required
for
us,
I
mean
it's
good
to
have.
You
can
have
everything.
Of
course
it's
great,
but
at
least
you
need
to
have
some
unit
tests
and
have
some
more
drivers.
H
H
B
Yeah,
that's
that's
true.
Let's
aim
to
have
e2e
for
this.
I
think
srini
here
has
actually
worked
on
this
before
right.
Srini,
you've
set
up
the
test
and
prep
for
for
a
different
project
in
kubernetes
yeah.
Well,.
E
I
did
add
jobs,
but
are
we
going
to
integrate
with
the
testing
for
us
ai
at
some
point
in
time
right,
I
think
so.
B
Perfect,
okay
and
krish
is
also
available
to
help
you
with
that.
So
we
can.
We
can
get
started
on
that
quickly.
B
Okay,
any
other
concerns
we're
going
to
talk
about.
E
So
at
this
point
we
can
start
prepping
the
repos
to
to
allow
code
in
right.
I
mean
at
least
before
the
cap
merges
like
things
like
you
know,
the
template
files
and
all
those
things
that
are
required.
So
what
template
files
like
there
is
a
lot
of
this
automatic
build
file.
Stuff
and
oh.
H
E
B
And
on
the
pull
request,
you
know
whenever
there's
a
new
pull
request.
Sorry,
no!
Whenever
there's
a
new
issue
generally,
there's
a
there's,
a
template,
that's
there
I
don't
know
yeah.
We
should
have
that
many
times.
People
may
not
ask
us
questions
giving
us
all
the
information
we
need.
We
should
have
that
and
maybe
even
create
whatever
labels.
Okay,
we
already
have
the
labels
and
stuff
yeah.
H
I
would
suggest
reaching
out
to
kind
of
kubernetes
org
folks
and
making
sure
that
we
align
with
whatever
the
larger
community
is
doing
as
much
as
possible.
With
these
things
got.
B
It
got
it
okay,
all
right,
so
we
can
get
started
on
that
and
then
we
will
yeah
we'll
start
making
progress
on
that
and
and
next
week
you
know
we'll
know
where
we're
at
in
the
meantime.
You
know
please
take
some
time
to
review
the
cap.
We've
brought
it
to
a
level.
B
We've
brought
it
to
the
extent
where
it's,
I
think
every
comment
has
been
addressed
so
please
go
over
them
and
and
if
you
have
any
other
concerns
bring
them
up
and,
like
I
said
earlier,
if,
if
you
can
review
even
just
the
parts
that
are
most
relevant
or
interesting
to
you,
that
will
contribute
to
the
overall
review
of
the
cap
and
and
we
would
have
covered
all
the
different
parts
that
way
so
yeah,
that's
yeah!
That's
it!
That's
it
from
me.
E
B
So
it's
in
kubernetes
csi
and
what
am
I
looking
for?
Release.
B
B
There
does
that
is,
is
that
the
intention
zhang
is
that
how
we
want
to
take
it
just.
A
B
Okay,
got
it,
okay,
got
it
all
right,
yeah,
that's
it
from
me:
we
will,
we
will
take,
you
know,
go
back
and
you
know
use
the
resources
that
you've
shared
with
us
today
and
you
know
we'll
get
started
on
this.
This
administrative
tasks
of
setting
up,
repos
and
and
templates
for
the
issues
and
stuff
and
then
we'll
go
from
there
in
the
meantime,
I'll
look
forward
to
your
reviews
and
and
yeah
we'll
respond
to
that
simultaneously.
H
All
right,
one
more
thing
I
had
is:
whoever
owns
github.com
container
object:
storage
interface.
Can
you
please
update
that
to
start
pointing
to
the
new
kubernetes
repos
and
trying
to
say
this
is
deprecated,
don't
use
it.
F
L
H
And
maybe
archive
the
existing
repos
that
are
underneath
that
org
just
to
make
sure
people
don't
get
confused.
G
B
All
right
yeah,
I
locked
up
the
repost
and
we
can
move
from
there
cool
all
right.
Do
we
have
time?
Okay,
oh
we're
almost
done
with.
They
are
all
right.
I
will.
I
will
talk
to
you
all
on
monday,
for
the
engineering
update,
we've
been
writing
quite
a
bit
of
code
and
and
some
some
new
questions
have
come
up,
so
it'll
be
good
to
go
with
them
on
monday
and
go
from
there
sounds
good
all
right.
Thank
you.
So
much
all
right.
Thank.