►
From YouTube: KBE Insider (E13) - Travis Nielsen
Description
KBE Insider interviews Travis Nielsen, Sr. Principal Software Engineer at Red Hat and one of the original founders of Rook, the open source storage orchestrator for Kubernetes. In this KBE Insider episode we’ll dive into the work Travis does as the Maintainer of Rook, his work on the Ceph distributed team, and how to get involved in open source projects.
A
All
right,
well,
I
guess
we're
live.
We
are,
are,
sadly
still
missing
our
intro
video,
but
you
know
hopefully
we'll
get
that
in
the
near
future.
Nothing
like
a
little.
You
know
a
couple
of
technical
difficulties
to
start
off
our
day.
Well,
welcome
to
cube
by
example,
insider
where
we
talk
to
people
who
are
directly
involved
in
the
creation
and
kind
of
continuation
of
kubernetes
and
all
the
ancillary
projects
that
go
along
with
it.
A
A
B
B
I
was
here
as
a
guest
on
the
episode
number
five
and
I
loved
the
show
so
much-
and
I
got
this
opportunity
to
be
here
as
a
co-host
today
and
I
am
excited
to
talk
to
travis
about
rook
and
more
exciting
stuff.
Around
storage,
I'm
a
big
fan,
so
it's
an
honor
to
be
here
with
both
of
you
and
the
community.
C
Yes,
hello,
travis
nielsen
happy
to
be
here
to
talk
about
rook
rook
is
what
I
do
for
my
life.
So
I'm
always
amazed
how
many
people
want
to
hear
about
it
and
learn
more,
but
yeah,
I'm
one
of
the
original
founders
of
of
the
rook
project
and
that's
really
where
I
got
into
kubernetes
and
that
whole
ecosystem.
C
A
C
No,
it's
really
the
the
same
project
we
at
the
startup.
I
was
with
informed
we
thought
about
well,
should
we
open
source
what
we
were
working
on?
It
never
really
worked
out
while
we
were
on
that
project,
but
then,
as
we
got
into
the
next
things,
which
basically
turned
into
rook,
that's
where
we
really
got
into
open
source
followed
a
lot
of
patterns
that
we
saw
in
the
kubernetes
ecosystem.
C
Yeah-
and
I
guess
maybe
it's
too
long
ago
to
remember
now
exactly
how
we
got
into
it,
but
it
it
felt
like
yeah
as
we
got
into
the
open
source
world,
we
yeah
we've
just
looked
at
well.
How
are
other
projects
doing
it?
How
are
you,
how
do
we
do
releases?
How
do
we
do?
You
know
even
things
like
rebasing
and
prs
and
dealing
with
git
a
lot
of
we
wanted
to
make
sure
we
were
following
patterns.
Other
people
were
using,
so
I
think
kubernetes
was
one
of
those
projects.
C
A
B
Luck
has
been
successful,
so
thanks
for
sharing
that
little
bit
about
like
how
we
look
up
in
the
community,
we
take
the
good
portion
of
it
and
how
to
create
a
successful
project,
and
it
is
the
first
graduated
storage
cloud
native
storage
project
in
the
cncf
community.
So
how
do
you
feel
about
that?
Like?
Can
you
share
this
a
little
bit
more
on
the
success
stories
and,
like
you
know,
more
background
on
it
on
that.
C
Yeah
great,
it
has
been
a
nice
journey
and
to
become
a
graduated
project.
It's
already
been,
I
think,
has
it
been
three
years
since
we
were
graduated
in
2020?
No
wait.
It's
only
20
to
22
a
couple
years
since
we've
been
graduated
but
yeah
how
this
journey
worked
is
so
maybe
I'll
just
go
back
in
the
history
a
bit
so
back
in
2016
when
the
rook
project
started.
C
That's
when
we
started
to
look
at
really
wanted
to
look
at
well.
What's
cloud
native
storage,
what
does
storage
mean
in
the
cloud
native
world
cloud
native
was
kind
of
the
latest
buzzword
back
in
that
time?
Where
really
you
want?
You
want
your
software
to
work
in
the
cloud
you
want
to
work
well
in
the
cloud
be
designed
for
the
cloud
and
we
wanted
to
see
well.
Storage
is,
we
know,
is
important
for
the
world
and
it's
storage
is
a
really
hard
problem.
We
want
to
make
it
work
well
for
people.
C
So
originally
we
looked
at
ceph
as
the
storage
project
that
we
would
build
on
and
quickly
learned
that
our
it's
definitely
a
good
thing
and
it's
been
a
great
thing
to
build
on
seth
as
the
storage
platform,
but
ceph
wasn't
billed
for
cloud
native.
It
wasn't
built
for
kubernetes,
and
so
we
thought
well.
We
need
to
bring
this
storage
platform.
That's
been
stable
for
years,
already,
bring
it
into
the
cloud
native
and
kubernetes
ecosystem.
C
So
initially
we
were
thinking
well,
let's
make
make
it
work
well
for
any
cloud
native
environment,
whether
or
not
it's
kubernetes
or
not.
Well,
initially,
we
didn't
even
start
with
kubernetes.
We
thought
oh
we're
going
to
build
kind
of
our
own
installation
system
for
this
distributed
system
and
we
quickly
realized
well,
if
we
just
build
on
fcd
and
try
and
use
all
those
primitives,
it's
just
going
to
be
too
complicated.
Why
would
we
do
that
if
kubernetes
is
already
doing
all
of
that
for
us?
C
So
that's
when
we
really
took
a
bet
on
kubernetes
and
said
hey.
This
is
the
platform
for
distributed
systems.
Let's,
let's
build
storage,
the
storage
platform
on
kubernetes,
since
it
gives
us
that
distributed
platform
for
free,
essentially
and
then
yeah
from
there.
It's
like
we
created
an
operator
and
I
think
around
2006
yeah
that
first
conference
in
2016
also
we
went
to
the
seattle
kubecon
and
there
were
maybe
a
thousand
people
there.
C
The
concepts
were
new
and
at
that
conference
is
where
I
believe,
brandon
phillips,
presented
on
operators
in
the
operator
pattern
with
that
cd
and
the
prometheus
operators
of
the
first
two
examples,
and
while
we
were
there,
we
heard
that
and
we
thought
wait,
that's
exactly
what
we
want
to
do.
We
want
an
operator,
that's
going
to
automate
storage
and
bring
ceph
to
to
kubernetes.
C
So
then
yeah
we
immediately
kind
of
pivoted
and
said
yep
we're
creating
an
operator.
We're
gonna
create
crds.
Well,
they
weren't
called
crds
back.
Then
they
were
tpr's,
that's
how
old
the
project
is,
but
so
we
create
an
operator
and
then
soon
after
that,
the
kubernetes
community
came
up
with
this
whole
project
or
pattern
for
graduating
moving
from
sandbox
to
incubating
to
graduating,
and
so
we
we
thought.
Okay,
we
want
this
for
the
community,
we're
open
source,
just
like
it's
expected
in
this
community
to
progress.
So
we
worked
through
that.
C
We
worked
through
that
whole
progression
and
we're
happy
to
that.
The
community
was
receptive
of
the
project.
We
got
some
feedback
along
the
way
for
how
we
could
make
the
project
even
more
useful
for
the
community,
and
so
it
was.
It's
just
been
great
to
see
the
reception,
then,
for
you
know,
there's
the
theft
community
that
already
existed
than
any
any
of
them
who
were
using
kubernetes
said:
oh
yeah,
well,
rook's.
Obviously
the
solution
for
us,
so
we
naturally
had
the
theft
community
join
us
and
then
actually
somewhere
in
there.
C
I
joined
the
ceph
team
at
red
hat
to
more
naturally
work
together
and
make
sure
we
were
building
the
right
thing
and,
and
then
I
think,
graduation
a
couple
years
ago,
was
the
final
stamp
of
approval,
where
it's
like
yep.
The
community
really
sees
the
value
in
this
there's.
There's
good
production
deployments
lots
of
testimonies
of
people
happy
to
use
it
and
that
it's
you
know
open
community.
A
C
We
want
it
to
be
just
native
to
the
platform,
and
that
was
the.
I
guess
that
was
the
basic
assumption
was
like.
We
don't
want
to
be
external.
We
want
it
to
be
part
of
the
same
cluster
you're,
already
managing
and,
and
then
with
that
comes
all
the
patterns
that
kubernetes
have
well.
You
have
to
run
in
you're,
going
to
be
running
in
containers,
you're,
going,
which
traditionally
really
seth
hadn't
been
running
on
containers,
although
it
was
moving
in
that
direction
already
you've
got.
A
World,
and-
and
so
do
you
think
things
like
eventual
consistency,
are
kind
of
in
line
with
the
cloud
nativeness
or
do
you
think
they're,
you
know
a
way
kind
of
around
some
of
those
problems,
or
is
that
or
just
anathema
altogether?
You
know
I'm
just
kind
of
curious
of
your
thoughts
on,
because
it's
it's
definitely
growing
in
popularity
and
it
to
me
it
seems
like
something
that,
if
you're
kind
of
a
true
storage
person,
you
might
be
really
stressed
out
about
about.
C
The
eventual
consistency,
nature
of
it
or
yeah,
yeah
and
ceph
itself
kind
of-
has
some
assumptions
that
well
it's
not
eventually
consistent.
It's
it's
fully
consistent,
like
once
you
put
data
in
to
ceph.
You
know
that
it's
replicated
and
you
know
that
ceph
is
taking
care
of
it,
the
the
difference
being
well.
If
it's
eventually
consistent,
then
you
know
you
put
it
in
and
you
might
not
get
it
back.
C
If
you
ask
for
it
too
soon
right,
because
the
back
end
is
is
replicating
the
data
and
until
it's
replicated,
then
you
might
not
get
it
back
but
stuff
yeah.
We
liked
the
full
consistency
of
ceph
for
a
data
platform,
and
so
there's
there's
a
little
trade-off
there,
which
is.
Maybe
it
takes
a
you
know,
a
touch
longer
to
commit
your
data.
I
mean
we're
talking
milliseconds
right,
but
but
that
full
consistency
has
been
yeah.
We
just
really
like
that
that
solution
from
zeph
having
a
full
consistency.
A
That
makes
sense.
I
was
just
kind
of
curious,
you
know
if,
if
there's
you
know,
it
seems
like
we're,
maybe
getting
to
the
point
where
we
can
do
full
consistency
most
of
the
time
you
know,
if
not
all
of
the
time.
So
maybe
it's
it's
not
you
know.
Maybe
it
was
a
stop
gap
right.
You
know,
that's
why
I
was
kind
of
curious
what
your
your
kind
of
feeling
on
it
was.
Did
you
have
a
question.
A
B
Before,
like
I
used
to
be
a
cluster
administrator,
so
what
I
would
look
for
in
a
cluster
storage
is
always
baffling.
It's
still
baffling
to
me
and
I'm
trying
to
like
learn
a
little
bit.
I
am
improving
all
my
knowledge,
I
wouldn't
say
like.
I
know
everything
about
story,
storage.cloud
native
storage,
for
the
matter.
The
one
amazing
thing
about
rook,
I
would
say,
is
that
it
has
those
things
like
how
kubernetes
is
self
healing.
B
The
rook
storage
operators
is
like
it's
self-healing,
so
it
gives
me
peace
of
mind.
You
know
like
I
don't
have
to
know
about
everything.
I
just
need
to
know
about
some
basics,
and
I
can
still
do
my
job
and
keep
on
improving
my
knowledge
on
the
side.
It's
an
amazing
win.
To
be
honest.
So
when
you
talk
about
like
how
you
made
it
work
with
kubernetes
and
everything,
it's
it's
amazing.
C
That's
great
to
hear
you
know
yeah
I'd
like
to
talk
to
that
point
too,
really,
because
what
we
really
saw
as
potential
in
kubernetes
as
the
patterns
there.
The
basic
pattern
is
you:
you
need
to
declare
desired
state
like
what.
How
do
you
want
the
software
to
behave?
That's
what
you're
telling
kubernetes
with
these
manifests
these
ammo
files.
Whatever
you
tell
you
tell
the
platform,
what
your
settings
are,
what
your
desired
state
is
and
the
operator's
job
is
to
go.
Make
that
happen
to
make
sure
that
you're.
A
A
Where
I'm
kind
of
trying
to
understand
how
I
want
my
storage
eventually
to
work,
what's
the
best
way
to
kind
of
get
started
with
it
is
you
know,
do
I
you
know
kind
of?
Do
I
start
at
rook?
Do
I
start
at
nfs?
Do
I
start
at
ceph?
Do
I
start
you
know?
Where
do
I
kind
of
get
plugged
in
to
understanding
how
doing
the
storage
inside
kubernetes
like
where's
the
best
point
to
kind
of
start
for
you
in
your
opinion,.
C
Okay,
yeah
yeah,
okay,
all
right
yeah,
so
really
with
with
seth.
There
are
two
very
different
environments
to
run
it
in
one
is
kubernetes
and
with
rook,
and
one
is,
you
know
doing
it
on
your
own
bare
metal,
where
there's
just
no
kubernetes
platform
available,
so
so
up
upstream
and
for
downstream
solutions.
C
Those
two
those
two
scenarios
really
remain
both
important
and
critical,
because
some
people
just
aren't
on
kubernetes.
Yet
more
and
more
people
are
moving
there,
but
for
people
who
are
who
are
already
running
kubernetes,
if
they
want
storage,
then
I'd
recommend
you
to
get
started
with
rook
to
deploy
stuff
because
rook
just
makes
it
excuse
me.
Rick
just
naturally
deploys
ceph
and
makes
ceph
easier
to
deploy
and
manage
and
upgrade,
and
all
of
that,
so
it's
certainly
possible
to
deploy
seph
without
rook,
but
not
really
in
a
kubernetes
environment
so
and
like
in
rook.
C
We
have
documentation
on
our
web
link
from
our
website
on
rook.io,
where
you
can
go
there,
there's
a
quick
start
guide.
This
is
how
you
get
started
with
kubernetes
and
deploying
stuff,
and
we
try
and
make
it
as
clear
as
possible.
I
know
it's
still.
Storage
is
still
a
difficult
thing.
There's
no
easy
way
to
do
it
really,
and
it
takes
a
bit
of
dedication
to
get
it
going,
but
it's
once
people
get
it
going
then
I
feel
like
they
really
say,
hey
this.
This
does
work
nicely.
A
C
B
C
Great
yeah,
you
know,
as
with
any
project,
you
know
anything
naming
is
kind
of
a
big
question.
What
do
we
call
this
thing
right,
we're
creating
something
new.
Do
we
just
call
it
ceph
for
kubernetes?
Do
we
you
know
what
do
we
call
it
and
when
initially,
it
wasn't
even
set
for
kubernetes?
It
was
for
cloud
native
anyway,
our
our
initial
code
name
for
the
project
was
castle
and
where
castle
came
from,
is
we
wanted
to
build?
C
C
That's
you
know,
built
on
built
with
rock
and
stone.
It's
it's
a
safe
place.
So
castle
was
the
original
name
of
the
project,
but
then,
as
it
started
as
it
came
time
to
kind
of
look
at
copyrights
and
what
other
projects
out
there
called
castle
there
were,
there
were
a
couple
other
projects
called
castle,
so
we
thought
well,
we
we
kind
of
like
our
logo
that
looks
like
a
castle.
We
like
this
whole
theme.
What
do
we
do?
Well
so
then
we
came
up
with
rook
as
it's.
C
You
know,
of
course,
the
the
the
piece
in
the
game
of
chess,
which
is
a
castle,
and
I
think
in
arabic.
It's
rook
is
the
word
for
castle.
It's
a
nice
short
word,
rook.o
was
available
and
we
thought
oh
great.
Let's
go
with
this
and
it's
it's
been
good
ever
since
I've
got
it
on
my
license
plate
on
my
car
now
and
it's.
A
Yeah,
to
be
honest,
I
can't
believe
rook.io
was
available.
To
be
honest
right,
like
I
mean
you
know
that
it
is
a
pretty
common,
pretty
solid
word,
you
know,
so
I'm
I'm
impressed
you
were
able
to
get
the
domain,
but
yeah
I'm
actually
familiar.
Isn't
there
like?
Let's
say
it's
a
php
web
framework
called
castle?
I
think
which
was
probably
or
something
like
that
I
it's
been
a
while,
but
I
used
to.
B
C
C
A
Yeah,
it's
always
handy
yeah
and
the
naming
of
things
I
completely
agree.
I
was
involved
in
the
naming
of
modularity,
which
led
to
real
app
streams.
Modularity
was
a
terrible
name,
and
you
know,
but
it
was
one
of
those
ones
where
you
know
we
kind
of
started,
throwing
it
around
and
it's
stuck
rather
than
you
know,
putting
real
effort
into
naming.
I
strongly
recommend
if
you're
ever
building
a
project
put
some
effort
into
either
coming
up
with
a
good
name
or
an
arbitrary
name.
A
C
B
Just
gonna
go
on
a
tangent
and
ask
like
tell
us
a
little
bit
more
about
how
to
contribute
to
look
or
like
some
folks
are
interested
in
like
getting
started
somewhere.
I
know
langdon
had
shared
some
intro
links
to
intro
videos
and
like
a
way
to
get
started
but
say
I'm
a
new
newbie
I
want
to
like
learn.
I
come.
I
try
it
out
hey
there
is
this
thing
that
I
want
to
improve
on
and
I
want
to
like
start
contributing
back
so
like.
Can
you
share?
C
C
We
want
an
environment
where
people
feel
feel
welcome
and
that
their
questions
will
be
answered
so
yeah
on
rook.io,
like
we've
already
linked,
there's
the
documentation
for
getting
started,
there's
also
a
link
there
to
join
the
rook
slack.
So
in
the
rook
slack,
it's
where
we,
you
know
really
it's
intended
to
be
a
place
where
you
can
ask
questions,
get
answers
and
community
members
can
answer
each
other's
questions.
C
C
There's
in
the
getting
started
guide
and
in
our
documentation
we
have
a
doc
that's
about
how
to
contribute
to
rook.
So
if
you
really
want
to,
you
know,
contribute
some
code
back.
Let's
see,
how
do
I
paste
a
link
in
there,
let's
see
where
to
paste
it,
but
there's
in
the
documentation.
If
you
click
on
the
contributing
tab,
I
can
yeah,
we
find
we
have
a
whole
yeah.
We
all
have
a
whole
topic
there
on.
C
B
C
A
So
we
actually
had
a
question
from
the
audience
too.
I
think
I
found
the
link
so
I'm
going
to
post
that
real,
quick
and
then,
but
we
did
have
a
question
from
the
audience,
was
what
is
rook's
relationship
to
databases
you
know:
does
it
does
rook
help
me?
You
know,
deploy
people
or
whatever
in
kubernetes,.
C
C
C
So
it's
a
and
kubernetes
it's
a
read,
write
once
volume
generally
then
shared
file
system
storage
with
set
fs-
that's
where
well,
you
might
have
a
pod
that
wants
to
share
its
storage
with
other
pods,
so
you've
got
to
read,
write
many
volume
and
so
stuff
allows
that
so
sharing
storage
between
pods
is
completely
possible
with
that,
and
then
the
third
forum
object.
Storage
is
all
about
kind
of
what
you
think
of
as
amazon
s3,
which
initially
created
object,
storage
where
you're
putting
and
getting
objects
into
into
the
storage
platform.
C
So
so
seth
provides
all
three
of
those
and
you
can
choose
which
ones
you
want
to
enable
all
three
of
them,
or
just
one
of
them
depending
on
your
storage
needs,
but
for
so
databases
now
like
postgres
cassandra
or
any
of
those
typically,
databases
would
be
created
on
top
of
the
the
block
storage.
So
you
create
your
read,
write
once
pvc
provision,
the
volume
and
then
you
will
would
write
to
that.
Your
database
would
then
write
to
that
volume
that
ceph
volume
just
like
it
would
write
to
any
other
volume
that
you
might
provision.
A
Overview
there
yeah,
so
basically
what
you're
saying
you
kind
of
like
you,
set
up
the
storage
with
rook
and
ceph
as
block
storage
right,
and
then
you
would
kind
of
install
your
database
normally,
and
it's
just
that
it
would
be
kind
of
getting
its
storage
through
this
kind
of
automatically
replicating
or
distributed
files
well
block
store.
You
know
to
be
specific.
C
Yeah,
that's
right
and
another
example.
I
guess,
if
you're
running
in
aws,
you
know
your
database
might
be
backed
by
an
ebs
volume,
or
I
mean,
if
you're
not
running
an
idea
of
a
aws
you're
running
somewhere
else.
Where
you,
if
you're
in
your
own
data
center,
where
you
configured
rook,
then
it
would
just
you'd
just
be
putting
it
on
top
of
a
block
storage
volume
instead
of
the
evs
volume.
A
Right,
okay,
so
ven
10,
who
is
the
person
who
asked
the
question
you
know
feel
free
to
add
follow-ups?
If
you
have
any
more
questions?
What
I
would
like
to
kind
of
move
on
to
is,
you
know
kind
of,
as
we
talk
about
with
the
insider
show
right.
We
talk
about
kind
of
what's
coming
right.
So
what?
What
are
you
most
excited
about
from
a
kind
of
a
feature,
perspective
or
improvement?
You
know,
maybe
it's
stability.
Maybe
it's
something
else.
C
Yeah
and
yeah
we
have
several
engineers
working
on
rook
full
time,
so
there's
always
improvements,
there's
always
something
coming
and
and
maybe
I'll
talk
to
our
release
cycle.
Just
briefly,
so
every
about
three
or
four
months
we
kind
of
tried
to
follow
the
kubernetes
release
cycle,
which
is
about,
I
think
three
times
a
year.
Now,
every
four
months
is
the
goal,
so
we're
about
on
the
same
schedule
that
we'll
have
a
release.
C
B
C
One
will
be
coming
up
in
august:
it's
planned
for
rook
version
1.10,
so
in
and
really
where,
where
rook
is
feature
wise,
I
feel
like
I'm
just
happy
we're
worse.
I
feel
like
it's
stable.
We've
got
the
basic
feature
set
now
we're
we're
still
improving
we're
still
adding
features,
but
the
basic
things
are
all
there
like
one
feature.
We're
looking
at
for
1.10
is
the
ability
to
say
it's
kind
of
at
the
cef
level
to
be
able
to
say
you
know,
keep
track
of
who
ran
what
command
like?
C
What's
the
operator
doing
versus
what
is
a
user
or
admin
doing
to
manage
ceph
in
what
we
call
the
toolbox?
The
toolbox
is
this,
this
pod,
that
we
make
it
so
you
can
run
ceph
commands
to.
If
you
know
what
you're
doing
with
seth,
you
can
go
run
those
commands
there,
so
it
kind
of
making
it
better
at
the
logging
level.
So
we
know
what's
happening.
We
can
keep
track
of
that.
I
mean
there's
already
logs
it's
just.
We
can't
tell
who's
doing
it
if
we're
looking
back
at
logs.
C
C
Then
we've
got
this
nfs
driver.
That
makes
it
so
you
can
connect
your
storage
with
nfs,
that's
that's
the
external
storage
and
then
kind
of
convert
it
into
rook
storage.
So
you
can
get
away
from
that
nfs
storage
and
convert
it
into
stuff.
So
that's
another
big
feature
area
that
someone
else
on.
My
team
has
been
working
on
happy
to
have
that
one
and
there's
always
so
much
so
much
going
on
with
the
project,
I'm
going
to
forget
them
on
the
spot.
But
that's
a
couple
of
ideas.
B
I
think
the
nfs
bit
it's
going
to
be
a
music
to
so
many
people,
because
they
like
large
companies,
many
of
them
have
their
on-premises
data
centers
still,
even
though
they
use
cloud
and
for
predominantly
for
the
on-prem,
they
would
be
reliant
on
nfs,
most
of
them
use
nfs,
so
yeah.
It
would
be
like
amazing
for
them
to
even
adopt
communities
at
a
faster
rate.
B
C
Yeah,
there's
always
a
you
know.
Those
feature
requests
coming
in
that
we're
happy
to
entertain,
and
sometimes
we
we
say.
Yes,
that's
a
great
idea,
and
sometimes
we
say
well,
do
you
have
the
bandwidth
to
work
on
that,
because
sometimes
we
just
don't
have
the
bandwidth
as
with
any
software
project,
I
think.
C
A
Four
or
sorry
three
times
a
year
is,
you
know,
particularly
storage
right,
that's
something
that
tends
to
be.
You
know
both
jokingly
and
seriously.
I
it
should
be
pretty
stable.
How?
How
does
you
know?
How
does
the
user
base
feel
about
that
kind
of
release?
Schedule?
Is
it
you
know,
or
how
do
you
manage
to
the
fact
that
you
know
the
thing
that
I
don't
want
changing
in
my
environment
is
the
storage
right,
because
I
want
it
to
always
be
there
and
I
want
it
to
never.
You
know
never
go
away.
C
C
C
In
retrospect,
like
three
years
ago,
one
of
the
major
changes
we
made
was
decoupling
that
seth
version
from
rook,
because
originally
in
the
project,
we
basically
embedded
the
latest
version
of
seth
with
rook,
and
you
couldn't
choose
what
version
of
of
step
you
deployed,
and
so
we
kind
of
would
you
know
there's
we
would
force
that
that
data
up
data
layer
upgrade
whenever
we
have
to
carry
it
rook
and
we
realized
yeah.
That's
people
really
do
need
that
mind
that
peace
of
mind
that
they're
getting
a
stable
data
layer,
and
so
we
separated
it.
C
We
said:
okay,
you
can
choose
your
version
of
seth
that
we
deploy
with
the
ceph
demons
in
those
pods
and
rook
will
have
its
own
version
in
with
the
brook
operator,
basically
so
that,
since
those
are
fully
separate
now,
seth
has
its
major
releases
once
a
year,
and
you
know
rooks
is
three
times
a
year.
So
if
you
don't
want
to
upgrade
the
stuff
layer
as
often
then
you
can
choose
to
do
that,
you
probably
should
do
it
delayed.
You
know.
Upgrading
to
the
latest
patch
release
of
stuff
is
a
good
idea.
Anytime.
C
It
comes
out
generally,
but
then
you
can
choose
when
you're
ready
to
make
that
jump
to
the
major
upgrade
of
seth,
which
rook
usually
makes
pretty
smooth,
because
our
goal
is
to
make
ceph
deployment
and
upgrades
simple
and
automated,
but
yeah.
You
just
need
to
be
aware
of
when
you're
upgrading,
so
you
can
be
ready
in
case
something
happens.
A
C
The
main
difference
that
that
really
benefits
rook
users,
too,
is
that
you
can
tell
rook
to
back
the
ceph
storage
by
the
cloud
native
storage.
So
if
you're
in
aws,
you
can
say
oh
back
safe
by
ebs
volumes
and
now
the
limitations
of
ebs
can
be
overcome
by
ceph.
Because
now
you
know,
for
example,
ebs
volumes
are
limited
to
an
az
and
you
can
only
have
so
many
volumes
mounted
on
per
node
like
30
last.
I
heard
that
might
be
out
of
date,
though
some
limitations
like
that,
but
now
with
ceph.
C
A
No,
no,
I
I
thought
it
was
good.
I
was
just
kind
of
like
I
wanted
to
also
kind
of
make
the
point
that
you
know.
Openshift
okd
are
really
like
an
open
source,
vendorized
version
of
kubernetes
right,
I
mean
so
at
the
end
of
the
day,
it's
still
kubernetes
underneath
so
as
a
result,
anything
that
works
with
kubernetes
should
work
with
openshift
and
okd,
including
rook.
So
but
then
we
had,
we
just
got
a
whole
influx
of
people.
A
C
Yeah
I
mean,
if
you
have
having
it
app
you're,
probably
going
to
use
like
a
with
kubernetes,
a
storage
class
that
consumes
that
netapp
storage
and
so
rook
probably
wouldn't
be
involved
there.
If
you
could
also
choose
to
back
rook
by
some
other
storage
as
long
as
there's
a
storage
class,
rook
can
consume
that
storage
behind
it.
I'm
not
sure
I've
heard
of
someone
using
netapp
in
conjunction
with
rook
and
seth.
Usually,
I
would
say
they
they're
in
parallel
or
you
can
have
netapp
as
well
as
brooke.
A
But
there's
a
little
a
bit
of
both
both
and
right,
or
you
know,
and
or
depending
on
on
your
perspective.
You
know
what
you're
trying
to
accomplish
you
know
and
that
I
think
we
were
talking
about
this
a
little
bit
with
on
the
in
the
chat
of
like
you
know,
databases
often
offer
replication
right,
but
then
storage,
particularly
these
days
right
distributed
storage,
also
offers
replication
and,
depending
on
your
use
case,
depending
on
what
you
already
have
set
up
or
whatever
like
you,
you
want
to
choose
one
or
the
other.
A
What
you
don't
usually
want
to
choose
is
trying
to
have
them
like
fight
right.
You
know
you
don't
really
want
database
doing
replication
and
your
store
is
doing
replication
because
often
that
will
go
poorly.
You
know,
because
one
gets
confused
about
who's
responsible
for
what
I
think
the
the
same
kind
of
thing
happens,
potentially
with
something
like
netapp
or
whoever
your
storage
provider
is.
A
Where
you,
you
know,
it's
like
make
sure
it's
very
clear
to
all
the
software
involved,
who's
responsible
for
which
bits
right
and
it's
and
you
get
into
trouble
when
you
try
to
kind
of
just
take
all
the
defaults
from
everybody
without
really
thinking
about
how
much
they
potentially
overlap.
Would
you
would
you
largely
agree,
I
think
that's
the
problems.
I've
run
into
the
most.
C
A
A
On
the
flip
side,
the
lake
itself
could
be
managed
by
a
delta
on
top
of
something
like
ceph,
and
then
you
kind
of
could
expose
it
through
your
kind
of
kubernetes
environment,
but
this
is
where
it
gets
a
little
dicey
about
like
this
as
one
you
know,
it's
very
specific
to
the
scenario
that
you
actually
want
to
deploy
and
so
kind
of
giving
a
general
answer
is
tough.
You
know,
ceph
is
storage,
so
you
can
run
your
lake
on
the
storage
or
you
can
try
to
build
a
lake.
A
C
And
what
I'd
say
is
you
know?
Rook
is
really
targeted
at
managing
a
storage
for
a
single
kubernetes
cluster.
So
if
the
legs
were
to
try
and
span
kubernetes
clusters,
that's
not
so
much
a
thing
for
seth,
although
I
will
point
out
that
ceph
and
and
rook
helps
provide
the
features
where
you
can
mirror
data
across
clusters.
A
C
And
as
of
today,
I'd
say:
rook
rook
upstream,
is
really
just
targeting
a
single
cluster.
If
you
have
multiple
clusters,
you're
just
going
to
be
having
multiple
rooks
and
you
could
configure
each
rook
to
mirror.
If
you
want
to
mirror
the
data
across
but
ultimately
yeah,
we
don't
really
have
something
in
mind
for
multi-cluster
support.
I
think,
for
you
know,
for
downstream
there's.
C
A
Yeah,
this
is
actually
one
of
the
challenges
I
think,
with
kind
of
the
multi-cluster
management
in
general
with
kubernetes
is
like
from
operator
perspective.
You
know
single
plane
of
glass
on
into
all
of
the
things
you're
kind
of
managing
is
nice,
but
I'm
not
sure
that
all
the
things
that
you're
managing
need
to
be
aware
of
each
other.
So
in
other
words,
you
know
you
might
have
67
rooks
as
long
as
you
know,
from
an
operator
perspective.
A
Sorry,
when
I
say
operator
I
mean
human
operator
from
an
operator
perspective.
I
want
to
know
about
the
67,
but
I
they
don't
necessarily.
I
don't
necessarily
need
them
to
literally
be
just
one
that
is
being
managed
on
its
own.
Instead,
you
know
give
me
a
kind
of
user
interface
that
lets
me
say
this
is
how
I
want
rook
to
operate
in
all
67
or
I
want
rook
to
operate
in
this
way
for
60
of
them
and
set.
A
You
know
another
way
for
seven,
but
that's
kind
of
that
they're
not
operating
as
a
cluster
they're
being
individually
managed
at
a
kind
of
a
step
back
level.
I
know
this
is
one
of
the
before
I
left
red
hat
actually
acm
was
was
starting
to
come
up
and
it's
it's
one
of
those
difficult
problems
of
like
who
owns,
which
part.
C
Yeah
and
I'd
what
I'd
say
about
if
you
have
lots
of
clusters,
probably
you're
going
to
be
automating
things
scripting
things,
so
you
get
consistent
configurations
across
clusters
because
rook
is
all
based
on
you
know.
The
yaml
manifests.
We've
got
helm,
charts
as
well
for
people
who
like
to
use
helm
so
so
those
would
allow
automation
across
clusters
for
sure
and
then
to
monitor,
what's
happening
in
the
clusters.
C
You
know
there's
a
lot
of
functionality
around.
You
know
the
prometheus
monitoring,
so
you
can
collect
metrics.
You
can
see
dashboards
about
how
ceph
is
is
behaving
in
the
cluster,
and
things
like
that.
So
you
can
get
insight
for
sure
with
those
other
tools
like
prometheus
and
grafana,
which
yeah,
which
a
lot
of
people
really
appreciate.
Seph
also
has
a
dashboard
that
that
you
can
connect
to
the
individual
cluster
and
see
more
details
for
what's.
A
Right
so
I
wanted
to
pause
there
because
we
are
almost
out
of
time.
We
do
have
a
number
of
other
questions
in
the
chat,
so
I'm
going
to
put
the
kubernetes
by
example,
forums
in
the
chat,
so
please
go
open
a
topic
there
or
you
know
anything
that
you're
interested
in
we'll
try
to.
You
know,
make
sure
to
come
back
and
take
a
look.
You
know
and
and
respond
to
any
more
questions
that
you
might
have
we
want
to.
A
I
also
would
like
to
pitch
an
upcoming
conference
that
is
all
about
open
source
development
and
it
is
called
devconf.us.
There
is
an
analog
in
cz,
which
is
actually
quite
a
bit
there.
Sorry
in
the
czech
republic,
but
that
is
in
january-
and
this
is
actually
next
month
about
the
middle
of
august,
and
so
I
I
want
to
say
we
actually
have
at
least
one
rook
talk
there,
but
I
could
be
crazy.
A
I'm
trying
to
remember,
even
though
I'm
a
co-chair,
there's
enough
talks
that
I
can't
remember
them
all
so
definitely
check
that
out.
It's
in
boston,
we're
going
to
be
doing
some
streaming
of
it,
but
it
is
meant
to
be
an
in-person
conference,
so
hopefully
you
can
make
it
it's
free,
as
with
a
lot
of
open
source
things
so
check
that
out.
Let's
see,
I
think
that
was
all,
but
we
would
of
course
really
like
to
thank
travis
for
coming
and
talking
to
us
about
rook
travis.
C
Yeah,
maybe
I'll
throw
out
there
that
with
kubecons,
hopefully
with
we're
doing
them
in
person
going
forward
again,
I'm
looking
forward
to
that.
We
we
always
have
a
rook
booth
there.
So,
if
anybody's
a
kubecon
be
happy
to
meet
you
and
talk
to
you
at
the
the
rook
booth
is
the
easiest
place
to
find
and
there's
always
work
talks
at
that
conference
as
well.
So
looking
forward
to
meeting.
A
People
to
detroit
and
october-
and
yes
that
should
be,
that
should
be
fun.
I
will
also
be
there
actually
we're
going
to
be
running
a
kubernetes
by
example.
Insider
day,
maybe
or
you
know
we're
going
to
definitely
kind
of
walk
the
floors
and
try
to
interview
people
so
we'll
we'll
definitely
be
there
and
involved
as
well,
but
yeah
thanks
so
much
again
for
your
time
and
we
really
appreciate
it,
did
you
want
to
add
anything
else.
B
No,
this
has
been
an
amazing
session
travis.
I
was
like
I
learned
a
lot
and
I
hope
all
the
viewers-
the
community,
learnt
a
lot
from
hearing
listening
to
today's
episode
and
thank
you
again
for
being
here
taking
your
time
and
chatting
with
us
about
look
in
storage
and
stuff,
and
we
have
definitely
simplified
some
topics,
at
least
for
me,
and
I
hope
it's
gonna
benefit
everyone
outside.
B
A
All
right
well
with
that
note
thanks
again
travis
thanks
to
the
audience,
thanks
to
the
I
think
it
was
brazil,
linux,
sips
and
you
know
maybe
we'll
see
you
at
the
big
brazilian
open
source
conference
which
I'm
blanking
on
the
name
of
I
know
a
bunch
of
my
friends
regularly
speak
there
and
you
know,
hopefully
we'll
we'll
see
you
soon,
thanks
again
for
coming.
Remember
we're
on
the
last
tuesday
of
the
month
and
we
hope
to
see
you
next
time.
Thanks
everybody
thanks.
It's.