►
Description
Have you have created and deployed an application in OpenShift and want to capture your results? Maybe you are doing analytics and want to read from a persistent data source?
Or maybe you have configured jobs that run in parallel that needs to share information? If any of these scenarios appeal to you, lets talk about STORAGE!
This talk will discuss persistent storage in OpenShift; how to configure it and best practices. It will also briefly cover some new and exciting features coming soon to make storage even better!
For the latest information on OpenShift 3.2 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
So,
hopefully,
though,
they'll
tell
us
how
to
solve
on
troubles
with
persistence
and
logistics
for
today
and
as
they're
all
open
ship
Commons
if
you'll
let
Jeff
and
Erin
do
twenty
to
thirty
minutes
of
talking
on
this
while
they're
talking,
you
can
ask
questions
in
chat
and
let's
fine
answer
them
in
chat
and
then
afterwards,
we'll
do
a
Q&A
session
in
this
hole.
If
anything,
we
have
an
hour
today,
so
I
expect.
A
This
kind
of
a
topic
will
probably
have
lots
of
questions,
so
what
I
will
do
in
the
Q&A
is
unuq
a
lot
of
you.
I'll
read
your
question:
if
you
type
it
in
chat
and
then
I'm
using
for
follow-up,
it
works
pretty
nicely
and
that
way
we
did
a
really
nice
clean
introductory
video
for
people
in
the
future
to
watch
so
without
further
ado
I'm
going
to
introduce
what
Erin
and
Jeff
introduce
themselves
and
get
started
today.
Thanks.
B
Thank
You
Diane,
so
my
name
is
Aaron
Boyd
I'm,
with
the
emerging
technologies
group
for
the
opposite
technology
for
Red
Hat
and
myself
and
Jeff
Vance.
Both
work
on
improving
persistent
storage
and
kubernetes
and
open
shift
from
a
complete
and
the
end
point
of
view,
and
that
we
are
improving
the
way
we
debug
use
and
present
storage
to
our
users
Jeff.
If
you
want
to
go
ahead
and
give
an
introduction,
I'll
start
on
the
second
slide.
After
that.
B
Hey
so
thanks
everyone
for
coming
today,
let's
go
ahead
and
get
started.
So,
as
you
know,
containers
are
ephemeral,
and
so
what
would
motivate
a
person
to
need
persistent
storage,
then,
if
they're
using
containers?
So
the
first
reason
is
that
any
local
files
running
inside
that
container
will
not
exist
outside
its
lifetime.
So
in
the
event
you've
deployed
your
application
within
OpenShift
and
running
your
container
and
producing
data
once
that
pod
terminates,
your
data
will
be
lost.
B
In
addition,
if
you're
running
jobs,
which
typically
are
done
efficiently
to
run
in
parallel,
the
pods
will
not
be
able
to
share
data
between
them
without
the
persistent
storage
enabled
to
read
from
a
location
to
share
that
data.
Also,
data
analytics,
which
is
coming
soon
and
OpenShift,
is
one
of
the
drivers
of
having
persistent
storage.
Let's
say
that
you're
running
data
analytics
on
your
logs
to
troubleshoot
a
problem
within
the
system.
B
You
would
need
to
read
from
an
existing
storage
location
in
order
to
pull
that
data
into
OpenShift,
and
then
the
last
reason
is
that,
as
kubernetes
being
a
container
tration
model
may
reschedule
nodes
as
appropriate,
with
the
with
them
coming
in
and
out
of
existence,
the
pods
could
possibly
land
on
a
separate
node
than
where
they
were
originally
scheduled.
Therefore,
you
know
we
can't
depend
on
local
storage
to
always
be
where
we
expect
it
to
be
within
the
container
infrastructure.
B
So,
with
an
open
shift,
we
offer
a
computer
experience
around
storage.
We
have
two
native
storage
platforms
that
we
offer
that
are
you
know,
tightly
coupled
and
run
well
within
Red
Hat,
both
Red
Hat,
bluster
storage
and
Red
Hat's
S
storage.
Kubernetes
includes
a
you
know
with
it
additional
volume,
security
options,
but
openshift
includes
a
lot
more
than
that.
B
There's
pre-configured
plugins
within
openshift
that
allow
us
to
run
different
cloud
providers
like
Google,
GCE
or
Amazon
EBS
as
your,
and
so
what
we
offer
is
that
when
you
deploy
open
shift
and
you
use
storage,
all
this
is
contained.
You
don't
have
to
install
any
extra
things
to
to
enable
persistent
storage.
B
So
consuming
clustered
storage,
there
are
very
two
very
specific
use
cases
when
we
talk
to
customers
and
developers
about
how
they're
going
to
use
persistent
storage.
So
the
first
one
is,
you
know,
specific
known
storage,
and
this
is
commonly
referred
to
in
the
community
as
pet
though
that
name
is
not
well
liked,
and
this
is
really
a
non
fungible
storage,
meaning
that
you
know
where
it
is.
B
You
want
to
locate
it
specifically
either
within
the
data
center
or
with
a
node
within
a
cloud
provider,
and
you
don't
just
throw
it
away
and
get
a
new
one.
You
know
you
want
this
storage
to
be
within
a
specific
location,
maybe
you're,
sharing
it
within
projects
or
teams.
You
manage
where
it's
located
and
as
given
in
the
analytics
example,
you
need
the
specific
storage
volume
in
order
to
get
that
data.
B
B
There's
also
a
second
generic
storage
nonspecific
use
case,
and
this
is
widely
used
for
testing
and,
for
you
know,
generating
results
that
may
not
be
kept,
maybe
you're
doing
streaming
analytics
and
you're
only
keeping
partial
parts
of
the
data-
and
this
is
referred
to
as
cattle
storage-
in
that
your
storage
can
be
interchanged
without
it
affecting
the
way
that
your
application
runs,
it's
usually
qualified
by
a
number
rather
than
a
name.
You
simply
are
asking
it
amend
for
some
storage.
Some.
You
know
you
don't
care
where
you
don't
care.
B
What
kind
you
just
want
storage
to
store
your
data.
At
the
moment,
it's
managed
the
same
as
normal
storage.
It's
just
not
allocated
in
the
same
thing
and
you
have
in
a
difference
to
where
it
lands
on.
So
this
would
not
be
local
storage.
This
would
not
be
emptied
your
hoster
as
part
of
the
volumes
that
are
also
included
within
kubernetes
and
it's
replicated
rather
than
backed
up.
So
it
scales
up
and
down
very
easily.
It's
not
maintained
across
each
one
of
the
nodes
and.
B
B
So
when
you
look
at
the
file
system
and
you
look
at
the
permissions
they're
the
same
way
as
if
you
were
looking
at,
you
know
an
LS
in
your
directory
on
Linux
and
the
access
is
controlled
via
the
file
level.
The
typical
POSIX
permissions
you're
comfortable
with
and
the
owner
group
and
the
underlying
storage
permissions
are
not
awkward
like
they
are
on
the
file
block.
C
So
the
the
open
shift,
kubernetes
framework
for
storage
consists
of
a
persistent
volume
and
a
persistent
volume
claim
and
we'll
go
over
the
claims
shortly.
Persistent
volume,
known
as
a
PV,
is
a
global
resource
available
to
your
OpenShift
cluster.
So
it's
not
specific
to
a
particular
project
or
a
namespace.
It
is
global
for
the
entire
cluster
and
the
ideas
that
are
persistent
volumes
that
are
defined
and
created
by
a
storage
administrator.
C
Someone
with
that
type
of
law
and
a
JSON
or
VM
file
is
what's
going
to
most
typically
define
your
persistent
volume
and
it's
defined
by
an
expert
in
that
type
of
storage.
So
they
know,
for
instance,
in
a
cluster
or
trusted
pool.
They
know
the
endpoints,
the
IP
addresses
of
each
cluster
node
for
a
Seth,
our
DB
storage.
They
know
the
secret,
they
may
they
know
the
author,
the
admin
authorization
key
and
other
features
like
that
that
a
developer
probably
wouldn't
know
they'd
have
to
ask
someone
and
it
would
slow
down
the
process.
C
But
the
storage
administration
individual
has
that
knowledge
and
they
create
the
persistent
volume
and
they
can
create
multiple
persistent
volumes
and
each
different
type
of
storage.
Like
Aaron
mentioned
OpenStack
cinder
or
AWS
NFS
cluster,
they
are
when
they
are
defined
in
the
the
PV
spec.
We
are
referencing
a
plugin
or
a
storage
adapter.
So
there's
an
NFS
plug-in.
There
is
a
Gluster
plug-in,
there's
a
step,
RTV
plug-in
and
many
more
and
many
more
being
developed
as
we
speak.
C
Okay,
so
this
is
just
a
graphic,
but
it's
basically
saying
what
I
just
said:
you've
got
in
there
kubernetes
or
open
shift
in
the
center
and
on
the
top
left
you
have
your
on-prem
storage,
plug-ins
or
adapters.
Then
on
the
bottom
or
the
right,
you
have
a
cloud
storage
and
it's
just
really
just
showing
you
a
list
of
what
we
have
today
and
that
list
is
growing.
In
fact,
we
just
merged
in
Corrine
Eddie's,
another
storage,
vendors
plug-in
yesterday.
C
So
so
it's
it's
a
dynamic
area
right
now
and
another
thing
just
so
in
case
I,
don't
pay
it
later.
Is
that
when
you
get
these
different
storage,
plugins
or
adapters
with
openshift
or
kubernetes,
you
get
them
in
the
same
single
binary.
So
so
one
open
shift
is
installed
in
your
cluster.
You
don't
have
to
install
storage,
separate
it's
it's
baked
into
it's
baked
into
openshift,
okay,
Aaron
next
slide.
C
She
knows
some
characteristics
of
that
storage
which
we'll
cover
which
we'll
cover
shortly.
You
knows
the
access
she
needs,
she
wants
read-only
access
or
she
knows
how
much
storage
she
needs.
She
needs
to
gig
and
until
she
can
claim
it
from
that
level
and
not
worry
about
the
storage
details
that
the
storage
administrator
was
concerned
about,
and
so
it's
just
the
separation
of
concerns
as
sort
of
the
motivating
factor
for
the
persistent
volume
and
volume
claim
framework
that
we
have
today.
C
If
I
wanted
to
say
anything
else,
there
no
go
ahead,
and
next
one
Aaron
I
guess
both
as
the
slides
of
dancing
Aaron
will
discover,
will
will
describe
storage
classes
and
that's
just
another
invention
that
will
allow
that
that
facilitates
the
developer,
to
discover
more
about
the
stores
that
she
needs
to
access
so
open.
So
we
talked
about
claims,
and
this
is
more
details
about
a
claim,
though
kubernetes
and
openshift
have
this
concept
of
a
persistent
volume
claim,
and
it's
just
a
request
for
storage.
That's
it
and
and
it's
it
can
be.
C
Very
generic
generic
like
I
just
want
a
gig
of
storage
and
I
need,
read
access
or
I
need
rewrite
access
or
can
be
much
more
specific.
You
can
say:
I
need,
high-speed
storage,
I
need
low-cost
storage
in
an
eastern
United,
States,
etc.
So
you
can
do
you
can
be
fairly
specific?
You
can
be
fairly
generic
or
you
can
be
a
100%
specific
which
were
we
don't
have
slides
to
cover.
C
But
you
can
really
say:
I
want
that
persistent
volume
right
there,
that's
the
one
I
need,
and
so
you
can
get
to
all
those
levels
of
abstraction
and
how
you
claim
your
storage,
you
can.
A
claim
doesn't
have
to
be
fulfilled
or
bound
to
a
persistent
volume.
If
you
don't
have
a
PV
that
matches
the
characteristics
of
your
claim.
That
claim
just
remains
in
a
pending
state,
ready
for
a
PV
to
show
up
that
will
match
what
the
claim
needs.
C
Once
that
happens,
the
claim
automatically
binds
to
the
PV
and
then
the
pod
and
the
containers
within
that
pod
can
start
running
and
again,
as
I
said,
once
a
PV
is
bound
to
a
claim
that
PV
is
unavailable
for
any
other
claims.
You
can
have
multiple
pods
within
the
same
project.
They
can
all
reference
the
same
claim,
so
you
don't
need
one
claim
per
pod
and,
as
I
said
before,
you
can
have
multiple
TVs
describing
the
same
underlying
physical
storage
and
the
next
slide.
Aaron.
C
Label
selectors,
like
I,
want
gold,
storage
or
I,
want
high
IOP,
storage,
etc,
but
right
now
we're
just
showing
I
can
name
my
claim
it
will
be
in
my
project.
I
can
describe
what
kind
of
access
I
need
and
how
much
storage
I
need.
I
create
I
click,
the
Create
button
and
I'll
see
the
next
slide.
Aaron
and
I'll
see
a
list
of
claims
that
are
available
to
me
in
my
project
and
I.
Think
this
slide
will
also
be
augmented
shortly,
where
characteristics
of
the
claim
like
I,
said
AWS
u.s.
C
is
own
east
or
something
like
that
will
also
be
visible,
but
the
top
claim
there
Oh
see
PVC
one
I'll
show
you
how
we
get
to
that
claim
in
the
next
slide.
So
that's
just
a
summary,
a
graphical
summary
of
my
claims-
and
this
slide
is
a
fragment
of
yeah
mol,
yeah,
Milland,
JSON
or
just
a
markup
language.
C
There's
a
an
open
shift
command
that
would,
let
me
create
this
pod
and
and
then
the
the
pod
will
do
its
thing,
which
I
think
we
cover
later
it
basically,
but
for
our
storage
goes,
the
pod
will
be
scheduled
on
one
of
the
nodes
in
my
open
ship
cluster
and
then
part
of
the
pod
startup
process
will
be
to
do
the
to
run
the
storage,
adapter
or
the
plug-in,
and
that
plug-in
will
attach
a
volume
form
at
the
volume.
If
that's
needed,
mount
the
volume
on
the
host
that
the
pot
is
running
on
automatically.
C
B
So,
thank
you,
jess
for
covering
mm-hmm.
You
know
what
the
framework
for
persistent
volume,
persistent
volume
claims
looks
like.
We
leverage
this
foundation
of
the
framework
for
using
persistent
volumes
and
vents
their
claims.
We
have
added
some
rich
features
to
enabled
storage
to
be
even
easier,
as
you
noticed
in
the
previous
slides,
it's
a
little
bit
intensive
for
both
the
administrator
and
the
user
to
create
the
claims.
B
Even
though
we've
created
a
UI,
there
still
is
a
usability
issue
in
that
a
user
should
just
be
able
to
say,
I
want
storage
and
if
it
doesn't
exist,
please
go
off
and
create
it
for
me,
and
so
a
feature
that
was
integrated
in
3.1
as
an
alpha
feature
and
in
3.3
will
be
further.
Enhanced
is
called
dynamic,
provisioning
and
basically,
this
allows
the
user
the
developer
to
dynamically
ask
for
storage
to
be
provisioned
on
demand
if
they
have
the
permissions
to
invoke
a
provision
err.
B
Another
feature
that
Jeff
was
alluding
to
was
called
storage
classes
and
storage
classes
is
really
you
can
think
about.
It
is
a
quality
of
service
that
you're
offering
to
your
users,
so
an
administrator
again
goes
off
and
configures
different
levels
of
storage,
creating
a
taxonomy
of
what
the
storage
should
look
like.
So
they
may
have
you
know,
stuff
or
fiber,
I,
scuzzy
and
different
labels
associated
with
that
type
of
storage.
Your
fast
storage
might
be
gold
storage,
in
that
it's
the
most
premium
storage,
that
a
user
can
request.
B
Your
fiber
might
be
a
little
bit
slower
or
less
capacity,
therefore,
having
silver
and
then
bronze
might
be
your
I
scuzzy.
The
administrator
can
put
different
features
within
these
classes
to
allow
a
user
to
just
select
a
level
of
service,
with
an
expectation
that
they're
going
to
have
and
it's
kind
of
a
recipe.
So
there's
many
different
aspects
within
that
label
that
the
administrator
can
also
assign.
B
Therefore,
the
developer,
instead
of
making
a
claim,
actually
uses
what
will
be
a
new
API
API
object,
called
storage
class
to
request
this
storage
and
it
will
allow
us
to
better
organize
the
classes
into
a
catalog,
so
a
user
can
search
for
what
they're
looking
for,
because,
typically
the
idea
of
kubernetes
and
storage
is
that
the
user
doesn't
have
to
know
much
about
it.
They
can
just
simply
request
it.
So
storage
classes
offers
another
level
of
abstraction
with
a
little
better
description
of
what
they
need,
depending
on
their
applications.
B
Once
the
last
feature
that
will
be
in
the
next
release
of
openshift
is
called
a
storage
selector.
So
a
storage
selector
allows
an
administrator
to
create
labels
which
are
intrinsic
to
kubernetes
on
the
storage,
to
give
it
define
better
the
characteristics
of
that
storage.
In
this
example,
I
have
here,
we
have
two
different
persistent
volumes
in
AWS
EBS.
We
have
one
in
the
availability
zone
of
east
and
the
other
in
the
availability
zone
of
west.
The
user
may
care
about
this
depending
on
latency
within
their
application,
or
maybe
they
have
Co.
B
You
know,
applications
that
exist
in
that
same
geography.
So
they
care
about
this
specific
label
they're
less
concerned
with
a
certain
quality
of
service
and
they're
more
concerned
about
a
specific
feature
of
that
storage
storage.
Selectors
allow
the
user,
within
their
claim,
request
to
request
a
specific
label
of
that
selector.
So,
within
the
claim
request
is
Jeff
showed
earlier
the
the
snippet.
We
can
then
add
a
selector
column
and
then
we
can
put
in
a
claim
request
and
have
it
match
us
east
one,
and
then
we
are
matched
to
that
specific
PV.
B
The
last
feature
that
I
want
to
talk
about
is
a
pretty
exciting
one
that
has
just
been
released,
and
this
is
container
native
storage
solution.
You
referred
to
as
a
flow
within
openshift,
which
is
the
the
Klingon
word
for
contain.
What
this
is
allowed
is
us
to
actually
run
Gluster
FS
in
a
containerized
manner.
This
allows
us
to
scale
out
storage
cluster
very
rapidly.
It
also
allows
us
to
contain
better
the
security
around
that
and
has
much
more
control
and
ease
for
the
developer.
B
We
have
created
a
way
of
orchestrating
this
through
Sacchetti,
also
an
open-source
project,
and
it
has
a
full
integration
with
open
chest
container
platform.
So
this
is
an
exciting
and
new
feature
for
Red
Hat,
and
it's
also
a
very
new
concept
within
the
community
across
the
board
in
containers
to
have
this
type
of
storage
available.
B
C
Yeah,
just
a
1-up
piggybacking.
One
other
thing
on
error:
Erin's
comment:
one
of
the
neat
things
about
the
cluster
containerized
cluster
is
that
it
you
now
don't
need
to
worry
you
don't
you
can
have
your
Gluster
cluster
can
be
completely
separate,
like
you
probably
have
today,
or
it
can
be
combined
with
your
OpenShift
cluster,
which
they
call
converged,
storage
and
share
the
same
notes
that
your
openshift
cluster
is
using,
but
anyway
with
red
hats,
emphasis
on
enterprise
needs
and
satisfying
requirements
for
enterprise
customers.
C
It's
not
surprising
that
security
matters,
and
it's
also
typical
that
in
the
upstream
community
mindset,
security
is
often
bolted
on
or
thought
of
later
it's
just
future
future
future
and
we
worry
about
security
later,
but
OpenShift
and
Red
Hat
doesn't
quite
think
that
way.
Security
is
important
and
we
try
to
get
it
baked
in
correctly
upfront
and
so
storage
has
purity
concerns.
C
Obviously,
you
need
to
be
able
to
allow
applications
access
to
the
storage
that
they
need
and
at
the
same
time,
you
need
to
prevent
other
users
applications
processes
from
gaining
access
to
storage
that
you're
trying
to
keep
them
away
from,
and
so
we
try
to
handle
all
those
requirements
within
openshift
storage
and
of
course,
we
support.
Selinux
and
you'll
see
more
details
about
that.
In
the
next
slide,
we
support
POSIX
permissions
and
and
there's
some
differences
between
block
and
shared
devices
and
how
that's
done
go
ahead.
Aaron.
C
Security
contract
context,
constraints
and
it's
a
very
rich
set
of
features
and
descriptors
that
confine
what
a
pod
can
do
just
are
a
gateway
to
whether
the
pod
can
even
be
created
or
not,
and
once
a
pot
is
created.
What
is
that
pot
allowed
to
do?
What's
the
pod
prevent
it
from
doing
so?
We
have
admission
controller,
we
have
authorization,
we
have
the
concept
of
roles
and
users
and
groups
and
projects
kubernetes
doesn't
even
have
the
concept
of
a
user.
Yet
they
do
have.
C
C
C
I'm
just
waiting
for
it
to
refresh
on
my
screen,
so
in
su
Linux,
you
can
see
the
bulleted
list.
These
are
the
storage,
plugins
or
adapters
that
are
SELinux
aware
at
the
very
bottom
of
this
slide.
You
can
just
see
a
fragment
of
y
Amal,
which
has
security
context
attribute,
and
it
shows
SELinux
options
and
that's
just
the
most
common
option
is
the
level
there,
but
you
can.
You
can
describe
a
user,
you
can
describe
walls,
you
can
just
bride
types
and
those
are
all
make
up
the
SELinux
option
portion
of
the
security
context.
C
As
I
said,
the
plugins
you
see,
bulleted
they're
those
support,
SELinux
and
those
plugins
happen
to
be
or
block
storage
and-
and
you
know
what
that
means
now
and
what
we
do
for
selinux,
and
we
also
do
it
for
group
IDs
as
you'll.
See
soon
is
we
re
label
the
storage
we
take
it
over
and
the
storage
mount
point
on
the
host
is
the
connector
point
and
that
directory
in
all
directories
and
files
under
it
are
relabeled
with
the
SELinux
label.
That's
provided
in
in
the
pod.
C
Now
the
pod
author
doesn't
need
to
know
what
that
SELinux
label
looks
like
that,
could
be
defaulted
for
her
by
OpenShift
through
the
security
context
constraints.
So
those
constraints
say
hey.
If
whether
or
not
you
can
even
define
a
security
attribute
in
your
pod
and
if
you
can,
what
range
you're
allowed?
What's
legal?
What's
not
legal
and
if
you're
not
allowed
to,
then
the
security
context
constraint
will
define
a
default
value
for
you.
So
the
developer
doesn't
need
to
worry
about
those
things.
These
clustered,
minister,
can
be
the
one
concerned
with
security.
C
It's
just
POSIX
permissions,
essentially
and
again,
just
like
with
SELinux
it
OpenShift,
the
SCC,
the
security
context
constraint,
is
the
arbitrator
and
decides
whether
you
can
define
your
own
group
ID.
What
values
are
legal,
what
the
default
is,
if
you
don't
define
it,
and
in
this
case
we
just
have
an
idea
of
one
two,
three
four,
but
it
could
be
it's
an
array.
It
can
be
a
list
of
IDs
and
this
is
for
shared
storage.
So
we
don't
take
over
shared
storage.
C
So
we
call
that
taking
over
storage-
and
it's
only
applies
to
these
plugins
and
they
are
all
they
are
block.
Storage
plugins.
Never
do
it
for
shared
storage,
Aaron,
I.
Think
the
next
slide
is
just
our
generic
question
and
answer
slide.
So
I
think
that
marks
the
end
of
our
formal
presentation
and
we're
both
ready
to
answer
questions
that
you
may
have
all.
A
A
C
A
C
The
piece
isn't
something
that
changes
in
real
time
as
your
pod
or
application
chugs
around
through
storage
and
say,
creates
a
pens
to
a
file
and
makes
it
larger
and
larger
starts
consuming
storage.
A
pee,
a
PVC,
does
doesn't
have
that
purpose.
Now,
Aaron
may
have
more
experience
in
the
in
the
in
the
open
shift
console
to
know
what
metrics
might
be
exposed.
That
would
show
you
so
kubernetes.
C
B
And
just
add
all
that
that
is
accurate
in
the
console.
You
can
see
how
much
you
requested
and
actually
how
much
within
the
PV
that
is
bound
to.
But
you
know
you
can't
do
a
DF
or
anything
on
the
PV
C
to
see
you
know
how
much
space
you've
actually
consumed
against
what
you've
asked
for.
So
that
is,
you
know,
being
tuned
as
we
speak,
but
today
that
capability
doesn't
exist.
C
Yeah
I
see
four
ak's
question,
which
is
a
good
one:
it's
if
a
PV
is
created
with
ten
gig,
but
the
claim
is
only
five
gig
and
there's
a
one-to-one
mapping,
so
that
PV
is
not
available.
Any
other
claims.
What
happened
to
the
remaining
5
gig?
That
was
we're
defined
in
the
PV.
So
it's
important
to
know
and
I
should
have
said
this
I
forgot
that
when
we
define
a
PV
today-
and
we
say
it's
a
10
gig
PV
and
it's
read-only-
they
that's
its
access
modes.
C
It's
natural
to
think
that
there's
some
enforcement
going
on
by
kubernetes
or
OpenShift
to
make
sure
that
the
underlying
storage
really
has
10
gig
and
that
we
don't
use
more
than
the
10
gig.
And
then
you,
if
you
think
that
way,
then
you
also
feel
a
claim.
That's
only
asking
for
half
of
it
has
wasted
storage,
but
it
turns
out.
That's
not
true.
The
the
aaron
maybe
can
can
fill
you
in
more
on
quota.
C
B
So
with
the
idea
of
storage
classes
and
storage,
selectors
is
the
ability
for
the
admin
to
have
the
AI
ops
defined
as
part
of
that
tax
hominid,
and
then
the
user
be
able
to
claim
against
that.
There
isn't
a
plan
right
now
to
be
able
to
change
the
characteristics
of
the
storages
being
used.
It's
just
to
properly
expose
what
is
set
at
at
the
time.
B
Currently,
actually,
our
team
is
looking
at
storage
security.
We
have
a
lot
of
different
considerations
to
take
into
mind,
with
consensus
within
the
community
has
not
been
reached
as
to
how
we
handle
the
security.
We
would
certainly
entertain
that
possibility.
We're
looking
at
you
know
how
to
properly
expose
Ackles
and
keep
those
down
as
well
as
looking
at
you
know,
things
like
key
cloak,
but
today
that
hasn't
been
firmed
up.
It'll,
probably
be
one
or
two
versions
down
in
openshift
before
we
have
anything
not
sophisticated.
A
C
D
Yeah,
actually,
my
question
is,
for
example,
let's
say
we
have
one
PV
which
is
currently
used
by
a
specific
project
and
that
project
hash,
told
us
I
mean
the
ports
which
are
requested
to
that
project.
Hash
tore
some
data
in
it,
so
the
project
has
been
decommissioned
now
and
the
PV
has
been
recycled.
So
after
some
days,
I
want
to
recover
that
data
which
has
been
created
by
previous
ports
in
the
project.
So
is
it
possible
for
recycling
that
PV?
Is
it
possible
to
recover
that
data.
D
D
B
Versions,
there's
already
been
APR
submitted
about
six
months
ago
to
deprecated
the
recycling
capability,
just
because
it
leaves
open
the
possibility
of
something
like
this.
If
you
you,
the
TV
and
you've
said
it
to
recycle
and
it's
been
set
aside
and
waiting
for
delete.
You
know
you're
opening
up
the
possibility
of
someone,
possibly
claiming
that
volume
before
the
date
has
been
deleted
and
reading
it.
So
recycling
is
only
supported,
I
believe
in
cinder
and
NFS
today
and
that
feature
will
actually
be
phased
out.
You
know
over
the
next
six
months.
D
A
C
Erin
alluded
to
it,
and
it's
important
is
that
we
have
to
be
careful
and
openshift
when
we're
talking
about
storage
and
the
end
of
access,
the
end
of
the
claim
or
the
end
of
the
pods
access
that
if
it's
protected
storage
that
no
other
claim
and
pod
can
come
along
there
and
start
reading
it
and
at
the
same
time,
open
shift
has
to
be
very
wary
of
doing
an
RM
dash
RF
on
storage
to
clean
it
up.
Right,
certainly,
don't
want
make
a
mistake
in
executing
that
kind
of
command.
C
So
there's
a
balancing
act
that
we
have
to
do
and
in
terms
of
this
gorge
and
that's
one
of
the
reasons
for
recycling
being
deprecated.
It's
a
dangerous
and
potentially
heir
prone
retention
policy
and
there's
a
risk
of
not
only
having
the
timing
windows
where
someone
can
gain
access.
The
storage
that
they
shouldn't
there's
also
the
possibility
of
removing
stores
that
shouldn't
have
been
removed.
A
B
I
think
what
Jeff
had
alluded
to
earlier
in
here
is
that
you
know
currently
snapshots
are
not
supported.
It
is
a
PR
that
is
active
in
the
community
and
being
worked
outside
of
RedHat
that
today
we
we
don't
offer
snapshots
and,
most
generally,
if
you
use
a
storage
provider
from
a
hat
like
like
Gluster,
you
have
replication
so
you're
facilitating
you
know
the
backup
and
retention
of
it
through
through
those
means,
but
I
think
your
question
probably
is
around
snapshotting
and
that's
coming
in
future
releases.