►
Description
In this briefing Stephen Watt, Chief Architect of the Emergent Technologies group at Red Hat, will give you an intro to the state of the art of the storage within OpenShift. Then he will talk about the direction the team is taking.
For the latest information on OpenShift 3.1 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally. The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org
A
A
Persistent
storage
but
containerized
applications,
ski
wat,
who
is
our
chief
architect
in
the
emerging
technologies
group
at
ok,
leglock
living
ship,
but
at
Red
Hat
itself
is
going
to
walk
us
through
how
to
do
this
and
I'm
going
to
turn
it
over
to
Steve
and
let
him
introduce
himself
a
little
more
and
get
going
and
then
we'll
have
QA
through
the
chat
and
then
at
the
end
of
his
presentation
and
demo
go
for
it.
Steve.
B
Thanks
Diane,
so,
as
I
said,
my
name
is
steve
watts
and
my
wicked
imaging
technologies
group
at
Red,
Hat
and
I
lead
the
container
storage
engineering
program
at
Red
Hat,
and
so
that
means
that
I
work
with
open
shift
to
enable
the
storage
features
and
within
open
shift.
And
then
I
also
work
with
our
storage
business
units
and
our
engineering
teams
there
to
basically
and
prepare
our
storage
portfolio
to
work
with
containers
optimally.
B
So
in
this
presentation,
I'm
going
to
first
catch
you
all
up
on
the
current
state
of
the
art,
around
storage,
enablement
within
open
shift
and
just
to
sort
of
set
a
platform
and
then
I'm
going
to
talk
a
little
bit
about
where
we,
where
are
we
going
and
so
I'm
going
to
talk
about
container,
is
connecting
to
storage
and
to
start
off
with
and
then
I'm
going
to.
Actually
talk
about,
running
storage
platforms,
improve
annuities
in
killeen,
openshift,
okay,
so
I
first
want
to
jump
to.
B
You
know
start
on
the
slide
right,
which
is
sort
of
the
road
to
storage
as
a
service
white.
And
so
what
you
see
here
are
saw
the
five
dimensions
around
enterprise.
It
and
how
they've
sort
of
progressed
downwards
towards
the
current
state
of
the
art,
so
that
the
top
rows
sort
of
where
we
started
and
the
bottom
rows
where
we
ended
I'm
sure
many
of
you
being
open
chef
users
are
quite
familiar
with
this.
B
You
know
often
co
located
within
the
same
team,
with
multiple
with
people
starting
to
share
roles
that
are
both
div
and
a
bit
of
ops,
incorporating
agile,
doing
small
scope,
very
rapid
iteration
and
sometimes
iterating,
quite
often
with
releases
in
production,
as
opposed
to
very
long
periods
of
time,
before
changing
things
in
our
in
operations
and
so
with,
and
then
we
also
have
a
sort
of
a
shifter
microservices.
Where
you
know,
applications
are
becoming
much
more
granular.
B
The
contract
is
very
service-oriented
where
they
communicate
with
each
other
based
on
restful
interfaces
and
they
don't
care
so
much
about.
You
know
what's
running
behind
the
interface
all
right,
and
so
it's
very
service
oriented
and
we're,
seeing
you
know,
broad
adoption
of
containers
as
a
unit
of
deployment,
often
packaging,
the
entire
micro
service
itself,
and
these
containers
are
running
sort
of
on
cloud
platform.
Right.
We've
seen
that
the
data
center
specifically
changed
from
you
know
having
the
cloud
and
the
data
center
and
everything
in
enterprise
in
the
enterprise
running
in
the
data
center.
B
Just
thought
it's
using
the
cloud
to
you
know
the
enterprise
I'm
running
some
stuff
in
the
data
in
the
data
center
and
some
stuff
in
the
cloud,
and
now
you
know
where
our
enterprise
data
centers
are
starting
to
look
much
more
like
the
cloud,
and
so
this
is
pretty
interesting
from
a
storage
dimension,
because
you
know-
and
if
you
look
at
where
scourge
started,
you
know
you
sort
of
had
a
single
box
with
a
certain
amount
of
storage
that
would
give
carved
up
and
that
you
know
had
various
amounts
of
constraints.
They're
very
expensive.
B
You
know
you
need
to
buy
a
better
sort
of
storage
appliance
if
your
site
to
run
out
of
storage
capacity,
and
so
you
know
we
got
many
kinds
of
economic
benefits
by
mu
to
scale
out.
Software-Defined
storage
platforms
like
the
Hadoop
distributed
file
system
in
cluster
affairs
and
said
things
like
this,
which
took
advantage
of
the
economic
benefits
of
commodity
x86
infrastructure,
and
you
know
that
that
was
awesome,
but
also
I'm
not
very
cloud
like
in
that.
You
have
to
go
tap
a
storage
administrator
on
the
shoulder
and
say:
hey.
B
Would
you
go
make
me
a
block
device
or
a
distributed
file
system
volume
and
tell
me
what
the
connection
information
is?
And
so
you
know
your
productivity
was
sort
of
gated
on
how
quick
storage
administrators
could
turn
around
those
requests,
and
so
eventually,
where
we're
moving
to
the
enterprise
data
center
being
able
to
consume
storages
service.
The
same
way
that
we
consumes.
B
You
know,
storage
in
the
cloud
right
so
we'll
have
you
know,
microservices
running
in
containers
running
in
a
card
like
enterprise
data
center
that
can
supplement
rip.
You
know
wrist
will
recall
restful
calls
to
a
storage
service
that
says:
hey
go
make
me
a
block
device
will
go.
Make
me
a
volume,
provide
the
information
and
I
can
attach
mount
it
into
my
container
and
use
it
right
away
right.
B
B
All
right
so
just
double
checking,
so
the
one
you're
seeing
now
is
what
is
in
full
screen
and
storage
innovation
for
containerized
applications.
Yep,
that's
correct,
okay,
so
so
what
you're
seeing
here
on
this
slide
is
is
what
you
get
with
open
shove,
three
dot,
one
which
you
know
is
being
released
this
week
right
so
and
and
what
does
the
way
the
way
this
works
now?
Is
that
you're?
You
know
containerized
applications
that
run
an
open
shift,
and
you
know
this
features
obviously
available
in
origin
as
well.
B
B
You
know
pointers
to
your
storage
and
enville,
allocate
them
to
applications
and
then
use
them,
and-
and
you
have
a
much
wider
choice
of
persistent
storage
than
you
know
you
used
to
which
was
like
you
know,
the
available
storage
capacity
on
the
docker
host
right,
and
so
obviously
these
these
are
the
additions.
We've
always
had
host
path
and
empty
der
within
an
open
shift,
so
rich,
which
are
local
storage
and
available
within
Cuba,
Nettie's
and
and
the
other
big
thing
that
we've
added
recently
is
volume
security.
B
So
before,
when
you
were
accessing
NFS,
you
know
or
I
scuzzy,
safe,
etc.
Everything
was
done
as
root
root
right
and
so,
essentially
the
the
storage
asset
had
to
be
configured
to
be
accessible.
You
know
wide
open
right
and
so
that
this
is
a
huge
thing
that
we've
added
recently.
It
is
to
be
able
to
add
support
for
dr.
B
supplemental
groups,
and
so
the
way
we've
incorporated
that
within
the
open
ship
security
context
is
that
for
block
devices,
your
open
shift
user
will
be
assigned
a
particular
FS
group,
a
particular
type
of
supplemental
group,
and
that
supplemental
group
will
be
used
to
come
perform.
What
we
call
a
takeover
of
the
the
block
device,
which
means
completely
owned
it.
So
it
sets
the
selinux
context,
assess
all
the
appropriate
selinux
labels
so
that
that
group
and
that
container
can
access
that
block
device.
B
And
then
it
does
the
relevant
challenge
your
mods
to
that
the
device
so
that
the
file
system
on
that
device
is
set
for
access.
Only
for
that
particular
group
right
and
so
so
now.
We've
gone
from
essentially
wide
open
security
to
at
least
group
level.
Access
control
and
same
with
the
shared
storage,
shared
storage
works
a
little
differently,
so
we
can't
we
don't
have
the
same
level
of
automated
access
control
that
we
can
do
on
block
devices
they're
a
little
different
in
that
you
know.
B
The
other
aspect
of
shared
storage
is
that
you
don't
necessarily
the
container,
won't
necessarily
own
the
shared
storage
right.
The
container
might
be
using
just
a
part
of
it,
and
you
know
the
accounting
group
must
be
running
python.
Applications
that
you
know
who's
the
same
shared
storage
as
well
right,
so
you've
got
a
you
know.
It's
shared
asset.
You've
got
to
be
a
little
more
considerate
about
how
things
work,
and
so
you
know
the
way
that
works.
Is
that
basically
you
config
configure
it.
B
You
know
if
it's
in
NFS
share
and
you
configure
the
directory
access
permissions
for
accessed
by
a
particular
group
I'm,
it's
a
cluster
of
fest
volume.
You
do
the
same
thing
and,
and
then
you
may
60
provide
that
group
in
with
your
pod,
in
the
security
context
as
a
supplemental
group,
so
that
all
I,
oh,
that
that
accesses
those
NFS
JS
of
glossary
of
volume
directories
will
have
full
access,
but
any
other
groups
that
attempt
to
access
it
will
not
write
so
so.
B
B
So
this
is
ridikolus
true
face
with
that
cluster
storage
and
an
example
of
way
and
how
you
might
use
this
is
that
you
have
a
scale-out
web
server
form
and
you
really
don't
want
to
copy
the
your
web
content
onto
every
single
server
within
your
web
server
farm
and
have
the
pods
mounted
use
it
directly.
You
know
using
something
like
a
host
path:
volume
plugin.
B
Instead,
you
know
it
makes
a
lot
more
sense
to
be
able
to
stall
that
information
centrally
in
some
sort
of
shared
file
system.
So
at
any
time,
your
content
team
wants
to
make
an
update.
They
just
change
it
in
one
place
and
they
don't
have
to
update
all
50
servers
in
your
website
before
and
so,
and
so
what
you
would
do
here
is
configure.
B
You
know
your
engine
X
pod,
to
use
a
claim
against
a
glossary,
FS
volume-
and
you
know
all
your
content
inside
that
and
then
basically
gives
you
kind
of
a
unique
set
of
controls
from
a
control
plane
perspective
and
that
you
know
you
can
have
your
development
team.
Your
content
team
copy
data
directly
into
your
glossary
storage
and
just
using
fastest
amounts.
B
But
if
you
want
to
scale
at
your
web
server-
and
you
just
change
the
amount
of
replica
instances
that
you're
running
for
that
and
they
will,
as
the
new
pods
come
up,
they
will
automatically
bind
to
the
same
cluster.
So
there's
literally
no
work
you
have
to
do
to
scale
out
and
make
sure
that
those
new
pods
connect
to
the
same
cluster.
B
That's
a
classic
example!
When
you
choose
something
like
safe,
rrb,
DS
right,
which
was
basically
a
file
or
block
device,
and
so
you
would
use
the
a
persistent
volume
claim
against
a
safe
rbd
or
a
direct
volume
and
against
an
r
BD
and
in
your
pod
definition
for
your
my
sequel
container
and
you
would
still
valla
my
sequel
into
wherever
you're
mounting
the
save
file
system.
And
so
what
would
happen
is
you
would
create
this
database?
B
And
then
you
know
if,
if
the
container
needs
to
get
moved,
when
it
starts
up,
it
will
connect
back
to
exactly
the
same
set
rbd
and
automatically,
and
you
won't
have
to
do
anything
and
your
database
as
a
slots
up.
Your
database
will
come
back
right
back
up
with
one
of
its
files
and
keep
working
so
so
this
is
what
we
have
today,
and
so
this
is
great.
But
if
you
recall
what
I
spoke
about
storages
of
platform
which
discourages
it
as
a
service,
this
model
requires.
B
You
know
the
storage
to
be
managed
by
separate
storage
administrator.
There
needs
to
be
communication
between
the
open
shift,
users,
administrators
and
storage
administrator
users
to
be
able
to
consume
the
storage.
So
we
would,
like
you
know,
in
the
theme
of
DevOps
right
and
agility
to
basically
empower
our
development
community
we'd
like
to
make
this
a
whole
lot
easier.
So
the
what
we're
moving
to
now
is
a
hyper
converge
as
an
additional
option,
so
we'll
keep
our
offering
the
others.
B
Obviously
you
have
storage
investments
that
you've
paid
for
that
you
want
to
use,
so
we
will
keep
offering
all
of
that
inside
origin
and
osc,
but
what
we're
looking
to
do
is
for
the
roadmap
is
basically
be
able
to
read
storage
in
openshift
itself,
okay,
and
also
to
be
able
to
add
dynamic
provision.
So
let
me
start
with
dynamic
provision.
It's
a
dynamic
provisioning.
B
The
concept
here
is
that
for
providers
that
that
can
have
service
interfaces,
so
examples
of
this
might
be
if
you're
running
origin
in
Amazon,
AWS
or
GCE
in
Google
cloud
or
in
OpenStack.
You
know
awss
EBS,
discs
of
GC
es
persistent
disks,
OpenStack
health
center.
All
of
these
have
restful
interfaces
which
you
can
communicate
with
we're
planning
on
adding
provisioners
so
that
you're
able
to
basically
submit
claims
for
a
particular
class
of
storage
to
say
you
would
like
a
AWS
GPE
SSD.
B
Instead
of
an
AWS
magnetic
SSD
right,
you
could
basically
create
tiers
of
storage
and
use
arbitrary
labels
to
describe
those.
So
I
would,
like
you
know,
Goldstuck
the
word
gold,
the
label,
gold
mapped
to
EBS
GP
SSDs
I
would
like
silver
map
to
EBS
I,
ops,
SSDs
and
I
would
like
bronze
map
to
EBS
magnetic
right,
and
so
your
developers
will
be
able
to
submit
claims
against
one
of
those
labels.
B
And
then
the
idea
is
that
we
will
have
a
provision
for
each
different
kind
of
label
built
into
the
volume
the
overall
volume
plug-in
for
that
storage
type,
and
it
would
condom
and
go
provision
provisionally
am
storage
asset
that
you
want,
register
the
persistent
volume
and
bind
it
to
your
claim
so
that
you
can
use
it
and
now
obviously,
if
you're
an
ops
person,
you
know
you
might
get
nervous
about
the
accounting
dimensions
of
this.
Where
you
develop,
a
community
could
run
up
and
a
very
high
bill
without
you
being
able
to
control
it.
B
So
what
we've
set
our
the
ability
to
control
claim
quarters
within
the
project's
themselves
right,
so
you
can
actually
sort
of
empower
you
developers
but
sort
of
set
boundaries
as
to
exactly
how
empowered
they
are,
and
so
that's
a
dynamic
provision
right
so
that
you
know,
regardless
of
which
cloud
provider
openshift
is
running
in
you,
should
be
able
to
dynamically
provision
storage
within
net.
Now
these
are
all
block
storage.
B
We
can
actually
deploy
Gloucester
if
this
as
pods
within
communities
and
open
shift,
and
we
can
constitute
a
Gloucester,
a
phase
cluster
that
runs
inside
an
open
shift,
cluster
or
kooban
in
this
cluster,
and
then
from
that
we
can
carve
out
storage
now,
there's
obviously
a
prerequisite
to
this,
which
is
the
nodes
that
those
containers
land
on
the
host.
The
open
shift
hosts
communities
nodes
have
to
have
some
sort
of
direct
attached
storage
available
for
gustl
to
use
right.
B
B
So
you
could
sub,
you
know,
create
a
label
called
applo
and
that
is
mapped
to
you
know
the
app
load,
one
you
plug
in,
so
that
when
someone
splits
a
claim,
it
can
actually
go
and
dynamically
provision
storage
out
of
your
appt
load
cluster,
that's
running
inside
your
open
shift
cluster.
So
there
there
are
many
benefits
of
this.
You
know
you
know
mainly,
you
know,
unified
orchestration,
which
sort
of
means
ease
of
use
of
greater
control,
so
a
single
sort
of
control
plane
and
then
obviously,
the
the
convergence
benefits,
lower
total
cost
of
ownership.
B
So
you
know
you're
running
your
storage
cluster
inside
you
know
inside
your
open
shift
cluster,
so
you've
got
one
set
of
hardware
there
and
a
single
control
plane
for
sort
of
your
your
software-defined
Network,
software-defined
storage.
You
know
and
your
Software
Defined
computing
applications,
so
one
stop
shop
from
openshift
origin,
and
you
know
this
is
actually
quite
valuable
because
even
though
you
may
have
storage
in
your
data
center
may
not
always
be
accessible.
There
may
be
physical
impediments
to
it
to
accessing
it,
but
there
may
also
be
sort
of
organizational
impediments
to
access
it.
B
B
You
know
that
this,
the
software
on
them
the
storage
platform
software
on
them,
you
know-
and
only
then,
can
you
make
it
available
to
your
openshift
cluster,
so
there's
there's
sort
of
time
to
solution
advantages
in
this
model
as
well,
right
and
all
right.
So
so
with
that
said,
I
just
want
to
sort
of
clarify
that
all
this
work
is
sort
of
not
downstream
on
product
related,
yet
we're
still
building
this
out
in
the
community.
But
it's
not
market
extra
vaporware
as
I'll
show
you.
B
I
have
a
sort
of
a
demo
working
already,
so
we're
kind
of
focusing
the
initial
integration
within
origin.
You
know
providing
storages
and
micro
service
with
dynamic
provisioning
and
it's
not
just
bluster
of
face
right,
we're
looking
at
containerized
and
safe
as
well.
There's
a
pretty
well-known
project
up
there
called
safe
dash
darker,
which
is
dr.
containers,
so
we're
looking
at
working
with
that
project
to
sort
of
bolster
it
build
out
some
red
SF
clusters
from
that
sort
of
deciding
on
the
granularity
of
the
images
there.
B
It's
a
little
safe
as
a
sort
of
kernel
space
storage
platform
where
cluster
is
sort
of
the
user
space.
It's
a
little
different
working
with
safe.
But
you
know
the
intent
is
to
hopefully
be
able
to
do
the
same
thing
with
Seth
that
we're
doing
with
cluster
and
bringing
it
into
open
shifter,
so
that
you'll
be
able
to
not
only
provision
shared
file,
but
also
you
know,
Phi
1
block.
So
with
that
said,
I'm
going
to
show
you
a
demo
so.
B
Whined
a
little
bit
too
so
so
what
we're
seeing
here
is
a
kubin,
a
nice
cluster
I've
got
a
couple
of
files
here.
So
basically
my
cluster
a
face
whoops,
my
cluster,
a
face
cluster
is
really
just
two
files
at
Gloucester
Wanyama
land,
a
cluster
dash
to
yamo
each
one
of
these
is
an
individual
pod,
so
I'm
running
a
two
node
cluster
face
cluster
and
once
I
run
that
I
will
and
I.
The
first
part
of
the
demo
is
actually
getting
Gloucester
FS
and
running
inside
Cuban
eighties.
B
So
it's
able
to
sort
of
I'm
able
to
create
volumes
from
what's
running
in
cube
and
then
the
second
aspect
is,
you
know
the
pre-existing
bits
that
already
existed
so
we've
always
had
a
glossary,
fest
volume
plug
in
Cuba
Nene's
well
for
a
long
time.
Cuba's
have
been
around
that
long,
but
forever
how
long
it's
been
around.
B
It's
been
around
in
that
for
quite
a
bit
of
time,
and
and
so
we're
going
to
use
that
cluster
office
volume
plugin
for
those
of
you
that
aren't
familiar
volume,
plugins
they're,
just
storage
adapters,
it's
just
a
way
to
connect
your
you
know
your
application.
You,
which
is
your
glass
or
your
your
pod,
in
open,
open
shift
to
Cuba
nidhi's
to
some
sort
of
external
storage
right
and
so
I
have
an
application,
which
is
this
engine
X
dash
cluster
and
that's
actually,
the
web
server.
B
B
So
you
can
see
here
this.
This
is
a
example
of
one
of
the
pods
that
cluster
of
face
is
running,
so
there's
some
design
decisions
that
are
reflected
in
here
and
the
first
is
the
label
right.
It's
got
to.
Each
pod
has
got
a
unique
label
and
the
second
aspect
is
you
know
if
you
go
look
at
the
the
host
network
right.
B
This
is
a
pretty
new
parameter
to
you,
know,
origin
and
Cuban
eating's,
which
is
that
you
don't
have
to
use
an
overlay
near
to
Accord
the
dock
and
network,
and
you
can
actually
use
the
host
network.
So
I'm
running
this
demo
on
three
virtual
machines
running
fedora
20
to
they
you
know
there
are
192
dot,
one
sixty
eight
dot,
58
dot,
something
each
one
of
them
right.
That's
the
Masters
dot.
Twenty!
You
know
work
once
the
21
and
where
excuse
me,
worker
2
is
dot
22.
B
So
when
the
containers
come
up,
they
actually
share
the
IP
of
the
host
that
they're
reading
on,
and
this
is
required-
and
this
is
a
also
an
element
of
quality
of
service
that
we're
looking
to
do
in
that.
You
know
means
the
storage
traffic
isn't
mixed
up
into
the
overlay
network
traffic
that
we're
able
to
segment
it,
and
in
some
cases
you
know
we,
if
there's
a
separate
network
available
I'm,
so
there's
two
nicks
on
the
server,
for
example,
we
might
be
able
to
take
advantage
of
that.
B
So
I
offer
some
sort
of
quality
of
service
where
performance
fan
this
is.
The
second
aspect
is
overlay.
Networks
are
kind
of
a
new
thing
for
storage
platforms,
and
you
run
into
a
lot
of
trouble
when
you're
trying
to
use
them.
So
we
read,
you
know
we're
trying
to
iterate
up
from
a
working
solution
and
host
network
was
something
that
would
just
work
out
of
the
box
of
cluster.
So
the
next
aspect
is
the
node
selector
right.
So
this
this
is
something
that
I'm
works
in
conjunction
of
sort
of
a
another
design
decision.
B
But
the
other
aspect
is
you
know
when
the
content,
the
glossary
of
s
container
on
worker
one
starts
getting
Hughes
and
what
it's
going
to
do
is
it's
going
to
mount
basically,
a
directory
on
the
host
called
Mount
Rick,
one
right
and
so
mount
brick,
one
refusing
with
a
host
path,
volume,
plugin,
so
host
path
means
hey,
take
this
directory
from
the
origin
host
and
basically
mounts
it
into
this
particular
place
within
the
cluster
right.
So
the
place
I'm
mounting
it
into
you
in
the
container
is
the
same
place.
B
That's
on
the
host
I'm
then
basically
make
it
so
I'm
providing
a
local
directory
on
the
host
available
inside
the
container,
and
you
know
I'm
using
this
cluster
of
s,
image
to
actually
run
the
cluster
affairs
processes.
Now
here's
the
thing
right.
This
is
why
I'm
pinning
the
pod
on
to
the
same
worker,
because
after
you
know
it's
being
used,
there's
going
to
be
data
stored
on
that
localhost
directory
right
on
the
host
host
path
funny,
and
so,
if
you're
going
to
move
that
brick
to
some
other
server
within
the
cluster.
B
Sorry,
if
you
go
move
this
blustery
container
to
say
server
50
instead
of
worker
one
when
it
comes
up,
it's
going
to
try
and
and
it's
going
to
need
access
to
the
data
things
that
needs
to
be
storing,
and
it's
not
going
to
be
there
on
that
host,
which
is
another
reason
why
we're
putting
it
on
record
now
we
could
use
something
like
safe
rbd
cure
as
an
alternative.
We
could
put
his
block
storage
and
that
wouldn't
be
a
problem,
but
the
performance
would
be
it
would
be
as
good
right.
B
I
mean
obviously
you're
you're
talking
about
iOS
that
are
going
to
local
disk
as
opposed
to
going
across
the
network.
Every
time
you
make
him
an
I/o
request,
so
this
is
a
design
decision
that
we're
currently
making
for
performance
reasons.
Okay,
so
if
we
essentially
go
look
at
the
the
second
part,
it's
identical,
it's
identical.
B
The
only
thing
that's
different
with
the
second
part
is
that,
basically,
you
know
it's
got
a
different
names
instead
of
cluster
ones,
cluster
team
and
it's
the
node
selector
set
to
work
worker
to
write
so
but
beyond
that,
it's
exactly
the
same.
So,
let's
take
a
look
at
my
clustering
so
that
you
can
get
a
sense
of
what
I've
got
so
I've
got
a
single
master
and
then
I've
got
you
know
to
Cuba
Nettie's
workers
or
server.
One
is
work
for
one
server
to
is
work
or
two.
B
You
can
see
that
I'm
not
running
any
pods
right
now.
If
I
do,
u
cube
control,
get
points,
I
get
pods,
and
so
what
I'm
going
to
do
is
I'm
going
to
go
off
and
I'm
going
to
submit
both
of
these
Gloucester
Affairs
pots
right.
So
I've
submitted
the
first
one,
and
now
I'm
going
to
go,
submit
the
second
one
and
then
I'm
going
to
do
cube
control
get
pods,
and
if
you
do
the
dash
oh
wyd,
this
works
same
with
OC
you
might
as
well
in
origin.
B
You
can
actually
see
the
nodes
that
the
pods
got
scheduled
on,
which
is
useful.
In
our
example
right
you
can
see
they're
getting
pinned
to
the
right
thing
right,
so
ready,
1
out
of
1,
the
the
cluster
is
running.
So
at
this
point,
what
we
have
is
a
cluster
f
s.
Cluster
running
inside
Cuba
needs
right
now,
I,
don't
actually
have
any
volumes
to
use
the
right
and
I've
actually
got
to
be
able
to
set
the
cluster
up
as
well
before
I
can
properly
use
the
volume
right.
B
So
the
first
thing
I
do
is
keep
control
exec
into
one
of
the
pots.
This
is
the
same
as
doing
like
a
doctor,
exactly
I,
you
know
bash
or
Sh
I
reset
the
UID.
This
is
just
a
bug
in
the
image
that
I'm
community
image
that
I'm
using.
So
you
know
it's
a
step.
I
have
to
do
and
then
the
second
step
is
to
sort
of
tell
gluster
what
the,
how
to
constitute
the
cluster
now
in
our
ultimate
design,
were
planning
on
automating.
B
This
incorporating
information
in
its
easy,
but
I'm
just
doing
it
manually
now
so
I'm
from
the
container
Gloucester
container
on
worker
1,
I'm,
probing
the
container
second
container
on
work
or
two
and
then
basically,
when
I
run
blaster
peer
status,
it
looks
at
work,
/
1.
It
says
how
many
additional
peers
do
you
have?
We've
got
one
additional
pier,
so
a
total
courtroom
of
two
so
I've
got
my
cluster
in
effect
and
now
I
can
like
go
and
create
a
volume
right.
So
now
I
can
go
create
a
volume
called
nouveau.
B
I
specify
the
IP
address
of
the
first
container,
which
I
happen
to
be
in
right
now
and
pass
in
a
brick
path
that
was
the
host
path
volume.
Then
I
mounted
into
the
container
that
I
spoke
about
earlier
and
I
pass
in
the
second
one
as
well
for
the
second
container
and
it's
brick
path
right.
So
that's
great.
The
command
work
so
now,
I
have
a
volume.
I
need
a
started,
make
sure
that
it
started
and
then
double
check
that
it's
running.
B
So
if
I
do
a
glossary
volume
status,
you
can
see
that
everything's
running
and
you
can
see
the
two
bricks
I'm
going
to
highlight
these
that
I
created
within
all
right.
So
so
you
see
the
two
containers
and
the
host
past
directories
that
they're
using
and
each
one
of
them.
So
now
we
have
a
glossary
of
fist
volume,
that's
ready
for
use
and
we
were
able
to
actually
use
a
coup.
Benetti's
application
and
configure
it
to
mount
and
hughes.
This
cluster
f
s
volume
to
serve
some
data.
B
So
the
first
thing
that
you
I'm,
showing
as
I
run,
a
mount
command
on
the
hosting
and
while
I
have
a
glossary
of
fist
volume,
you
can
see
that
the
the
volume
is
not
there.
In
fact
that
was
a
bit
quick,
so
I'm
just
going
to
go
back
a
little
bit,
so
there
we
go
all
right.
So
when
you
run
out
it'll
show
you
all
the
available
mounts
on
the
host
right,
I'm
on
the
actual
host
right
now,
and
you
can
see
that
there
are
no
mounts
on
the
host.
B
Now
the
engineers
application
will
automatically
do
this,
but
you
know
I
want
to
it'll
mount
the
volume,
but
the
volume
means
something
inside
of
it
now
for
me
to
actually
do
a
dim,
so
I'm
going
to
just
mount
the
volume
and
then
create
a
file
inside
of
it,
a
little
hello
will
HTML
and
then
so
that
will
be
there
that
when
my
wet
engine
X
web
server
uses
the
volume
I
can
basically
tests
that
it
can
serve
that
file
right
so
I.
This
is
how
you
do
a
glossary
of
phase
mount
manually.
It's
pretty
simplistic!
B
B
You
ok!
So
now
that's
done
so
now.
I
can
just
unmount
the
the
volume
from
the
master,
and
so
it's
not
mounted
it
anywhere.
At
this
point
off
this
command
runs
if
Iran
mount
again
you'll
see
that
it's
no
longer
there
on
the
host
right.
So
now
it's
just
living
inside
the
containers
with
it
not
connected
to
anything.
So
now
I'm
going
to,
let's
see
I'm
going
to
show
you
the
entered
x.
Well,
actually,
first,
I'm
going
to
show
you
the
the
endpoints
file
right.
B
So
you
can
see
if
I
run
cube,
control
get
endpoints
are
not
running
any
endpoints
right
now
for
gloucester
FS.
So
what
I'm
going
to
do
is
show
you,
the
cluster
affairs
endpoints
file.
So
this
is
something
that
you'd
need
to
create
to
user
glossary
first
volume
directly
and
it's
pretty
simplistic.
All
this
thing
is
an
array
of
IP
addresses
of
some
of
the
addresses
that
are
in
the
cluster.
So
now
that
that's
done,
I'm
going
to
create
a
the
endpoints
file
just
to
submit
it.
I
do
get
endpoints
it.
B
You
can
see
that
it's
there
gluster
FS
dash
cluster.
Is
the
label
associated
with
the
endpoints
file
and
see
the
two
IP
is
in
there
now
I'm
going
to
show
you
the
actual
web
application.
So
it's
a
fedora
engine,
X
web
image,
I'm
using
the
gloucester
fsbo
liam
plugin,
I'm
using
the
glossary
of
s
dash
cluster
endpoint
that
I
used
I'm,
mentioning
the
volume
name
that
I
created
and
then
in
the
read-only,
semantics,
I,
say
false,
which
means
it
supports
for
read/write
and
then
I'm
mounting
this
into
usershare
engine
XHTML
inside
the
container
right.
B
So
at
this
point,
what
will
happen
is
it
will
take
the
cluster
face
volume
I
created
mounted
inside
the
engine
X
web
server.
Add
users
share
HTML
test.
This
is
the
document
root
of
the
web
server.
So
this
is
the
place
in
the
file
system
of
the
web
server,
where
it
serves
content
from
right.
So
so
I'm
going
to
submit
the
pod
at
this
point
so
that
the
application
pod
the
engine
X
pod-
and
you
can
see
it's
still
starting
up-
it's
ready,
0
dash
1.
B
B
Pods
and
I
find
the
IP
data
that's
been
assigned
for
the
containers,
it's
running
on
worker
too
so
I'm
just
going
to
shell
into
work
or
two
now
and
run
a
curl
command
against
that
IP
and
then
the
path
of
the
document
root
and,
let's
see
if
it
serves
it
from
cluster,
and
it
does
right.
So
what
we're
seeing
here
is
a
ninja
next
web
server,
mounting
a
glossary,
face
volume
and
serving
web
content
from
it,
as
demonstrated
by
the
school
request,
and
that
volume
itself
is
running
inside
containers
as
pods
inside
Cuban
agents.
B
A
A
B
B
The
first
part
remember
I,
spoke
about
having
this
thing,
storage
and
being
able
to
automate
and
manage
connections,
as
your
containers
move
around
your
cluster.
Keeping
that
connection
information
to
your
storage
around.
So
that's
one
thing
they
do
and
then
they
also
have
something
to
do
with
ZFS
I
think
where
you
can
sort
of
hues
of
storage
that
appears
to
be
direct
attached
like
host
port.
That
is
able
to
move
around
the
cluster
with
you,
I,
don't
know
if
they
support
dynamic
provisioning
at
all.
B
A
So
I
haven't
seen
anything
pop
up
in
the
Q&A
section
here,
so
I'm
going
to
put
it
up
again
to
see
if
there's
folks
so
there's
there's
a
lot
of
folks
on
the
call
I
think
they
make
me
stunned
and
amazed
at
how
forward-thinking
some
of
this
work
is
but
see.
If
we've
got
anybody
here,
yeah
I'm
you
coming
in
I
think
they
just
basically
they
basically
want
your
presentation,
so
they
can
go
run
out
and
try
it
now.
A
We
got
faults.
Really.
It
really
was
a
very
detailed
and
the
step-by-step
was
probably
one
of
the
best
that
I've
seen
in
a
long
time
and
I'm
not
just
doing
this
so
that
I
can
get
you
on
another
common
creeping
in
the
future.
But
I
really
appreciate
the
detail
that
you
went
into.
It
was
very
clearing
inside.
So
thanks
very
much
Steve
sure
no
problem
popped
in
one
more
question,
just
to
be
clear:
you're
using
persistent
volumes
here
to
connect
to
bog
pods
to
clusters.
Yes,
so.
B
So
Nicholas
just
to
clarify
so
pissed,
so
this
is
one
of
the
things
that
I
think
we
could
describe
a
little
better
in
the
queue
benetti's
project,
but
the
there
there
are
two
things
that
refer
to
storage
in
cuban
edits.
There's
volumes
and
persistent
volume
per
volume
is,
is
a
storage
asset
that
you
have
intimate
knowledge
of?
In
other
words,
you
know
what
IP
that
thing's
running
on
what
the
volume
is
called.
You
basically
are
able
to
provide
all
the
connection
information
to
a
storage
adapter
to
connect
to
that
thing
directly.
B
Ok,
and
that
and
that
volume
is
independent
storage.
It's
not
running
inside
openshift
itself.
Right
into
am
usually,
then
persistent
volumes
are
similar
but
they're
abstracted.
So
the
idea
is
that
developers
don't
really
care
that
hey
I
want
to
connect
to
this
thing
directly
and
what
they
care
about
is
hey
I,
need
you
know,
300
gigabytes
of
storage
capacity
on
you
know
a
shared
file
system
or
a
non
shared
file
system.
I
I
want
other
people
to
be
able
to
access
this
file
system,
or
just
me
and
I
wanted
to
have.
B
You
know
this
sort
of
sort
of
I/o
performance
right
and
they
don't
really
care
what
product
is
serving
that
and
so,
and
that's
essentially
the
idea
behind
persistent
volumes
in
that
as
an
open
shift
administrator,
you
can
create
a
ton
of
these
persistent
volumes.
You
can
register
them
inside
open
shift
and
you
can
specify
whether
they
are
what
semantics
they
support.
B
So
whether
they're
read/write
many,
which
basically
means
they
shared
storage
or
read,
write
once,
which
means
that
their
block
storage
and
and
then
when
the
developer
makes
their
claim
they
can
sort
of
claim
what
they
want
and
they'll
just
get
something
out
of
the
pool
that
uses
fuzzy
logic
that
to
best
match
what
they
want.
So
what
I
mean
by
fuzzy
logic?
I
mean
there.
B
You
know
if
you
have
a
hundred
one
terabyte
persistent
volumes
in
the
pool
and
the
and
then
you
have
say,
1,
500
gigabyte
boiling
in
the
pool
and
a
developer
asked
for
400
gigabytes.
The
developers
claim
will
be
bound
to
the
500
gigabyte
for
you,
so
it
does
its
best
to
match
what's
available
with
what's
requested.
A
B
That's
so
there's
a
another
question
here.
So
can
one
grow
the
storage
once
this
is
being
claimed?
That
is
in
the
plan
right
only
certain
so
for
dynamic
provisioning
right,
so
it
sure
would
be
annoying
if
you
could
provision
storage,
but
then
you
know
so
se
eu
provisioned
an
EBS
volume
or
something
to
that
effect,
and
you
put
your
database
on
it
and
then
you're,
like
oh
man,
I,
didn't
ask
for
enough
storage
capacity,
and
then
you
run
out
of
disk
space
in
your
database.
B
You
know,
won't
come,
won't,
restart
right
and
so
for
the
volume
types
that
we
supported,
that
the
current
thinking
in
the
design
is
that
what
you
can
do
is
set
a
flag
on
each
storage
type
associated
with
a
particular
label
that
says:
hey
I'll,
allow
the
developer
to
manage
this
right,
and
so
so
say
Diane
is,
you
know,
has
some
budget
flexibility,
the
open
shift
administrator
can
say:
hey
Diane,
you're,
building
a
school
application.
You
know
I'm
going
to
allow
you
to
increase
or
decrease
your
storage
capacity
as
you
see
fit.
B
You
know
it's
not
going
to
be
a
financial
problem
for
us,
and
so
they
can
basically
set
the
the
act,
the
capacity
management
flag
to
developer
as
opposed
to
administrator,
so
that
means
developers
aren't
powered
now.
Obviously
that
means
that
when
you
go
and
look
at
your
claims-
and
you
know
it
not-
all
claims
are
connected
to
things
that
will
allow
you
to
dynamically
increase
your
storage
capacity.
Most
of
the
cloud
options
do
and
the
app
lo1
the
glossary
fs1
that
we're
running
co
located
within
openshift.
We
intend
to
offer
that
as
well
right.
B
So
that's
a
scale-out
storage.
It's
not
too
hard
to
scale
out
once
you've
got
some,
you
just
throw
more
servers
out
or
more
containers
in
this
concept,
so
yeah.
The
long
long
answer
is
yes,
the
intent
is
to
allow
developers
themselves
as
well
as
administrators,
to
increase
their
storage
capacity
when
they
need
it.
A
C
No
we're
not
using
Gloucester
one
question:
I
do
have
you
know
it's
somewhat
on
topic,
but
today,
if
one
get
a
persistent
volume
in
the
persistent
volume,
let's
say
is
defined
as
50
gigs
and
right
now,
the
only
supported
sort
of
persistent
volume
until
31
was
NFS.
If
that
NFS
volume
was
to
grow
and
whomever
claimed
that
persistent
volume
needed
it
could
that
extra
storage
be
taken
advantage
of,
even
though
it
was
only
defined
as
50
gigs.
B
B
Yes
yeah,
so
so
right
now
for
shared
file,
storage,
interface
and
cluster,
that
is
a
conversation
you
can
have
with
your
storage
administrator.
So
the
way
the
year,
the
only
way
to
constrain
you
250
gigs.
If
the
storage
administrator
puts
a
quote
on
your
directory
in
NFS
or
Gloucester,
so
if
they
don't
do
that,
you
can
technically
grow
cube
or
open
shift
will
not
in
cotton,
30
and
32.
One
will
not
currently
limit
you
from
growing
beyond
what
you
originally
claimed.
If
the
administrator
has
not
put
a
quote
on
you
good.
A
Well
well,
I'm,
looking
going
once
going
twice,
I
think
that's
got
everybody
covered
thanks
Nicholas
for
those
questions
and
if
there's
other
topics
that
everyone
would
like
to
hear,
I
will
post
it
to
the
commons
mailing
list.
Oops
hair
cameras
in
one
more
see
we
can
never
give
up
on
these
questions.
How
do
we
handle
things
like
snapshots
so.
B
We're
designing
a
ploy
to
include
snapshots.
There
are
trade-offs
for
things
like
snapshots,
in
that
they
require
much
more
complex,
brick
setter
right,
so
you
have
to
thin
provision
in
lv
m
and
provide
that
to
applo.
If
you
want
it
to
support
snapshots,
but
so
applo
is
designed-
or
you
know
its
intent.
B
A
C
A
Questions,
but
I
think
it's
probably
way
out
of
scope
at
this
point.
Thank
you.
Oh
that's,
okay,
all
right!
There
we
go
going
one
two
three!
Well,
it's
the
top
of
the
hour.
Almost
that's
an
hour-long
session
Steve.
You
deserve
much
kudos
for
a
great
session.
So
thank
you
very
much
everybody
for
joining
us
and
we'll
be
back
next
week.
Last
week,
session
is
Ella
from
which
was
storage
as
a
service
or
security
as
a
service.
Rather
the
criterion.