►
From YouTube: Kubernetes SIG Storage 20200116
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) - 16 January 2020
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.n01ntm6zlx49
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
A
All
right
today
is
January
16
2020.
This
is
the
meeting
of
the
kubernetes
storage
special
interest
group.
Today
on
the
agenda.
We
have
just
the
planning
session
so
far,
we're
gonna
go
over
the
items
that
we've
committed
to
say
group
for
the
1.18
release
and
get
status
updates
on
that.
If
you
have
any
PRS
that
need
attention,
please
feel
free
to
adhere
and
if
you
have
any
designs
that
need
attention
to
add
them
here,
anything
else
add
them
to
the
end
of
the
agenda
section
here.
A
A
B
So
the
one
other
thing
that
we
are
working
on
I'm
working
on
is
like
recovering
from
recess
fieldwork
I'm
working
on
a
cap
for
it
and
I
have
most
of
it
written
down,
but
there's
a
issue
that,
like
for
volume,
types
that
are
only
expandable
on
the
nodes
like
that
I
only
have
the
suicide
note.
Expansion
support,
there's
a
problem
that
we
don't
know
the
size
of
the.
B
We
may
not
know
the
size
of
the
volume
after
the
resize
has
happened
because
the
capacity
is
optional
field
in
the
node
expand
response,
so
yeah,
that's
the
problem
and
Misha
I
was
talking
to
Michelle
and
yarn
and
I
was
wondering.
I
have
open
issue
within
the
CSI
repository
for
this
iron.
That
looks
good.
We
could
the
what
Michelle
was
saying
was
that
you
could
just
make
the
recovery
recovery
from
resize
way,
behavior
only
not
supported
if
the
driver
does
not
return
size
after
expansion
of
the
node,
but
I
guess
could
work
a.
C
Month
the
stuff
you
have
written
down
is
it,
is
it
public
somewhere
can?
Can
we
look
at
it?
Is
there
a
link.
B
A
E
F
A
E
A
A
A
H
So
I'm
currently
working
on
documentation
and
there
is
also
a
PR,
adding
snapshot
secrets,
so
I
will
review
that
one
and
we're
also
working
on
adding
more
tests,
and
then
there
are
a
few
bucks.
This
fix
this
like
Chris
natural
timeout
right.
So
we
need
to
work
on
those
John
Chen.
You
want
to
add
something
you.
H
C
E
C
H
A
E
A
A
A
A
No,
it
doesn't
look
like
Chris
is
here
last
status.
Update
we
had
here
was
Chris
was
still
waiting
to
identify
scope
of
work.
Ben
was
looking
into
this
in
q4
and
believes,
although
confusing
it
may
be
okay
and
working
as
intended.
So
let's
mark
it
as
no
update
for
now,
CSI
driver
skip
attach
pod
info
moving
that
to
G
a
Christian
Huffman.
Any
updates,
no
updates,
yeah.
Okay.
A
I
A
H
So
just
Hydra
be
meeting
had
a
lot
of
discussions.
We
actually
didn't
finish
yet,
so
we
need
to
schedule
another
a
meeting
to
continue
just
based
on
the
feedback
we
have
from
this
week's
meeting.
We
need
to
make
some
changes
under
a
guy
part,
at
least
maybe
make
make
this
a
field
in
the
status
of
the
PVC,
so
so
I'm
going
to
discuss
with
Nick
about
the
so
prolly
wall
need
to
update
the
cap
before
next
year.
Meeting
sounds
good.
Thank
you.
So
much
is.
H
I
just
want
to
you
determining
what
do
you
is
this
API
change
it
first
and
then
schedule
something.
Maybe
next
week.
A
A
A
Item
is
deprecating
the
CSI
NFS
I,
scuzzy
fibre,
channel
and
flux
drivers.
For
those
of
you
who
don't
have
a
background
on
this,
we
wanted
to
maintain
some
community
owned,
CSI
drivers,
drivers
that
don't
really
have
a
good
common
home
and
what
we
discovered
was
very
few
people
offering
to
help
maintain
them
so,
rather
than
kind
of
neglect
them
and
have
them.
In
a
weird
unmaintained
state,
we've
decided
to
deprecate
and
archive
these
repos
and.
A
Next
one
is
deprecation
of
kubernetes
incubator,
external
storage,
repo,
the
entire
kubernetes
incubator,
org
is
being
deleted,
and
so
we
need
to
make
sure
that
anything,
that's
important
for
us
in
the
external
storage
repo
finds
a
new
home,
the
most
important
project
there,
the
external
provisioner
was
moved
a
while
ago,
but
there
are
a
number
of
old
external
provisioners
that
still
live
in
that
directory.
That
need
to
be
moved.
If
you
depend
on
one
of
those,
please
work
on
this
to
get
those
projects
move
because
they
will
be
deleted
soon.
A
J
A
A
lot
of
hold
it
for
a
while,
so
I
think
for
at
least
for
this
they're
planning
to
archive
it
for
a
while
and
then
delete
it
make
sense
again
warning
if
you
depend
on
anything
in
that
external
storage
repo,
please,
please,
please
go
take
a
look
at
it
and
help
get
that
moved
somewhere.
Otherwise
it
will
be
gone.
Next
item
is
rob
lock,
GA
yan,
any
updates
on
this.
E
Their
behalf
so
I
know
there
was
a
bug
around
volume
to
the
mission
and
David
has
a
design
plus
a
couple
of
PRS
out
for
that
and
I
think
both
beyond
and
Jonathan
have
been
reviewing
it
other
than
that
I
think
the
main
thing
is.
We
need
to
start
pushing
all
the
other
cloud
providers
to
get
their
migration
limitations
to
beta.
A
B
G
E
A
A
All
right,
thank
you
all
and
if
you're
on
the
call-
and
you
have
an
entry
plug-in
that
is
not
a
cloud
provider-
know
that
you're
going
to
be
next
in
line
so
I
think
the
next
set
after
cloud
providers
that
we
want
to
do.
The
migration
for
is
going
to
be
the
vendor
storage,
vendor
volume
plugins,
and
we
have
a
number
of
entry
storage,
vendor
volume
plugins.
A
One
is
you
could
decide
that
you
want
to
deprecated
the
entry
one
and
not
provide
a
kind
of
migration
story,
or
you
can
decide
that
you
do
want
to
provide
a
migration
story
and
implement
the
logic
that
is
required
there
and
work
with
David,
Chang
and
deep
on
that
all
right
next
item.
What
would
be
the
impact
if
there
was
no
migration
just
to
be
clear?
Oh
it'll
break
users
who
were
using
it
depending
on
it
once
the
code
is
removed,
so.
C
A
And
I
think
the
reason
is
basically
it's
up
to
the
vendor
to
decide
so,
for
example,
scale
I/o
was
deprecated
because
the
authors
no
longer
wanted
to
support
it
and
ultimately
it's
their
call.
Okay,
and
so
in
this
case,
it's
up
to
the
vendors
if
they
want
to
deprecated
their
old
entry
plugin.
That
is
an
option.
C
J
J
Our
and
I've
I've
done
a
couple
of
commits
to
the
cap
to
incorporate
that
feedback.
It's
our
feeling
is
that
we're
going
to
have
to
switch
to
a
CSI
interface
and
and
John
on
the
team
is
looking
at
doing
that.
I'd,
like
your
opinion,
on
with
such
a
significant
change
to
the
cap,
what
do
you
feel
I
can
just
make
that
as
US
as
a
new
commit,
or
do
you
think
it
should
start
more?
You
know
fresh
I
think.
A
A
A
H
A
H
G
C
C
A
E
A
C
A
C
A
I
C
You're
right,
you're
right,
there's
a
huge
amount
of
discussion
about
what
data
populate
errs.
Do
we
one
in
what
form
should
they
take,
but
the
question
of
should
we
relaxed
the
restrictions
on
the
data
source
field
in
the
object
in
cube?
Api
server
is
that's
a
very
specific,
very
small
issue
and,
and
the
answer
could
be,
we
want
to
open
it
up
wide
so
whatever
and
let
the
chips
fall
or
or
maybe
gradually
add
them
one
at
a
time.
C
But
that's
not
really
a
an
external
data
popular
that's
just
a
white
list
of
community
approved
populate
errs
so
I.
We
need
to
have
that
that
discussion
now
I,
think
and
then,
depending
on
the
outcome
in
that
discussion,
may
be
easier
or
harder
to
actually
do
individual
instances
of
data
populated
when
we
get
there.
But
I
already
have
two
two
different
implementations
that
I'm
happy
with
so
I
wanted
to
get
them
all
for
now.
C
H
A
Ok,
I
think
that
that
makes
sense.
Let's
get
the
cap
out
there,
let's
discuss
it
in
the
data
protection
work
group,
let's
aim
to
get
it
in
before
the
deadline
and,
let's
let
the
pieces
fall
where
they
may
all
right.
Thanks,
Ben
anything
else.
Anybody
wanted
to
talk
about
on
the
sick
planning,
spreadsheet
yeah.
D
E
E
I
think
Jing
started
looking
at
this,
but
and
also
I
think
some
other
folks
writing.
Csi
drivers
have
started
seeing
some
issues
related
to
this,
so
this
might
be
something
we
still
want
to
keep
on
tracking,
although
I'm
not
sure
if
Kings
actually
going
to
make,
is
going
to
make
a
lot
of
changes
around
us.
F
A
A
H
So
1
p.m.
Pacific
time
this
Friday
it's
the
first
meeting
and
then
we'll
have
our
regular
weekly
meetings
in
in
two
weeks
or
send
out
the
other
meeting
right
after
this.
But
the
first
meeting
my
disorder
send
out.
There
is
a
mailing
list
for
data
protection
work
group.
So
if
you're
interested
just
subscribed
to
that
mailing
list,
I
should
yeah
I'll
add
a
link
there.
We
also
have
a
slack
channel,
which
is
you
see?
What
is
that
I.
I
H
Is
it's
just?
We
need
to
update
the
some
of
the
pages
and
some
of
the
links
on
our
right.
Like
the
meeting
time,
we
need
to
update
the
meaning
time,
but
there
is
a
Google
Doc
agenda.
That
link
is
correct,
so
we'll
have
all
the
updated
information
there,
but
then
we
need
to
fix
all
the
other
things
that
are
not
right.
Like
an
erisa,
there
is
a
link
to
store
the
videos.
Things
like
those
those
are
not
not
correct
yet
so
need
to
fix
those.
A
Cool,
thank
you.
So
this
is
super
exciting.
It's
a
joint
effort
between
sixth
orage
and
cig
apps
to
start
working
on
data
protection
for
kubernetes
objects
and
resources.
I'm
expecting
a
lot
to
come
out
of
this
group
if
you
are
familiar
with
other
workgroups.
Esi
itself
was
a
work
group
and
it
continues
to
be
one
that
michelle
is
currently
running.
They
meet
about
three
times
a
week
and
so
there's
precedents
here
for
like
sub
projects
within
the
sig
that
are
important
and
critical
and
have
enough
kind
of
potential
behind
them.