►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket Standup Meeting - 09 November 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
Good
morning,
everyone
today,
I
would
like
to
start
off
our
engineering
meeting
by
first
getting
an
update
on
where
we
are
in
terms
of
development,
and
then
we
can.
We
can
talk
about
topology,
which
is
a
discussion
we
were
having
as
of
last
thursday,
and
and
we
can,
we
can
try
and
get
some
closure
on
that
topic.
B
So
I
noticed
that
a
lot
of
new
people
today
so
first
of
all
welcome.
So
this
is
the
slide
here
shows
where
we
are
in
terms
of
development,
for
our
first
milestone,
our
first
milestone.
We
defined
it
as
a
demo
of
the
simplest
use
case
that
cosy
will
enable,
which
is
to
create
a
green
field
bucket
and
create
credentials
for
that
bucket
and
then
provide
those
credentials
into
a
part
that
wishes
to
use
that
bucket.
B
B
So
for
that
here
is
where
the
tasks
shown
here.
Are
the
tasks
required
to
complete
the
demo
and
the
tasks
shown
in
green
are
the
ones
that
are
already
done.
The
tasks
shown
in
black
or
dark
blue
here
are
tasks
that
are
not
required
for
this
demo
and
the
tasks
in
red
needs
to
be
completed
for
the
demo,
so
you
might
notice
there
are
tasks
like
unit
and
functional
tests.
B
Again
for
the
for
the
demo,
we
said
that
we
want
the
code
to
be
as
close
to
production
quality
as
possible,
so
we've
also
included
unit
and
functional
tests.
To
that.
B
So
I
want
to
first
quickly
get
an
update
on
where
we
are
during
this
call
itself,
so
everyone
can
follow
okay,
so
this
is
today
I'll
start
by
I'll
start
with
shrini.
So
shrini,
do
you
want
to
give
a
quick
update
on.
C
Yeah,
I
haven't
made
much
progress
on
the
center
controller
itself,
because
I'm
concentrating
for
the
last
few
weeks
in
setting
up
the
ci
pro
job,
and
so
I
did
a
ptr
out
to
the
the
pro
test,
infra
repo
and
also
started
working
on
the
product,
sh
customizing,
the
release
tools
for
the
for
this
project.
Release
tools
are
pretty
pretty
much
returned
for
csi,
so
there
is
a
bit
of
work
there.
C
I
I
kind
of
finished
that
90,
I'm
testing
it
as
we
go
testing
various
features
like
you
know,
enabling
the
cry
starting
the
client,
a
kind
cluster
running
the
test
and
such
things
so
setting
up
the
the
these.
The
containers
using
you
know
some
deployment
files.
Although
we
decided
different
deployment
strategies,
I'm
doing
simply
ammo
deployments.
C
So
that's
where
I
am,
and
also
on
to
the
official
repos.
I
have
two
main
prs
that
are
outstanding
right
now.
One
is
the
spec
under
the
spec
repo
and
then
the
that's
for
the
the
grpc
definitions
and
the
other
one
is
for
the
api
definitions
and
the
api
repo.
B
Okay,
it's
understood
so
the
I
remember
there
was
a
pull
request
we
were.
We
were
talking
about
to
add.
You
know
approvers
for
the
spec.
Is
that
what
you're
talking
about
or.
C
E
C
Went
through
a
couple
of
passes
and
xing
rightly
pointed
out
that
I
should
do
more
documentation.
I
did
that
to
each
of
these
fields
and
the
api,
and
that's
one
I'm
talking
about
the
other.
One
is
actual
api
definitions
under
the
apis,
so.
C
Outstanding
still
it's
I
have
made
a
pull
request.
Adding
you.
B
Got
it
so
shane?
Do
you
know
what
is
left
for
pushing
that
forward.
F
So
for
that
approval,
pr,
I
think,
sat
is
going
to
take
a
look
of
that
one
right.
So
I
think
the
only
thing
is
the
I
was,
as
I
said
last
time,
the
the
csi
spec
repo.
That
is
really
really
a
very
limited
number
of
approvals,
so
I
was
just
that
was
the
only
reason
I
didn't
approve
the
I
actually
already
had
local
to
meet
this
one.
So
just
waiting
for
someone.
B
Yeah,
oh
no,
I
agree.
We
shouldn't,
we
shouldn't
be
making
changes
that
are
willing
early.
I
mean
I,
I
still
think
one
you
know.
One
of
us
should
be
there,
but
probably
that's
all
is
needed
and
we
shouldn't
be
adding
or
removing
people
very
easily,
just
just
like
for
the
csi
spec,
because
it's
going
to
be
the
standard.
B
I
understand
that
part.
So
thanks
shane,
let's,
let's
go
to
rob,
rob-
is
rob
on
the
call.
A
A
There
so
I
couldn't
get
time
to
work
on
that,
but
I
I
made
some
progress
but
still
working
on
it.
Oh
okay,
the.
B
So
for
those
of
you
new
to
this,
so
we're
writing
a
sample
provisioner,
which
will
be
used
for
our
end-to-end
testing
and
also
functional
testing.
The
sample
provisioner
is
based
on
min
io
and
sargent
has
implemented,
create
bucket
and
grant
access
in
that
provisioner
currently
is
implementing
revoke
access.
Did
I
miss
anything
searching.
B
Yeah
thanks
susan
and
and
it's
okay,
you
know
we
we're
making
good
good
progress
and
moving
fast.
So
when
you
get
a
chance,
please
you
know
you
can
work
on
it
and
if
you
have
any
questions
or
reach
out
to
me
or
anyone
in
the
group.
B
Thanks
and
there's
another
person-
tedious,
oh
rob
here,
hey
rob!
We
were
just
talking
about
you,
howdy,
hey,
so
do
you
want
to
give
us
an
update
on
the
sidecar
controller
and
and
the
you
know,
integration
efforts.
E
There
hasn't
really
been
much
progress
there.
Honestly,
I
just
other
than
what
I
pushed
up
before
the
meeting
we
had
in
the
end
of
last
week
about
protocol
stuff
other
than
that,
and
that
the
the
pr
for
more
of
the
fields
to
get
passed
down
over
the
grpc
protocol.
E
There
hasn't
been
too
much
update.
B
Got
it
so
so,
just
to
kind
of
you
know
summarize
on
where
we
are
in
terms
of
the
sidecar
controller.
We
we
can
currently
do
pretty
much
all
the
operations
and
pass
it
along
to
the
grpc
spec
right
like
create
up.
You
know,
grant
access,
revoke
access
and
delete
bucket.
E
Well,
yes,
and
no,
yes,
the
the
operations
are
there,
but
the
full
data
set
is
not
right.
So
certainly.
E
All
get
there,
the
requests
will
get
certain.
Some
number
of
some
amount
of
data
will
be
in
the
fields
for
their
for
all
their
requests
over
grpc,
but
not
all
of
the
data
is
there
and
and
but
yeah
I
mean
for
the
most
part.
You
know
the
it
will.
The
sidecar
will
act
upon
object
events.
It
will
do
the
next
thing
necessary
things
to
send
the
messages
to
the
grpc
server
with
the
driver.
It
will
update
the
status
in
the
the
bucket
objects
as
needed.
So
from
that
perspective,
yes,.
B
Got
it
okay,
and
I
think
we
had
a
discussion
about
what's
left
some
something
to
do
with
the
protocol
fields.
Correct.
E
Right,
yeah,
the
we
have
protocol
fields,
the
biggest
one
being
since
we
moved
the
name
generation
into
the
driver.
E
The
response
from
the
gr
from
the
create
request
needs
to
have
a
couple
of
fields
in
in
it,
at
the
very
least,
to
call
you
know
the
bucket
name
that
was
created,
and
maybe
the
endpoint
url
needs
to
be
in
the
response
back
and
possibly
more
fields
depending
on
how
the
protocol
information
gets
flushed
out
right,
the
protocol
stuff
that
we
needed.
B
Got
it
okay,
so
yeah,
do
you
want
to
so
there's
two
ways
we
can
do
this
one
is
we
can?
We
can
just
add
the
fields
to
the
respect
that
we
need
right
now
or
we
could
actually
have
the
larger
discussion
about
the
protocol
and
then
based
on
the
outcome,
we
can
make
changes
to
respect
and
move
forward.
That
way,
which
do
you
think
is
better,
I
mean
it's
more
about
like.
Are
you
blocked
right
now
or.
E
That
kind
of
will
depend
on
whether
or
not
we're
blocked
if
we
just
need
and
and
what
the
driver
is
doing
right
now,
because
the
sidecar
right
now
is
not
going
to
generate
a
name
right.
It's
going
to
say,
if
there's
a
name
in
the
bucket
field
or
a
prefix,
it
will
pass
that
information
down,
but
it's
not
generating
a
name
since
we
move
that
into
the
driver.
C
B
I
understood
okay,
okay,
so
so,
let's
let's
do
this,
then,
let's
I
don't
think
we'll
have
enough
time
to
bring
up
the
protocol
discussion
today.
Well,
let's
have
that
on
thursday-
and
you
know,
based
on
the
result
of
that,
we'll
we'll
make
changes
to
this
back
as
needed.
Yep
yep,
okay,.
G
Hi
hey,
so
I
have
a
open
pr
on
sorry
went
to
the
wrong
cozy
controller
manager.
It's
a
question
for
srini.
Basically
there
based
on
the
comment
he
had
made.
It's
a
minor
pr,
just
renaming
the
binary
in
the
docker
file-
and
I
have
you
know
we.
I
did
find
an
issue
with
the
release
tool
that
screen
effects
last
week
in
another
repo.
G
B
Okay,
okay,
yeah,
so
so
I
think
we
decided
okay,
so
we
decided
that
we
will.
We
will
because
we
can't
update
the
spec
repo
or
srini.
What's
what
was
the?
What
was
the
final
decision
regarding
us
making
changes
to
the
temporary
repos
rather
than
upstream.
C
C
Will
tell
us
few
things:
we
barely
rely
on
ourselves
reviewing
the
code
so
so
so.
C
C
Okay,
so
release
tools,
pr
is
just
merged.
B
Okay,
great
so
shing,
do
you
know
how
we
can
move
this
along
faster
because.
F
Oh,
are
you
waiting
for
me?
I
thought
I
did
that.
F
F
F
Oh,
you
know
what
so
let
me
so
I'm
well
I
will
just
I
don't
think
I
can.
I
think
we
need
somebody
else
to
actually
approve
this
one.
So
maybe
I
will
pin
somebody
else,
probably
yeah,
somebody
in
the
infras
team.
Probably
I
will
see.
Let
me
check
the
owner's
phone
and
see
so
yeah.
I
think
this
one
looks
good
should
be
fine
yeah.
I
would
just
give
a
look
to
me
and
then
pin
somebody
and
see
if
we
can
get
somebody
to
take
a
look.
C
C
B
Yeah
I
mean
if
they
respond,
you
know
we
can
also
move
forward.
I
think
should
be
quick
review.
If
I'm
not
mistaken.
Let's
hope
you
know
they
get
a
chance
to
look
at
it.
I'll
I'll
also
think
some
people
yeah
yeah,
if
both
you
and
xingping,
I
think
I
think
something
something
will
move
forward.
G
Get
this
one
go
ahead.
One
more
thing
said
on
the
driver:
the
code
needs
to
be
refactored
a
little
bit
to
work
with
the
release
tools,
so
we
need
to
move
the
we
need
to
move
some
code
around
so
that
it's
organized
the
way.
Other
repos
are
because
release
tool
looks
for
a
specific
pattern.
B
Okay,
so
is
this
in
the
csi
favor?
It's,
yes,
I
see.
Okay,
so
when
you
say
it
needs
to
be
following
a
certain
pattern.
Good.
G
So
I
I
I'll
give
you
a
quick
example
here.
So
main.go
is
right
now
at
the
root
level,
but
the
that
needs
to
be
under
command.
Slash
the
ethernet
csi
driver,
so
that
released
will
fix
it
up
from
there
and
that's
how
it
picks
up
the
binary
name
as
well
so
release
to
expect
things
to
be
in
a
certain
way.
B
Okay,
I'll
I'll
follow
with
krish,
but
in
case
you
know
I'll
I'll
see
if
he's
working
on
this,
if
not
they
just
could
you
could
you
take
a
look
at
this
and
take
care
of
this
yeah.
G
B
Sounds
good,
I
think
chris
made
a
pull
request
and
I
wanted
some
changes
to
it
yeah.
So
what
is
the
this?
This
question?
I
was
just
going
to
ask
this
srini
or
anyone
else
here.
Do
we
do
we
have
the
repository
names
well
understood
right.
C
B
Okay,
all
right
yeah
I'll,
follow
with
him
and
tejas
I'll,
follow
with
you
shortly,
depending
on
what
krish
says
and
we'll
go
from
there:
okay,
yeah
all
right.
So,
let's,
let's
okay,
we
have
10
minutes.
We
probably
can't
have
the
full
discussion,
but
last
week
we
started
talking
about
topology
and
I
thought
it
was
a
really
good
discussion.
B
We
were
you
know:
xing
brought
up
that
just
having
feels
like
region
or
zone
may
not
work
for
all
the
different
object.
Storage
providers,
especially
the
ones
running
on
in
our
data
centers,
because
data
centers
do
not
map
their
their
workloads
based
on
region
and
zone.
They
would
rather
do
it
based
on
their
own
custom,
set
of
classifications
like
racks,
or
you
know,
power,
distribution
units,
maybe
or
our
nodes
themselves.
B
So
we
wanted
a
more
generic
way
to
request
a
bucket
to
be
available
from
a
certain
topology
and-
and
we
were
coming
up
with
the
framework
for
that-
and
here
is
I've-
just
summarized
the
discussion
from
last
week
where
we
left
off.
B
So
we
we
came
up
with
the
concept
of
in
order
to
better
understand
what
was
you
know
what
is
needed?
We
we
divided
this
topology
discussion
into
two
different
concepts:
one
is
storage
topology,
which
is
how
an
object,
storage
system
maps,
the
storage
within
itself
and
second
is
accessible.
Topology,
accessible
topology
is
the
different
places
or
the
or
the
topology
from
which
a
bucket
will
be
consumable
within
kubernetes.
B
So,
for
instance,
let's
take
aws
s3
for
and
in
aws
s3.
If
you
request
a
bucket
from
one
region,
say
u.s
east
one,
and
you
could
technically
access
the
bucket
from
anywhere
in
the
world.
But
if
you
were
to
access
the
bucket
from
u.s
west
one,
then
there
is
network
cost
involved
in
transferring
data
across
regions,
so
the
accessible
topology
for
a
bucket
created
in
usc
swan
would
generally
be
u.s
east
one.
B
So
we're
making
this
distinction
between
accessible,
topology
and
storage
topology
in
in
the
example
I
gave,
storage
topology
would
be
usc,
1
and
accessible.
Topology
would
also
be
usc
swan,
but
then
this
this
accessible
topology
is
from
where
it
should
be
accessed
rather
than
how
it
looks
like
in
the
back
end.
B
So
another
example
in
a
private
data
center
would
be
like.
I
I
want
my
bucket
to
be
provisioned
in
storage
rack.
One
say
there
are
four
racks
storage
rank.
One
storage
rack
one
to
four,
and
let's
say
I
wanted
provision
on
storage
rack
one,
but
then
let's
say
it's
accessible
from
application,
rack
one.
B
So
the
storage
support
would
be
storage,
rack.
One
and
actual
topology
would
be
application,
rack
one.
So
we're
making
that
distinction,
and
what
we
finally
said
was
on
the
create
bucket
call.
We
would
we
would
ask
the
object,
storage
system
to
have
the
storage
topology
or
to
create
the
bucket
in
a
particular
storage
topology.
B
B
This
kind
of
way
we
left
under
which
field
we're
still
having
a
discussion
like
between
me,
rob
and
srini
and
jeff
as
well
about
what
we
should
name
these
fields
and
how
we
should
put
them
here.
I
wanted
to
bring
that
up,
but
given
the
amount
of
time
we
have,
I
think
we
should
have
that
discussion
on
thursday,
so
we
request
the
topology.
B
We
want
to
put
the
bucket
in
the
create
bucket
call
and
then
once
it
is
created
in
our
requested
topology,
the
driver
is
expected
to
respond
by
giving
us
accessible
topology
or
in
the
response.
It
would
respond
by
giving
us
the
accessible
topology
so
because
you
would
make
a
call
to
the
back
end
and
then
then,
on
the
response
we
get
back
pocket,
name
bucket
context
and
endpoint
or
whatever,
and
we
would
get
back
accessible
topology.
I
was
in
the
middle
of
editing
this,
so
there
were
some.
B
It
was
halfway
done,
but
ideally
what
we
want
here
is
the
object,
storage
system,
responding
and
saying
these
are
the
places
from
which
you
can
access
this
bucket.
So
the
object
storage
system,
going
back
to
our
aws
example,
should
say
usc
swan,
saying
it
should
be
accessible
from
here.
B
So
so
this
is
how
we're
thinking
of
modeling
it
for
now
hey.
D
So
this
this
kind
of
handles
the
fixed
assignment
of
a
storage
location
right,
so
I
so
an
application
can
set
that
there's
a
storage
location
or
maybe
not
the
application
administrator
right
and
and
then
also
allows
to
set
back
from
the
from
cozy
the
like
the
restrictions
for
the
pods
right
for
accessibility.
D
B
Yeah,
so
this
is,
this
is
a
follow.
The
bucket
kind
of
model
in
terms
of
follow
the
follow
the
part
not.
B
It
it
is
definitely
relevant.
I
mean
if
you're
in
us,
east
one
you
want
a
bucket
from
us
east,
one.
So
yeah.
You
know
it's
about
the
order
in
which
we
make
the
call
to
create
bucket
so
in
the
requested.
So
if
you're
creating
a
bucket,
you
know
it
would
come
from
the
bucket
class.
But
if
it's
follow
the
part,
it
should
come
from
the
bucket
request.
D
Yeah
I
mean
we,
don't
I
think
in
other
cases
we
also
said.
Sometimes
we
leave
it
to
an
administrator
to
create
classes
correctly,
and
things
like
that
right
so
that,
if
you
had
like
regions
for
your
application
for
the
workloads,
maybe
the
application,
the
admin
can
also
create
classes
for
these
workloads.
B
So
so
follow
the
part
is
kind
of
after
the
scheduling
of
the
part
is
done.
We
want
to
understand
where
it's
scheduled
and
then
based
on
that
we
want
to
create
the
bucket
correct.
D
Yeah,
but
but
I'm
not
sure
if
it's
in
the
the
scope
of
nodes
or
just
to
the
scope
of
well,
I'm
not
sure
yeah
right,
I'm
not
sure
how
relevant
this
will
become
between
nodes
right.
It
might
because
we
might.
D
Like
the
storage
topology
on
top
of
the
the
cluster
topology
right,
yeah.
B
B
Yeah
exactly
like
racks
to
be
honest,
yeah,
we
have
to
think
it
through.
I
don't
have
you
know
I
can
see.
I
can
see
it
being
relevant.
B
So
let
let's
do
this,
so
that's
the
one
thing
that
I
didn't
kind
of
summarize
here,
which
is
follow
the
part
pod
versus
follow
the
bucket.
Let's
start,
let's
have
a
discussion
in
in
full
fledged
fashion
on
thursday,
because
I
don't
think
we've
resolved
this
fully.
B
I
think
I
think
you
know
even
I
have
some
questions
and
that
I
want
to
verify
with
everyone
once
once
we
have
a
once.
You
have
good
clarity
on
on
topology,
and
then
you
know
we
can.
We
can
go
for
and
talk
about
the
protocol
issue
that
I
was
talking
about
too.
I
think
I
think
those
two
go
hang
hand
specifically
talking
about
which
field
would
map
to
topology,
because
we
we
found
an
issue
with
how
we
represent
protocols
today.
So
let's
have
a
discussion
on
thursday.
D
Can
you
also
by
the
way,
maybe
it
will
be
helpful
if
you
guys,
I
think
it
yeah,
you
know
you
can
describe.
Maybe
these
issues
on
slack
and
you
know
maybe
we
can
just
understand
them
before
and.
B
Yeah
that
that's
the
idea,
so
so
it
was
just
brought
up
thursday.
We
were
talking
about
just
some
development
in
the
sidecar
controller
and
we
noticed
this
and
and
yeah
when
we
have
the
discussion
like
when
we
have
a
meeting
amongst
ourselves,
I'll
put
on
the
six
storage
cosy
channel.
So
if
anyone's
available,
they
can
join
and
also
we'll
I'll
summarize
it
in
in
in
the
six
storage
cozy
channel.
So
everyone's
clear.
D
I
mean
no
pressure,
I
mean
just
if
you,
if
you
are
looking
for
feedback,
I
think
the
slack
channel
can
be
used.
I
mean
I'm
monitoring,
but
I'm
not
sure
if,
if
there's
much
activity
to
help
with
at
this
point,
yeah.
B
Yeah,
I
understand,
I
think
we
should.
I
encourage
everyone
to
have
any
discussions
or
any
questions
you
have
to
to.
You
know,
use
the
slack
channel
for
it.
I
monitor
it
too,
and
I
know
everyone
from
the
you
know
like
whoever
is
developing
writing
code
right
now,
monitors
it
so
so
yeah
feel
free
to
you
know
pitch
in
or
ask
questions
there
we'll
also
start
creating
this
habit
of
I've
been
talking
about
it
otherwise
too,
but
I
think
we
should
start
using
the
six
storage
cosy,
slack
channel
more.
B
All
right
so
so
we're
out
of
time.
I'm
one
of
the
main
agendas
today
was
to
understand
progress
of
development.
I
think
I
have
a
better
understanding.
Hopefully
the
ci
pull
request
gets
more
soon,
hopefully
this
week,
so
we
can
start
pushing
code
to
the
upstream
repositories
and
yeah.
Let's
continue
the
discussion
on
topology
on
thursday.