►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro + Deep Dive: Kubernetes Storage SIG - Saad Ali, Google
Join Kubernetes SIG Storage to learn about the areas of our focus, what we are working on currently, and how you can get involved. Veteran SIG Storage members will also present details on projects the SIG is actively working on, and help answer any questions you may have.
https://sched.co/UakS
A
Alright,
let's
go
ahead
and
get
started.
My
name
is
Sally
I'm,
one
of
the
co-chairs
of
SIG's
storage
and
today,
I
wanted
to
take
some
time
to
talk
to
you
about
what
the
storage
special
interest
group
for
kubernetes
is
what
it
does,
how
to
get
involved
and
so
on
and
I
have
a
few
of
the
veteran
members
of
the
sig
here
to
help
me
out
they're
going
to
be
doing
some
presentations
and
we're
going
to
be
doing
a
panel
at
the
end.
A
I,
don't
think
Ben
knows
that
he'll
be
on
the
panel,
but
he
will
all
right
so
again.
Here's
the
agenda
I'm
going
to
go
over
just
an
intro
to
get
you
familiar
with
what
the
sig
is
and
then
Michelle's
gonna
jump
in
and
talk
about,
kubernetes
and
give
you
an
update
for
CSI
in
particular,
and
Shing
is
going
to
be
talking
to
you,
along
with
Sean
Chen,
about
volume,
snapshots
which
is
being
moved
to
beta
this
quarter
and
then
finally,
we'll
end
up
with
a
general
Q&A
with
the
panel.
A
So
what
is
the
kubernetes
storage
special
interest
group
responsible
for
we
focus
primarily
on
block
and
file
storage.
So,
if
you're
familiar
with
storage
at
all,
you
probably
know
about
you
know
ton
of
different
things
that
are
able
to
store
bits,
write
your
databases,
message
queues
so
on
and
so
forth.
Not
all
of
that
is
within
the
purview
of
the
storage
special
interest
group.
What
we're
interested
in
is
kind
of
where
the
rubber
meets
the
road.
You
know
whether
you
have
a
message:
queue
a
database
or
some
other
managed
service.
A
Ultimately,
it's
going
to
need
to
write
bits
down
to
the
disk
and
the
way
that
they
do,
that
is
through
some
sort
of
file
system
or
block
device
abstraction,
and
what
we
do
in
the
kubernetes
storage
special-interest
group
is
provide
that
abstraction
such
that,
regardless
of
where
your
workload
is
scheduled
and
regardless
of
who
or
what
implementation
is
providing
that
underlying
block
or
file.
We
make
it
available
inside
your
container
wherever
it's
scheduled,
and
so
this
involves
at
the
very
bare
minimum,
the
ability
to
automatically
provision
block
or
file
storage
through
the
kubernetes
api.
A
We
also
have
interfaces
that
allow
the
kubernetes
scheduler,
for
example,
to
influence
where
a
particular
volume
is
going
to
be
provisioned.
If
you
have
a
storage
system
that
is
not
available
equally
to
all
nodes
in
a
cluster,
for
example,
you
want
the
scheduler
to
be
able
to
take
that
into
account
when
it's
making
a
scheduling
decision.
A
So
we
have
logic
to
enable
that
and
of
course
doing
things
like
storage
capacity
management,
so
you
as
a
cluster
administrator,
can
define
how
much
storage
is
available
to
particular
subsets
of
users
and
how
large
a
volume
they
are
able
to
carve
out
and
things
like
that.
So
storage
management
moving
on
some
of
the
notable
examples
of
the
things
that
are
sig
owns,
you're,
probably
familiar
with
our
persistent
volume
claims,
persistent
volume,
storage
classes,
dynamic,
provisioning
and
much
more.
A
We
also
own
the
interfaces
by
which
kubernetes
interacts
with
storage
systems,
the
biggest
one
that
we
have
in
the
kind
of
the
one
that
we're
moving
into
the
future
with
is
called
the
container
storage
interface.
This
was
g8
as
if
kubernetes
1.13
in
December
of
last
year
and
is
since
maturing
and
adding
more
and
more
functionality
and
Michelle
is
going
to
tell
you
a
lot
more
about
that.
A
We're
also
responsible
for
ephemeral
volumes,
all
right
so
you're,
familiar
with
traditional
persistent
volumes,
where
your
data
is
persisted
off
on
some
data
store
and
if
your
pod
dies
and
comes
back
up
somewhere
else.
That
persistent
data
is
persisted
on
a
for
example,
a
storage
array
or
a
cloud
volume
of
some
sort,
but
we're
also
responsible
for
ephemeral
volumes
where
you
could
have
information
that
is
temporary.
It's
created
when
the
pod
is
started
and
then
deleted
when
the
pod
goes
away.
So
the
traditional
example
of
that
is
what
we
call
an
empty
door.
A
It's
scratch
space
that
can
be
shared
amongst
all
the
containers
in
a
pod,
and
then
we
build
on
top
of
that
with
secret
config
map
and
downward
API
volumes,
which
are
basically
taking
an
empty
der
and
pre
populating
it
with
some
data
so
that
it's
easier
for
your
application
to
consume.
So
your
application
may
not
how
to
know
how
to
talk
to
kubernetes
to
fetch
a
secret,
for
example,
but
it
probably
knows
how
to
read
a
file
in
order
to
extract
a
secret.
A
So
what
the
secret
volume
allows
you
to
do
is
point
to
some
kubernetes
secrets
and
have
those
surfaced
inside
your
container
as
a
file
that
your
application
can
then
read.
The
goal
of
this
is
try
to
meet
users
where
they
are
so
there's
a
lot
more.
We're
responsible
for
everything
about
our
team
is
documented
on
this
github
page.
If
you
go
there,
you're
gonna
find
all
the
projects
and
repos
for
the
code
that
we're
responsible
for,
as
well
as
the
mailing
lists,
team
meetings
and
so
on
and
so
forth.
A
The
sig
is
very,
very
large.
We
held
a
face-to-face
meeting
on
Monday
here
at
cube
con
for
folks
who
are
contributors
to
the
sig
and
we
had
60
attendees
and
we
have
to
cap
it
at
60
because
we
ran
out
of
space.
We
have
folks
from
all
over
the
industry,
lots
and
lots
of
storage,
vendors,
lots
of
cloud
providers
and
pretty
much
everything
in
between.
A
So
what
does
this
signal
for
this
kind
of
storage
layer,
but
like
what
do
we
do?
We
show
up
and
ultimately
what
we
do
is
write
code.
We
write
code
to
enable
these
features.
We
write
tests,
we
fix
bugs
all
related
to
the
volume
subsystem
and
the
way
that
we
do
this
is
that
we
have
a
virtual
meeting
on
zoom'
every
two
weeks
and
we
use
that
meeting
to
kind
of
keep
track
of
what
the
sig
and
the
members
of
the
siga
are
working
on.
A
A
We
try
to
do
that
about
every
one
year
or
every
twice
a
year,
and
the
purpose
of
that
is
just
for
folks
to
be
able
to
see
each
other
figure
out
who's
behind
the
github
name
socialize,
but
also
try
to
drive
forward
some
of
the
bigger
design
discussions
that
you
can't
really
make
progress
on
in
a
one
or
two
hour.
Video
conference
call-
and
we
found
those
to
be
very,
very
useful
as
well,
and
the
cig
is
accessible
via
a
number
of
means.
A
There
is
a
mailing
list:
kubernetes
egg
storage,
google
group
that
you
can
join
to
to
ask
questions
to
see
what
folks
are
asking
about.
There's.
Also
a
slack
channel
there's
actually
multiple
slack
channels.
We
have
the
sink
storage,
slack
channel
where
you
can
come
in
and
ask
questions
about
anything.
There
is
now
a
CSI
channel.
There
is
a
CSI
migration
channel
and
a
CSI
windows
channel
as
well.
These
are
sub
areas
and
sub
projects.
A
If
you
have
specific
questions,
you
have
folks
in
those
channels
that
can
help
answer
your
questions,
so
the
community
tends
to
be
pretty
responsive.
So
what?
If
we?
What
have
we
been
working
on
in
kubernetes
1.16?
We
moved
a
number
of
features
to
beta
I
talked
about
CSI
and
how
CSI
was
G
aid
in
the
1.13
release.
A
Csi
is
kind
of
the
platform
that
we're
building
on
top
before
so
for
all
additional
functionality,
we're
adding
it
to
CSI
on
the
the
the
big
features
that
went
into
the
last
release
were
volume,
cloning,
volume,
expansion
and
ephemeral
volumes
volume.
Cloning
is
the
ability
to
say,
hey,
I
have
a
PVC
I
want
to
create
another
PVC.
That
is
an
exact
copy
of
this
and
with
the
hope
that
the
storage
system
can
do
that
efficiently
and
volume
expansion
allows
you
through
the
kubernetes
api
to
say,
hey.
A
I
started
off
with
the
volume
of
a
specific
size,
maybe
a
hundred
gigs,
but
I'm
running
out
of
space.
Please
expand
the
size
of
this
volume
to
200
gigs
so
that
you
know
if
you
are
hitting
limits
or
whatever
you
can
do.
You
can
address
that
through
the
kubernetes
api
and
then
finally,
CSI
ephemeral
volumes
they've
also
been
moved
to
beta
I
talked
about
secret
config
map
downward
API
and
empty
durval
yems,
which
are
built
into
the
core
of
kubernetes.
A
So
for
this
quarter,
1.17
we
have
a
number
of
features
in
progress:
we're
moving
CSI
topology
to
GA.
This
is
a
big
milestone
for
us.
Tapa
CSI
topology
is
all
about
realizing
that
a
storage
volume
may
not
be
equally
accessible
to
all
nodes
within
a
cluster,
and
this
could
be
for
a
number
of
reasons
you
could
have.
You
know
something:
that's
local
to
a
given
node,
it's
a
disk,
that's
attached
to
only
one
node,
and
you
can
only
use
it
on
that
one
node.
A
It
may
be
that
you
have
a
storage
array
or
you're
running
in
a
cloud
environment
where
a
particular
volume
is
available
in
a
specific
zone.
Only
nodes
in
that
zone
can
access
it,
but
your
cluster
may
span
multiple
zones
so
to
in
order
to
for
the
kubernetes
scheduler
to
make
intelligent
scheduling
decisions.
We've
introduced
a
number
of
features
around
here
that
we're
calling
sea,
topology
and
and
specifically
we're
adding
that
to
CSI
next
up
is
the
volume
attach
limits.
So
this
is
a
kind
of
a
smaller
feature,
but
it's
very
important.
A
The
idea
here
is
that
a
given
storage
system
may
have
limits
on
the
number
of
volumes
that
can
be
attached
to
a
single
node
and
if
kubernetes
doesn't
know
about
that,
it
may
schedule
more
than
that
number
on
a
given
node
and
end
up
with
pods
that
aren't
able
to
start,
and
so
this
functionality
allows
the
storage
system
to
bubble
this
information
up
to
kubernetes
so
that
the
kubernetes
scheduler
can
make
intelligent
decisions
about
scheduling.
Based
on
that,
we
also
have
a
couple
of
features
that
are
moving
to
beta.
A
A
But
the
kind
of
high-level
here
is
a
lot
of
storage
systems,
support
the
ability
to
take
some
sort
of
point
in
time
capture
of
what
you
have
on
disk,
so
that
if
something
goes
wrong
in
the
future,
you
can
revert
back
to
that
state
and
they're
able
to
do
that
efficiently.
On
disk,
and
so
with
kubernetes,
we
wanted
to
expose
the
ability
to
do
that
through
the
kubernetes
api,
so
that,
for
example,
if
you're
a
database,
administrator
and
you're
gonna
do
something
weird
that
you're
not
sure
is
going
to
work.
A
You
can
make
that
risky
change,
but
before
that
you
can
create
a
snapshot
through
the
kubernetes
api.
If
something
goes
wrong,
you
can
always
roll
back
and
then
finally,
we
have
what
we're
calling
the
CSI
migration
effort.
So
before
CSI
existed,
we
had
a
couple
of
different
ways
to
create
volume.
Plug-Ins
for
kubernetes
first
was
entry,
and
the
second
was
flex.
Entry
meant
that
the
code
for
how
you,
how
kubernetes
interacted
with
a
volume
subsystem,
was
actually
built
into
the
core,
kubernetes
binaries,
so
initially
you're,
probably
familiar
with
the
volume
subsystem.
A
It's
all
built
into
the
kubernetes
api.
You
specify
a
volume
and
then
a
type
of
volume.
It
could
be
something
like
a
GCE,
persistent
disk,
an
AWS
volume
or
some
other
type
of
storage
volume,
they're
all
encoded
hard-coded
into
the
kubernetes
api,
and
that
was
the
old
way
of
doing
things.
The
problem
with
that
approach
was
that
it
wasn't
scalable
it
required
all
that
third-party
code
to
live
inside
the
core
kubernetes
repo.
A
It
was
very
difficult
for
the
maintainer
zuv
kubernetes
to
actually
test,
and
it
also
caused
security
vulnerabilities
where,
if
there
is
an
issue
with
one
of
these
extensions,
they
could
crash
core
kubernetes
components,
and
so
we
wanted
to
get
away
from
that
in
our
first
attempt
at
doing
that
was
something
that
we
call
flex
volumes.
Flex
volumes
was
very
basic.
You
had
a
file,
it
could
be
a
executable.
A
It
could
be
a
script
that
handled
a
handful
of
commands,
mount
unmount
and
I
think
there
were
a
couple
others
and
it
got
the
job
done,
but
it
also
had
a
number
of
challenges,
especially
around
deployment.
The
way
that
it
worked
is
that
you
had
to
deploy
the
Flex
driver
as
a
file
that
needed
to
be
copied
to
the
root
filesystem
on
every
node
in
your
cluster
and,
as
you
can
imagine,
that
can
be
pretty
daunting
and
difficult
to
manage
all
the
problems
that
kubernetes
solves
for
applications
in
terms
of
upgrade
downgrade
deployment
life.
A
The
volume
didn't
really
solve
that
for
itself.
So
how
do
you
deploy
all
these
files?
How
do
you
keep
them
up
to
date?
And
all
of
that
was
a
challenge.
Our
second
attempt
at
this
is
was
CSI
and
that's
been
much
more
successful.
Csi
allows
you
to
deploy
a
plug
in
a
storage
plug
into
kubernetes.
Just
like
you
deploy
any
other
workload
on
kubernetes,
you
can
do
cue.
Cuddle
apply
some
yeah
Mille
and
you've
taught
kubernetes
how
to
interact
with
a
new
storage
system.
If
you
have
a
new
storage
array
or
whatever.
A
So
it's
a
much
better
approach
and
it's
been
pretty
successful,
we
g8
in
q4
of
last
year,
December
of
last
year,
so
the
original
entry
volume
plug-in
existed
in
kubernetes
1.0,
so
from
1.0
to
113
was
almost
34
years.
We
ended
up
with
about
20
entry
volume,
plugins
and
then
from
December
to
now.
We
now
have
50
CSI
drivers,
so
it
kind
of
opened
up
the
doors
and
let
everybody
come
in
and
integrate
with
kubernetes
more
more
more
easily.
A
So,
moving
on,
let's
talk
about
how
do
you
get
involved
if
you
are
interested
again
go
to
the
cig
storage
page
you're
gonna
find
all
the
information
on
there.
Our
bi-weekly
meeting
happens
at
9:00
paint
9:00
a.m.
Pacific
time
every
second
Thursday,
it's
a
zoom
meeting.
You
can
turn
your
camera
on
or
not
whatever.
You
like,
there's
an
agenda
doc
that
we
link
to
feel
free
to
add
content
to
that.
A
If
there's
something
that
you
want
to
talk
about,
throw
it
in
the
agenda
and
then
we'll
make
sure
that
we
get
to
it
during
the
call.
The
next
meeting
is
going
to
be
December
5th.
We
skipped
the
meeting
this
morning
because
we
had
a
face-to-face
on
Monday
and,
if
you're
interested
in
contributing
start
familiarizing
yourself
with
a
code
just
I
like
to
walk
start
with
the
main
method
and
try
to
understand
how
the
code
works
with
kubernetes.
A
That
can
be
pretty
daunting,
but
I'd
say,
look
at
the
cube
controller
manager
and
look
for
the
attached
detached
controller
or
look
at
the
volume
manager
code
in
cubelet.
Yawn
is
up
here
giggling,
because
that
code
is
non-trivial,
but
it's
a
good
place
to
start
just
familiarizing
yourself
and
then,
when
you
feel
comfortable
start
with
fixing
a
bug.
I
took
a
look
a
couple
of
weeks
ago
and
there
were
272
open,
bugs
and
kubernetes
kubernetes
that
were
marked
with
Cyg
storage.
A
So
there's
a
lot
of
work
that
is
left
to
be
done
if
you
want
to
figure
out
which
ones
to
help
out
with
there's
also
a
Help
Wanted
label
that
you
can
filter
by
and
use
that
as
a
guide
for
where
to
begin
and
of
course,
talk
to
us.
The
folks
who've
been
in
the
community
for
a
while
we'd
be
more
than
happy
to
help
you
kind
of
onboard
you
can
reach
us
through
slack.
You
can
reach
us
through
the
zoom
chat,
the
zoom
meetings.
A
You
can
send
us
messages
on
the
kubernetes
storage,
say
google
group
we'd
be
happy
to
get
you
ramped
up
so
start
by
writing
tests,
and
once
you
become
more
comfortable,
you
can
start
taking
on
larger
features
and
we
do
quarterly
planning
for
every
kubernetes
release.
This
happens
at
the
beginning
of
the
quarter.
A
For
the
1.18
release,
it's
going
to
happen
at
the
end
of
December
and
when
we
do
that,
we
say
what
are
what
are
the
things
that
folks
in
the
in
the
sig
are
interested
in
working
on
people
often
ask
like
how
does
a
sig
figure
out
what
it
works
on
like?
Who
decides
whose
decision
is
that
is
that
my
decision
and
ultimately
it's
not
it's
the
people
who
show
up
to
the
sig
and
decide
to
write
code
right?
A
We
keep
track
of
that
all
in
this
planning
spreadsheet,
which
you
can
find
a
link
of
in
the
agenda
and
then
the
process
for
how
you
introduce
a
feature
into
kubernetes
is
kind
of
two
parts
you
need
in
terms
of
process.
You
need
an
enhancement
issue
to
keep
track,
which
release
a
particular
feature
is
going
into.
This
gives
folks
outside
of
the
cig,
an
idea
of
what
features
are
going
into
a
particular
kubernetes
release
and
the
second
part
of
it
is
a
cap.
A
This
is
basically
a
design
document
that
you
would
that's
a
proposal
for
here's.
A
new
feature
I
want
to
implement
here,
so
I'm
going
to
implement
it
here.
Are
the
alternatives.
I've
considered
here's
the
what
the
API
is
gonna
look
like
and
once
your
cap
is
approved,
then
it
moves
on
to
the
implementation
stage.
A
We
do
need
more
contributors,
so
I
see
a
lot
of
you
in
this
room.
If
you're
at
all
interested,
please
reach
out
we'd
love
to
get
you
involved.
There's
a
handful
of
very
dedicated
contributors.
Who've
been
working
very
hard,
but
there
are
a
ton
of
features
that
everyone
is
asking
for.
So
the
more
people
we
have
involved,
the
better
@q
con.
We
happen
to
be
one
of
the
last
presentations,
so
this
is
a
little
bit
backwards,
but
there
were
a
number
of
presentations
that
happen,
that
we're
storage
related
book
on
Tuesday
and
Wednesday.
A
B
First,
as
some
general
Brak
background,
one
of
major
effort
that
we've
been
trying
to
take
on
in
the
CSI
group
is
to
improve
the
experience
for
people
to
write,
CSI
drivers,
so
the
main
documentation
page
where
you
can
find
all
the
information
about
what
it
takes
to
write.
A
CSI
driver
is
up
here
at
Cooper,
Nettie's
CSI
docket
hit
the
I/o,
and
we
have
a
sample
driver
that
you
can
also
take
a
look
at
too
if
you
just
want
to
get
started,
and
you
just
want
to
like
copy
paste
something
and
start
from
there.
B
In
addition,
other
resources
you
have
as
a
driver
developer,
is
around
testing
and
we
currently
provide
two
main
types
of
testing
that
you
can
use
on.
Your
CSI
driver
first
is
what
we
call
CSI
sanity,
and
the
purpose
of
this
test
suite
is
to
test
how
well
your
driver
conforms
to
the
CSI
spec
and
it's
mostly
a
test,
some
positive
test
cases,
but
it's
most
Amole
tests.
A
lot
of
negative
test
cases,
like
is
your
driver
returning
to
correct
error
codes
and
these
specific
error
conditions.
B
If
so,
that's
sort
of
testing
performance,
it
assists
high
spec
if
you
want,
and
to
end
testing
in
an
actual
kubernetes
cluster
and
get
like
functional
tests.
That
way,
we
also
have
eat
an
e
to
e
test
suite
that
runs
against
any
kubernetes
cluster
and
any
CSI
driver,
and
it
runs
about
thirty
or
so
different
test
cases.
So
I
would
highly
recommend
taking
a
look
at
this
to
actually
test
out
your
driver
against
kubernetes.
We've
tried
to
make
the
process
as
streamline
as
possible.
B
Mainly
you
with
every
kubernetes
release.
There
is
an
e
to
e
test
binary
that
is
made
available
as
one
of
the
release
artifacts
and
you
just
need
to
download
that
e
to
e
binary
define
a
simple
llamó
file.
With
some
information
about
your
CSI
driver.
Like
what
storage
class
you
want
the
test
against
and
then
and
then
you
just
run
that
binary
with
one
command
and
then
it
will
run
a
bunch
of
test
cases
there.
B
B
First
is
CSI
migration,
like
Saad
said
this
went
beta
and
1.17.
So
what
exactly
is
co-sign
immigration?
The
idea
with
CSI
migration
is
that
you
can
we
end
up
servicing
in
Sri
volume.
Api
is
with
a
CSI
back-end.
So
today,
if
you
use
volumes
like
GC,
persistent
disk
or
AWS
CBS
and
kubernetes
you're,
using
an
entry
volume
API
now,
we're
kind
of
this
is
sort
of
a
joint
project
with
state
cloud
provider,
and
the
idea
is
that
all
cloud
providers
specific
code
is
going
to
get
removed
from
kubernetes
about
a
year
time
frame.
B
So
normally
something
like
that
would
be
considered
a
breaking
change
because
the
API
you
were
using
before
no
longer
works
when
all
of
the
code
behind
it
is
removed.
So
the
idea
with
CSI
migration
is
that
we
can
continue
to
keep
those
api's
working
with
the
entry
volume
api's,
but
the
only
differences
is
actually
being
serviced
by
the
equivalent
CSI
driver,
so
that
is
kind
of
like
an
overview
of
what
CSI
migration
is.
B
So
to
give
a
summary
of
the
timeline
on
current
status
on
each
of
the
cloud
providers,
we
have
just
baited
the
feature
with
the
AWS
CBS
and
GCE
PD
drivers,
the
other
remaining
entry
cloud
providers,
OpenStack,
Azure
and
vSphere-
are
still
coming
along,
but
the
we're
kind
of
working
backwards
from
the
deadline
set
by
sig
cloud
provider,
which
is
by
1.21
all
of
the
cloud
provider
code,
will
be
removed
so
kind
of
working
backwards
from
there.
We
kind
of
arrived
to
this
timeline
for
future
graduation.
So.
B
B
First,
from
the
CSI
perspective,
you
need
to
install
the
CSI
driver
in
your
cluster
turn
on
the
CSI
migration
feature
gates
and
then
and
then
from
there
you
can
you're,
basically
trying
out
the
feature.
Now
this
is
like
I
said
this
is
part
of
the
bigger
overall
provider
extraction
effort.
So
one
of
the
goals
that
we
have
is
to
put
all
of
those
CSI
deployments
details
into
the
main
external
cloud
provider
repositories.
So
that
way
you
don't
have
to
separately
deploy
the
external
cloud
provider
controllers
and
the
CSI
driver.
B
B
So,
in
order
to
use
this,
the
CSI
proxy
exposes
a
set
of
G
RPC,
api's
and
CSI
drivers
have
to
be
aware
of
these
api's
and
communicator
to
proxy
using
them.
Currently,
we
have
planned
api's
for
most
of
the
common
file
and
block
storage
protocols
like
samba
and
I
scuzzy,
as
well
as
basic
block
devices.
B
B
The
next
feature
I
want
to
highlight
is
CSI
ephemeral
volumes.
The
main
purpose
of
this
is
to
allow
inline
volumes
where
the
volume
life
cycle
is
equivalent
to
the
pot
life
cycle.
So
these
are
things
like
today
in
kubernetes
the
ephemeral
volumes
you
we
have
our
things
like
empty
der
config,
naps
or
secrets.
This
is
kind
of
in
line
with
that,
but
it's
a
CSI
based,
which
means
you
can
create
a
volume
type
or
a
volume
driver
for
like
anything,
you
want
some
interesting
examples
of
some
ephemeral
drivers.
Are
the
image
pop
you
later?
B
This
basically
lets
you
mount
any
container
image
as
a
volume
in
your
container
and
then
there's
a
couple
of
cool
drivers
around
the
certificate,
management
and
secret
storage
from
third-party
storage
like
volt.
So
these
are
really
cool
examples
of
ephemeral
volumes
and
I'm
sure
there's.
This
is
basically
going
to
open
doors
for
all
sorts
of
really
interesting
use
cases.
B
All
right
and
sort
of
to
go
over
what
we
have
in
store
in
the
future.
We
have
a
lot
of
features
in
progress
and
our
major
goal
for
the
next
year
is
to
drive
all
of
these
features
to
GA.
So
we
have
some
features
like
I'll
just
go
down
the
list.
The
first
feature
is
given
touch.
This
is
mainly
for
CSI
drivers
like
NFS
or
yeah,
like
file
drivers
like
NFS,
where
they
don't
actually
have
an
attach
or
detach
operation
right
now.
B
What
you
have
to
do
is
deploy
the
external
attach
or
side
cars
to
them,
but
this
feature
makes
it
so
that
you
don't
have
to
do
that
and
it
skips
that
whole
code
path
next
is
pod
info
on
mount.
This
feature
basically
passes
in
some
pod
metadata
to
your
on
every
mount
call.
This
is,
if
your
driver,
you
know,
wants
to
create
some
sort
of
like
pod,
specific
secret
or
a
pod
specific
authentication
kind
of
thing
you
have.
You
can
get
that
pod
metadata
on
every
single
mount
call,
and
then
next
we
have
raw
block.
B
B
Then
we
have
cloning,
which
saw
it
talked
about
a
little
earlier.
This
is
the
ability
to
make
a
copy
of
an
existing
PVC
I
think
saw
it
also
talked
about
resizing.
This
is
letting
you
expand.
The
volume
size
of
a
volume,
and
then
snapshots
is
something
we
are.
We
just
baited
in
117
we
are
hoping
to
GA
snapshots,
also
within
the
first
half
of
next
year
and
Shingen.
B
Xiang
Chen
are
going
to
talk
a
lot
more
about
this
in
more
detail
and
then,
like
I,
said
earlier,
we
plan
to
have
an
alpha
for
Windows
ESI
drivers
very
soon
from
there
for
the
second
half
of
2020.
The
other
features
we
plan
to
graduate
are
ephemeral
volumes
and
the
CSI
migration
for
all
of
the
cloud
provider
plugins.
B
In
order
for
us
to
meet
the
1.21
deadline
to
remove
all
entry
file
provider
code,
so
that's
sort
of
our
future
plans
for
features
that
we
currently
have
outstanding
and
people
are
working
on.
At
the
same
time,
we
are
sort
of
investigating
and
prototyping
more
use
cases
and
features
such
as
volume,
health.
B
Another
feature
that
we
are
currently
investigating
is
the
notion
of
storage
pools
and
the
capacity
of
those
storage
pools.
This
is
to
help
enable
use
cases
like
local
volume,
dynamic
provisioning,
as
well
as
the
CSI,
ephemeral
volumes,
sort
of
capacity
management
and
then
I
think
Jing
and
Shan.
Chen
will
talk
about
this
in
more
detail
later,
but
we're
also
looking
at
a
lot
of
other
use
cases
around
snapshots
and
backups
as
well.
B
So
you
can
see
we
have
a
lot
of
work
that
we
are
doing
in
CSI.
We
definitely
need
all
the
help
we
can
get
so
there's
lots
in
addition
to
the
all
of
the
different
features
that
I've
been
talking
about.
We
also
have.
We
also
have
community
maintain
CSI
drivers
for
common
protocols
like
NFS
and
I
scuzzy,
we're
looking
for
contributors
to
help
maintain
those
drivers.
We
are
also
looking
at
people
to
help
with
our
whole
testing
and
release
infrastructure
for
all
the
different
CSI
common
components
that
we
provide
to
see
the
site
plugins.
B
C
C
C
So
there
are
two
ways
to
provision
well
in
snapshots:
dynamically
provisioning
or
be
provisioned
snapshots
so
to
dynamically,
create
a
snapshot.
User
will
create
a
volume
snapshot
if
an
object
which
is
names
based
and
is
created
with
the
TVC
as
a
data
source
that
will
trigger
a
creation
of
a
physical
snapshot
on
their
storage
system
and
also
a
volume,
a
snapshot
content
object
will
be
created
to
represent
the
physical
snapshot
for
pre
provision.
C
So
your
way
in
the
API
object
or
in
many
AP
object,
you
see
a
spell
and
a
status
spec
represents
the
desired
State.
There
could
be
configuration
settings,
it
could
be
some
properties
and
the
status
represents
the
actual
state.
It
could
be
the
that
will
be
the
information
updated
by
the
controller.
So
when
user
first
to
create
a
API
object,
status
cannot
be
specified,
it
has
to
be
updated
by
the
controller
and
also
we
also
should
be
able
to
recover
the
status
if
it's
somehow
lost,
based
on
the
spec
by
the
controller.
C
D
Thanks
Jane,
he
just
revealed
my
secret
just
so
you
guys
know
before
I
was
complete
a
newbie
when
joining
this
sick
storage
a
couple
months
back
and
that's
actually
the
first
project
I
ever
conducted.
There's
no
reason
for
me
to
say
no.
First
of
all,
I
got
all
the
attention
right,
people
need
it
and,
secondly,
it's
really
really
been
there
for
a
little
while,
so
we
want
to
push
it
up.
And
thirdly,
it's
really
I
think
it's
gonna
be
simple,
like
this
right.
D
How
many
lines
of
code
change
you
can
you
guys
can
tell
I
can
literally
count
it
to
jump
into
all
these
API
changes.
Every
single
change
we
made
during
the
process
is
actually
involves
a
whole
bunch
of
discussion
with
the
help
of
The
Seeker
storage
right.
The
first
thing
ever
we
did
is
to
get
rid
of
the
source
if
you're
familiar
with
Alpha
API
the
source.
It
represents
the
PVC
reference
before
and
now
it
become
a
union,
it
can
come
from
a
persistent
bottom
name
or
it
can
come
from
a
snapshot,
content
name.
D
The
major
reason
why
we
did
this
is
one
we
want
be
able
to
distinguish
between
whether
a
warning
snapshot
is
actually
dynamically
created
or
you
are
actually
pointing
to
a
pre-prohibition
snapshot
in
the
system
and
then
we
go.
It
went
ahead
and
then
removed
this
natural
content,
name
from
the
spec.
The
reason
why
it's
back
to
the
API
principles,
which,
unfortunately,
we
called
released
ahead
of
us,
you
need
to
make
sure
your
spec
specifies
the
user
wanted
feature
and
that
field
is
actually
stamps.
D
So
if
you
notice
that
under
status,
we
added
a
field
called
bound
volumes,
national
content
name
and
that's
actually,
the
paired
content
in
the
API
server
tells
you
hey.
This
is
the
accountant
and
that's
basically,
cup
of
lime.
Changed
in
Boerum
snapshot
object.
Let's
move
on
to
what
I'm
snapshot
content,
it's
a
very
similar
idea
before
had
we
had
reference
to
a
persistent
volume
actually
from
where
you
take
your
snapshot.
D
Now
it
becomes
an
option
where
the
where
a
user
can
either
specify
oh
I
want
to
use
existing
snapshot,
handle
that's
normally
your
system,
it
means
drop
or
you
don't
even
care.
What's
in
there,
the
controller
is
gonna,
take
care
of
there,
the
control
it's
going
to
go
ahead
and
find
the
PVC
and
the
course
on
the
PV
and
get
the
volume
handle
and
put
it
over
there
again.
We
have
this
snapshot
handle
in
the
status,
and
that
is
basically
the
entries
out.
The
controller
observes
at
this
type
of
at
this
point
of
time.
D
What
is
the
status
of
your
your
snapshot?
Content?
One
more
thing,
I
want
to
emphasize
a
little
bit
over
here
is
what
Sheen
was
mentioning.
You
need
to
be
able
to
recover
your
status
at
any
good
important
time,
because
for
those
who
you
are
familiar
with
the
API
server,
if
you
co-create
a
object,
it
only
creates
the
space
you
only.
You
need
to
call
as
not
a
set
of
API
to
opt
as
a
sub
resource
in
the
stack
for
the
status.
D
D
With
all
this
in
mind,
we
start
thinking
a
little
bit
more.
One
thing
we
were
thinking
is:
if
we
think
about
this,
alpha
controller
architecture
basically
works
like
this.
You
we
have
very
nicely
written.
You
know
script
as
served
as
a
installer.
The
first
step
is
I'll,
go
ahead
and
create
across
the
row
pending
and
this
cluster
rope
binding.
D
We
allow
the
controller
to
have
access
to
both
a
namespace
object,
which
is
worm,
snapshot,
PVC,
cetera,
et
cetera
and
anon
namespaced
objects,
for
example,
PV
and
William
snapshot,
count
and
etc,
etc,
and
then
go
ahead
and
bind
that
cluster
row
to
a
service
account
and
within
the
code
the
controller
actually
generates
a
CR
D
and
it
registers
the
API
server.
That's
basically
how
it
works
right
in
the
alpha.
Now
this
looks
perfect.
D
We
will
work
until
you
have
to
write
if
you
have
to
CSI
providers,
meaning
that
it's
very
possible
that
you
have
two
storage
program
providers.
One
of
the
big
problem
is
that
ok,
we
first
need
to
make
sure
the
cluster
low
names
are
different.
Otherwise
you
end
up
with
a
conflict.
You
won't
be
able
to
study
apart
and
then
the
bigger
problem
is
they
will
both
try
to
register
a
ERD
with
the
imperial
server.
Now,
if
this
to
CSI
providers
happen
to
you
know
they
pull
a
different
version
of
the
controller.
D
Then
you
have
big
over
a
big
issue,
because
the
CR
DS
may
not
necessarily
compatible.
So
when
we
look
at
that
all
this
architecture,
then
we
started
thinking,
and
you
know
when
engineering
start
thinking
it
does
normally
the
problem
comes
right
and
we
figured
it
out.
There
are
a
couple
of
challenges
we
are
facing
with
this
architecture.
D
You
have
to
even
more
on
multiple
CSI
driver
providers
hosting
exact
same
binary,
but
where
do
you
report
the
matrix
to
and
how
do
you
combine
them
together
for
cost
of
administration
point
of
view?
How
do
I
actually
get
them
together?
They
make
sense
out
of
it.
And
third
thing:
is
that
any
controller
release
anything
I
mean
really
made
anything.
The
storage
vendors
needs
to
get
involved
because
they
needed
can
can
actually
update
the
llamo
file
and
and
change
the
deployment
in
the
site.
So
how
do
we
try
to
mitigate
this
problem?
D
We
spit.
So
if
one
controller
cannot
do
the
whole
thing
we
used
to.
Basically,
we
introduced
a
new
new
controller
which
cost
natural
controller.
That's
basically,
a
cluster
level
deployment
which
coordinates
with
all
the
CSI
plugins
CSI
side,
car
drivers
it
conducts
complex
kubernetes
logic,
for
example,
object,
binding
snapshot,
snapshot,
binding,
choose
natural
content,
etc,
etc.
They
periodically
scraps
the
Williams
snapshot
content
and
try
to
update
the
status
in
a
snapshot.
This
guy
is
not
aware
of.
Csi
is
completely
within
the
six
storages
control.
D
You
can
reduce
separately,
there's
no
problem
as
long
as
you
don't
make
any
backwards,
incompatible
changes
and
there's
a
sidecar
controller,
and
this
guy
we
tried
to
limit
its
access
for
many
many
reasons.
One
reason
is
that
for
security,
and
this
guy
only
conducts
CSI
course
and
only
works
on
the
content
object.
Most
specifically,
he
only
works
on
the
status
of
the
content
object.
D
The
key
idea
we're
here
is
to
keep
very
simple,
so
people
you
guys
probably
will
be
asking
why
this
will
solve
the
problem.
It
won't
right.
It
won't
solve
the
problem
in
a
very
general
way.
However,
it
didn't
mitigate
the
problem.
For
example,
the
cycle
controller
is
so
simple
that
we
don't
expect
it
to
upgrade
from
time
to
time
right.
It's
gonna,
be
a
worry,
worry.
D
Stable
binary
data
you
can
choose
to
deploy
over
the
time
and
the
matrix
size,
at
least
that
we
have
a
centralized
place,
which
is
the
common
controller,
to
give
you
a
matrix,
endpoint
and
under
control
of
the
system
enemy
in
such
that
they
can
go
ahead
and
scrub.
All
this
matrix
yeah
with
all
these
major
changes,
I
will
move
to
Shin.
To
give
you
guys
some
nice
thing
about
the
end
result.
C
D
E
C
C
C
C
C
C
C
C
Ok,
so
the
natural
class
is
created,
so
here
we
can
see.
That
is
the
deletion
policy.
So
that's
actually
our
required
field
now,
and
then
we
have
a
other
information
about
the
class.
Now
this
is
the
Emma
file
for
voting
snapshot
here,
which
has
the
reference
that
autumn
snapshot
class
we
just
created
and
also
under
source.
We
specify
the
person
involving
clean
name,
that's
for
the
dynamic
provisioning.
C
C
C
C
So
now
we're
going
to
try
to
do
our
pre
provision
snapshot.
So
we
have.
This.
Is
the
Warren
snapshot
content
admin
well,
create
this
so
specify
the
source
as
a
snapshot
handle.
This
is
for
the
pre
provisioned
snapshots
and
also
specify
volume
snapshot.
Reference
need
to
specify
name
and
name
space
here
and
then
user.
Well
so,
after
contains
created,
a
user
will
create
a
whole
new
snapshot
pointing
to
that
wall
in
snapshot
contain
name.
C
C
Ok
and
then
in
the
new
snapshot,
content
either
object.
Now
we
have
a
status
field
which
is
new,
and
here
we
have
the
question
time,
ready
to
use
Restless
eyes
and
also
now
we
have
a
snapshot
handle
in
this
status
so
for
pre
provision
snapshots
so
I
have
an
well
create
a
boring
snapshot,
content
specifying
the
snapshot,
handle
under
source
and
also
specify
name
and
the
name
space
under
volume,
the
snapshot,
reference
and
then
user
creates
a
volume
snapshot
specify
the
source,
which
is
the
volumes
name,
shall
contain
name.
C
So
we
have
a
lot
of
work
to
do
going
forward,
so
we
need
to
add
a
web
hook
for
validation,
and
we
also
need
to
add
metrics
for
throw
to
controller
so
that
we
can
tell
how
long
it
takes
to
create
a
snapshot
or
the
lead
snapshot.
We
need
to
add
more
intimate
tests
and
also
we
are
looking
at
volume
group
snapshots
how
to
create
consistent
groups,
we're
working
our
design
for
that,
and
also
now
there
are
a
lot
of
people
interested
in
bowling
backups.
Now
we
have
this
basic
building
block
of
bottom
snapshot.
C
C
Yesterday,
I
got
a
question:
someone
was
asking
me
why
it
took
so
long
for
moving
snapshot
for
an
alpha,
2
beta,
because
we
we
introduced
this
feature
in,
went
our
toe
and
now
it's
already
1.17,
but
in
the
same
time
the
colonial
moves
for
alpha
to
beta
really
quickly.
So
I
just
want
to
address
that.
So
this
is
because
14
snapshot
hide
the
CRD
and
Loney
feature
does
not
have
the
CRT
and
also
for
orang
snapshot.
We
have
a
independent
controller.
C
So
now
we
have
to
have
2
controller
app
after
the
split
and
for
the
colonial
features.
So
we
don't
really
need
a
independent
controller,
so
we
can
just
add
extra
logic
in
the
existing
external
provisioner.
That's
why
it
takes
much
longer
to
finish
the
what'm
snapshot
work.
That's
all.
We
have
for
only
snapshot.
A
Very
much
so
next
up
we're
gonna
switch
to
a
cig
storage
panel.
I'm
gonna
ask
Shing,
Michelle,
Sean,
Jian
and
Ben
to
come
on
up
and
we're
gonna
open
up
the
floor
to
questions.
If
you
have
any
questions,
I'll
try
to
be
the
mic.
Runner
maybe
I'll
hand
over
one
of
the
mics
to
the
folks
on
stage.
Whatever
works
for
you.
F
C
Okay,
so
I
think
we
haven't
really
planned
that
far
yet
so
we
are
basically
so
we
just
finished
this
snapshot
bringing
to
beta.
That's
like
the
basic
building
block
result.
We
gradually
add
in
feature
to
it:
TG
loading,
backups
and
then
so
forward.
He
was
saying
if
it's
a
disaster
recovery.
That
would
be
something
that
we
will
be
looking
at
you
in
the
future
as
well.
D
A
No
I
I,
agree,
I
think
it
is
where
we
want
to
end
up.
We've
been
discussing
it
within
the
sig
for
a
while,
but
we
need
to
get
the
building
blocks
in
place
first
and
then
we're
gonna
work
with
our
counterparts
and
say
gaps
and
folks
from
other
communities
to
make
sure
that
we
have
a
solid
solution.
I
think
one
of
the
biggest
challenges
with
when
you
start
talking
about
application
backup
is
having
to
move
data
across
storage
systems.
A
All
right
with
snapshot
and
restore
the
assumption
is
that
the
storage
system
is
consistent
and
so
being
able
to
tell
a
storage
system.
Take
a
snapshot
and
recover
a
snapshot
within
the
same
storage
system
is
overall,
a
kind
of
doable
problem
being
able
to
say
please
ex
export
this
data
to
somewhere
else,
whether
it's
an
object,
bucket
or
somewhere
else
is
a
larger
problem
that
requires
kubernetes
to
get
involved
in
the
data
path.
Somehow,
and
that
is
going
to
be
a
larger
problem
that
we're
gonna
have
to
think
about
how
to
address.
G
A
So,
there's
a
couple
of
ways
to
think
about
the
features
that
we
expose
up
into
kubernetes
as
hard-coded
features
and
those
tend
to
be
the
ones
where
kubernetes
needs
to
do
something
special
in
order
to
make
that
functionality
work.
So
if
we
talk
about
storage
topology,
for
example,
the
kubernetes
scheduler
needs
to
be
aware
of
you
know
where
to
schedule
or
for
snapshots,
when
you
provision
a
new
volume,
you
need
to
be
able
to
specify
and
the
source
for
that
volume
for
something
like
replication.
A
As
far
as
kubernetes
is
concerned,
it's
kind
of
a
storage
level
implementation
detail
so
the
way
that
we
surface
it
up
is.
If
you
look
inside
your
storage
class,
there
are
a
set
of
opaque
parameters.
It's
up
to
each
storage
vendor
to
define
what
those
parameters
are
so
for
storage
vendors
that
support
replicate
they
can
set.
That
is
a
parameter
like
hey
when
I
create
a
volume.
Please
replicate
it
in
this
way
and
then
that
way,
that's
you
can
enable
replication
with
what
we
have
today.
C
C
So
nervous,
actually
there
is
a
another
proposal
that
actually
it's
a
it's
a
Captagon
merge
called
execution
hook
so
right
now
it's
actually
he's
not
here
anymore.
So
it's
a
right
now
are
someone
for
sick
apps
is
going
to
implement
that.
So
we
did
a
POC
at
a
sick
storage.
We
design
that
so
that
who
can
be
used
to
do
choir
ass,
so
there's
another
feature.
I.
Think
initial
slides
show
that
it's
called
application
snapshots
so
that
feature
will
be
using
the
execution
hook.
C
A
Way
that
we
think
about
it
is
that
this
snapshot
API
is
the
building
block
that
we're
going
to
be
able
to
build
a
lot
more.
On
top
of
so
just
the
ability
to
poke
the
storage
system
in
a
consistent
way
without
having
to
know
what
that
underlying
storage
system
to
take
a
snapshot
and
then
use
it
to
restore,
is
a
powerful
building
block
that
we're
gonna
be
able
to
unblock
a
lot
of
functionality
in
the
future.
So
one
of
the
things
that
we
want
to
tackle
is
hey.
A
I
have
an
application;
it
is
actually
using
more
than
one
volume,
and
so
when
I
take
a
snapshot
of
that
application,
it's
more
than
one
volume
and
I
want
that
to
be
consistent
across
all
of
these
volumes.
How
do
I
do
that,
and
so
this
execution
hook
kept,
is
a
piece
of
that
by
saying
hey,
here's
a
way
for
an
application
to
specify
how
to
qsr
the
application
and
flush
the
rights
and
then
there's
a
larger,
kept
that
in
the
works
or
is
coming
soon
through
cig
apps
to
define
at
an
application
level.
J
A
Replication
is
independent
of
what's
going
on
at
the
higher
of
kubernetes
layers,
so
at
the
CSI
level
the
storage
vendor
can
expose
a
opaque
parameter
through
a
storage
class.
So
if
you
look
inside
the
storage
class
object,
there
are
set
of
opaque
parameters.
It's
completely
up
to
the
storage
vendor
through
the
CSI
driver,
to
define
what
those
opaque
parameters
are.
You
know
it
could
be
something
like.
What
is
this
the
speed
of
the
volume
that's
going
to
be
provision?
J
A
Well,
so
for
replication,
this
is
how
it
works.
So,
for
example,
with
GC
persistent
disks,
there
is
a
parameter
that
allows
you
to
say:
please
replicate
across
zones
and
in
that
way,
a
GC
persistent
disk.
It
can
be
set
a
set
up
to
do
synchronous,
replication
across
two
different
zones,
and
when
that
persistent
volume
is
created,
the
kubernetes
the
gcpd
volume
plug-in
decorates.
A
The
pv
object
such
that
the
kubernetes
storage
system
knows
that
it's
available
in
both
of
these
zones
using
the
topology
feature
that
I
talked
about,
and
so
therefore,
if
the
volume
goes,
the
entire
zone
goes
out,
for
whatever
reason
the
kubernetes
scheduler
knows
that
this
volume
is
not
just
available
to
nodes
in
this
zone.
It's
available
to
nodes
another
zone
and
is
automatically
able
to
failover
to
that
other
zone.
Thanks.
E
E
A
E
J
C
B
C
B
A
It's
taking
so
long
to
move
to
beta,
but
I
want
to
point
out
it's
primarily
Shan
Shan
and
Jing
three
people
who
are
driving
this
feature:
they're
coding
it
they're
writing
all
the
antenna
tests
are
doing
the
deployment
they're
doing
everything
for
it
and
seeing
all
the
excitement
in
this
room
about
this
feature,
I
want
to
see
all
of
you
in
the
sig
helping
build.
These
features
help
us
code.
These
things
right,
please
show
up.
That
would
be
awesome.
A
L
Congratulations
for
all
the
work
on
gun
snapshots
and
everything.
That's
very
cool.
My
question
is
a
bit
knave.
Maybe
it's
not
not
even
belong
here.
Maybe
yes,
so
let
me
know
I'm
very
interested
in
raw
volumes,
because
I
can
specify
file,
system
formatting
and
mount
options
which
are
critical
for
what
I
do,
which
is
databases
now
I'm,
even
more
interested
in
CFS
and
and
CFS
also
requires
a
kernel,
module
which
might
or
might
not
be
present.
M
What
I
can
imagine
is
that
you
could
deploy
demons
that
the
angel,
the
very
the
module,
but
then
I.
You
need
to
get
the
volume
from
somewhere
and
pilot
or
you
need
to
know
the
colonel
on
the
host
and
this
kind
of
stuff.
So
I
don't
think
that
kubernetes
is
the
right
vehicle
to
inject
modules
on
the
host,
and
that
should
be
considered
before
installing
a
Burnett
is
on
top
of
something.
A
A
L
N
And
again,
this
might
not
be
a
good
question
for
the
group
here,
but,
as
an
array
administrator,
one
might
be
worried
about
resource
allocations
and
not
sure
if
that
should
be
set
at
an
array
level
or
a
storage
provider
level
or
with
inside
of
kubernetes
itself.
Even
though
maybe
a
kubernetes
operator
would
like
to
set
a
maximum
resource
allocation
to
like
a
per
pod
or
app
her
name.
Space
in
an
array
administrator
might
want
to
be
able
to
set
that
at
a
cluster
level.
N
Obviously,
the
CSI
driver
can
maybe
send
mean
space
or
pod
information
and
it
yepp
to
the
array
provider
to
do
with
that
information,
what
they
would
to
be
able
to
set
resource
limitations,
but,
as
there
hadn't
been
any
thought
about
not
exhausting
a
storage
provider
from
somebody
who
launches
a
thousand
containers
with
8,000
each
one
with
a
one,
terabyte
volume
hang
and
off
of
it
and
they
start
writing
storage
out
same
thing
with,
like
a
resize
growing
a
volume.
How
do
you
prevent
the
array
from
basically
getting
DDoS.
M
You
can
limit
number
of
claims
that
a
namespace
can
use.
You
can
limit
the
total
size
of
this
volume
claims
per
name
space,
so
you
can
limit
each
namespace
individually
depending
how
important
they
are
and
another
thing
we
have
on
note
level
and
each
CSI
driver
can
tell
know
how
many
volumes
it
supports.
We
call
it
volume
limit.
So
if
a
driver
says,
for
example,
on
AWS
a
node
can
handle
I,
don't
know,
39
will
add
up
us
EBS
volumes,
then
the
scheduler
then
schedules
only
at
month
at
most
39
volumes
on
that.
C
A
O
In
addition
to
quotas,
individual
CSI
drivers,
art
can
have
limits
on
what
they're
gonna
expose.
So,
like
you
know,
different
CSI
drivers
have
are
built
on
different
things
like
if
it's
built
on
GCP,
basically
have
infinite
storage
and
Google
wants
to
sell
you
more
storage,
so
they're
not
going
to
limit
how
much
you
can
consume.
But
if
you
have
physical
boxes,
you
know
the
CSI
driver
sort
of
is
responsible
for
saying,
okay,
this.
This
is
how
much
of
the
box
you
can
take
up,
and
maybe
it's
100
percent.
Maybe
it's
less
the.
N
O
P
I,
so
congratulations.
First
on
all
the
hard
work
from
the
clones
topology,
you
know.
One
of
the
questions
that
came
up
so
is
the
intent
that
when
the
clone
is
being
created,
it
could
be
a
full-blown
clone
or
it
could
be
a
ten
clone
right.
It's
sharing
resources,
so
is
the
intent
that
the
storage
for
provider
will
be
managing
all
of
this,
because
if
we
are
talking
about
it
say,
let's
take
a
simple
use
case:
repurpose
use
case
right,
I'm,
spinning
up
four
clones
and
one
of
the
patches
is
successful.
I
just
restored
it.
P
A
P
D
D
You
know
that
in
companies
were
in
the
in
the
cloud
word
when
we
have
a
persistent
volume
when
we
take
a
snapshot,
a
point
in
time
snapshot,
they
actually
cut
a
point
in
time,
snapshot
and
uploads
to
a
remote
of
the
pocket
or
something
tie
right
and
in
this
up.
Corey
uploading
period
is
significantly
long.
If
your
volume
is
huge,
so
we
don't
want
to
hand
that
for
the
applications,
because
normally
applications
need
to
queers
and
that's
really
why
we
introduced
stuff
like
tanning
application.
Hey
your
snapshot
is
card.
A
A
The
snapshot
may
not
be
immediately
available
to
use,
but
it
when
you
give
me
that
first
signal
it's
the
signal
for
me
to
know
that
I
can
resume
the
application
safely
and
I
can
resume
the
application
minimize
that
downtime
for
the
application
and
then
whatever
the
storage
system
needs
to
do
in
order
to
prepare
that
snapshot.
You
can
continue
to
do
that
in
the
background
and
then
give
me
a
final
signal
with
ready-to-use
to
say:
oh,
the
snapshot
is
now
ready
to
consume
and
create
new
volumes
from.