►
From YouTube: Kubernetes SIG Storage 20181220
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 20 December 2018
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.9xceuqir0s13
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
None
A
All
right,
hello,
everyone
today
is
December
20
2018.
This
is
the
meeting
of
the
kubernetes
storage
special
interest
group.
As
a
reminder,
this
meeting
is
public
recorded
and
posted
on
YouTube.
Today
on
the
agenda,
we
have
planning
for
q1
of
next
year.
This
is
the
1.14
release
of
kubernetes,
so
the
idea
is
to
add
items
to
the
spreadsheet
that
we
use
to
keep
track
of
tasks
assigned
items
and
priorities,
and
then
we
can
keep
track
of
those
over
the
quarter
as
we
work
through
them.
A
A
A
Some
of
the
entry
code,
two
out
of
two
CSI
and
in
order
to
get
there
there's
a
number
of
items
that
we're
tracking
for
that
and
what
I
want
to
do
is
make
sure
the
P
ones
that
we
have
for
migration,
have
owners
assigned
to
them
and
preferably
all
the
P
ones
should
have
a
unique
owner
so
that
everybody
has
a
unique
project
that
they're
working
on
for
the
quarter
and
aren't
isn't
overloaded
working
on
two
or
three
different
things.
So,
ideally
folks
just
have
one
big
project
for
for
the
quarter.
A
Now,
let's
go
ahead
and
get
started.
So
the
first
item
is
the
migration
engine.
This
is
code
that
needs
to
go
into
the
Nettie's
to
burn
IDs
that
actually
it's
code,
that'll
go
into
community
staging
that
will
allow
for
seamless
migration
of
the
entry
code
to
an
external
CSI
driver.
David
has
been
working
on
this
along
with
Chang
and
deep
I
believe
they're
going
to
continue
to
work
on
it.
A
B
B
So
we
can
have
the
translation
logic,
entry
going
into
staging
and
then
populated
or
synced
up
into
external
repo,
that
other
components
like
the
external
provisioner
can
use
to
make
sure
that
they're
using
the
CSI
volume,
the
CSI
driver
code
to
provision
the
volumes,
but
when
they
are
returning
the
the
PP
objects,
they
switch
the
source
according
to
the
translation
library,
so
that
they
get
picked
up
by
the
entries
they
get
represented.
As
entry
right
entry
travel
created,
Wohlers.
A
That
sounds
like
a
lot
of
that.
Work
is
already
done,
so
it
should
be
more
fit
and
finished
stuff.
So
that's
good.
Next
up
is
inline
volume
support,
but
next
I
guess
four
items
here
important
to
keep
in
mind
that
migration
has
a
dependency
on
these.
These
features
need
to
go
in
and
there
needs
to
be
a
little
bit
of
work
on
the
migration
side
to
pick
up
these
features.
A
A
A
C
Yes,
so
definitely
this
will
be
picked
up.
First
thing
will
start
having
some
sort
of
meeting
for
interested
parties
to
join
because
I
know
K
Fox
has
been
pushing
for
this
as
far
as
driving
some
of
the
requirements
we'll
see
how
this
will
shape
for
alpha,
whether
or
not
we're
gonna
have
everything
or
is
it
gonna
be
pared
down
instead
of
features
that
will
make
it
in
and
be
able
to
support
whatever
on
migration
means,
so
definitely
something
that
will
be
patient
for
a
quick.
C
A
A
A
D
Yeah
I
don't
know
if
I
should
be
the
one
to
actually
like
update
the
gcpd
driver.
If
that's
the
one
to
be
done
or
the
cept
I
mean
I.
Think
Misaki
has
already
done
the
work
on
the
south
side,
but
I
don't
know
if
that
one
is
able
to
be
run,
but
but
I
can
work
with
the
interested
parties
to
figure
out
which
one
we're
gonna
do
and
make
sure
it
happens.
That.
A
F
D
H
D
F
D
F
D
A
G
A
G
I
A
A
J
A
A
B
Right,
so
that
is
still
a
bit
of
an
unsolved
problem.
We
thought
that
we
would
move
that
validation
logic
to
maybe
an
external
repo
for
now,
like
not
keep
it
entry,
and
so
that
was
sort
of
one
of
the
decisions.
I
was
taking
giving
like
one
of
the
chief
con
meetings
and
the
second
aspect
of
that
is
getting
the
certificate
set
up
properly.
So
for
that,
I
didn't
get
any
any
sort
of
guidance.
So
the
guidance
pretty
much
was
to
talk
to
sig
arch
and
see
if
they
have
anything
to
say
around
how
to
okay.
A
A
All
right
we'll
leave
your
name
on
there
for
now
deep
and
if
you
become
overburdened
just
let
us
know
and
balance
next
up
is
secured
volumes,
and
this
is
around
trying
to
come
up
with
a
design
that
will
work
with,
for
example,
G,
visor
and
cotta
containers
and
everything
that's
going
on
there.
Preliminary
I'm
gonna
put
either
Jing
or
Chang's
name
on
there,
and
we
can
sort
it
out
afterwards
who's
going
to
work
on
what
next
up
is
scalability
testing.
A
Ideally
we
want
to
do
so
with
a
no
op
driver
so
that
we
can
measure
the
impact
of
the
CSI
common
volume
code
in
terms
of
added
latency
on
top
of
nor
not
you
know,
stateless
pod
startup
times,
and
then
once
we
had
these
metrics,
we
can
figure
out
where
the
bottlenecks
are
and
add
additional
tracing
and
things
like
that
to
try
and
find
issues
and
fix
them.
Is
anybody
interested
in
working
on
that
I.
F
G
K
K
A
Thank
You
Patrick
next
up
is
moving
alpha,
CR
DS,
2
beta.
This
is
the
alpha.
Si
si
si
RDS.
This
includes
the
si
si
driver
object
and
the
si
si
node
info
object.
There's
a
considerable
amount
of
work.
Here
we
have
to
move
the
CR
DS
themselves
to
beta.
We
have
to
make
sure
that
all
the
end-to-end
tests
are
there.
We
have
to
make
sure
that
the
deployment
story
makes
sense
for
the
CR
DS
right
now,
they're
being
deployed
by
an
add-on.
A
I
A
K
A
K
L
A
A
A
A
This
is
our
already
exists
on
the
CSI
spec.
The
get
node
info
call
will
return
the
maximum
number
of
volume
supported
per
node.
We
need
to
wire
that
all
the
way
through
to
to
kubernetes
I,
believe
Michelle
and
her
month
and
a
few
others
had
a
conversation
about
how
to
make
this
work
over
Q
Khan,
yeah.
I
It
already
works
actually-
and
it's,
but
we
have
like
Tim,
has
some
concerns
about
like
how
to
expose
this.
How
to
represent
this
lemon
in
demand
like
how
from
where
the
key
comes.
This
the
basically
the
that
attach
limit
key,
comes
thus
the
main
thing
actually
I
think
just
of
it,
so
you
want
to
kind
of
reconsider
the
design
of
it.
The
trick
here
is
it's
already
in
beta
actually,
but.
A
I
We
have,
but
we
did
not
have
to
make
a
API
change
for
it,
so
there's
no
API
chain,
but
we
have
to
still
consider
like
when
we
introduce
a
new
mechanism
to
introduce
the
CSI
limits,
like
let's
say
we
introduce
a
new
field
somewhere.
Thus
the
other
thing
that
we
considered,
then
we
might
have
to
keep
that
and
alpha
actually
and
that
presents
a
challenge.
We
can
talk
about
that
later.
You
know
and
that's
all,
but
yeah
we
discussed
process
concept
doing
that
as
well,
but
to.
A
A
A
I
F
A
I
A
A
We'll
have
to
think
through
what
the
backwards
compatibility
story
looks
like
there
and
talked
to
Jordan
Hamad.
Do
you
already
have
a
p1
assigned
to
you
number
5?
Do
you
think
you're
gonna
have
time
to
work
on
this
as
well,
or
is
someone
else
that
you've
been
working
with
that
can
pick
up
this
work.
I
A
A
I
A
F
Think
that
the
original
idea
was
that
people
can
take
the
published
into
n
test
suite
binary
that
comes
with
a
given.
It
is
really
isn't:
I
just
run
the
tests,
the
in
bad
test,
suite
against
their
own
CSI
driver,
for
example,
or
some
other
driver
I,
see
I
think
we
got
a
quite
a
bit
closer
to
that
goal.
Now
that
this
test
suite
was
reflected
and.
G
F
Does
have
this
concept
of
a
test?
Driver
I
actually
have
prototypes
somewhere
lying
from
for
a
for
a
test
driver,
but
it's
really
just
the
data
structure
where
you
need
to
fill
in
things
like
which
image
is
to
deploy.
I.
Think
the
last
step
of
making
that
command
and
parameters
is
really
small
and
I'm.
Sure
I
hope
to
tell
that
soon.
Ok,.
A
G
A
Okay,
local
PB
to
GA
is
this
something
that
we
want
to
pursue
and
is
anybody
interested
in
helping
with
it?
If
you
use
local
persistent
volumes,
I
know
there's
a
lot
of
companies
that
are
depending
on
it
now.
This
might
be
a
good
opportunity
to
step
up
and
show
leadership
in
the
community
and
help
move
that
you
depend
on
through
GA
yeah.
K
I
think
there's
there's
not
much
work
to
do
here.
I
think
it's
mostly
just
flipping
the
flag
and
updating
the
documentation.
J
I
G
G
A
A
K
So,
basically,
last
release:
we
discovered
that
we
have
been
doing
feature
gates
wrong
this
whole
time
and
it
totally
breaks
down
grades
scenarios.
So
Jordan
has
updated
some
guide
the
guidelines
on
how
to
use
feature
gates
in
terms
of
a
bi,
validation
and-
and
basically
this
item
is
to
go
through
all
our
previous
storage
features
and
just
you
know,
change
update
the
code
to
follow
the
new
guidance
I.
A
C
A
E
E
A
Next
up
is
non-recursive
volume
ownership,
if
you
were
at
a
cute
con
I
think
one
of
the
big
complaints
we
heard
was
about
when
somebody
applies.
An
FS
group
to
a
volume.
Kubernetes
will
recursively
apply
big
bill,
it'll
recursively
tone
every
file
and
directory
in
that
volume,
and
if
the
size
of
that
volume
is
large,
there's
a
lot
of
files
and
directories
that
can
take
a
lot
of
time.
So
the
work
here
is
to
try
and
investigate.
A
I
H
A
There
have
been
a
number
of
issues
that
have
surfaced
around
the
way
that
we
do
UID
GID
handling
and
it's
confusing,
and
it's
not
clear
how
it
maps
to
the
windows,
world
and
I
think
some
of
the
other
issues
include
I
can't
remember
off
the
top
of
my
head,
but
there's
been
a
number
of
round
this
area.
The
security
team
is
interested
in
helping
us
flush
this
out
and
have
a
better,
more
complete
story
here.
I
J
I
I
A
A
Next
up
is
volume
health,
the
designing
something
where
you
can
expose
a
signal
for
the
health
of
a
volume.
So
you
can
imagine
this
could
be
anything
from
like
hey
this
disk,
smart
checks
that
are
failing
or
is
inaccessible
for
some
other
reason
or
unhealthy
for
some
other
reason
being
able
to
surface
that
somehow.
So
this
is
designing
that
end-to-end
story.
What
does
it
look
like
on
CSI
side
of
things?
How
does
that
surface
on
the
kubernetes
api
side
of
things?
We
don't
need
to
take
action
on
it
just
yet.
M
M
A
M
A
Next
up
is
CSI
entry,
post,
GA
tasks
specifically,
this
includes
moving
callers
at
the
internal
API
objects,
which
were
moved
to
v1
last
quarter
in
in
the
1.13
release
the
volume
attachment
object
and
so
on.
We
need
to
move
the
callers
to
use
to
be
one
version
instead
of
the
beta.
There
is
a
limitation
that
you
can't
do
all
of
that
in
one
release,
so
we
have
to
stagger
it.
There's
also
work
around
cleaning
up
the
way
that
we
do
read-only
and
possibly
some
refactoring
and
cleanup
work.
F
Are
automatically
cut
that
that
fits
nicely
with
all
the
other
testing
work
that
I'm
doing
so
III
intend
to
continue
with
that.
It's
also
a
group
effort
in
a
way,
because
we've
we
have
now
still
figuring
out
where
different
pieces
are
like
Yarborough's
and
everything,
but
we
I
think
we've
made
good
progress
on
that
in
the
last
quarter.
Already,
oh
yeah,
we
might
now
have
everything
in
the
place
where
we
can
actually
do
to
a
proper
release
with
just
just
four
things
in
be
ups
to
individuals.
I've
got
containers,
awesome
and
em
purchased
with
itself.
A
Yeah,
this
is
gonna,
be
extremely
important
for
the
long-term
sustainability
of
the
project.
So
thank
you.
Patrick
next
up
is
refactoring
the
cubelet
driver
registration
mechanism
to
use
a
reconciliation
model.
So
today
we
have
a
cubelet
device
registration
mechanism,
it
basically
scans
for
sockets
on
the
in
a
specific
directory.
If
a
socket
is
discovered,
it
interrogate
that
socket
to
find
out
what
type
of
plug-in
it
is.
A
Is
it
CSI
is
a
device
plug
in
and
then
based
on
that
it'll
do
a
callback
to
the
appropriate
code
inside
of
cubelet,
the
CSI
code
or
the
device
plug-in
code
to
say,
hey,
there's
a
new
driver,
please
register
it
and
then
that
CSI
or
device
plug-in
specific
code
kicks
in
and
continues
with
the
registration
and
then.
Similarly,
if
the
socket
is
deleted,
it'll
call
a
nun
registration
hook
which
allows
the
code
that
cares
about
it
to
do
any
on
registration
cleanup
that
it
needs
to
do
currently.
A
This
entire
system
is
an
event
based
model
where,
when
the
creation
of
the
socket
triggers
a
registration,
the
deletion
of
the
socket
triggers
unregister
a
ssin.
Ideally,
we
want
to
move
this
to
a
kind
of
kubernetes
controller
reconciliation
model
where
we
are,
even
if
registration,
for
example,
fails
because
of
some
error.
We
periodically
with
exponential
back-off
retry
to
try
and
register
the
same
driver
again
in
the
hopes
that
perhaps
this
was
a
temporary
issue
and
that
we
could
actually
unregister
it
later
so
I
imagine.
This
is
gonna.
A
C
I
was
gonna,
say
sorry,
I
do
have
a
question
because
I
remember
we
had
a
similar
discussion
at
cube
con
mm-hm.
So
so,
if
we
use
a
controller,
what
what
would
object?
Are
you
basing
your
registration
on?
Is
it
the
CSI
driver,
other
controller.
A
An
actual
state,
the
desired
state,
is
populated
by
events,
so
the
creation
and
deletion
of
the
sockets
are
isolated
events
that
are
going
to
trigger
the
creation
or
deletion
of
the
objects
in
the
desired
state
cache
and
then
Sylar
is
sitting
there
and
dipping
between
the
desired
state
in
the
actual
state
and
triggering
operations,
and
we
can
use
the
operation
executor
to
do
all
the
the
exponential
back-off
logic
and
all
of
that
all
right.
So
basically,.
A
E
That
was
kind
of
hoping
you
know,
because
it's
really
interesting.
Okay,.
A
A
A
L
A
You
have
a
very
long
list
of
items
overall,
Shing
enging
have
been
leading
this
work
and
both
of
them
are
going
to
be
helping
with
some
of
the
p1p2
items.
This
quarter
so
and
I
would
like
to
give
some
time
for
snapshots
to
bake
a
little
bit
with
the
existing
design
that
we
have
and
start
getting
feedback.
We
did
make
breaking
changes
in
last
release.
We
introduced
it
in
the
previous
release,
so
I'm
hoping
to
leave
this
as
a
p3.
A
We
can
do
some
minor
design
work
and,
if
there's
free
time
Shane
can
add
additional
features,
but
for
the
most
part,
let's
put
slow
this
down
a
little
bit
and
let
it
bake
this
quarter
and
then
hopefully
pick
it
up
next
quarter.
What
I
want
to
see
over
time
is
that
we
invest
a
lot
in
q1
to
try
and
unblock
as
much
of
the
migration
work
as
possible.
A
That
way,
we're
going
to
invest
a
lot
of
dev
effort
in
that
I'm,
going
to
see
that
taper
off
in
q2
q3
and
we
can
increase
our
investment
in
features
again
in
q2
q3.
So
q1,
let's
invest
in
like
the
the
technical
debt
that
we
have
accrued
and
try
to
get
that
unblocked,
and
then
we
can
start
focusing
again
on
adding
features
as
we
move
through
2019.
A
C
A
K
C
A
Now
that's
a
great
idea:
let's,
let's
leave
these
items
unassigned
unless
there's
something
in
the
last
six
items
that
folks
on
this
call
are
very
interested
in
working
on
I'll
leave
the
rest
of
this
unassigned
and
we
can
revisit
it
at
the
next
meeting,
which
I
believe
is
after
the
new
year,
and
hopefully
we
can
get
some
more
volunteers.
That's
a
good
point.
Blood.
A
I
G
I
A
A
Okay
and
a
reminder
that
if
you
have
a
task
that
is
assigned
to
you,
please
make
sure
there's
a
feature
repo
issue
open
for
the
task
if
it
says
now
in
the
column
e.
This
is
how
the
rest
of
the
kubernetes
community
keeps
track
of
the
work
that
we're
working
on.
They
don't
know
anything
about
our
spreadsheet,
so
please
make
sure
that
there
is
a
feature
enhancement
issue
for
your
task.
A
I
A
A
good
question,
I
think
what
we're
doing
now
is
that,
on
the
external
components
we
are
in
the
release
notes
for
every
release.
We
mention
what
is
part
of
that
release
and
what
the
status
of
the
overall
component
is,
and
then
we
can
add
in
sub
components
and
what
their
status
is
and
we
can
define
you
know,
for
example,
block
volume
is
currently
beta
or
alpha.
We
can
define
that
in
the
release
notes.
In
fact,
we
should
probably
fix
these
release.
Notes
to
capture
that.
H
A
A
A
A
All
right
well,
thank
you
very
much
and
happy
holidays.
We
will
reconvene
in
two
weeks.
I
believe
I
will
be
out
of
town
in
two
weeks.
So
if
Brad,
you
could
lead
that
meeting.
I,
don't
know
if
you're
going
to
be
around
sure
all
right,
great,
so
we'll
reconvene
in
two
weeks.
Brad
will
lead
that
meeting
and
we
will
do
a
review
of
these
items
that
we
have
remaining
in
the
planning,
spreadsheet
and
hopefully
get
final
assignees
on
all
the
items
and
then
we'll
start
with
the
q1
2019
and
the
1.14
release.
A
That's
all
I
have
happy
holidays
and
see
you
next
year,
yeah.