►
From YouTube: Kubernetes SIG Storage 20161123
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 23 November 2016
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.sq58voucwguu
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:04:16 From eparis : SAAD!!!!
09:11:48 From Saad Ali : Thread Michael is talking about: https://groups.google.com/forum/#!topic/kubernetes-sig-storage/0U8L8Tc-PYs
09:25:49 From rootfs : flex api proposal
09:25:50 From rootfs : https://github.com/kubernetes/kubernetes/pull/33538
09:31:06 From SIG Storage : https://github.com/kubernetes/kubernetes/pull/26926#issuecomment-241169632
09:35:08 From steve watt : we do have a timeline for adding the Attach/Detach in the current Flex Vol Plugin - which is 1.6
09:51:36 From SIG Storage : https://github.com/kubernetes/kubernetes/issues/31272
09:58:10 From eparis : any network attached storage....
09:58:15 From eparis : depending on the kernel client....
09:58:35 From matchstick : yes
09:59:46 From rootfs : mount option issue
09:59:47 From rootfs : https://github.com/kubernetes/kubernetes/issues/31613
10:05:09 From eparis : I'm not sure why we have to validate them....
10:07:53 From eparis : allow options doesn't fix the hang....
A
B
Yeah
I'm
here,
can
you
hear
me?
Yes,
okay,
so
basically,
this
came
up
at
cube.
Con
I
was
talking
with
Michael.
This
is
something
that
I've
had
a
few
ideas
about
this
and
a
couple
PRS
that
I've
put
out
there
and
basically
I
think
everyone
likes
the
idea
of
kind
of
enhancing
our
air
resolution
and
getting
the
root
cause
and
helping
users,
but
I,
don't
think
my
implementations
have
been
very
doable
so
I'm
talking
with
Michael
AQ
Khan.
B
A
C
A
C
So
there's
a
few
things
going
on:
one
of
them
is
Erin
Boyd,
Brad,
Scott
Rashad,
this
guy
named
sod.
It
seems
like
we're
all
converging
on
some
areas
of
places
inside
the
storage
environment
that
needs
to
be
possibly
strengthened
or
deserve
attention
and
I
know,
at
least
in
Google.
This
is
going
to
be
a
large
part
of
our
roadmap
for
next
year.
It's
funny
to
me
how
a
cube
cons,
so
many
people
were
looking
at
different
pieces
of
this
I
I,
don't
know
how
many
people
read.
C
C
We
want
to
be
able
to
have
very
simple
and
easy
and
early
error
messages
for
our
users,
and
I
think
this
is
why
I
was
talking
to
Scott
because
it
looks
like
it
is:
Scott
I
right,
correct,
really,
yep,
okay
cool,
it
sounds
like
he's
already
been
thinking
about
some
of
these
issues
before
and
it
wasn't
getting
the
proper
attention
I.
That
Rashad
has
also
been
there
going
to
these
issues
himself,
because
you
know
what's
happening,
it
sort
of
have
four
or
five
different
groups
that
come
together
for
storage,
plugins
have
the
storage
administrator.
C
We
have
the
person
running
the
application.
You
know
who
really
starts
off
the
whole
thing.
We
have
the
cluster
administrator
and
then
we
have
the
people
who
are
administering
Cooper
Nettie's
and
the
cluster
administrator
I
call
out
here,
because
these
are
the
people
who
will
be
making
decisions
of
what
sort
of
images
that
they
run
on
the
nodes,
I
think
in
a
cloud
provider,
it's
often
the
same
person
as
the
Cooper
Nettie's
operator,
but
in
other
installations.
It
may
not
be
the
case
and
that's
a
lot
of
places
for
your
storage
plugin
to
not
work.
C
It
could
not
be
working
as
a
binary
compatibility.
It
could
not
be
working
because
of
an
imaging
compatibility.
It
could
not
be
working
because
it
can
reach
the
storage
itself.
So
to
me,
it
seems
like
we
need
to
have
some
mechanism
to
have
increased
intelligence
of
making
sure
that
that
node
is
actually
meets
the
requirements
for
that
plug-in
and
then
being
able
to
integrate
that
with
scheduling
so
that
when
the
application
user
says
I
want
to
run
NFS
or
cephalopod
or
cucamonga
plugin,
it
will
know
ahead
of
time
which
nodes
can
support
it
or
not.
C
And
in
addition,
some
of
the
things
that
came
up
at
the
sig
was
that
this
will
probably
get
even
more
complicated
for
some
providers,
because
it
could
be
heterogeneous
where
some
nodes
support
some
things
and
some
don't
and
it
may
be
dynamic.
If
you
have
fibre
channel,
in
which
case
your
storage
say,
meeting
the
storage
requirement
on
the
node
could
be
something
that
comes
in
and
comes
out.
Well,
you
know,
after
you
set
up
your
cluster,
then
it
becomes
even
more
interesting.
C
Sorry
I
was
up
late
with
the
turkey
and
kind
of
became
up
with
the
inkling
of
an
idea
that
I
think
that
a
lot
of
us
that
sort
of
cover
is
I,
don't
want
to
make
it
panacea
software,
which
is
something
that
you
know,
solves
everyone's
problems
at
once.
I,
don't
think
this
is
going
to
do
that,
but
I
think
it's
a
it's
a
big
sort
of
step
in
the
right
direction
with
something
that
we
can
break
down
into
two
or
three
sub
projects.
C
And
might
I
think,
is
doable
by
the
end
of
next
year
and
it
also
aligns
with
how
Cooper
Nettie's
work's
overall,
you
know.
Basically,
the
idea
is
coming
up
with
facilities
to
have
a
demon
set,
that
you
can
run
that
will
allow
plugin
Lana
when
you
write
a
new
plug-in
you'll
write
a
little
module.
That
says:
is
this
node
compatible
or
not?
C
It
may
add
a
little
bit
more
requirement
to
a
storage,
plug-in
user,
but
at
the
same
point,
I
think
that
we
can
make
it
optional
and
I
believe
that
it's
sort
of
something
that
a
storage,
plugin
authors
should
be
thinking
about
anyway,
because
you
know
right
now
we're
we're
sort
of
throwing
this
complexity
on
our
users
and
we're
not
even
making
it
clear
what
users
need
to
worry
about
it.
Yeah.
C
It's
not
much
more
than
what
you
kind
of
heard
in
my
head
already,
except
it's
written
down,
and
it's
something
that
I
think
you
know.
I
know.
Aaron
I
talked
to
her
about
it
yesterday,
she's
interested
also
in
contributing
to
this
and
I
am
looking
to
sod
and
the
the
team
of
storage
folks
in
Google
to
start
making
progress
on
this
in
q1,
so
I'm,
hoping
that
we
see
a
real
proposal
that
we
can
all
start
commenting
on
in
January,
surprise
sod,
I'm,.
A
A
A
So
this
is
a
good
segue
into
the
next
topic,
which
was
the
original
topic
of
discussion
that
led
to
this.
What
are
we
doing
with
entry
out
of
tree
plugins?
What's
going
on
with
flex
for
1.6,
so
I
know,
Brad,
Steve
and
Michael
were
talking
about
this
a
little
bit
on
that
thread
and
at
coupon
do
any
of
you
want
to
add
to
that
its.
G
So
we
are
going
to
basically
do
that
and
hopefully
try
and
get
it
early
for
review
well
before
the
man
dot
sex
now
coming
over
to
to
you
know
whatever
you
guys
are
calling
plug
in
freedom
and
what
to
do
and
what
that
proposal
will
look
like
I
think,
hopefully,
a
lot
of
the
discussions
which
went
on
which
basically
Chakri
presented.
You
know
they
were
a
list
of
issues
which
rahbani
a
bike:
storage,
sick,
so
he's
gonna.
He
either
he
or
I
will
update
the
his
current
spec
for
those.
G
C
G
Correct
but
I
don't
so
what?
What
is
not
clear
is
how
you
starting
off
this
flex,
to
effort
and
how
we
can
help
right.
So
at
least,
basically,
we
have
closure
on
v
one
of
what
things
need
to
be
done,
and
hopefully
we
get
that
done
so
what
the
time
frame
and
and
and
what
all
other
stuff
do
we
need
to
do
to
help
to
get
version.
2
of
the
gram.
C
E
So
I
would
say,
like
the
note
I
sent
to
the
raid
work.
Sorry
to
the
list
was
off
a
couple
o
clock.
You
know
I
have
to
step
out
at
three
o'clock
to
change
hotels,
unfortunately,
and-
and
so
I
think
it
was
a
conversation
between
3
to
6
45
in
then
I
wanted
to
clarify
and
just
to
sort
of
summarize
it,
and
it
was
what
I
sort
of
put
in
a
thread
which
was
you
know,
hey
this
flex
version
to
stuff
is
going
to
take
a
while
to
develop.
E
Could
you
clarify-
and
you
know,
which
was
that
we
were
going
to
a
detached,
detached
support
to
flex
beat
one
and
Chakri
was
going
to
be
on
point
with
that,
and
so
that
folks,
who
wanted
to
move
out
of
tree
in
the
near
term,
could
use
the
flics
t1
support
in
q1
dot.
Six
to
do
that
and
then
so
that
was
sort
of
the
one
thing
I
wanted
to
clarify.
Maybe
I
should
just
pose
there
is
that
sort
of
the
general
consensus.
A
Yeah
hold
heard
yes
yeah.
I
agree
from
what
I've
heard
attached,
detach
and
dynamic
provisioning
were
proposed
as
being
part
of
what
we're
calling
flex
v1.
One
thing
I
would
add,
is
we
should
be
cautious
about
calling
it
v1?
Whatever
version
we're
going
to
ship
with
1.6
should
be
something
we
call
alpha,
2
or
beta.
We
don't
want
to
get
into
the
business
of
calling
it
something
with
a
label
where
we
are
guaranteeing
an
API
we're
there.
You.
A
C
E
Just
to
clarify
like
this
there's
two
flicks
there's
an
iteration
and
an
improvement
on
the
flicks
that
we
have
today
like
we
need
to
come
up
with
a
name
for
that
thing,
and
then
there's
like
what
we're
talking
about
like
the
flicks
of
tomorrow,
which,
and
you
know
one
word
we
were
using-
was
maybe
CDI
or
something
medical
for
that
thing.
I
just
want
to,
because
both
things
are
sort
of
flakes
like
we
need
a
way
to
life,
simplify.
C
The
conversation
so
I
I
think
this
is
a
way
to
look
at
it
Stieb
that
may
actually
address
your.
Your
other
needs
to
that.
I
think
you
talked
about
in
some
of
the
hallway
conversations
like,
let's,
let's
separate,
like
the
CVI
thing,
a
little
bit
even
more
the
CBI
idea
from
the
idea
of
flex
like
for
Cooper
Nettie's,
for
storage
for
the
storage
cig.
C
Let's
have
like
some
flex,
that's
have
finished
and
we
broadcast
that
that
we're
going
to
use
to
get
us
through
the
immediate
you
know
needs
for
out
of
tree
and
we
can
start
working
on
that
figuring
that
out
and
then
a
more
finished
flex
API
and
whether
we
call
let's
call
the
second
one,
1
dot
0
and
the
first
one
we
can
call
alpha
or
point
five
or
Beaufort
or
who
cares
what
like
or
other
people
make
care?
I'm
sorry!
C
I
don't
know
if
I
care
that
much,
but
let's
call
like
whatever
the
CVI
thing
is
like
we
can.
Basically,
we
can
even
decouple
that
a
little
bit
and
just
say
whatever
we're
doing
for
flex
10,
we
can
cut,
you
know,
cut
and
paste
it
or
copy
and
paste
it
and
say
that
CBI
and
whenever
we
make
changes
to
it
just
say:
hey
look.
D
C
So
we've
been
pretty
I.
Think
we've
been
open,
at
least
on
the
Google
side,
that
whenever
we
talked
to
these
folks,
we
we
throw
things
on
the
cig
and
we
throw
what
we're
talking
about
and
giving
updates
to
it.
I
kind
of
encourage
you
to
do
that
too.
Just
so
that
a
you
know
we're
all
on
the
same
page,
and
we
know
for
duplicating
effort
and
things
like
that.
D
C
Work,
you
may
be
overthinking
it
or
maybe
I'm
thinking
for
more
than
I
may
be
implying,
which
is
just
you
know,
hey
you
know,
I
Steve,
Wong
and
some
buds.
We
met
and
talked
with.
You
know
these
folks,
and
these
were
what
they
were
thinking,
and
these
are
what
we
were
thinking
and
it's
sort
of
a
conversation
and
a
heads-up
than
anything
like
official.
At
this
point,
yeah.
C
C
D
A
So
getting
back
to
the
topic
of
what
going
to
look
like
in
1.6,
I
think
we
agree
that
it
should
have
dynamic
provisioning
and
attached
or
interface.
There's
some
question
about
exactly
what
we
want
to
call
it.
We
can
hash
that
out
later
any
other
comments
on
flex
or
outreach,
just
a
photo
I
share
proposal
or
the
Flex
API.
H
C
I'm
curious
who's
gonna
be
driving
it
a
little
bit.
I
think
I
think
you
know
we're
all
talking
about,
yeah
be
really
cool
to
have
it,
who's
got
cycles
and
the
interest
in
working
on
it.
I
know
that
I
do
feel
that
you
know
sod
and
I
and
some
people
from
Tim
and
probably
you'd
start
looking
at
it
in
January
more
actively
than
we
have
been.
It
feels
like
for
the
alpha
version
of
flags
or
the
half
point
five
virgin.
It
looks
like
Gopal,
Gopal
and
chakra
Chuck
I'm.
C
Sorry,
Chakri
are
I
heard
of
driving
that
and
working
on
the
detach
and
a
tad
stuff
for
the
more
finished
version.
You
know
we
one
of
the
things
that
sounds
like
we
may
want
to
start
thinking
about
with
a
storage.
Stick
in
general
is
sort
of
breaking
down
into
working
groups
a
little
bit
where
we
have
people
who
are
actively
pushing
and
focusing
on
things
as
it
goes
to
where
I
think
we're
all
sort
of
talking
about.
Wouldn't
it
be
nice,
though,.
F
So
we
don't
I,
don't
want
to
take
the
work
away
from
Chakri
I
kind
of
feel
like
if
this
is
something
that
he
wants
to
continue
to
own.
Like
you
should
you
know
he
has
kind
of
first
rights
to
it
if
nobody
willing
to
take
it
or
if
it's
too
much
of
a
burden,
I,
definitely
think
it's
something
that
you
know
we'd
be
willing
to
pick
up
all
right.
It's
there's
some.
You
know
some
tie-in
with
containerized
them
out
and
some
other
stuff
that
we
might
trickle
into
it.
Wait
all
right.
C
C
That
it
sounds
like
what
we
need
to
do
is
maybe
just
sort
of
engage
with
Chakri.
You
know
next
week
and
say:
let's
start
working
on
this.
You
know
and
then
have
updates
to
the
sig
every
two
weeks.
Aldila
and
people
are
interested.
It
sounds
like
a
Chakri,
sir
Sergei
I
apologize,
Search,
Search
Brad,
you
you're
interested
in
this
too.
It
sounds
like.
J
C
G
Listen,
we
got,
we
do
so.
The
first
thing
which
we
will
do,
which
I
think
I
mean
we
haven't
done.
We
update
the
proposal
with
like
okay.
What
are
the?
What
are
the
blockers?
Some
of
the
questions
which
which
we
did
not
answer
and
basically
maybe
deviate
down
divvied
up
among
the
folks
and
at
least
basically
have
broader
audiences
look
through
it
and
and
and
break
it
down
right,
so
I'll
I'll
have
a
I'll.
Have
him
basically
update
that
and
then
start
start
up
to
gather
people
to?
G
F
H
F
H
C
H
Just
so
Oh
quick
summary,
so
soja
sauce
there
and
right
on
Iowa
stairs.
So
my
feeling
is
that
some
there's
a
wide
range
of
unfamiliarity
with
API
proposal
that
I
will
suggest
you
for
your
look
at
api
like
comments
over
there
and
we
start
from
their
office
and
not
a
feeling
that
there's
no
are
exhaustive
inputs
that
we
can
take
for
the
version.
1
legislate
api
version
1.
So
when
it's
being
realistic
to
have
everything
covered,
so
we
probably
can
have
a
word
in
the
delivery
and
going
forward
because
we
don't
have
every
functionality
yet.
H
E
Woman
that
you
know,
saw
the
goals
of
the
final
product
for
flex
for
kneeing,
on
possible
gate
and,
if
there's
yeah
kingdoms
that
we
need
to
do
or
I'm
gonna,
load
infos
and
instead
of
thing
to
you
can
arrive
at
that
point.
So
it's
not
possible
to
maybe
design
around
some
of
these
things.
Yet.
Is
that
your
point
on
the.
H
I
A
He
actually
so
in
1.4
mikkel
was
actually
working
on
a
PR
I'll
paste
it
into
the
chat
window.
That
was
actually
pretty
close
to
what
the
API
proposes.
An
included
attach,
detach
and
I
believe
it
also
included
the
dynamic
provisioning
I
have
to
verify
that
it
might
not
have
actually
included
an
emic
provisioning,
I'm
gonna.
It
was
a
very
solid
PR.
It
was
a
very
good
refactor.
One
of
the
problems
with
it
was.
It
was
a
huge
breaking
change.
A
lot
of
people
already
depend
on
flex.
A
This
would
break
it
and
there
were
a
few
big
open
design
issue,
questions
that
weren't
resolved
and
we
were
unsure
if
we
were
willing
to
merge
that
break
the
flex
API
and
then
come
back
iterate
on
it
again
and
break
the
API
again,
and
it
sounds
like
we
still.
Even
if
we
come
up
with
some
API
that
we're
happy
with
at
the
moment
it's
going
to
be
questions
about
well,
hi.
We
add
in
snap
a
you
know,
a
snapshot
supporter.
A
If
we
want
to
tweak
the
API
somehow
do
we
have
the
ability
to
do
that
and
that's
why
I'd
caution
against
calling
this
v1?
We
want
to
make
sure
that
we
became
the
flexibility
of
being
able
to
modify
the
API
in
future
iterations,
but
at
the
same
time
we
don't
want
to
iterate
so
off
that
we're
breaking
the
API
every
milestone
and
people
can't
develop.
You
know
plugins
against
against
flex.
So
it's
a
trade-off.
A
H
F
Of
future
features
that
are
implemented
in
any
volume
code
like
snapshotting,
and
we
kind
of
lump
that
into
like
the
next
version
of
flexing
how
that
would
be
handled.
I
I
don't
want
to
address
that
in
any
shape
or
form
on
the
first
draft
of
the
design.
Doc
we'd
probably
want
to
keep
it
something:
realizable
I
and
then
just
iterate.
On
that
his
features
come
into
play
right,
I
mean
I.
F
Everything
I
think
we
spent
like
three
quarters
of
time
on
the
second
iteration
of
flex,
plug-in
talking
about
features
that
don't
even
exist
in
the
buying
framework.
Yet
how
we
would
add,
so
there
may
not
be
a
whole
audience
the
second
iteration
of
this
until
we
have
snapshotting
I.
You
know,
and
some
of
the
other
media
things
to
talk
about
I.
A
C
Make
sure
the
action
item
is
clear:
while
Chakri
is
out
Brad,
you
will
go
Paul.
Can
you
make
sure
to
you,
know,
work
with
Brad
and
so
that
you
know
Chakri
hasn't
left
in
the
dust
and
you
guys
can
start
working
on
this.
You
know
today
or
tomorrow,
I
think
we
should
be
careful
that
you
know
for
folks
who
are
gonna
get
involved
in
this.
Please
be
people
who
are
contributing,
as
opposed
to
just
people
who
are
interested
in
trust.
The
team
will
communicate.
C
Don't
see
a
time
frame
for
CBI
I
see
CBI
is
going
to
probably
be
you
know,
a
a
set
of
long-term
discussions
that
will
be
happening.
It
seems
like
many
different
forums
between
Cloud
Foundry,
meses
and
Cooper.
Nettie's
Tim
and
I
have
talked
to
two
representatives
from
that
team
already
and
it
sounds
like
the
MC
folks
are
also
talking
to
them
on
the
same
score.
So
I
I
don't
see
anything
urgent
about
that
time
frame.
C
E
K
F
A
Know
about
that
bad!
I
I'm
not
sure
about
that,
because
flex
is
not
at
the
point
where
we
can
start
advertising
it
as
something
that
is
production
ready.
It
doesn't
have
the
same
level
of
testing
and
it
just
has
basic
issues.
Things
like
how
do
you
deploy
when
you
don't
control
the
master
right?
So,
for
those
reasons,
are
you
go
ahead?
Michael,
don't.
A
D
C
So
here's
my
take
away
right
now
when
people
ask
me
about
this
stuff
and
I'm
curious,
what
other
people
think
I
believe
that
Cooper
Nettie's,
especially
from
cute
con?
My
impression,
is
it's
pretty
successful,
there's
a
lot
of
interest
in
it
and
there's
a
lot
of
belief
that
you
know
this
is
something
that
a
lot
of
vendors
want
to
be
able
to
include
their
functionality
inside
storage.
C
At
the
same
time,
I
also
feel
that
it's
almost
faster
than
the
infrastructure
has
been
able
to
handle,
and
if
we
look
at
it
now,
I
see
sort
of
two
angles
here,
which
is
why
I'm
very
comfortable,
there's
two
tracks,
and
maybe
even
two
working
groups
that
will
be
dealing
with
in
2017.
One
of
them
is
how
the
heck
do
we
make
sure
that
we
have.
You
know
the
diagnosis
mechanism
to
you
know,
make
this
easier
on
the
users
and
then
the
other
one
is.
C
How
do
we
make
things
easier
for
the
vendors
I
feel
that
there's
probably
gonna
have
to
be
some
I
wish.
In
my
mind
we
could
say:
hey
vendors.
We
have
a
great
solution
that
will
let
you
integrate
now
and
iterate
at
your
own
speeds
and
we're
ready
to
go,
but
I'm
not
sure
that
we're
there
yet,
and
I
also
think
that
it's
so
important
to
get
this
right,
because
we've
seen
you
know,
everyone
keeps
telling
me
about.
C
What's
that
other
open
source
project
that
you
know
became
really
unruly
to
some
degree
out
open
or
stack,
Hogan
or
OpenStack,
where
you
know
it
got
a
little.
You
know
it
didn't
focus
enough
on
the
user
experience.
So
we
are,
you
know
we.
We
may
have
a
bit
of
a
frustrating
first
half
of
the
year
for
integrating
things
out
of
tree
I'm,
hoping
that
it
pays
off
and
I
think
that
we
need
to
make
sure
that
we
stay
honest
with
ourselves,
get
the
proposal
in
one
dot
six
and
then
implement
it.
C
You
know
as
soon
as
we
can
so
that
we
can
start
migrating
storage
plugins
in
17
or
18,
but
I
right
now
from
the
discussions
that
I'm
seeing
it
feels
like
it's
worth.
Taking
this
time,
I'm
curious.
Does
anyone
else,
think
that
I
mean
am
I,
crazy
or
well?
I'm
just
trying
to
parse
the
message
that
we
would
tell
somebody
like.
E
Just
trying
to
rationalize
it
also
we're
saying
you
know
what
as
an
example
like
for
folks,
if
they
want
to
9am
flatter
me
as
very
motivated
to
try
and
get
something
out
by
keep
16,
for
example,
like
with
say
the
external
and
external
provisioner
proposal.
There
was
a
external
interface
provision
that
was
developed,
and
so,
like
one
thing
we
could
say
is
hey.
If
folks
are
interested
in
building
something
out
of
tree
today,
they
could
take
that
same
approach.
E
A
Because
my
fear
is
that
the
whatever
version
of
flex,
whatever
iteration
of
flex
we
come
up
with
in
1.6,
will
not
be
final.
We're
going
to
make
breaking
changes
to
it
at
some
point
and
when
that
happens,
if
people
have
developed
vol
plugins
against
that
they're
going
to
be
in
a
very
bad
state
versus
the
the
volumes
that
are
entry,
what
we've
been
doing
is
whenever
we
make
a
break
and
change
we
go
in
and
we
modify
those
volumes
and
make
sure
that
they're
working
with
the
current
current
version.
A
A
C
E
A
I
C
I
A
C
A
A
Or
whatever
we're
going
to
call
it
like
the
next,
the
final
version
of
the
out
of
tree:
that's
what
we
want
people
to
actually
develop
against,
and
we
tell
people
whatever
we
ship
in
1.6
rewrite
your
flex,
your
volume
plugins
against
that
and
then,
whenever
we
ship
that
they
have
to
rewrite
I.
Just.
C
Going
to
have
to
be
a
release
or
two
releases
where
we
overlap
support
for
both
we
deprecate
one,
and
we
turn
on
the
other,
nothing
to
say
it's
probably
a
year
that
we
have
to
do
that
right
and
this
the
standard,
API
deprecation,
your
mom,
ready,
I,
think
who
benetti's
I
thought.
Well,
it
depends
if
it's
an
API
thing
or
if
its
release
support
thing.
I've
seen
the
game
played
both
ways.
It's
either
two
releases,
which
means
six
months
or
I've.
F
C
I
mean,
I
think,
for
six
months:
that's
what
we're
going
to
be
and
then
we
we
pull
it
out,
and
you
know
it
will
pull
it
out
in
such
a
way
that
when
it
does
work,
we
point
out
to
people
hey
this.
Is
you
know
it's
not
like
a
amount
failure,
that's
impossible
to
debug,
but
it's
something.
That's
a
very
clear
signal
of
you
know
we
give
everyone
heads
up.
This
is
going
away.
This
is
going
away
and
then,
when
it
does
it's
not
they
fall
flat
on
their
face.
It's
oh
look.
C
I
F
So
right
in
regards
to
like
live
storage
as
a
hospital,
I'm
exemplar
prefer
the
flex
pattern.
I
was
kind
of
hoping
that
the
you
know
the
complexity
in
the
features
of
that
would
help
drive
of
the
features
that
we're
expecting
for
version
wanted
versions
right
like
we
don't
have
like
a
solid.
What
we're
hooking
this
into
and
live
storage
happens
to
be
like
a
fairly
complicated,
pretty
cool
piece
of
code
that
we
could
use
submit
this
I.
F
F
C
How
are
those
people
also
working
on
the
the
there's
to
flick
solutions
right,
I'm?
Sorry
now
you
got
me
confused,
but
also
I
really
want
to
make
sure
that
we
spend
the
last
ten
minutes
talking
about
the
NFS
wedging
to
you
know
we
didn't
have
this
issue
eat
up
everything
that
seems
like
something.
We
really
need
to
get
off
our
tickets
for
106,
and
there
is.
E
The
broader
thing
right,
we
have
folks
right
now,
like
Vladimir
who's,
got
a
PR
in
flight
and
is
continuing
to
rebase.
It
replace
a
rebase,
a
rebase
it
you
know
so
like
if
you
know
that
that
was
sort
of
one
of
the
motivations
right
so
like.
If
we're
making
the
decision
where
stuff
that's
not
yet
merchants
to
go
out
a
tree,
then
effects
that
are
continually
rebasing
stuff
should
be
told
so
that
they're
not
feel
like
they're
just
in
time
to
the
world.
Okay,
yeah.
A
C
E
I
L
L
C
Think
entry
is
probably
going
to
be
the
thing
that
we
recommend
to
people
until
the
proposal
is
complete:
okay,
great
evolution.
If
I
was
a
vendor
I
that,
regardless
of
anything,
anyone
in
this
room
said
I
think
that's
what
I
would
do
I'm
curious.
What
what
other
people
you
know
inside
the
room?
Think,
but
you
know,
if
everyone
told
me
yeah
look
flex
is
coming.
C
We
should
have
a
proposal,
have
one
dot
six,
but
the
proposal
isn't
done
yet
and
there's
a
group
thats.
You
know
really
getting
the
last
bit
of
it
home
to
the
touchdown
line
it
kind
of
ugly
and
that
we're
sort
of
saying
entry
for
now,
even
though
it's
got
a
higher
bar
and
then
watch
flex
and
you're
probably
going
to
have
to
support
to
yourself
for
a
little
bit
so
that
when
it
comes,
you
want
to
be
maybe
one
of
the
first
people
integrating
to
it.
So
the
hell
you're
you're
involved
in
already
exactly.
L
F
Functionally
one
dot,
six
flex
will
part
of
all
the
features
of
intrigue.
Plugins
capable
will
have
a
text
attached
mount
on
mount
this.
The
proposal
that
we're
talking
about
is
the
second
iteration
of
it.
It
I,
you
know,
I
mean
you're
kind
of
getting
a
little
bit
for
looking
features
that
we
haven't
totally
fleshed
out
yet
so
I
I
feel
like
we're
going
to
have
something:
that's
usable
and
an
API
that
used.
You
know
that
could
be
integrated
with
for
sure.
F
A
F
A
Think
Michaels
point
was:
if
you
are
a
vendor
who
is
developing
a
plug-in?
Do
you
want
to
take
the
gamble
and
hope
that
everything
that
we
are
promising
for
1.6
4
flex
lands
as
expected
or
not,
and
I
think
he's
right
as
a
vendor?
You
kind
of
have
to
make
that
decision.
Own
and
I
agree
with
the
him.
If
I
was
a
vendor,
I
would
probably
go
with
the
tried
and
true
solution
rather
than
gamble.
I
would.
C
Do
both
I
would
do
exactly
what
I
think
someone
from
storage
OS
just
said,
which
is
watch,
watch
the
new
things
that
Brad's
working
out
with
Chakri
really
tightly,
and
you
know
Shepherd
that
along
and
kick
it.
You
know
as
you
go
and
then
also
still
invest
in
the
entry
stuff.
At
the
same
time,
which
is
going
to
just
teach
you
more
about
Cooper,
Nettie's
anyway,
I
agree.
C
L
H
A
Yes,
that's
the
next
item
on
the
agenda.
Let
me
paste
it
into
the
chat
window.
This
is
an
issue
that
has
existed
for
quite
a
while.
The
problem
is
that
when
an
NFS
server
goes
down,
it
can
cause
Cuba
to
hang
and
the
reason
is
because
qubit
I
will
go
out
and
do
a
stack
on
the
directory
that
was
mounted
for
NFS
and
the
colonel
just
hangs
indefinitely.
While
this
wild
NFS
server,
sorry
the
kernel,
hangs
indefinitely.
A
While
the
server
is
down
in
1.3,
we
did
a
major
rewrite
where
we
isolated
all
the
volume
plugins
from
the
primary
queue
blood
path,
so
that
if
there
was
an
issue
in
the
mount
unmount
or
any
of
these
paths
for
a
particular
volume,
it
only
affected
that
particular
pod.
It
doesn't
affect
all
of
cube
late.
A
Basically,
if
it
hits
an
NFS
volume,
that
is,
the
server
is
down,
it
will
block
cubelets
indefinitely
into
but
needs
to
be
restarted.
Some
of
the
folks
at
Red
Hat
put
out
a
fix
for
this.
They
modified
it
so
that
this
path
was
not
doing
a
stat,
but
it
was
just
doing
a
reader
to
get
the
file
names
for
for
that
directory,
and
then
we
broke
that
we
being
me
and
Jing
at
Google,
because
we
added
in
code
to
actually
verify
that
directory
is
mounted
or
not
yet.
C
A
So,
like
any
other
bug-
and
this
is
something
that
Aaron
and
I
have
been
hammering
over
and
over
again
for
the
last
quarter-
is
every
fix-
we
do
should
have
a
été
test
or
an
integration
test
or
unit
test
verifying
it.
In
this
particular
case,
when
we
quote
unquote
fix
the
NFS
wedge
issue,
we
should
have
had
a
test
which
basically
brought
up
a
server,
did
amount
pour
down
the
server
and
made
sure
that
cube
'let
was
responsive
and
that
things
could
move
along
normally,
oh
my.
M
N
M
A
So
yeah
you
still
want
to
get
this
fixed,
Jing
and
I
have
been
talking
very
quickly
about.
If
there's
anything
we
can
do
for
1.5,
we
may
be
able
to
revert
to
a
read
directory
solution
and
not
verify
whether
mounts
are
whether
the
directories
are
mounted,
because
we
may
not
need
that
on.
That's
still
a
solution
that
we're
discussing
at
the
moment.
A
If
we
have
something
we'll
update
the
thread,
otherwise
speaking
with
Tim
Tim
Hawkins,
it
looks
like
the
solution,
for
this
is
going
to
be
a
bigger
refactor
to
ensure
that
when
the
primary
culet
thread
spawns
off
any
process
that
can
potentially
block
like
stat,
that
it
gets
spun
off
on
a
separate
thread
and
that's
non
blocking
and
it
times
out
and
things
like
that,
that's
a
bigger
rewrite
I
will
see
if
we
can
get
a
quicker
fix
in
for
1.5,
it
may
or
may
not
be
possible.
We'll
keep
you
updated,
though,.
C
A
F
G
L
C
Question
is
like
I:
we
don't
have
a
ton
of
NFS
expertise
over
here.
Is
there
any
way
that
we
can?
You
know,
come
up
with
some
net
or
detector
for
any
sort
of
access
of
the
NFS
storage.
That
would,
you
know,
cause
these
lockups
when
the
storage
is
down
so
that
we
can
almost
like
have
a
you
know,
some
way
of
detecting
when
people
add
in
code
that
might
trip
this
in
the
future.
Because
someone
we
know
we're
gonna
do
it.
I
mean
the
moment
we
set
this
up
to
be
clean.
H
Others
are
not
0
comments,
so
the
volume
code
is
really
complicated,
is
getting
complicated
nowadays
and
is
really
appreciated
if
Jim
Landoll
stat
can
give
us
overview
or
some
kind
of
all
of
you
and
like
a
YouTube,
so
we
kind
of
stand
of
us
is
going
well.
So
rather
when
we
touch
this
code
with
no,
this
is
a
sensitive
stuff
and
you
should
pay
special
attention.
That
is.
C
Another,
but
this
is
true
of
two
ways:
I
think
one
is
that
not
only
is
the
code
in
queue
on
the
node
complicated,
but
the
or
the
the
storage
area
complicated
but
also
I,
think
NFS
is
complicated
for
us,
and
so
it
might
be
good
in
both
directions
to
have
like
an
NFS
primer
that
you
know
it
doesn't
even
have
to
be
a
video.
You
know
if
anyone
ever
wanted
to
just
either
come
and
talk
to
us
or
give
us
like
a
GBC
or
anything.
C
That
would
be
really
really
helpful,
I
think
for
at
least
us
in
Google,
and
maybe
other
people
on
the
cig
and
then
the
other
one
is
I,
think
you're,
absolutely
right.
Woman
and
I
think
that
we
should
do
something
like
that,
and
you
know
sods
been
kicking
around
some
ideas
and
we
should
probably
do
something
even
more
in
can.
D
A
H
Toria
Cassandra
spare
moments
from
this
topic,
so
we
have
been
talking
about
the
mouse
options
and
the
fastest
and
most
options.
If
you
up
for
apply
a
proper
maths
options,
maybe
you
can
just
avoid
this
problem
at
all
on.
You
know
it's
not
really
like
an
ideal
solution,
but
so
could
it
be
a
walk
around
yeah.
A
Now,
that's
that's
a
possibility.
We
can
modify
the
options
we
use
to
mount
NFS
so
that
it
doesn't
hang
speaking
with
Tim
I
think
he
was
hesitant
about
that,
because
the
options
would
quote
unquote,
do
a
lazy
unmount
and
what
that
ends
up
doing
is
actually
not
doing
the
unmount
and
just
promising
that
when
it's
possible
it'll
do
the
unmount
and
that
may
break
assumptions
that
were
making
about
the
system.
So
we
need
to
be
very
careful
about
that.
I'm.
N
Guessing
that
what
Wallman
was
actually
talking
about
was
doing
the
NFS
mount
with
interruptible
or
soft
I
mean
we're.
Yes,
oh,
come
out
starred,
which
means
it
will
retry
the
colonel
will
retry
forever
and
will
never
return,
whereas
if
you
mount
with
what
is
it
soft,
the
colonel
will
throw
back,
but
what
I
don't
remember,
e
busy
or
eerie
try
or
one
of
those
eerie
tries
rather
than
hang
forever,
so
we
could
potentially
mutate
the
NFS
mount
options
we
use.
So
the
colonel
doesn't.
N
H
A
The
mount
options
PR
it's
been
out
for
a
while
and
I-
think
the
big
concern
there
is
about
punching
a
hole
in
our
abstraction
layer.
We
expose
an
API.
Do
we
want
to
get
into
the
business
of
saying
that
there
is
an
unverified
blob
of
options
that
will
be
passed
through?
We
don't
do
any
verification
on
it
and
we're
just
gonna
Massacre.
F
H
A
So
the
thing
is
these
options
would
be
specific
to
the
volume
plugin
all
right.
So
now
you
need
to
do
verification,
/,
plugin
and
I.
It's
technically
feasible.
We
could
extend
the
API
to
a
verifier
for
for
the
amount
options
that
are
passed
in
the
API
server
when
it
sees
one
of
these
fields.
It
can
invoke
theoretically
the
volume
plugin
that's
responsible
and
ask
it
to
validate
the
options
and
reject
options.
It
doesn't
support,
but
the
we
should
take
it
to
to
the
thread
itself.
G
J
G
C
G
C
C
G
C
No,
no,
the
NFS
by
its
nature
is
knobs.
My
question
is,
like
you
know:
Steve
Brad,
the
people
I
know
who
are
really
really
tight
with
NFS.
You
know
who
deal
with
customers
all
the
time
on
these
things.
Is
there
any
customer
who
comes
to
NFS
and
doesn't
expect
to
have
to
and
want
to
turn
all
the
knobs
themselves,
but.
H
C
I
get
that
that's
the
second
part
of
where
I
was
going
to
get
to
so
is
there
any
like?
Is
the
number
of
customers
for
NFS?
Who
don't
want
to
have
to
think
about
knobs,
just
so
small
that
it's
not
even
someone
we
should
be
talking
to,
and
instead
we
should
just
focus
on
being
able
to
make
the
command
line
like
that
to
expose
the
knobs
to
the
users
in
a
way.
That's
like
simple
and
clear
so.
F
C
F
Yeah
yeah
so
I
think
that's
what
wallman's
chasing
it
is
like.
What
we
have
right
now
is
probably
a
reasonable
set
of
default
options,
and
if
we
had
the
ability
to
adjust
knobs,
we
could
probably
just
not
didn't
require
a
code
fix
we
could
tie
around
with.
You
know
mount
options
to
make.
You
know
to
get
past
this
issue.
Do
you
think
that.
H
F
A
F
F
C
D
Whole
reason
you've
got
all
these
options.
Is
that
NFS
morphed
over
years
and
years,
then
you
have
different
vendor
implementations
and
some
of
the
specs
are
so
loose
that
you
could
conceivably
at
certain
errors,
have
things
you
deemed
compliant
that
that
were
arguably
compliant
to
what
the
written
spec
was,
but
still
wouldn't
talk
to
the
other
end.
D
But
if
you
put
these
options
there,
you're
you're
also
going
to
be
obligate
to
explain
what
they
mean
so
there's
a
big
documentation
load,
including
this
they're
cool
because
I
don't
know
it
I'm,
not.
The
NFS
expert
I
heard
your
request
to
maybe
get
a
training
guy
and
within
the
LM
EMC
we
have
those
guys
but
I'm,
not
that
guy
I'm
gonna
see
what
I
can
do,
but
it
just
my
experience
is
that
NFS
is
easy,
even
within
the
hallways
of
one
single
vendor
it.
C
Okay,
let's
can
we
make
this
a
p0,
not
bug,
but
like
actually
a
feature
for
one
dot,
six,
something
that
I
think
it
fits
into.
The
idea
of
the
like
refinement,
release
and
planning
anyway
not
make
this
something
that
we
kick
the
can
on,
and
it's
not
so
much
as
fixing
things
that
are
wedged,
but
addressing
the
options,
issues
that
woman
has
been
pushing
for
I
think
quarters
anyway,
it
sounds
like
woman
should
probably
be
you
know.
I
I
don't
want
I
feel
always
bad
when
I'm
like.
Oh,
why
don't
you
look
in
this?
C
Why
don't
you
look
on
that?
I'm?
Not
you
know
everyone's
boss
or
anything,
but
it
feels
like
woman
has
a
lot
of
investment
in
this
already.
Do
you
want
to
you
know?
Is
it
would
that
be
appropriate,
like
Brad
and
woman
to
have
him
make
this
sort
of
like
his
feature
for
16,
and
we
make
sure
it
gets
reviewed
and
make
sure
it
gets
the
attention
that
it
needs?
C
He
does
and
I
think
that,
because
of
where
we
were
with
dynamic
provisioning
and
with
testing
and
with
a
bunch
of
other
things,
we
have
not
given
it
the
attention
it
deserves,
and
I
think
that
time
is
past
and
I
feel
like.
We
really
need
to
delve
deeper
into
this
4416
and
I
think
we
should
have
the
time
to
do
so.
We.
F
F
A
C
Needs
to
be
general
honestly.
This
is
something
where
I
want
to
throw
it
by
the
google.
The
way
we
arranged
this
is
that
Tim
Hawkins
is
our
uber
TL
for
infrastructure,
and
so
this
is
something
where
I
it
doesn't
just
get
applied
to
storage.
It's
also
things
that
we're
seeing
in
networking
and
some
things
in
the
node
team,
so
I
wouldn't
mind
throwing
this
past
his
desk
in
saying,
hey,
Tim,
you
must
look
at
this
and
you
know
he
I
think
he'll
be
able
to
carve
time
out
for
it
all.