►
From YouTube: Dynamic Storage Provisioning With NetApp and OpenShift
Description
NetApp’s project Trident, an open source storage provisioner for OpenShift, enables containerized applications to request, receive and consume storage on-demand according to pre-established policies, including the ability to create clones and resize PVs as needed. This session explores how Trident orchestrates the provisioning of storage across configured storage providers to meet the needs of the application. We will also explore how Trident interfaces with OpenShift, how storage provisioning related decisions are made by Trident, and how to get the most out of Trident’s storage attributes for your applications. If you’re curious about how to leverage your NetApp storage to maximize the capabilities of your OpenShift users, this session is for you!
A
It's
a
promise.
I
want
to
have
the
world's
most
boring
demo.
Why?
Because
I
do
storage,
the
storage
is
supposed
to
be
boring,
storage
is
supposed
to
be
reliable.
Storage
is
supposed
to
be
something
that's
just
there.
It
works
I,
don't
have
to
worry
about
data
loss
or
data
crush,
or
any
of
these
other
things
right.
A
I
want
a
boring
demo,
terrifyingly
I'm.
Also
doing
this
demo
live
so
we're
gonna
find
out
whether
or
not
I've
made
the
appropriate
sacrifices
etc
to
the
demo
gods
right,
because
my
Internet's
coming
from
my
pocket
right
now,
so
we're
gonna
find
out
so
how
many
of
us
are
storage
consumer's
right,
we're
an
application
administrator
we're
an
open,
shipped
administrator
rates
where
we're
not
storage
administrators.
A
What's
the
process
of
getting
storage
like
for
you
right,
I
was
a
storage
admin
for
a
long
time,
but
I
was
also
an
application
admin
for
a
long
time
and
most
of
the
time,
the
way
that
you
get
storage
is
by
putting
in
a
request
right
put
in
a
helpdesk
ticket
right,
something
like
that
and,
however,
that
ends
up
at
the
storage
administrators
desk.
It
lands
there
right,
carrier,
Pidgeon
office
dog,
whatever
that
happens
to
be,
and
the
first
thing
that
that
storage
admin
probably
does
is
come
back
and
start
a
fight
right.
A
Did
you
really
want
one
terabyte
of
storage,
or
did
you
mean
you
wanted
250
gigabytes
of
storage
right,
and
we
have
this
back
and
forth
that
can
take
days
or
sometimes
weeks,
depending
on
how
much
he
feels
like
responding
to
your
emails
and
eventually
we
land
at
that
capacity,
and
then
a
storage
guys
like
to
come
and
ask
a
bunch
of
questions
that
nobody
in
the
history
of
storage
has
ever
known
the
answer
to
right.
What's
your
read
right,
sighs?
What's
your
block
size,
what
you
read
right
ratio?
What's
your
I
ops
requirement?
A
A
We
like
to
think
that
it
helps
us
with
the
next
phase
in
that
storage
provisioning,
which
is
choosing
where
to
provision
it
to
right
where,
in
this
vast
empire
of
storage,
am
I
going
to
put
this
volume
and
at
the
end
of
the
day
we
rely
on
our
vast
experience
and
intuition
to
guess
the
end
of
the
day,
we're
more
or
less
guessing
that
I
think
this
is
the
best
place.
To
put
it,
we
create
that
volume.
We
give
it
back
to
you
the
requester,
and
then
we
forget
about
it.
It
exists
forever.
A
It
rarely
changes.
Maybe
you
need
some
more
space.
Maybe
you
need
us
to
revert
a
snapshot
or
something
like
that,
but
it
gets
forgotten
about
and
they
never
disappear.
They
exist
for
years
and
years
and
years
I
was
a
storage
administrator
for
15
years
before
I
worked
for
another
I
bet
for
everyone.
Volume
I
deleted
I
provisioned,
at
least
500,
but
applications
are
changing.
A
So
the
first
thing
that
we
want
to
look
at
with
this
challenge
is:
how
do
we
get
that
persistence
right?
We
know
that
our
applications
have
persistence.
We
know
that
the
applications
that
are
containerized
still
need
to
store
things
just
because
it's
in
a
container
doesn't
mean
that
it
fundamentally
changes
the
application
itself
right.
We
still
need
to
store
the
things.
A
So
how
do
we
do
that,
and
how
do
we
importantly
get
our
storage
to
play
along
with
that
right?
Does
anybody
ever
seen
a
bulldog
do
an
agility
course?
Imagine
a
storage
admin
like
me
doing
an
agility
right,
it's
kind
of
funny,
so
we
want
to
enable
those
storage
administrators
to
be
able
to
do
that
for
us,
but
we're
a
stodgy
group.
A
A
So
how
do
we
do
this?
We
begin
to
look
at
open
shift
and
really
the
entire
kubernetes
ecosystem.
We
have
the
persistent
volume
paradigm,
probably
familiar
with
this
right-
pvcs,
Peavey's,
etc.
Right
so
I'm
gonna
very
briefly,
go
over
what
this
looks
like.
So
traditionally
what
happens
is
the
open
shifts
or
the
kubernetes
administrator
goes
to
the
storage
team
and
deals
with
all
of
that
harassment
right
they
go
and
they
get
a
whole
bunch
of
volumes
that
then
sit
in
a
pool
waiting
to
be
consumed.
A
Our
application
team
comes
along
and
they
say:
hey
guys,
I
need
some
storage.
I
need
three
gigabytes
of
storage,
kubernetes
matches
to
the
closest
thing
possible
and
hands
it
over
to
our
application.
This
is
super
inefficient
right.
I
had
to
go
to
the
storage
team,
who
probably
manually
typing
banged
out
every
one
of
those
volumes
we'll
be
lucky
if
more
than
three
of
those
are
actually
deployed,
the
same
with
the
same
set
of
options,
the
same
set
of
controls,
etc.
The
open
shift
administrator
had
to
introduce
all
of
those
PVS
right.
A
We
hope
they
did
that
in
an
automated
fashion,
but
you
never
know,
and
then
it's
a
lot
of
capacity.
That's
just
sitting
there
not
doing
anything,
waiting
to
be
consumed
and
as
soon
as
one
of
those
gets
used,
we
don't
have
to
go
back
and
request
another
one
so
that
we
can
keep
that
pool
readily
available.
A
So,
of
course,
never
one
to
rest
on
their
laurels.
The
community
created
the
community
added
storage
classes
in
storage
classes.
Give
us
the
ability
to
define
a
provisioner
for
a
storage
resource.
We're
now.
My
open
shipped
administrator
and
my
storage
administrator
worked
together
to
define
a
set
of
capabilities.
I
used
the
incredibly
overused
and
very
mundane
gold,
silver
and
bronze
just
as
easily
be
monkey
giraffe
and
rhinoceros
right.
It
doesn't
really
matter,
but
the
key
being
the
application
now
requests
a
capacity
of
that
storage
class
I
need
three
gigabytes
of
bronze
storage.
A
Our
provisioner
takes
action.
It
creates
the
volume
in
real-time,
on-demand,
Kerber.
Nettie's.
Excuse
me,
open
shifts,
allocates
it
over
to
the
application
and
we
roll
along
as
though
that
storage
had
always
been
available.
As
though
that's
just
the
way.
It's
always
been
so
net
up
is
a
data
management
company
right
I
hope
that
you
already
know
this,
that
we
are
a
storage
company.
Our
booth
is
just
right
over
here
right.
So
of
course,
we
participate
in
this
paradigm.
We
help
define
this
paradigm
in
the
early
days.
A
Trident
is
our
implementation
of
a
dynamic
storage
provision
er,
but
we
do
more
than
just
generically
provision
volumes
off
of
our
storage
arrays,
because
we're
able
to
create
an
SLA
inside
of
those
storage
class
definitions-
hey
I,
went
gold
to
represent
all
flash
storage.
What
bronze
to
represents
just
hard
drive
storage,
so
we
can
take
advantage
of
that
and
we
can
help
to
define
SLA
x'
where
the
application
can
select
the
storage
that
it
needs,
that's
appropriate
for
what
it's
doing
in
order
to
make
sure
that
they
get
well
the
best
outcome
possible.
A
So
what
does
this
look
like
turn
networks
across
the
net
out
portfolio
on
tab,
SolidFire
eseries
across
all
of
the
variants?
So,
if
you're,
using
on
top
fast
aff
on
tap
cloud
on
tap,
select
write
any
of
these,
we
can
work
with
all
of
these,
not
individually,
but
collectively.
We
can
work
with
all
of
them
simultaneously
once
we
deploy
Trident,
which
is
very
simply
a
standard
deployment
inside
of
OpenShift
right,
just
pods
that
are
being
deployed
to
the
to
a
node.
A
So,
in
the
case
of
blue
here,
my
application
requests,
10
gigabytes
of
blue
storage,
Trident
will
evaluate
which
one
of
those
best
meets
the
needs.
At
that
particular
moment,
I
can
request
five
volumes.
They
come
off
of
SolidFire,
the
next
four
come
off
of
on
top
and
then
the
last
one
comes
off
the
b-series
right.
We
don't
know
we
don't
care
from
an
application
perspective.
A
You
don't
care
generally
speaking
what
protocol
it
is
right,
occasionally,
there's
always
exceptions
as
a
storage,
administrator,
I,
more
care
that
you're
getting
the
storage
that
you
need,
because
I
can
follow
up
and
I
can
fix
anything
that
happens
to
go
wrong.
I
can
do
a
ball
move
if
I
need
to
I
can
change
a
QoS
policy,
so
Trident
makes
it
easy
to
get
the
storage
that
you
need
again
when
where
and
how
you
need
it.
A
Alright,
can
people
in
the
back
see
the
text
we're
good,
okay,
cuz
I
can
make
it
a
little
bit
larger.
So,
as
I
said
before,
this
is
pretty
much
going
to
be
the
most
boring
demo
that
you
will
probably
see
all
week,
hopefully
all
year,
because
remember
we're
dealing
with
storage.
We
don't
want
it
to
be
exciting.
We
don't
want
it
to
be
unknown.
So
what
I'm
going
to
do
here
is
I'm
gonna
provision,
a
volume
so
I'm
one
of
those
people
who
can't
talk
and
type
at
the
same
time
right
it
gets
really
jumbled.
A
A
A
A
A
So
you
can
see
that
it
was
created
as
an
NFS
PV.
It's
just
a
standard
NFS
PV,
where
we
define
the
data
live
off
of
that
particular
on
top
system.
In
the
mount
point
that
it's
been
created
at
simple
boring,
nobody
knew
what
was
going
on
in
the
background
right,
tried
and
abstract
it
everything
away
from
us,
but
we
can
still
see
the
details,
find
the
storage
administrator
or
in
the
openshift
administrator.
I
care
about
things
like
what
does
trident
know.
How
can
I
define
what
my
SLA
is?
Are
going
to
be.
A
So
by
looking
at
tridents,
we
can
see
that
I've
added
a
particular
back-end
here
now
I
can
add
backends
in
order
to
provide
different
capabilities.
Different
snapshot
policies,
different
export
policies,
I
can
customize
replication.
I
can
do
all
of
these
things
to
create
a
custom
storage
definition
for
an
application
for
a
class
of
applications
for
an
entire
namespace.
Whatever
I
happen
to
want
to
do
with
that
and
when
I
describe
that
I
can
find
out
what
Trident
knows
about
that
storage.
A
So
the
output
of
this
is
going
to
be
a
substantial
amount
of
yamo
that
describes
literally
my
back-end
aggregates
in
this
instance.
So
we
can
scroll
up
here
to
the
top
that
we
can
see
my
system.
We
can
see
my
controllers
that
exist.
We
can
see
the
aggregates
that
have
been
assigned,
and
importantly,
we
can
see
the
capabilities
that
are
being
offered
here
right.
This
is
an
ass
back
in
its
using
NFS
right.
I
can
do
clones,
I
can
do
encryption.
A
I
can
do
hybrid
storage
with
thicker
thin
provisioning,
because
one
of
the
unique
features
about
trident
is
well
4.
On
top
and
SolidFire
backends
we
can
do
storage
clones
directly
from
inside
of
a
PVC
right.
It's
a
simple
annotation
that
says
clone
from
this
PVC.
It
will
leverage
the
storage
array
to
clone
that
volume
instantly,
regardless
of
the
size
of
the
volume
or
the
amount
of
capacity
that's
been
used.
A
So
at
this
point,
I'm
not
gonna
dig
any
deeper
because
we
don't
need
to
dig
any
deeper.
We
don't
need
to
know
as
application
users
as
OpenShift
administrators.
We
don't
need
to
know
anything
else
about
the
storage.
Some
of
the
storage
team
to
worry
about
they're,
the
ones
who
understand
what
all
of
these
different
things
mean.
So,
let's
let
them
worry
about
it.
A
And
I'm
gonna
close
very
simply
with
the
public,
if
you're
interested
in
finding
out
more
about
NetApp
tridents,
if
you're
interested
in
finding
more
about
how
nettop
and
our
storage
portfolio
can
help
make
your
applications
better
can
help
you
do
things
better,
faster,
stronger
rates,
how
the
storage
can
improve
the
development
process
can
improve
application
process
right
as
we
go
through
the
CI
CD
pipeline.
Come
check
us
out
at
the
pub
the
pub
is
where
we
documents
where
we
show
how
all
of
these
things
work.
A
If
you
go
to
net
up,
comm
you'll
find
the
Wai
Wai
net.
Up
is
great.
Why
often
tap
is
phenomenal.
Why
SolidFire
is
fantastic?
Have
you
come
to
the
pub?
It's
the?
Why?
Probably
the
most
important
part
or
the
most
useful
part
of
the
pub,
however,
is
our
slack
channels.
You
browse
tin
that
up
dot,
io
/
slack,
it
will
prompt
you
for
your
email
address.
This
is
simply
to
generate
the
slack
invites
I
promise.
You
marketing
doesn't
know
that
that
exists.
A
You
will
never
get
a
marketing
email
from
us
as
a
result
of
that,
instead
of
our
slack
team
sits
something
like
1500
of
our
community
members
of
our
employees.
Lowly
tMI's,
like
myself,
but
also
product
managers,
also
technical
directors,
support
personnel
and,
arguably,
most
importantly,
the
engineers,
the
developers
who
are
literally
creating
not
just
trident,
but
our
open
stack,
integrations
our
ansible
modules,
our
puppet
modules,
Jenkins
integration.
All
of
these
other
open-source
things
all
of
our
developers.
All
of
our
engineers
sit
inside
of
here,
so
I
highly,
encourage
you
to
come
check
it
out.