►
From YouTube: OCB: AMA on Rook - Travis Nelson (Red Hat) and guests
Description
Rook, an open source cloud native storage orchestrator for Kubernetes, was the first storage project accepted into CNCF back in January 2018. Rook provides the platform, framework, and support for a diverse set of storage solutions to natively integrate with cloud-native environments.
Rook turns storage software into self-managing, self-scaling, and self-healing storage services. It does this by automating deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management. Rook uses the facilities provided by the underlying cloud-native container management, scheduling and orchestration platform to perform its duties.
In this Commons Briefing, we'll get an intro and update on Rook from Travis Nielsen and have an open live Q/A session with Travis and other members of the Rook Community.
A
All
right,
everybody
welcome
back
to
the
openshift
commons
and
today,
as
we
want
to
do
on
mondays,
we're
going
to
have
an
upstream
deep
dive.
Ama
ask
me
anything
session
with
the
rook
ceph
folks,
travis
nelson
sebastian,
han
annette
clewett
are
here
with
us,
there's
a
number
of
other
folks
joining
in
as
well.
What
we're
gonna
do
is
have
them.
B
D
B
B
It
is
driven
by
the
community
and
community
is
is
first
for
us.
It
is
a
collection
of
separators
for
kubernetes,
we'll
talk
about
more
what
that
means,
but
basically,
if
in
kubernetes
we
express
things
as
desired
state,
we
want
things
to
be
configured
in
our
kubernetes
cluster
and
the
operator
is
the
way
that
that
you
get
that
done.
B
It
manages
the
deployment
of
your
of
your
project,
so
in
this
case
today,
what
we're
going
to
dive
into
is
how
rook
automates
management
of
the
ceph
storage,
software-defined
storage,
so
rook
as
the
operator
manages
how
to
deploy
the
ceph
storage
layer,
it
configures
it
for
you.
It
manages
things
like
upgrades
for
you
and
yep.
B
Now,
let's
get
into
kind
of
overall
project
status
before
we
dive
into
architecture.
So
the
the
work
project
has
been
a
cncf
incubating
project
for
about
the
past
two
years.
Now
we're
excited
that
we
are
in
the
graduation
voting
phase
now
so
any
day.
Now
we're
hoping
to
get
more
votes
and
just
finish
off
this,
this
graduation
process
we've
completed
security
reviews
and
hopefully
crossed
all
the
teas
and
died
all
the
eyes
to
to
really
to
be
the
first
storage
project.
That's
graduated
in
the
cncf,
but
we're
excited.
B
B
You
know
we're
going
on
300,
unique
contributors
to
the
project.
Of
course,
not
all
of
those
are
are
active
on
an
ongoing
basis,
but
over
time
it's
just
been
a
great
testament
to
the
community
driven
nature
of
of
the
product
on
the
project,
all
right
so
I'll
hand
it
off
to
annette
for
the
next
few
slides.
E
E
E
It
is
able
to
support
multiple
types
of
volume,
types
and
and
the
software
defines
storage
part.
Essentially
because
it's
an
abstraction,
it's
software,
you
all
that
it
really
needs
to
support.
All
of
these
different
types
of
block
file
object
is,
is
really
raw
block
devices.
So
you,
the
actual
storage
backing
stuff,
is
a
raw
block
device.
It
could
be
an
nvme
drive,
it
could
be
a
ssc,
it
could
be
a
ebs-2
volume,
it
could
be
an
azure
volume,
it
could
be
a
vmware,
it
could
be
a
pass-through
disk
and
vmware
or
vmdk.
E
E
What?
What
are
some
of
the
ways
that
we
can
use
these
different
kinds
of
volumes?
So
the
first
is
with
block
volumes.
Until
recently
we
we
really
would
say
that
they
could
only
support,
read,
write
one
types,
applications
and
and
they're
very
superior
for
supporting
database,
transactional
databases
and
other
kinds
of
applications.
E
This
is
what
we
call
open,
openshift
vert
used
to
be
called
cnv
and
what's
nice
is
when
we
use
block
volumes
from
from
stuff
for
the
image
storage,
we
we
actually
have
a
volume
type
rwx
read,
write
many
on
that
which
allows
live
migration
of
the
vms.
This
is
really
currently
downstream.
This
is
the
only
use
of
rwx
for
block
volumes,
but
it's
it's.
E
This
exposes
object,
storage
and
again
this
has
been
part
of
stuff
for
quite
a
long
time
our
rw
rgw
radio's
gateway.
Excuse
me
the
raido's
gateway
service,
and
this
allows
really
any
s3
compatible
applications
and
whether
they
those
applications
reside
in
openshift
or
outside
of
openshift
to
to
retrieve
and
store
objects
into
stuff.
So
again
you
know
these.
These
are
the
reasons
that
we
do
all
this
is
to
be
able
to
have
all
of
these
types
of
services.
E
B
That's
yeah
thanks
and
then
so
now
we're
planning
on
driving
diving
into
the
architecture
to
show
at
the
next
level
what
we're
talking
about
to
get
started.
You
know
when
talking
about
openshift
and
kubernetes,
it's
really
a
whole
new
set
of
terminology,
so
just
to
cover
basic
definitions
here,
an
operator.
B
B
Okay.
Crd
is
a
custom
resource
definition.
This
is
the
extensibility
mechanism
that
kubernetes
has
defined
in
their
api
to
allow
us
to
plug
in
our
own
types.
So,
for
example,
with
rook
we've
defined
all
the
types
we
need
to
drive
the
storage,
and
so
the
crd
is
just
a
high
level
definition.
A
cr
is
basically
one
instance
or
one
object
of
that
resource
that
conforms
to
the
crd
and
now
getting
into
some
of
the
kubernetes
storage
terminology.
B
A
storage
class
is
a
definition
of
storage
that,
where
you
can
request
storage
from
it,
this
is
not
unique
to
rook
or
or
seth.
It's
a
general.
You
know
any
any
storage
plugging
into
kubernetes
uses
a
storage
class
along
with
that
a
pvc
purpose,
persistent
volume
claim
is
the
way
you
attach
your
storage
to
a
pod
and
then
the
pod
is
a
group
of
containers.
That's
running
your
software
managed
by
kubernetes
with
that
you
know
with
when
we
got
started
on
the
rook
project.
B
B
You
know
you
have
to
hire
someone
really
to
deploy
stuff,
and
so
we
wanted
to
simplify
that
problem
and
make
it
a
natural
and
integrated
part
of
the
kubernetes
ecosystem.
Well,
that's
where
rook
was
born.
Rook's
job
is
to
deploy
the
management
or
own.
The
management
of
seth
seth
has
the
storage
layer.
It's
a
long,
proven
storage
stack.
We
don't
want
to
rewrite
storage.
Every
time
you
have
a
new
platform
like
kubernetes.
B
B
B
So
on
one
node
we
might
have
the
rook
operator
running
as
a
pod,
and
the
operator
also
starts
up
some
other
rook
demons.
We
call
these
discovery
demons,
so
there's
discovery,
demon
whoops
go
back
here,
running
on
every
node
and
what
it
does
is
it
goes
out
and
discovers.
What's
my
hardware
inventory,
what
what
devices
do
I
have
locally
on
each
node?
B
So
rook
rook
owns
deploying
those
those
pods
brook
knows
how
to
start
up
the
ceph
monitors
and
the
osds
and
all
these
different
demons
in
a
way
that
you
don't
have
to
worry
about.
All
of
the
all
the
details
of
how
to
run
the
storage
work.
Does
that
for
you
automates
it
and
connect
attaches
it
to
the
local
storage.
B
B
So
let's
say
you
have
an
an
application
here
on
the
left
that
needs
block
storage,
so
it
needs
to
mount
a
volume.
What
it
does
is
you
define
in
your
application,
a
pvc
or
a
persistent
volume
claim
and
with
block
storage?
Usually
that's
going
to
be
a
read,
write
once
volume
which
says
give
me
a
volume,
I'm
the
only
one
that
can
read
and
write
to
it.
B
B
So
I
get,
I
define
my
claim,
which
asks
the
storage
class
for
an
rbd
volume
which
then,
through
the
kubernetes
storage
infrastructure,
asks
the
csi
driver
for
the
rbd
volume.
That
volume
is
provisioned
it's
and
then
it's
mounted
in
your
in
your
pod,
and
you
now
have
access
to
read
and
write
that
storage.
Okay.
So
that's
that's
a
basic
block
volume
for
your
application
in
the
next
section
here,
we've
got
well
what,
if
you're,
what
if
you
have
two
applications
that
need
to
share
storage
you've
got
two,
maybe
two
or
more
readers
and
writers.
B
They
request
the
storage
class
now
from
a
different
driver.
So
this
ffs
driver
allows
you
to
have
multiple
revision
writers
and
then
the
set
does
ffs
csi
driver
provisions
and
allows
you
to
mount
that
volume
in
multiple
buttons
and
then
the
final
type
of
storage,
we're
talking
about
is
object.
Storage,
where
you
know
as
you've,
got
an
s3
endpoint
that
seth
provides
with
rgw,
where
you've
got
a
bucket.
B
B
That
gives
you
that
creates
the
bucket
and
allows
you
to
access
it
from
your
pods
in
your
your
application
points
and
that
rounds
up
the
the
three
different
types
of
storage
for
the
csi
driver.
Okay,
then
the
final
layer,
you
know
how
does
after
you've
got
your
storage
available,
it's
all
mounted
from
the
csi
driver.
B
B
Is
it's
mounted
through,
or
it's
already
been
mounted
with
the
csi
driver
and
when
you're
reading
right
to
the
seth
cluster,
now
there's
an
rbd
kernel
driver
that
then
connects
to
all
of
the
seth
demons
and
of
course
you
don't
even
have
to
think
about
how
that
works.
Seth
handles
all
of
the
connection
to
the
mons
and
osds
and
all
those
daemons
to
read
and
write
to
the
data.
E
B
So
there's
no
there's
no
corruption
of
the
data
that
gives
you
the
at
that
layer
and
then
finally,
the
object
or
s3
endpoint
uses
an
s3
client
just
like
it
would
for
any
or
whether
it's
running
in
the
cloud
with
amazon,
s3
or
now
with
ceph,
we
have
the
the
endpoint
provided
through
rgw,
so
your
sg
client
connects
to
the
rgw
endpoint
and
seth
and
gives
you
that
okay,
so
those
are
the
three
layers
to
think
about
in
rook.
So
what
does
it
take
to
get
started?
B
You
know
we
want
to
make
it
as
easy
as
possible
to
deploy
this
storage,
so
we've
done
our
best
to
make
it
to
make
it
easy
easy.
Maybe
an
overstatement
storage
is
never
easy,
but
we
hope
it's
simple
enough
to
get
started.
There
are
the
other
way
you
define
things
in
openshift
is
through
manifests
or
yaml
files.
Okay,
so
there
are
three
ammo
files.
If
you
create
these,
then
basically
you'll
have
a
rook
and
ceph
cluster
up
and
running
in
minutes.
B
So
you
have
common.yaml
that
defines
your
rbac
settings
which
are
back
is
what
controls
control
security
settings
in
openshift.
Okay,
then
you
create
the
operator
with
operator.yaml.
Of
course
it's
just
a
simple
deployment.
It
starts
up
a
single
pod
that
will
manage
this
f
cluster
and
then,
finally,
you
create
the
seth
cluster
custom
resource,
which
is
this
type
that
we've
defined
purely
for
rook
and
ceph
to
manage
the
cluster
now
on
the
right
here.
What
we've
got
is
a
an
example.
B
Yaml
extract,
there's
a
lot
more
settings
than
you
see
here.
This
is
just
to
get
started,
but
basically
you
can
do
things
like
say
well,
what
version
of
ceph
do
I
want
to
deploy
in
this
case?
That's
the
latest
latest
octopus
version
15.2.4,
then
how
many
mods
do
I
want
three
is
the
usual
number
and
then
how
do
I
want
to
deploy
the
storage
using
all
nodes
and
devices?
B
And
there
are
ways
to
do
that,
but
that
gets
a
basic
cluster
started
and
once
the
basic
cluster
started
now,
of
course,
your
storage
needs
to
consume
it.
So
your
admin
needs
to
define
a
storage
class
and
then
your
application
creates
your
pvc
and
starts
up
this
example
on
the
right
is
what
your,
what
a
simple
application,
pod
definition,
might
look
like.
B
As
far
as
defining
a
pvc
which
is
claiming
from
the
rbd
storage
class
yup,
we
don't
want
to
get
caught
up
on
that
yellow
too
much.
So
we'll
continue
now
when
deploying
rook.
The
next
question
is,
you
might
ask.
Well,
I've
got
my
environment,
that's
so
much
different
from
this
other
environment.
Maybe
I'm
running
in
the
cloud.
Maybe
I'm
running
in
my
data
center.
B
B
Primarily,
people
are
going
to
be
using
it
in
either
bare
metal
clusters
where
they
just
there
is
no
other
option
for
for
software
to
find
storage
like
if
I'm
running
on
bare
metal,
I
don't
have
amazon
ebs
right,
there's
just
so.
I
need
seph
to
provide
me
that
storage,
but
there
are
also
scenarios
for
running
rook
in
the
cloud
which
we'll
talk
more
about.
B
As
you
think
about
your
clusters
and
the
topology
you've
got
you
with
storage,
you
really
have
to
worry
about
failure
domains.
You
want
to
make
sure
your
data
is
highly
available.
It's
durable
and
there
are
ways
to
distribute
the
staff
demons
across
the
cluster
to
make
sure
the
the
failure
domains
are
handled
properly
and
we've
done
a
good
job.
I
think
of
making
that
simple,
so
you
just
have
to
define
a
few
attributes
either
on
the
nodes
or
labels
on
the
nodes.
B
B
F
B
B
B
Next
of
all
the
you
know
you
there
may
be
shortcomings
of
the
cloud
provider.
Storage.
Some
common
ones
are
that
storage
are
is
limited
to
within
an
az,
maybe
there's
slow
failover
times,
and
you
want
failover
time
of
seconds.
Instead
of
minutes,
cloud
providers
have
limitations
on
a
number
of
pvs
per
node.
B
I've
heard
of
at
least
one
one
or
two
of
them
that
have
limits
of
say,
30
pvs
per
node,
which
is
you
know,
which
can
be
really
limiting.
If
you
have
a
lot
of
small
applications
and
then
also
in
cloud
providers,
when
you
request
small
volumes,
you
get
proof
characteristics
of
a
small
volume
and
it's
going
to
going
to
run
slower
with
rook.
B
And
then,
finally,
when
you're
running
in
the
cloud,
the
the
cef
demons
that
need
require
persistence,
the
monitors
and
osts
they
can
be
backed
by
pvcs
like
I
was
saying
earlier,
no
need
to
access
for
direct
local
devices.
You
can
theft
and
rook
can
request
that
storage.
It
just
makes
the
deployment
that
much
simpler.
C
B
C
Get
yeah,
I
think
so.
The
first
one
is
basically
asking
to
go
back
to
the
slide
where
we
have
the
architecture
layout
of
all
how
the
set
demons
are
basically
deployed,
and
I
think
it's
looking
for
the
verification
here
yeah.
I
think
this
which
one
another
one
with
no
no,
no
layer,
one
get
this
one
yeah.
C
F
F
B
B
C
F
Sure,
if
you
have
multi-node
self-deployment
inside
communities
in
this
cluster,
imagine
a
pod
based
on
the
worker
node
one
by
getting
attached
to
a
block
storage
on
another
node.
Does
that
provide
or
root
provides
any
intelligence
to
pick
up
the
right
closest
that
can
obviously
node
for
lower
lower
latency.
C
C
F
C
F
In
in
this
presentation
the
channel
mentioned,
we
can
replace
local
node
storage
as
the
blob
storage
with
seth.
It
is
perfect
yeah,
but
the
value
of
local
node
storage
is
low,
latency
and
high
items,
because
local
node
storage
is
usually
nvmes
and
so
on
and
so
forth.
If
you're
going
to
swap
them
out,
you
better
offer
similar
capabilities
by
user
ios
and
latency.
Don't
you
think.
C
B
You
yeah
sure,
and
just
to
add
to
that
you
know
I
it's
definitely
a
different
scenario
where,
if
you
really
need
local
storage
high
high
iops
and
if
you
have
replication
at
the
apple
application
layer
like
if
your
cassandra
database
is
replicating
at
its
layer
and
you
don't
need
the
locals
or
staff
to
replicate
the
data
for
you,
then
then
step
it.
You
know
it
isn't
going
to
be
the
right
answer.
You
should
just
use
a
local
device
and
you
get
all
the
local
it's
of
that
performance.
B
B
C
C
E
C
C
So
this
is
essentially
what
you
get
when
you
use
rook
through
that
bucket
interface,
and
although
again
you,
I
think
you
can
also
argue
that
you
could
use
straight
s3
at
this
point,
but
I
think
we
also
have
to
see
it
from
the
perspective
of
the
overall
experience.
From
that
back
end.
You
can
not
only
do
object,
but
you
can
do
files
and
block
so
because
you
get
everything.
It's
probably
easier
to
manage
this
entire
storage
interfaces
through
a
single
storage
entity.
C
Yeah,
I
think
there
is
one
more
so
the
last
question
is:
is
there?
Is
there
any
ability
to
run
a
back-end
network
for
cluster
replication
in
front-end
replication?
So
I'm
going
to
touch
that
on
the
next
slide.
So
essentially
the
answer
is
yes,
we
can
segregate
the
storage
network
from
the
client
one
and
I
think
we're
gonna
see.
I
think
it's
a
good
segue
to
actually
start
discussing
the
key
features
for
for
rook.
C
C
Typically,
when
we
think
about
upgrades,
you
always
think
about
this
painful,
maybe
long-lasting
process
where
you
just
don't
know
what
in
which
areas
you're
going
to
end
up
to
and
it's
it
is
non-trivial
most
of
the
time.
But
it's
yet.
I
guess
another
beauty
of
the
operative
world
is
because
we
have
embedded
all
of
that
operational
logic
into
a
logical
entity.
So,
basically
an
operator,
then
we
just
basically
aggregatedly
aggregated
years
of
experience
to
run
upgrades
over
any
any
versions
of
staff,
and
now
what
we
have
today
is
actually
really
smooth.
C
So
we
have
what
we
have
to
differentiate.
Here
is
two
types
of
upgrades,
so
the
first
one
is
the
object
of
rook
itself,
so
the
upgrade
of
the
the
operator
and
the
upgrade
of
the
europe
operator
is
almost
as
simple
as
changing
the
image
in
the
spec,
as
well
as
following
following
some
upgrade
steps
in
the
documentation
guide.
C
Cluster
cr
specification
at
this
point
once
rook
intercepts
that
cr
update
and
it
realizes
that
it
is
a
new
stat
version,
it
will
simply
go
ahead
and
upgrade
the
cluster.
It
will
upgrade
nodes
by
nodes
disks
by
disks
and
always
make
sure
in
between
that
everything
is
healthy
and
will
proceed
with
the
upgrade.
C
Essentially
it
is
a
connector
just
like
travis
mentioned
earlier.
That
allows
you
to
provide
persistent
storage
to
your
containers
with
the
newest
release
of
rook
1.4.
We
have
implemented
and
integrated
the
three
other
spec
actually
self-csi
implemented.
The
3.0
csi
spec
and
rook
has
integrated
that
new
csi
version
in
its
engine.
And
again
you
can
see
that
we
support
whether
we,
whether
you
do
block
storage
or
or
file
system,
we
support
all
the
dynamic
provisioning
storage
interfaces
and
access
methods
like
rw
or
wx,
and
rocks.
C
What's
new
with
that
particular
3o
release
is
snapshots
and
cloning,
so
this
is
a
functionality
that
has
been
around
in
ceph
for
for
years
now,
but
kubernetes
just
started
to
surface
those
volumes
capabilities
and
we
we
have
early
support
for
that,
because
rook
supports
a
wide
range
of
kubernetes
versions.
We
continue
to
support
flex
driver,
so
it
is
more
in
the
maintenance
mode.
You
can
still
use
it,
but
obviously
it
is
highly
encouraged
to
to
go
with
the
step.
Csi
driver.
B
C
Please,
external
cluster
connection,
because
not
everything
is
always
green
field,
but
most
of
the
users
have
existing
subclusters
that
they
might
have
deployed
with
puppet
or
ansible
or
manually.
Maybe,
and
they
still
want
to
consume
it
or
maybe
something
else
is
already
consuming
it.
Maybe
they
use
openstack,
and
this
existing
subcluster
is
backing
openstack
for
block
storage,
but
they
now
have
a
use
case
where
they
are
starting
to.
C
They
have
started
to
run
applications
in
kubernetes,
so
they
really
want
to
take
advantage
of
that
cloud
native
experience,
but
they
don't
really
have
to
redeploy
a
new
sap
cluster
within
kubernetes
with
rook.
So
at
this
point
what
they
can
do
is
still
use
rook
and
csi,
but
rook
at
this
point
will
be
more
in
a
consumer
relationship,
consumer
producer
relationship
where
rook
only
connects
to
an
external
cluster
and
does
not
do
any
management
whatsoever.
C
Along
with
that,
we
have
helper
script
to
inject
the
right
metadata
in
the
communities,
environment
and
once
rook
sees
those
secrets
and
config
maps,
then
it
will
go
ahead
and
bootstrap
the
connection
that
is
basically
simple
as
this
as
an
extension
of
this.
Not
only
you
can
consume
block
and
file
system
resources
from
an
external
subcluster,
but
you
can
also
consume
object,
store,
object,
storage,
so
by
passing
an
endpoint
you
have
runner's
gateways
running,
they
might
be
running
independently,
but
most
likely
they're
running
beside
a
load
balancer.
E
C
Will
allow
you
to
consume
the
bucket
interface,
so
you
can
claim
for
bucket
and
as
for
users
and
credentials
still
along
with
that,
we
we
have
really
nice
capabilities
with
prometheus
incubators
and
one
of
the
use
cases
we
we
might
have
is
even
though
you
run
even
though
you
don't
run
ceph
in
kubernetes
per
se,
you
could
still
take
advantage
of
your
prometheus
instances
and
then
collect
metrics
and
alerts
just
by
actually
adding
the
monitoring
endpoint.
That
is
already
running
from
your
external
subcluster.
C
It
is
simply
the
equivalent
of
the
block,
storage
interface
and
the
pvc
interface,
and
it's
just
that
this
is
not
a
volume
at
this
point,
it's
a
bucket,
because
what
you're
looking
for
here
is
in
order
to
get
the
work
done.
You
need
a
bucket
and
then
you
need
s3
credentials
once
you
have
that
you
also
get
the
s3
endpoint
and
then
you
can
start
working.
C
If
you
have
been,
if
you
had
deployed
ceph
already,
maybe
years
ago
with
bermuda,
then
you
know
that
it's
always
highly
recommended
to
separate
network
interfaces
from
client
to
the
external
storage.
So
at
this
point
what
you
want
to
do
is
really
have
a
dedicated
network
for
the
replication.
So
saf
has
its
own
internal
replication
network.
Then
you
have
you
want
to
you
want
this
one
to
be
dedicated.
C
C
It's
just
that
in
order
to
get
this
really
complete,
a
couple
of
moving
pieces
need
to
well,
I
guess
continue
to
move
that.
Has
the
integration
with
ipam
whereabouts,
which
is
the
preferred
one
and
they
are
the
the
picture-
is
not
fully
complete.
So
there
is
lack
of
service
to
support,
so
you
cannot
create
a
service
and
then
have
a
service
backing
expose
dedicated
network
interfaces
like
kubernetes
services,
and
there
is
also
one
small
item
we
still
have.
C
B
Real
quick,
I
just
want
to
emphasize
that
we
do
have
a
number
of
people
running
in
production
with
the
separate
cluster
network.
But,
like
sebastian
said
it's
just
the
host
networking
option
and
then
you
tell
there's
a
way
to
tell
the
seth
demons
the
osd,
how
to
run
on
that
separate
network.
But
multis
will
be
a
much
better
solution.
C
Yeah,
it's
it's
really
at
this
point.
It's
really
a
matter
of
of
the
infrastructure
supporting
that
scenario,
because
seth
has
been
supporting
that
for
for
years
now,
moving
on
with
admission
controller,
the
admission
control
really
helps
us
validating
creation
of
customer
resources
as
well
as
updates
just
to
make
sure
that
we
don't
run
into
an
invalid
configuration.
C
C
This
cannot
be
done
and
in
order
for
this
to
be
prevented,
animation
controller
is
is
really
useful,
because
the
admission
controller
will
basically
intercept
the
cr
update
request
and
will
actually
refuse
to
acknowledge
it,
depending
on
how
like
on
which
validation
rule
have
been
applied,
and
this
will
actually
happen
even
before
the
operator
realizes
that
an
update
has
been
made.
So
it
won't
go
into
any
reconciliation
group
which
is
really
useful.
C
Toolbox
job
we
have
a
component
called
a
toolbox
which
is
essentially
a
toolbox
that
has
the
set
binaries
in
it
and
a
connection
to
the
set
cluster.
So
if
you're
familiar
with
ceph,
then
you
will
get
an
environment
where
you
can
run.
Subcommands
apply,
subcommands
and
perhaps
maybe
debug
your
cluster
too.
C
E
C
Is
to
really
facilitate
use
cases
like,
for
example,
removing
a
failing
osd.
So
one
of
the
drives
is
failing
and
you
have
to
replace
it
so,
instead
of
going
through
manual
cli
commands,
then
if
you
run
that
job,
then
everything
will
be
done
automatically
and
we
are
well
we're
still
working
on
improving
this
again
to
have
predefined
jobs
embedded
into
into
rook
but
yeah.
This
is
one
less
operational
thing
to
do
next
slide.
Please.
C
Quick,
I
think
it
is
so
real.
Quick
rook
has
cleaner
policies.
So
when
you
remove,
when
you
decide
to
remove
the
safe
cluster,
then
if
you
apply
that
policy
brook
will
go
ahead
and
remove
all
the
parts
and
the
demons,
and
also
it
will
also
it
will
remove
all
sales
demons.
Data
can
be,
directories
can
be
drives,
different
options
are
supported,
so
basically
it
will
give
you
a
clean
environment
once
the
cluster
goes.
D
E
Sure
what
you
mean
by
performing
this
storage
management,
but
but
certainly
you
could
have
a
single
external
ceph
cluster
utilized
by
by
multiple
kubernetes
clusters.
So
if
you
can
explain
the
storage
management,
I
mean
you,
you
can't
have
the
same
volume
used
by
applications
in
different
kubernetes
cluster.
D
F
My
question
is,
obviously
you
cannot
use
same
volume
attached
to
multiple
parts
that
that's
not
my
intended
question.
The
question
is
you:
have
you
have
an
investment
as
a
software
defined
storage
with
the
external
subcluster,
where
you
can
plug
in
your
kubernetes
cluster
with
the
rook
operator
into
this?
My
question
is:
can
I
plug
in
multiple
communities
clusters
with
each
has
their
own
rook
operator
and
leverage
this
backhand
as
a
single
storage?
Back-End?
That's
the
question.
F
E
F
B
C
Not
when
we
are
connected
to
an
external
cluster,
so
yes,
the
you
can
have
multiple
kubernetes
cluster
accessing
the
same
external
subcluster.
They
will
all
be
using
different
pools,
so
the
storage
will
be
isolated.
Underneath,
that's
that's!
That's
the
use
case.
Yeah!
Okay!
Thank
you.
It's
one,
one,
two
one
too
many.
C
A
B
Yup,
so
the
when
you
add
nodes
or
when
you
add
more
storage
rooks
will
create
the
osd's
automatically
depending
on
the
settings
in
your
in
your
clusters.
Cr,
but
yeah
rook
will
look
for
labels
on
those
the
new
nodes,
you're
adding
and
then
add
the
new
osds
into
the
crush
map.
According
to
you
know
the
labels
on
that
nodes,
you
know
the
labels
should
tell
you.
Is
it
in
this?
Which
zone
is
it
in
which
rack
or
or
other
topology
labels?
But
we
do
look
for
those
and
add
that
automatically.
A
B
A
Perfect,
I
think
that
was
great
content.
I'm
going
to
look
forward
to
seeing
rook
graduate
through
the
cncf
and
get
a
few
other
people
off
vacation
so
that
they
can
vote
for
you
guys
and
vote
it
up,
and
hopefully
we
can
do
this
again,
once
you're
a
graduated
project
and
maybe
take
a
deep
dive
into
the
road
map
next
and
where
you're
going
next
with
brooke
and
with
steph
and
what's
up,
I
think
that
would
be
even
another.
A
Another
thing
of
interest
is
obviously
some
really
interesting
use
cases
for
this
and
telco
and
other
places.
So
hopefully
everybody
got
what
they
needed
out
of
today
and
we'll
do
this
again
soon,
so
thanks
travis
and
sebastian
and
anne
for
taking
the
time
to
do
this.
Thank
you.
I
will
be
uploading
this
to
the
youtube
channel,
which
is
rh
openshift
on
youtube
and
putting
a
link
to
the
slides
there.
So,
if
you
were
taking
copious
notes,
don't
worry,
the
slides
will
be
public
as
well.