►
From YouTube: Kubernetes SIG Storage 20170817
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 17 August 2017
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.3gvb765za5sg
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:19:06 From Jan Šafránek : Out of curiosity, is there a way how to see a name of current speaker in zoom?
09:19:50 From hchiramm : iic, its per namespace
09:20:02 From Luis Pabón : cool, thanks Humble
09:20:08 From Luis Pabón : Jan, I'm not sure
09:20:41 From hchiramm : yw Luis!
09:21:30 From Luis Pabón : Jan, you can guess by looking at who is unmuted in the Participants window
09:22:31 From cxing : Jan if you see the list of thumbnail videos, there’s a yellow box around who is speaking. If that’s minimized it’ll say “Talking: [username]”
09:23:25 From eparis : If you minimize (so you can't see the screen) it tells you who is talking....
09:24:41 From cxing : If you don’t see that, go to the top of the screen, View Options -- Show Who’s Talking panel
09:39:35 From brad childs : https://github.com/kubernetes/community/pull/855
10:00:58 From eparis : Community meeting time!
10:01:51 From Gerry : For all it is worth, I'll be in San Francisco for LISA Oct 30-Nov 3rd
A
Alright,
hello,
everyone-
this
is
the
bi-weekly
meeting
of
the
kubernetes
storage
special
interest
group
today
is
August
17
2017.
As
a
reminder,
this
meeting
is
public
and
recorded
and
published
on
YouTube
I'm,
going
to
share
my
screen
and
we'll
go
through
the
agenda.
Doc.
If
you
have
any
questions,
comments
concerns
anything
you
want
to
discuss.
Please
add
it
to
the
agenda.
Dockets
link
in
the
calendar
invite.
A
We're
going
to
start
off
by
going
through
the
planning
spreadsheet.
Actually
you
know
we're
going
to
flip
flip
this
today,
we're
going
to
Jing
talked
to
me
earlier.
She
really
wanted
to
go
over
the
local
storage,
isolation,
design
and
I
want
to
make
sure
that
we
have
enough
time
for
that,
so
I'm
going
to
go
ahead
and
pull
the
design
reviews
to
the
front
and
let
Jing
talk
about
the
local
storage
isolation
stuff
first
and
then
we'll
go
through
the
rest
of
the
agenda.
Jing.
Do
you
want
to
take
over
yeah.
D
A
A
C
So,
basically,
after
last
week's
meeting-
and
we
discussed
this
feature-
but
after
that
we
have
another
meeting
and
things
through
the
design
again
and
finally,
we
visited
by
like
decide
anew
the
relative
new
design
is
revised
exam,
and
so
we
want
to
only
support
one
resource
API
for
this
local
storage
isolation
feature
on.
There
are
a
few
reasons
so
to
avoid
some
confusion
and
complexity
caused
by
this
multiple
storage
ignite.
We
for
why
like
proposed
before
and
also
it
gave
us
some
benefit
of,
like
local
storage
measurement,
will
be
very
consistent
with
memory
management.
C
So,
oh,
the
behavior
would
be
very
similar,
so
people
will
very
easy
to
understand
and
also
we
so
busily
with
design
to
only
manage
one
root,
partition,
storage
space
and
before
we
consider
you,
like
second
storage
partition,
but
it's
really
not
a
common
case,
and
normally
it
is
because
of
the
device
my
per
use
bag
like,
for
example,
Red,
Hat,
and
but
we
got
to
know
they
move
from
that
to
only
one
partition
and
also
on
actually
for
the
best.
My
prayer
is
not
good.
C
F
A
She
introduced
a
couple
of
alpha
resources,
Jun
correct
me
if
I'm
wrong,
I
think
they
were
called
overlay
and
with
its
crack
stretch.
Yes,
that's
right,
and
so
the
idea
was
you
introduced,
two
mechanisms
by
which
you
can
either
set
global
limits
on
what
how
much
a
container
can
take
and
then
set
minimums
as
well
if
your
container
needs
it.
A
In
that
case,
the
overlay
would
correspond
to
the
writable
layer
for
your
container
and
scratch
would
be
what
emptied
er
would
use,
and
so
what
Jing
is
talking
about
today
is
evolving
that
design
she
had
designed
discussions
with
folks
and
the
decision
was,
it
might
not
make
sense
to
have
two
separate
resources.
Rack
track
this,
and
instead,
let's
have
a
single
resource
to
track.
All
of
that
ephemeral
storage
that
we
steal
from
the
local
node
go
ahead.
Ding,
sorry
about
that.
C
Yes,
thank
you.
Thank
you.
I
forgot
to
give
more
background
on
this
Thank
You
that
and
so
after
this
decision,
then
I'll
just
go
over
the
design
for
this
basically
for
local
storage
and
for
storage,
and
we
have
one
API
to
represent.
There
are
bit
that's
issue
where
it
is.
Currently
we
already
have
one
storage,
API
called
the
resource
storage.
C
C
Later,
we'll
see
why
it
matters,
so
we
like
which
option
we
should
choose,
and
so
after
we
have
this
storage
type,
you
can
set
results,
limit
and
request
similar
to
CPU
and
memory.
So
currently
we
support
continued
level
resource
requirements.
So
in
your
container
stack
you
can
specify
like
limit
and
request
or
CPU
memory
and
now
with
support
storage
and
after
you
specify
that
the
scheduler
will
make
sure
whatever
you
request
would
be
satisfied
and
also
the
eviction
manager
will
make
sure
the
link
limit
is
bounded.
C
So
it's
monitor
the
usage
and
if
they
use
usage
of
the
container
exceeds
the
limit,
the
part
will
be
evicted
and
for
Part
A
level
results
constraints.
So
right
now
we
don't
explicitly
like
have
this
poly
level
results
requirement
set,
so
you
can
now
set
up
other
level
constraints
they're
actually
in
API,
but
we
do
have
poly
level
resource
constraint
support.
Basically,
it
will
use
the
some
of
the
total
image
you
specified
in
containers
and
consider
as
the
value
of
the
power
level
image.
C
So
after
you
specify
which
containers
limit,
then
the
total
resource
limit
will
be
the
power
level
and
for
local
storage
case,
because
we
have
different
type
of
users,
like
am
teacher,
uses,
graduate
and
containers
overlay
analogues.
So
all
of
these
resource
usage
will
be
bounded
by
this
pot
level
on
the
south
limit,
and
we
still
want
to
support
em
teacher.
We
gave
a
new
parameter
called
site
limit
it.
C
Basically,
it's
an
additional
not
that
you
can
control
like
how
much
results
you
want
to
give
for
your
anteater
I
mean
there
is
the
power
level
volume
so
managed
separately.
So,
if
you
that
gave
us
that
name
is
subscribe
for
this
and
leader,
then
we
also
check
whether
the
the
image
is
constrained,
elect
bounded
or
not,
and
here
is
a
simple
example.
So
in
this
example,
you
can
see
in
the
pot
definition
we
have
two
containers
of
fousey
and
the
bar,
so
each
one
have
their
limits.
C
C
Ok,
if
that
container
usage
exceed
10
gigabytes
for
Swissy
or
not
if
it
exceed
that
it
will
be
big,
the
whole
pot
and
also
I'm
data,
or
you
can
also
set
a
limit-
let's
say
just
5
device,
so
it's
also
monitored
and
music,
whether
it
is
inside
of
the
limit
and
again
for
pot
level
resource,
so
it
will
as
attending
events
from
Suzy
and
15
gigabytes
from
bar
as
the
pot
level
image,
so
that
is
total
25.
So
the
total
usage
of
your
whole
pot,
including
log
container
overlays
and
the
editor,
should
not
exceed
25.
C
So
is
that
clear
so
that
let
me
know
if
you
have
any
questions
so
here
is
just
again.
The
invention
policy
I
just
mentioned
for
poly
level,
container
level
and
also
scheduler,
will
try
to
verify
whether
the
some
of
the
containers
requests
can
be
satisfied
by
the
total
idle
credible
resource.
On
that
note,
and
so
we
also
want
to
support
Kota
for
white
and
so
for
Kota.
You
can
set
limit
and
request
to
here's
the
problem
again
for
API
design.
C
C
But
this
way
that
means
we
restrict
that
needs
to
value
this
to
Kota
will
be
always
the
same
day.
Today
for
local
and
remote
storage,
we
are
going
to
have
used
to
going
to
have
use
the
same
request.
Kota
and
the
other
option.
Is
we
again
use
a
new
API
and
we
call
results,
for
example,
scratch
storage
scratch,
so
you
will
have
to
code
help
or
resource
request
and
resource
limit.
C
A
So
sure
so,
basically,
what's
being
proposed,
is
there
already
exists,
multiple
resources
that
you
can
set
limits
on
in
the
kubernetes
api
on
containers
that
includes
CPU
and
memory?
It
happens
that
the
word
storage
already
also
exists,
and
it
has
been
used
to
apply
quota
limits
to
to
PVCs
so
to
be
able
to
limit
the
size
of
volumes
that
can
be
externally
dynamically
provisioned.
A
G
G
C
How
much
that
the
problem
is,
if
you
only
have
one
that
means,
because
for
Kota
right,
basically,
you
are
going
to
set
quota.
If
this
API
we're
going
to
apply
to
both
remote
and
the
local
remote
means
infinity,
storage,
Kota
and
the
local
is
the
local
ephemeral
storage.
So
suppose
you
have
a
coat
out
of
pending
back
then
that
means
for
remote,
TVC
storage
Kota
will
be
going
to
10k
back,
and
you
also
have
to
also
for
local.
G
D
So
we
in
3:6
added
the
ability
to
do
quota
per
storage
class,
so
I
I.
Actually
after
we
added
the
ability
to
do
quota
per
storage
class
I
disliked
the
resource
request.
Storage
quota
like
as
a
whole,
so
I
wonder
if
we
could
piggyback
off
of
the
per
storage
class
stuff
in
order
to
implement
a
local
storage
quota.
C
D
A
D
I'm
saying
could
if
we
created
a
magic
magic
name
that
to
the
end-user
looked
like
a
storage
class,
so
it
would
look
like
there
was
a
storage
class
to
the
end
user
called
a
ephemeral
storage,
or
something
like
that,
despite
the
fact
that
one
had
not
been
defined
other
than
creating
this
new
top-level
object,
I
mean
not
really
top
level
but
reusing
one
of
the
quotas.
It's
already
there
in
order
to
specifically
target
the
ephemeral,
you
get.
What
I
mean
said.
H
D
D
I
C
Because
this
is
her
name,
space
right
are
normally
I,
believe
just
the
mean
much
not
just
user
individual
note
capacity
as
the
coton,
but
it
surely
depends
this.
How
system
would
mean
want
to
set
it
up?
They
might
cave
user
in
this
namespace.
A
lot
of
the
local
storage
code
has
like
more
than
just
one
node
capacity,
it's
possible
so
as
possible
to
give
like
smaller
quota
for
local
storage.
Yeah
I
don't
have
like
the
answer.
I
believe
some
citizen
should
maybe
have
different
environment
and
different
setting
for
Kota
so
to
reuse.
C
A
So
I
agree
with
that:
I
think
reusing.
The
existing
value
could
cause
regressions,
which
concerns
me
I
agree
with
Eric
there.
That
leaves
two
two
options.
One
is
what
you
have
here,
which
is
basically
adding
a
new
resource
for
a
ephemeral
storage.
We
can
decide
on
the
name
later,
whether
it's
scratch
or
something
else,
and
then
what
Eric
was
proposing,
which
was
using
storage
classes.
I
am
NOT
super
familiar
with
how
that
would
work.
Eric.
Do
you
want
to
talk
through
that?
A
little
bit
I.
D
Mean
obviously,
I
just
came
up
with
this
thought
30
seconds
ago
sod.
So
it's
not
well
formed
in
my
head
either
arm.
So
the
way
kind
of
the
per
storage
class
quota
works
today.
Is
you
define
a
quota
on
an
object,
called
storage
class
name?
You
know
whatever
your
storage
class
is
or
will
be
named,
died
storage
class
like
kubernetes
that
IO
or
something
like
that?
D
If
that's
it's
sort
of
as
a
replacement
for
where
you
would
today
put
resource
requests,
storage,
a
resource
limit
storage
like
that
name,
you
use
the
storage
class
name,
so
we
could
come
up
with
a
magic
name
that
we
called
you
know.
Ephemeral
storage
does
kubernetes
service
class
dot
whatever,
and
that
would
be
the
place
where
users
per
namespace
would
set
the
quota.
So
it
wouldn't
be
a
top
level.
It
would
be
similar
to
you.
They
would
be
able
to
say
gold,
tier
bronze,
tier
and
ephemeral,
storage
and
gold.
D
Tier
bronze
tier
would
then
map
to
real
storage
classes.
That
may
or
may
not
have
a
provision.
Err
right
may
or
may
not
have
any
of
that
stuff.
That
storage
classes
enable,
but
ephemeral
storage
would
magic
in
the
code
map
to
all
of
these
things.
We're
talking
about
right
now,
that's
sort
of
my
thoughts,
oh
really
it's
just
the
end
user
would
have
to
know
the
storage
class
is
called,
not
end
user.
The
person
who
created
the
quota
so
so.
J
Grants
a
storage
class
just
be
defined
in
a
way
that
it
is
pointing
to
a
ephemeral
storage,
and
then
you
would
just
use
it
as
the
other
storage
resource
quotas
to
put
in
the
name
which,
and
then
it
already
provides
the
size
to
divvy.
I,
guess
I,
don't
understand
why
we
wouldn't
leverage
it
in
the
same
way,
creating
a
storage
class
that
actually
points
to
ephemeral.
So.
J
A
A
To
extend
that
further
I
think
there
is
also
the
it's
not
just
about
setting
quota,
it's
also
about
being
able
to
set
limits
on
the
containers
themselves.
So
if
we
go
down
the
storage
class
path,
I
don't
think
we'd
be
able
to
actually
set
limits
on
these
resources,
which
is
what
we
ultimately
want
to
do.
Quota
is
just
a
nice
to
have
alternative
life.
A
D
I'm
thinking
is
that
it
wouldn't
be
a
storage
class
right.
I
totally
agree
that
right
now
we're
trying
to
quota
at
least
what
three
distinct
things
right:
logs
container
image
and
empty
they're.
Lumping
those
three
things
together,
which
may
or
may
not
make
sense
I
actually
think
it
would
potentially
make
sense
one
day
we
might
want
to
split
those
out
and
then
what
are
we
going
to
do?
Are
we
going
to
create
three
more
top
level
fields?
Neither
here
nor
there
yeah.
A
D
Not
arguing
we
need
to
break
them
up
I'm,
certainly
not
asking
we
revisit
that
I'm
saying
we
might
one
day
decide
we
want
to
I.
My
whole
point
is
we're
teaching
users
how
to
set
quota
via
storage
class?
That's
currently
the
thing
we're
teaching
users
so
I'm
wondering.
Is
there
a
way
we
can
use
that
teaching
for
the
ephemeral
right?
All
we're
doing
is
setting.
F
D
You
know
a
JSON
object
arm
how
we
use
that
particular
name
in
the
backend.
It
might
be
too
difficult
to
go
to
make
a
femoral
magic
I,
don't
want
to
pretend
that
I
know
exactly
how
that
would
turn
out
in
the
code.
It's
really.
This
is
a
useless
discussion.
I
think
we
agree.
We
need
a
new
name,
whether
that
new
name
follows
on
with
the
teaching
we're
giving
people
on
how
to
set
it
for
certain
types
of
storage.
Like
that's
what
a
sword
class
is
right.
It's
a
type
of
storage,
I.
D
C
C
So
I
think.
Basically,
we
gave
a
user
ability
to
manage
this
type
of
resource.
It's
just
happened
that
we
have
existing
API.
That
is
specifically
for
PVC
storage,
that
use
a
very
general
name
called
resource
storage.
So,
but
we
cannot
change
that
and
if
we
just
overload
that
name,
it
would
be
quite
confusing
and
gave
us
trouble
when
setting
some
models.
Let
cota
is
that
ok,
we
can
tell
you
yeah.
C
Sure
so
I
also
gave
more
detail
like
use
cases
just
use
a
name
like,
for
example,
storage
scratch
before
we
have
used
kisses,
but
that's
for
two
different
tuples
for
the
AP
is
including
overlay
and
scratch.
So
now
we
need
to
change
the
use
pieces.
So
when
we
people
look
at
use
cases,
it
might
be
more
clear,
so
the
rest
would
be
just
like
we
have
so
they
support
limited
range,
so
it
can
specify
minimum
maximum
or
even
default.
Value
goes
for
these
type
of
resources
and
I.
Think
that's
the
main
issue.
C
A
C
A
Right,
thank
you.
So,
let's
get
to
the
spreadsheets
we're
going
to
go
through
these
items
fairly
quickly
out
of
tree
CSI
volume
plug-in
design.
Spec
is
out
I'm
hoping
to
send
it
to
Brad
Chakri
and
a
few
other
folks
for
a
first
pass
and
then
we'll
all
share
it
more
widely.
As
a
reminder,
September
first
is
the
code.
Freeze
deadline.
That's
just
about
two
weeks
away.
Please
keep
that
in
mind
capacity,
isolation,
resource
management,
Jing!
Do
you
want
to
give
a
quick
update
here?
Yes,.
C
A
So
I've
gone
been
a
Superman
over
here
getting
this
out.
The
door
he's
held
multiple
meetings,
folks
of
beat
back
and
pushed
back
and
said:
oh
how
about
this?
How
about
that
he's
been
very
accommodating
in
addressing
those
right
now?
There
is
a
proposal
out
that
we
believe
everybody
is
more
or
less
in
agreement
on.
He
has
both
design,
doc
and
code
out.
That
needs
to
review.
A
We
need
to
find
someone
from
the
know
team
to
take
a
look
at
it.
The
person
that
we
were
depending
on
is
on
vacation,
so
that's
on
me
to
to
go
and
find
that
person
or
sign-off,
and
otherwise
it
looks
like
it's
on
track
right,
but
there's
two
parts
to
this:
one
is
the
amount
namespace
propagation
which
is
on
track.
The
second
part
is
the
the
containerization
of
the
mount
calls
themselves
for
entry
volume
plugins
and
that's
a
little
bit
up
in
there.
Sorry.
A
I
M
A
J
Yeah
so
I
met
with
Clint
and
another
person.
I
gave
my
name
for
PNC
s
to
kind
of
kick
start
the
program
we're
having
another
call
on
the
30th
of
August
to
get
a
better
structure
of
how
we're
going
to
proceed
and
what
we're
going
to
include
in
the
initial
phases.
We
have
it
broken
down
into
what
we
would
like
to
do
initially
to
you
know,
eventually
having
some
sort
of
harness
that
people
can
use
to
become
kubernetes
certified
for
their
provisioners
as
they'll
all
be
out
of
tree.
J
Both
I
think
ideally
we'd
like
to
have
an
environment
where
we
can
test
everything
to
have
some
sort
of
confidence,
but
eventually
have
a
way
that
external,
provisioners
and
plugins
can
certify
against
its.
If
it's
that
you
know
a
test
suite
that
they
can
hook
into
and
run
and
then
provide
the
results
back,
that's
one
way
we're
thinking
about
it
like
they
could
either
clone
something
run
it
and
provide.
The
results
are
actually
physically
running
on
the
shared
hardware
and
also
provide
the
results,
and
then
that
would
give
any
customers.
J
A
J
Yeah,
there's
nothing.
We
will
do
of
course,
another
review
after
the
1a
release
to
make
sure
there
aren't
any
regressions
or
ain't
completely
uncovered,
but
I
think
we're
more
focused
on
trying
to
get
the
shared
environment
to
get
the
plugins
tested,
because
I
think
that's
where
a
lot
of
books
still
exist.
If
you
don't
even
know
right.
A
N
N
I
O
Actually
it
these
are
right,
this
is
Vava.
These
are
different.
As
far
as
I
understand,
the
the
one
that
Jing
and
I
are
looked
working
on
is
to
expose
the
metrics
that
are
already
reported.
The
stats
that
are
already
reported
expose
those
versus
I
think
what
the
the
other
proposal
was
commands
was
to
add
additional
metrics
from
plugins
real.
I
O
I
A
B
L
A
B
A
I
C
For
that
feature,
I
just
have
some
controller
design
kind
of
issue.
I
want
to
address
that
we
haven't
got
enough
time.
I,
someone
from
external,
like
a
young
scene,
is
helping
my
own
controller,
so
I
hope
we
can
like
get
more
done
for
this,
but
I
think
API
design
is
finished,
but
yeah.
The
only
thing
is
left
is
controller
part.
A
I
A
A
P
A
F
We
realized
the
amount
of
changes
we're
trying
to
just
fix
this.
One
corner
case
seems
to
be
like
a
overwhelming,
so,
but
now
we're
not
going
to
do
anything
and
we
will
just
update
the
documentation
for
flex
volume
saying
that
will
not
be
supported
in
volume
name.
Flower
I'll
use
it
ss5
inline
in
a
bar
spec.
F
A
But
really
what
we
decided
is
that
we
don't
have
enough
data
to
indicate
that
the
problems
that
we
have
from
this
are
large
enough
to
justify
the
amount
of
work
it
would
require
to
fix
it.
At
this
point,
we're
going
to
continue
to
track
it
over
the
next
few
quarters.
There's
already
an
effort
outside
of
this
group
to
try
to
checkpoint
the
internal
state
of
cubelet
and
we're
hoping
to
piggyback
off
of
that
work,
possibly
to
just
have
this
implicitly
fixed
for
us,
but
we'll
keep
an
eye
on
that
for
the
future.
A
I
A
G
A
I
A
N
All
that's
our
garden
suggested
data
API
new
picture
objects
for
secrets
reference
and
protect
the
worlds
and
minutes
for
my
assessment.
You
can
test
your
object
reference.
That's
we
can
reuse
because
that's
going
to
break
Vicky,
I
I
suggest
we
have
a
special
honor
for
approval
to
add
this
new
objects.
A
O
O
There
were
questions
around
whether
that
use
case
is
valid
and
also
the
scope
of
the
changes,
whether
they're
going
to
be
too
invasive.
At
this
stage
of
the
other
release,
so
I
have
a
proposal
out.
Jing
is
talking
about
it
offline
in
terms
of
the
use
case.
We've
definitely
got
people
querying
metrics
using
the
PDC
name
versus
pod
and
pod
volume.
Name
is
definitely
preferred,
so
I
think
we
do
have
a
couple
of
offs
for
that
interview.
A
O
O
B
O
A
A
H
A
A
H
A
Q
R
A
The
the
general
plan
is
that
the
volumes
that
are
currently
in
tree
I
will
remain
in
tree
until
we
decide
at
some
point.
We
want
to
deprecate
these
because
these
entry
volumes
are
part
of
the
kubernetes
api.
We
have
to
follow
the
kubernetes
api
deprecation
policy,
which
is
that
you
are
not
allowed
to
deprecated
until
the
next
major
version,
which
is
going
to
be
kubernetes
2.0,
or
at
least
one
year
after
publicly
announcing
that
you're
going
to
deprecated
a
field
we
have
yet
to
decide
which
path
we're
going
to
go
with
the
entry
volume
plugins.
A
Q
A
Guys
can
taper
it's
only
for
new
volume
plugins,
so
we
stopped
accepting
new
entry
volume
plugins,
and
so
anybody
who
is
trying
to
implement
a
new
volume
plug-in
we
are
redirecting
them
towards
flex
until
CSI
becomes
viable
and
so
ro
can
do
tonics.
You
guys
were
the
first
ones
to
go
through
that
process
and
with
the
existing
entry
volume
plugins
that
are
already
there.
The
question
is
what
what?
A
What
does
the
future
look
like
and
the
future
as
I
see
it
is
for
network-attached
volume,
plugins
I'd
like
to
see
them
move
out
of
tree,
and
in
order
to
do
that,
we
can
always
come
up
with
like
a
CSI
volume
plug-in
that
can
coexist
with
the
entry.
But
the
question
is
about
deprecation
of
the
entry
volume,
plugins
and
and
that's
subject
to
the
kubernetes
deprecation
policy.
S
G
A
Q
A
A
K
So
I
I
heard
now
there
that
flex,
partier
you're
recommending
for
Rios
entry
or
so
I
guess
just
a
path
we
should
go
up.
I
was
wondering
because
I
I
don't
alter
I,
don't
know
how
is
table
in
Kitty's.
Now
we
took
that
path
because
it
was
all
fun.
I
think
that
the
decision
of
going
the
tracks
way
has
been
taken.
Basically,
okay,
so.
A
The
the
the
the
because
so
many
people
have
started
using
flex.
The
plan
with
Flex
is
to
keep
the
API
stable
and
prevent
any
future
regressions
and
essentially
promoted
to
to
to
stable
without
making
any
breaking
changes,
because
so
many
people
are
already
depending
on
it
it.
To
that
end,
we
are
planning
on
adding
more
end-to-end
testing
to
the
API
to
prevent
from
breaking
chain
on.
Our
team
has
done
work
this
quarter
to
enable
dynamic
loading
of
flex
volume
plugins,
so
that
cubelet
doesn't
need
to
be
restarted.
A
K
T
K
A
We've
already
reviewed
Jenks
design,
PVC
metrics
we're
going
to
have
to
skip
that
until
next
time
we've
got
a
minute
left.
I
wanted
to
quickly
run
by
options
for
the
face-to-face
meeting.
It's
been
a
while,
since
we've
held
our
last
one
last
one
was
in
Santa
Clara,
hosted
by
Steve
Wang
and
the
del
DMC
team,
we're
thinking
potentially
sometime
in
September
or
October.
A
Since
Michelle
rightfully
pointed
out
that
late
August
is
going
to
be
code.
Freeze,
I
steve
offered
to
potentially
host
in
santa
clara
or
Austin
and
I
was
suggesting
having
it
be
act
in
Los
Angeles
this
time
around
the
Linux
Foundation,
the
open
source
summit
since
folks
are
going
to
be
there
already
I'm
not
dead,
set
on
that
idea
and
are
DeLong
suggested
meeting
in
late
October
on
the
East
Coast,
where
net
hath
NetApp
can
possibly
post
any
thoughts,
suggestions,
preferences,
I.
T
Added
some
common
for
that
LA
venue,
it's
pretty
crowded
at
that
location
because
it
isn't
just
open
source
summit
going
on
there,
there's
a
full
week
of
Linux
Foundation
events
and
at
least
some
of
the
people
from
my
team
are
in
those
others
too.
So
it's
kind
of
crowded
if
we're
planning
on
doing
full
day
or
multi-day
face-to-face
there,
but
we
can
do
it.
If
that's
the
group
obsess
then
okay.
A
T
T
I
A
T
A
J
A
L
G
N
I
I
J
A
U
U
A
A
R
A
Right
I'm,
a
green
technologies
I'm
both
as
far
as
I,
understand,
I,
believe
Brian
grant
wanted
to
explicitly
have
to
track.
One
focus
for
developers
and
one
focus
for
end-users.
I
believe
I'm,
not
sure
whether
that
actually
happened,
but
at
least
when
they're
looking
for
papers
they're
going
to
try
to
keep
a
good
balance.
I
think
they
tend
to
lean
towards
end-user
facing
things,
because
we
want
to
you
know,
promote
folks
using
kubernetes,
but
probably
both.