►
From YouTube: Kubernetes SIG Storage 20190228
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 28 February 2019
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.h2xlfal9gi0m
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:44:04 From Gerry Seidman : I'm not sure the scope of this, but for AuriStor, 'rack' is also useful.
09:47:08 From Aaron Spiegel : Agreed. A ‘rack’ topology key is useful for a number of data platforms.
09:49:07 From Andrew Kim : That’s one of the reasons we’re going with the `topology.kubernetes.io` prefix, to keep the label prefix generic enough for future use cases like ‘rack’ topology
A
All
right
today
is
February
28
2019.
This
is
the
meeting
of
the
kubernetes
storage
special
interest
group
today
on
the
agenda.
First,
we
have
the
updates
to
the
items
that
we're
working
on
for
this
quarter
as
a
sig
and
then
we'll
go
over
any
PRS
or
designs
that
need
review,
feel
free
to
add
any
items
there
and
if
there's
anything
else
that
you'd
like
to
discuss,
feel
free
to
add
it
to
the
agenda
document
as
well.
So
let's
go
ahead
and
jump
to
the
planning,
spreadsheet
and
we'll
get
started.
So
first
up.
A
A
C
C
D
A
A
F
F
So
there's
been
some
distractions
along
the
way,
but
that
the
plane
is
still
to
get
the
CSI
driver,
feature
merged
and
work
on
improving
the
tests
and
to
not
muck
around
with
the
the
internal
CSI
code
in
cubelet.
Yet
because
it
right
now
that
code
matches
spec
more
closely
than
the
file
system,
the
the
raw
block
implementation
matches
it
more
closely
than
the
file
system
version
does.
So
we
solved
that
to
sort
out
later,
but
they're
still
hopefully
getting
the
raw
block
stuff
in.
We
just
have
to
do
the
testing.
Okay.
F
Just
it
would
be
new
test
cases
if
we
identify
any
and
then
the
official
designation
of
the
feature
is
beta
or
the
only
changes.
All
of
the
new
code
is
skill,
a
host
path
driver
and
there
was
a
path,
a
patch
to
to
change
the
way
that
cubelet
interacted
with
the
CSI
plugins.
But
we've
decided
not
to
merge
that
because
of
the
whole
confusion
around
the
CSI
spec.
Okay,.
A
A
B
A
G
A
Okay,
so
I
haven't
seen
if
you
followed
up,
but
we
need
to
kind
of
declare
that
we
need
a
release
in
the
CSI
community
and,
if
folks
agree,
if
we
declare
there's
a
belief,
three-day
waiting
period
for
folks
to
accept
or
reject,
so
we
should
send
out
that
email
today,
I
think
the
special
that
should
be
proposed
would
be
on
Monday.
We
declare
that
we're
cutting
a
CSI,
1.1
RC
and
then
three
days
later,
we
actually
go
ahead
and
cut
it.
Yeah.
A
A
E
A
A
C
C
C
A
G
C
H
Hi
about
3
PRS
yesterday,
as
of
yesterday,
covering
about
9
tests
in
the
validation
suite.
There
are
more
in
the
list
that
Michelle
had
in
that
PR
I
work
on
that
before
the
court
priest,
but
validation
suite
will
be
the
larger
suite
and
then
we
promote
individual
tests
into
components
if
they
are
portable,
so
I
did
with
conformance
group
yesterday
answer:
ok.
A
C
I
think
if
the
update
yeah,
so
we
added
a
bunch
of
tests
and
we
found
issues
I
think
some
of
them
are
sort
of
corner
cases,
mostly
around
reconstruction,
so
I'm
still
trying
to
kind
of
evaluate
if
we
want
those
issues
to
be
solved
before
a
GA
or
not,
most
of
them
are
sort
of
rare
corner
cases.
So
I
need
to
think
about
that
at
this
point
other
than
that
we're
working
on
stabilizing
the
the
new
tests
that
we
added
and
then
other
than
that
we
should
be
good
to
go
cool.
A
Right,
thank
you
very
much.
Michelle
next
item
is
cleaning
up
actually
already
complete
with
that,
so
we'll
skip
next
up
is
non-recursive
volume,
ownership,
math
Smith
or
her
menthe.
Any
updates
on
this
looks
like
the
kept
did
not
merge.
There
were
some
outstanding
questions
about
username
facing
you
ID,
so
this
changed
into
just
design
for
this
quarter.
Yeah.
G
I
A
A
K
A
H
L
A
C
C
A
A
Next
item
is
refactor.
Cubelet
driver
registration
to
reconciliation
model
there,
the
person
who
was
working
on
it
left
some
comments
on
the
pr
about
how
exactly
to
implement
it.
I
responded
to
those
comments
and
she
is
still
taking
a
look
at
that
and
working
on
the
PR,
so
PR
in
progress.
I
don't
know
if
it's
going
to
make
it
in
the
114
code,
freeze
timeframe,
but
I'll
keep
an
eye
on
it.
A
A
L
Finally,
some
good
progress
to
report
there
I
took
the
larger
PR
that
was
out
there
and
I've
been
splitting
it
into
smaller
pieces
and
the
first
one
of
those
merged.
Yesterday
you
were
the
last
approver
on
that
side,
so
subpath
in
fact,
refactoring
sub
path
out
of
the
mountains.
What
that
covered
and
I've
got
a
couple,
smaller
steps
that
I'm
working
on
right
now,
I'm
still
not
sure
whether
or
not
the
whole
thing
will
be
moved
by
code
freeze,
but
but
working
on
it
and
making
lots
of
positive
steps
along
the
way
that.
A
A
C
B
B
Believe
this
is
around
like
coming
up
with
a
strategy
to
make
sure
that
some
of
the
new
storage
classes-
you
have
the
the
mode
that
says,
do
not
immediately
start
scheduling
like
basically
wait
for
the
pod
to
show
up
that.
That
requires
a
claim
and
how
we
can
potentially
look
at
a
model
where
that
becomes
the
default
setting.
It.
A
A
E
C
C
M
C
A
A
A
C
A
C
J
Know
if
we
don't
have
the
labs
and
I
think
there's
like
one
team,
it
RedHat
that
has
a
couple
boxes
that
we
can
go
and
borrow,
and
it's
it's
like
once
one
day,
every
three
weeks,
I
am
oh.
Let
me
dig
into
this
some
though
I
bred.
What
is
your
wish
list
for
the
hardware
you'd
like
to
have
well
we'd,
like
my
team,
to
have
some
teddy.
You
know
any
kind
of
dedicated
hardware
that
we
could
connect
to.
J
You
know
if
we
could
just
have
like
some
system
that
we
could
stick
in
a
lab,
someplace
and
use.
That
would
be
fine.
We
don't
have
to
have
anything
huge,
but
we
right
now
we
have
nothing
except
whatever
we
have
to
borrow.
What
are
we
can
borrow?
So
if,
if
people
had
hardware,
they
could
donate
we'd
be
down
to
take
it,
and
you
know
then
we'd
be
able
to
review
this
in
tested
a
little
bit
better.
Now.
N
N
J
But
that's
he's
moved
out,
that's
the
team
that
we
can
borrow
from
and,
like
I
said
we
can,
we
can
borrow
it
sometimes,
but
it's
it's
pretty
limited
access
like
we'll
ask
for
and
we'll
get
a
couple
days
and
then
we're
off.
So
it's
just
not
something
to
you
know
it's
it's
not
something.
We
have
enough
access
to
to
really
commit
to
doing.
You
know
having
the
ownership
of
the
the
full
plugin.
J
A
Think
we
can
put
the
driver
out,
though
Fiber
Channel,
I,
scuzzy
and
NFS
are
weird,
because
no
one's
really
going
to
take
ownership
of
them.
We
can
put
out
what
we
think
works,
and
if
anybody
wants
to
use
it,
they
use
it
at
their
own
risk
and,
if
they're
interested
in
helping
maintain
and
test
it
awesome.
A
J
A
All
right,
moving
on
next
item
is
online
resizing
to
beta
for
the
general
entry
feature.
This
is
design
only
last
status.
Update
here
was
that
the
cap
didn't
merge
because
there
were
unresolved
issues,
so
we
changed
this
to
a
design
for
this
quarter
and
I.
Think
a
month
was
planning
a
follow-up
call
with
six
storage.
Homuth.
Are
you
planning
on
putting
this
off
until
post
code?
Freeze,
yeah,.
G
But
just
a
quick
update,
I
presented
this
to
see
gaps.
Okay
now
this
week
as
well
and
the
feedback
I
got
was
like
it's
not
a
blah,
it's
not
the
no
blocker
should
they
have.
They
want
online
reselling
to
be
default.
The
fact
that
some
workload
needs
to
be
restarted
after
the
file
system
resizing
has
been
done
is
like
orthogonal
to
how
the
resizing
so
should
work.
The
workload
itself
can
be
like
the
workload
can
be
restarted
afterwards
as
well.
G
A
C
I
C
A
G
So
this
is
blocked
currently
on.
How
do
we
handle
like,
when
the
volume
only
supports
offline
resizing
like
something
like
a
zoo?
This
cow
will
be
resize.
The
workload.
Do
we
have
to
take
the
entire
state
full
set
down
are?
Is
there
a
way
we
could
do
one
part
at
a
time.
So
that's
the
thing
that
the
author
of
the
pier
has
to
figure
out
the
design
has
to
figure
out
represent.
G
A
L
This
is
more
cycling
up.
You
know
those
labels
have
been
there
since
11.3,
so
they're
they're,
pretty
much
GA
they're,
just
not
named
J
and
I,
think
it's
just
confusing
razors
and
so
just
trying
to
do
the
right
thing
and
and
and
get
those
labels
Jade
I,
don't
think
it's
gonna
be
done
for
114,
though
No
so
there's
a
rush
toward
you,
it
or
anything,
but
just
wanted
to
put
it
out
there.
L
Yeah
so
Michelle
had
mentioned
this
in
another
issue
for
this,
so
it
seems
like
long
term.
We
just
want
to
use
the
no
Definity
field
in
PBS,
so
I
guess
the
question
is
like:
do
we
still
want
the
label
information
there
just
for
informational
purposes
or
should
be
like
redo
or
should
be
yeah
yeah
like
reconsider,
just
removing
the
labels
entirely
for
volumes
either
way.
We
still
need
the
zone
region,
information
for
nodes,
so
we'd
still
we
just
update
the
cap
to
promote
the
labels
for
notes
and
just
ignore
volumes.
I
A
A
With
six
storage,
my
problem
with
promoting
it
to
GA
is
we'll
have
two
different
ways
of
enforcing
topology
essentially,
and
we
have
the
the
the
new
way,
which
is
the
way
that
we
want
everyone
to
use,
and
we
have
this
way
which,
ideally,
we
only
maintain
for
backwards.
Compatibility
reasons
and
I
worry
that
if
we
promote
this
ga,
it
will
be
a
a.
This
is
something
that
you
should
be
using
kind
of
thing
rather
than
hey.
It's
only
here
for
backwards
compatibility.
C
A
C
A
So
that
makes
sense,
I
think
from
the
storage
side.
The
answer
is,
ideally
we
want
to
deprecate
these
labels.
We
want
to
replace
them
with
the
new
topology
functionality
that
we
have
in
order
to
do
that,
we
first
need
to
update
the
entry
volume
plugins
to
use
the
new
topology
feature
and
then
wait
long
enough
that
we
can
go
ahead
and
safely
deprecated
yeah.
A
L
A
Got
15
minutes
left
in
this
call
and
I,
don't
think,
there's
anything
else
on
the
agenda
so
feel
free
to
use
this
as
a
design
discussion,
I
I
prefer
the
the
answer
of
let's
find
a
way
to
safely
deprecated
this
label,
and
that
way
we
don't
have
to
promote
it,
to
GA,
at
least
for
storage
and
for
storage.
We
have
the
new
topology
mechanism
that
is
replacing
this
but
agreed
with
Michelle.
The
challenge
is
safely
migrating.
The
old
volumes
that
already
exists.
C
The
version
gets
bumped
well,
yeah,
so
I
think
at
least
from
the
talks
with
API
machinery.
So
far,
I
don't
think
there
has
been
precedent
for
automatically
updating
fields
on
upgrade
for
for
same
object
in
the
same
version.
So
this
is
something
we
might
have
to
work
out
with
them
on
how
we
can
do
this.
A
Yeah
I'm
thinking
is
there
a
way
that
we
can
get
away
with
not
having
to
do
the
migration,
but
the
problem
is
somebody
could
have
created
a
volume
into
the
very
old
version
and
just
never
recreated
it.
It
just
sits
around
and
gets
upgraded
upgraded
upgrading
the
cluster
gets
upgraded
multiple
times
so
that
PV
has
existed
for
a
very
long
time
and
it's
not
going
to
magically
get
the
new
fields,
so
yeah
I
think
we'll
have
to
sort
that
out.
A
Ok,
so
I
guess
the
next
steps
are:
let's
talk
to
API
machinery
and
see
if
there's
a
way
to
safely
migrate,
the
old
volumes,
and
if
we
can
do
that,
then
deprecation
is
the
way
to
go.
If
there's
absolutely
no
way
or
it's
very
very
difficult,
then
we
can
look
into
moving
the
feature
to
GA
and
I.
Think
we'll
still
have
to
solve
the
problem
of
either.
Even
if
we
move
it
to
GA
will
either
have
to
maintain
the
beta
logic
forever
or
come
up
with
a
way
to
migrate.
The
old
Peavey's.