►
From YouTube: Rook: Cloud-Native Storage Orchestr... Jared Watts, Bassam Tabbara, Travis Nielsen & Alexander Trost
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Rook: Cloud-Native Storage Orchestration (Introduction and Deep Dive) - Jared Watts, Upbound; Bassam Tabbara, Upbound; Travis Nielsen, Red Hat; & Alexander Trost, Cloudical
Rook is an open source cloud-native storage orchestrator for Kubernetes, providing the platform, framework, and support for a diverse set of storage solutions to natively integrate with cloud-native environments. In this session, the maintainers of Rook will be presenting a variety of topics that are aimed at all attendees with differing levels of experience. We will begin with an introduction to the project that is suitable for newcomers to learn what problems Rook solves. Then we will be showcasing multiple demos of the various storage providers supported by Rook, providing attendees with a practical and diverse exposure of Rook in action. We will conclude with an exploration of the longer term goals and roadmap of the project, inviting participation and feedback from the community to help steer the project direction and continue solving real problems with storage in the Kubernetes ecosystem.
https://sched.co/Uakk
A
Alright,
hello,
everyone
I
think
we're
ready
to
get
going
here.
I'm,
Travis
Nielson,
one
of
the
rook
maintainer,
is
happy
to
be
with
you.
We
have
quite
a
group
of
people
here,
maintainer
z--,
to
talk
to
you
about
what
rook
is
what
it's
all
about.
What
rook
can
do
for
you?
We
have
seven
total
speakers
today
and
we'll
introduce
them
as
they
as
they
have
each
had
their
turn,
but
we
have
a
good
90
minute
session
here
at
the
end
of
the
conference.
A
A
All
right,
so,
let's
go
so
today
we
want
to
talk
about.
First
of
all,
what
is
rook
you
know.
Many
of
you
are
probably
new
to
rook.
Can
I
just
get
a
quick
show
of
hands?
Who
here
just
learned
about
rook
this
week,
all
right,
a
good
good
number
of
you
great
who
here
has
run
rook
in
production,
okay,
I
know
at
least
some
people
that
were
gonna,
be
here,
alright
yep,
so
we
have
a
good
spread
from
running
it
in
production
to
brand
new
to
rook,
but
so
we'll
introduce
it
to
you.
A
We
want
to
talk
about.
You
know
how
work
works.
What
does
its
architecture
look
like
where
we're
going?
What
graduation
looks
like
and
then
we'll
get
into
where
we're
going
to
spend
most
of
our
time
today
is
really
on
what
did
each
of
the
storage
providers
in
rook
offer?
You
know
how
do
they
work
so
we'll
we'll
have
well
basically,
I'll
show
you
this
just
to
give
you
an
idea
of
how
long
each
section
is
expected
to
be
will
have.
A
Intro
Jared
will
talk
to
us
about
CN,
CF
and
then
we'll
get
into
Seth
ed,
Jeff
s,
gigabyte
and
Cassandra
each
into
detail
and
and
what
they
do
and
how
they
work.
Alright,
so
first
of
all,
kubernetes
in
a
storage
kubernetes
was
really
designed
from
the
ground
for
for
stateless
services.
If
you
want
I'll
go
into
this
next
slide,
if
you
want
storage
for
kubernetes,
there
is
a
volume
plug-in
model
that
lets
you
attach
to
your
storage
that
is
running
somewhere
else.
It's
not
part
of
kubernetes,
fundamentally
just
the
way
the
the
plug-in
model
works.
A
A
Ok,
so
there
are
many
challenges
in
the
storage
world.
First
of
all,
if
you
have
to
rely
on
this
external
storage,
where,
where
does
where
does
that
external
storage
come
from?
If
your
on-prem
running
in
your
own
data
center,
do
you
have
to
you
know?
Do
you
buy
an
appliance?
What
bender
do
you
go?
Get
it
from?
Do
you
really
want
to
plug
in
something
external
to
your
cluster?
A
You
know
and
deploying
it
maintaining
it
all
the
challenges
that
come
with
it
or
even,
if
you're
running
in
the
cloud,
do
you
want
to
be
locked
in
to
that
cloud
provider
if
you're
building
on
their
storage
solutions
and
then,
lastly,
day
2
operations,
who's
managing
this
thing
is:
is
it
simple
to
manage?
Is
it
really
hard
to
manage?
How
can
we
simplify
this
management
story?
So
some
of
these
problems
is
where
we
started
with
the
rook
project
and
leads
us
to
well
what
is
rook
all
about
then.
A
So
it's
about
just
over
three
years
ago,
several
of
us,
the
rook
maintainer,
were
getting
started.
Looking
at
a
few
different
things,
looking
at
the
future
of
obscure
and
kubernetes
was
pretty
young
at
that
point
and
we
thought
well,
how
can
we
make
storage
just
work
really
well
for
kubernetes?
Why
does
it
have
to
be
this
external
entity?
How
can
we
get
just
make
it
work
well
for
Corinna
DS,
so
got
a
few
things
coming
in
here.
A
Let
me
see
if
I
can
get
them
up
and
I
went
too
far,
so
we,
where
we
ended
up
with,
is
okay.
We
need
an
operator
that
going
to
deploy
the
store,
a
storage
provider
for
you,
the
operators,
first
of
all,
they
they're.
Basically
a
pod
they're,
going
to
run
they
can
run
wherever
kubernetes
runs,
they're
going
to
call
kubernetes
api
is
they're
going
to
manage
this
system
in
the
way
that
just
feels
like
part
of
kubernetes,
it's
going
to
automate
deployment
of
it.
A
A
It
is
all
open
source.
We
have
a
pure,
you
know
open
source
philosophy,
Apache
2.0
come
use
it
deploy
it
use
it.
How
you
need
to
it
is
a
ciencia
project
in
incubation
and
Jared
will
talk
to
us
more
about
that
in
a
bit
it
and
the
way
it
works
is
by
extending
communities
with
custom
resource
definitions,
see
RDS,
and
so
we
can
define
the
storage
and
the
settings
for
deploying
deploying
the
storage
providers.
It
is
a
framework
for
many
storage
providers
and
solutions
and
we'll
get
into
that
in
a
bit.
A
But
at
the
end
of
the
day,
all
of
us
who
are
here
I'm
assuming
have
storage
problems
and
that's
why
we're
excited
to
solve
these
problems.
Because
storage
is
such
a
fundamental
need
to
run
applications
you
just
can't
have
an
application
that
that
doesn't
need
storage
Alex.
Was
it
anything
else
on
that
topic?
You
know
what
gets
you
excited
about
working
on,
Rudkin
storage,
yeah,.
B
So
one
of
the
use
cases
some
useless
have
where
root
comes
in
to
solve.
It
is
gay,
well
spin,
a
cocoon
is
cluster
and
depending
on
where
they
deploy
source
might
have
some
additional
discs
like
for
most
bigger
the
metal
provide
us
you
get
like
so
special
eat
like
two
disks
and
probably
if
it's
still
hdds
well,
a
few
terabytes.
Normally
you
put
this
on
there
and
the
other
storage
is
gone
so
for
some
people,
that's
after
use
case
to
just
utilize
the
storage
on
those
disks.
B
Well
it
depending
on
what
hardware
it
is
it's
not
too
severe
too
fast,
but,
for
example,
utilizing
utilizing
disk
storage
for
backups
or
something
like
an
object,
search
and
using
some
backup
tool
which
can
just
use
an
object,
search
for
there
or
a
storage.
That's
one
of
the
use
case,
for
example,
where
some
users
are
covering
it,
and
you
know
just
in
general
having
it,
basically
all
in
one
which
doesn't
matter
if
you're
in
AWS,
even
though
we
have
starch
castles,
it's
always
like
the
same
thing.
A
Yeah,
providing
a
consistent
storage
solution
that
runs
wherever
kubernetes
runs,
whether
you
are
in
the
cloud
or
on-premise,
so
what
storage
providers
do?
We
have?
Okay,
great
question,
so
Steph
is
where
we
started
with
the
project.
So
three
years
ago
we
open
sourced,
announced
it
at
pukin
2016
in
Seattle
and
seth
has
progressed,
and
about
a
year
ago
we
declared
Steph
as
as
stable
in
Brooke
at
the
management
layer.
A
We.
What
we
learned
through
this
process
is
that
hey,
there's,
there's
these
patterns
that
were
we're
putting
in
place
for
storage,
where
we
can
expand
these
and
add
more
operators
that
can
manage
storage
for
other
types
of
storage
providers
and
invite
community.
We
invited
community
members
to
say,
I'll,
come
and
join
the
project
and
create
an
operator
for
for
your
storage
provider.
So
this
is
where
we
started,
adding
others
cockroach
edge
of
s
edge.
A
Fs
is
you
know,
joined
about
a
year
ago,
and
there
are
other
stored
provider
that
is
declared
stable
now
and
we'll
we'll
get
into
these
in
a
lot
more
detail
soon.
But
at
the
end
of
the
day,
each
storage
provider-
it's
community,
driven
and
we're
always
open
to
more
contributions
for
storage,
provide
for
these
storage
providers
and
and
adding
more
in
the
future,
all
right.
So
a
bit
about
architecture,
I
like
to
explain
hook
as
having
three
layers.
The
first
one
is
that
we
have
an
operator
that
provides
the
management
layer.
A
Okay,
it's
going
to
deploy
the
storage
provider
into
kubernetes.
The
next
layer
down
is
that,
depending
on
the
storage
provider,
it
needs
to.
You
need
to
provision
that
storage
like
if
it's
block
you
need
to
provision
an
RW
o
volume,
so
you
can
attach
it
to
your
pod.
So
definitely
CSI
driver
is
the
way
to
connect
your
storage
provision
and
attach
it
to
your
pods.
The
last
layer
is
the
data
layer.
A
So
this
is
what
we
call
a
storage
provider
in
rook
and
it
provides
the
actual
block,
file,
object
or
or
database
for
you,
okay,
rook
itself,
the
rook,
an
operator
or
the
CSI
driver
is
not
noticeably
not
in
the
data
layer,
but
data
layer.
We
we
feel
is
important
to
keep
separate
from
from
rook
so
that
you
know
that
when
you're
reading
and
writing
your
data,
whatever
is
on
the
data
path,
is
it
doesn't
need
to
be
managed.
A
It
needs
the
data
layer
to
take
care
of
it
and
having
data
layers
that
have
been
around
a
long
time
even
before
kubernetes
is
where
we
believe
it's
important.
You
need
a
stable
data
layer
all
right,
so
this
is
as
simple
of
the
diagram
as
I
can
come
up
with
for
how
it
works.
We
have
these
storage
operatory
providers
and
each
of
them
has
their
own
operator.
So
we've
got
the
SEF
operator
edge
of
s.
You
go
by
Cassandra
cockroach
NFS,
each
of
these
at
runtime.
A
B
Is
where
rookin
itself
comes
into
the
part
of
being
a
framework
for
storage
Provisionals
that
we
try
to
have
more
and
more
commonality
which
we
can
share
be
with
each
D
with
each
to
start
provider?
So
it's
going
to
be
more
more
easier
for
storage
providers
to
integrate
with
Luke
and
making
it
easier
in
the
end
for
the
users
of
rope
to
get
storage.
A
A
And
the
operators-
you
know
they
they
talked
to
the
kubernetes
api.
Their
purpose
in
life
is
to
take
as
much
advantage
of
kubernetes
resources
as
possible
secrets.
Services.
Daemon
sets
there's
there's
a
whole
whole
slew
of
resources
that
are
created
depending
on
again
the
needs
of
the
storage
provider.
A
You
know
some
helpers
common
policies
patterns
build
and
CI
testing
tools,
things
that
make
getting
going
and
off
the
ground,
a
little
quicker
for
for
operators
and
for
community.
We
have
an
active
slack
channel
and
github
issues,
of
course,
is
the
way
to
track
what's
happening
so
so
think
about
for
a
second,
what
it's
like
to
deploy
a
rock
operator
and
and
then
consume
that
story.
So
what
an
admin
needs
to
do
at
the
end
of
day
is
after
he's,
configured
you've,
configured
kubernetes.
A
Okay,
now
you
decide
what
storage
solution
you're
going
to
deploy
so
you'll
install
the
operator
you
say:
you'll
create
this
llamó
file,
then
you
create
the
custom
resource
for
that
storage
provider
and
then,
if
need
to
create
storage
classes,
so
that
you
define
what
you
want
to
expose
from
the
cluster
the
application
and
requests
that
storage.
If,
for
example,
with
a
PVC,
that's
mounted
into
the
pod
with
a
CSI
driver
if
needed,
and
so
that's
the
pattern
admin
owns
configuring,
the
storage
applications
get
to
consume
it.
A
So
where
are
we
going
storage
providers?
It's
all
community
driven
we're
always
open
for
new
new
contributions
and
the
more
we
we
grow.
The
more
we're
gonna
grow,
an
API
for
storage
operators,
all
right
how
to
get
started,
go
to
root.
Do
I've,
got
documentation,
blogs
and
here's
link
a
QuickStart
guide
for
how
you
try
out
rook
the
different
providers
and
get
started
and
more
about
slack,
Twitter,
etc.
You
can
see
the
slides
later
and
moving
on
to
Jared.
A
C
Alright
Thank
You,
Travis
and
Alexander
alright,
so
my
name
is
Jared
watts
and
just
like
Travis
in
Alexander.
I
am
also
one
of
the
maintainer
x'
on
this
project
and
one
of
the
founders
of
it
as
well.
So
I
have
been
involved
in
the
Brooke
project
since
it's
very
inception
you
know
about
three
years
ago
or
so
so
I've
seen
you
know
the
full
lifecycle
in
maturity
process
of
this
project,
and
so
what
I'm
going
to
talk
about
here
is
you
know
as
a
as
a
CNCs
project,
the
cloud
native
computing
foundation.
C
C
C
These
are
people
that
are
still
you
know,
they're,
not
too
risk-adverse
they're
ready
to
try
something
out
before
it's
fully
matured,
but
then
you've
got
this
chasm
phase,
and
so
that's
where
this
this
term
comes
from
this
crossing.
The
chasm
idea
is
that
the
energy
and
the
effort
that
it
takes
to
take
a
project
from
the
early
stages
and
jump
over
this
giant
chasm
into
mainstream
adoption
into
ready
for
production
deployments
type
of
thing
it's
difficult.
It
takes
a
lot
of
effort.
C
C
So
rook
is
now
in
the
middle
stage,
the
incubating
stage
we
first
donated
rook
to
the
CN
CF
in
January
2018,
in
that
sandbox
stages
for
nurturing
early
stage
projects,
but
it's
also
good
for
getting
visibility
in
alignment
with
other
CN
CF
projects.
When
we
donated
rook
to
the
CN
CF,
we
saw
a
giant
jump
up
in
pageviews
and
github
stars
and
all
sorts
of
stuff.
C
It
got
a
lot
more
people
coming
into
the
rock
project
and
it
was
a
very
good
thing
to
start
getting
a
community
built
around
it
and
accelerating
the
effort
around
it,
then
not
too
much
later
later
in
that
year,
because
we
were,
we
were
kind
of
mature,
I,
think
for
a
sandbox
project.
We
were
able
to
go
to
the
incubating
stage
where
we're
starting
to
get
early
adopters.
C
That
are,
you
know,
starting
to
show
production
usage,
and
then
it's
around
that
same
time
to
that
we
went
from
just
SF
Storage
Orchestrator
to
creating
this
rook
framework,
where
we
can
start
supporting
many
different
storage
providers
underneath
and
then
now
the
final
stage
of
the
of
a
CN
CF
project's
maturity,
the
graduation
stage,
where
you
start
getting
mainstream
adoption
and
you
know
early
mainstream
adoption.
That
is,
you
need
to
show
that
the
project
is
sustainable.
C
It's
ready
for
people
that
are
maybe
a
little
bit
less
risk
adverse
and
ready
for
people
to
really
start
adopting
it.
So
there's
eight
projects
right
now
in
the
CN
CF
that
have
gotten
to
this
graduation
stage,
with
kubernetes
being
the
very
first
one
and
then
the
rest
of
the
ones
that
we
see
there.
We
would
hope
to
be
the
ninth
one
and
we're
targeting
before
the
next
cube
con
in
Amsterdam.
If
anybody
is
going
to
be
there,
we
hope
to
see
you
there
and
we
hope
to
be
a
graduated
project
by
then.
C
These
are
just
some
numbers.
Some
stats
about
growth,
since
the
rook
project
got
to
the
incubating
stage.
So
most
everything
is
at
least
2
X
3,
o
summer
3,
X,
4
or
5
x
growth,
but
it's
I
mean
it's
been
amazing
to
see
you
know
a
little
project
that
we
started
it
with
just
a
few
people
to
grow
into
more
than
200
people
have
written
code
for
it.
You
know
we've
got
40
different
releases
out
for
it
just
thousand.
You
know
thousands
of
people
using
it
in
almost
a
hundred
million
downloads.
C
Now,
so
that's
super
excited
just
to
see
that
growth
continuing
so
what's
left
before
we
get
to
graduation.
One
big
area
is
around
security.
So
a
criteria
for
graduating
the
CNC
F
is
to
go
through
a
full
security
audit.
We
have
got
that
scheduled
to
start
in
just
a
couple
weeks
here,
and
the
trail
of
bits
is
the
security
firm
that
will
be
doing
that
for
us
and
they're
the
ones
that
did
the
security
audit
for
core
kubernetes
upstream.
C
So
everything
that
we've
seen
from
them
is
they
know
how
to
do
security,
testing
and
analysis
for
cloud
native
projects.
We're
really
excited
to
be
working
with
them,
anything
that
they
find
we
have
to
fix.
You
can't
be
a
graduated
project
with
critical
security,
vulnerabilities,
unpatched
or
unfixed,
so
we
will
take
care
of
all
those
and
we'll
need
to
get
a
security
disclosure
process
in
place.
C
If
you
find
you
know
a
severe
exploit
or
a
vulnerability
out
in
the
field,
you
need
to
have
a
process
to
disclose
that
responsibly
and
to
make
sure
that
it
gets
patched
and
fixed
and
pushed
out
to
everybody.
And
the
final
thing
is
that
the
core
infrastructure
initiative,
a
set
of
criteria-
for
you,
know,
testing
and
quality
of
your
code
and
static
analysis,
build
infrastructure,
all
sorts
of
stuff.
Where
80%
of
that
and
we'll
be
done
with
that
before
graduation
as
well,
so
the
final
slide
here
is
a
call
to
action.
C
But
if
you
want
to
keep
your
usage
private,
you
can
give
us
the
data
and
we'll
aggregate
it
anonymously,
and
you
don't
have
to
share
your
company
name
publicly.
If
that's
not
something
you're
comfortable
with,
but
we
want
to
hear
from
you
if
you're,
using
rock
in
production
all
right
so
now
it's
time
to
jump
into
the
storage
providers
and
some
of
the
deep
dives
they're
in
is
set
first
yep.
D
A
C
A
E
So,
on
to
Seth
I'm
sebastio
I
work
for
reddit
I'm,
one
of
the
maintenance
for
the
rooks
eff
portion,
and
now
we
will
be
diving
into
Seth
first,
like
from
the
audience
who
is
running
safe
in
production
today
about
like
ten
percent
of
the
room.
Maybe
ok!
So
what
is
Seth?
So
that's,
probably
the
shortest
definition.
I
could
come
up
with
about
Seth.
E
So
essentially,
sap
is
an
open
source
attributed
storage
to
software-defined
solution
that
allows
you
to
consume
your
data
through
several
interfaces,
such
as
object,
block
and
file,
and-
and
this
is
something
that
is
really
unique.
When
you
look
when
you
look
at
the
ecosystem
today,
you
will
rarely
found
solutions,
storage
solution
or
a
capable
of
exposing
these
three
interfaces,
so
essentially
itself
is
built
on
top
of
what
we
call
a
dose
and
a
dose
is
an
object
store.
Radice
is
more
like,
like
an
entity.
E
It
has
no
real
representation
as
well
as
per
se,
because
rattles
is
made
of
a
lot
of
demons
that
we
will
see
in
a
second
but
think
of
rattles,
as
as
a
globally
distributed
object
system
that
replicates
that
are
recovers
data.
Scrubs
data
and
make
sure
that
if
something
goes
wrong,
the
data
gets
gets
recovered
on
top
of
the
object
store
without
three
main
interfaces.
That,
as
I
said,
allows
you
to
expose
our
data
through
server
interfaces.
So
the
first
one
is
Colorado's
gateway.
E
Essentially,
rattles
gateway
is
really
similar
to
Amazon
s3
or
OpenStack.
Swift
yeah
open
stacks
web
and
really
exposes
the
f3
API.
It's.
It
has
multiple
capabilities
such
as
multi-site
replication
and
active
passive
replication.
So
you
can
replicate
data
across
zones
in
regions,
so
it's
actually
pretty
powerful
and
and
obviously
this
does
object
at
rest.
The
second
building
block
from
Saif
is
called
our
BD
for
Radames
block
devices
in
this
in
this
or
BD
is
divided
into
two
one
part
is
a
criminal
module
which
really
resembles
to
what
we
do
with
vise
cozy.
E
So
you
map
a
block
device
onto
a
machine
and
then
you
can
consume
it.
Then
we
have
a
plug-in
for
hypervisors,
so
we
really
work
closely
with
qk
VM
so
that
we
can
create
a
network
or
BD
block
devices
and
attach
them
to
virtual
machines.
Well
and
we
really
integrate
at
the
core
storage
engine
level
of
cream.you.
So
basically,
when
you
attach
a
block
device
from
seft
and
you
once
it
gets
exposed
into
the
virtual
machine,
you
will
never
know
that
is
the
self
underneath
just
G's
block
devices
or
sparse
by
nature.
E
They
support
snapshots
cloning,
copyright,
copyright
and
they
have
many
functionalities
and
they
have
been
really
useful
in
the
hypervisor
world.
Then
the
last
not
the
least,
the
distributed
file
system
portion
so
typically
with
a
traditional
distributed
file
system
or
how
they
used
to
be
designed
for
the
past,
10
or
15
years.
Is
that
you
we
always
had
that
single
pole
of
contention.
E
I
should
say
an
almost
a
failure:
bottom,
the
metadata
server
with
staff
we
can
have
as
many
mirror
as
metadata
services.
We
want,
we
can
chain
them
change
them
all
together
and
we
we
have
several
modes
for
that.
We
can
have
what's
10
bars
and
everything,
but
that's
really
the
design
makes
it
so
that
we
can
really
scale
that
a
large
growth.
Obviously
this
is
POSIX
compliant.
So
it
really
supports
all
the
POSIX
semantics.
E
So
now
that
you're
a
little
bit
more
familiar
with
SAP,
we
will
dive
into
the
roots
of
architecture
and
how
love
all
the
bits
and
pieces
are
together.
So
if
you
look
at
the
blue
boxes,
they
represent
what
rook
is
going
to
deploy,
so
these
are
actually
no.
No.
These
are
actually
the
rook
components,
so
we
have
a
rogue
discovery,
demand
and
the
rook
up
operator.
So
briefly,
the
group
discovery
daemon
is
responsible
for
scanning
devices
on
one
machine.
E
So
if
you
decide
to
use
all
the
drives
from
your
machine,
then
it
will
basically
look
at
what's
available.
What's
what
drives
are
good
candidates
to
become
part
of
your
storage
cluster
and,
if
that's
the
case,
then
they
will
group
will
use
these
drives
so
that
you
can
create
a
scepter
astern.
The
ruko
operator
is
essentially
the
brain
of
everything.
It
is
really
responsible
for
bootstrapping
self,
maintaining
it
configuring
it
running
the
upgrades
everything
the
entire
lifecycle
will
be
managed
by
rook.
At
this
point,
the
green
boxes
represent
CSI,
as
Travis
mentioned.
E
So
Luke
has
two
missions.
When
it
comes
to
managing
storage
technologies,
the
first
one
is
to
deploy
it
when
the
second
is
also
to
provide
persistent
storage
to
containers
and
CSI.
Does
that
for
us?
Csi
is
really
divided
into
two,
because
we
support
our
block
implementation
as
well
as
our
file
system
implementation.
So
the
provisioner
here
is
responsible
for
big
for
acknowledging
your
PVC
requests.
When
you,
when
you
claim
a
volume,
then
it
will
go
ahead
and
create
that
volume,
then
the
plug-in
in
that
case
can
be
concluded.
E
The
attached
or
two
will
run
on
all
the
nodes
where
all
your
applications
are
running
and
it
will
attach
these
block
devices.
So
if
it's,
if
it's
a
block,
it
will
map
that
block
and
expose
it,
and
if
it's
a
file
system
it
will
mount
it,
then
the
red
boxes.
We
present
the
safe
demons.
So,
yes,
there
are
many
of
them,
and
that
may
be
it
at
first.
E
This
can
be
a
little
bit
overwhelming,
but
this
is
also
something
that
is
really
unique
with
self
is
that
it
was
created
more
than
fifteen
years
ago,
and
it
has
like
tens
of
really
active
development,
but
from
the
get-go.
It
was
really
designed
in
a
macro
service-oriented
fashion,
and
now
these
days
we
we
have
all
started,
realizing
that
this
is
how
apps
should
be
developed.
E
So
it's
kind
of
cool
to
to
have
that
sort
of
vision,
so
I'm
gonna
not
going
to
dive
into
each
of
them,
but
essentially
I
will
just
focus
on
the
months
and
us
these
here.
So
the
monitors
are
essentially
the
brain
of
the
cluster.
They
maintain
membership,
they
maintain
the
cluster
maps
everything.
So
if
the
months
are
done,
then
you
have
a
big
problem.
E
Then
we
have
do.
Sd
is
the
object,
storage
demons.
They
are
basically
making
the
storage
available
here.
So
what
we
do
is
we
have
a
single
drive
for
OSD
and
also
the
man
has
some
storage
too,
as
you
can
see,
because
it
has
a
little
key
value
database
to
store
all
of
the
information
from
the
cluster.
It's
pretty
lightweight.
It's
like
two
gigs
or
something,
and
we
so
we
never
go
beyond
that
size
for
or
is
this?
Obviously
it's
really
related
to
the
size
of
the
block
device.
E
So
when
it
comes
to
provisioning
storage
from
work
now
that
we
have
root
conserve,
deployed
CSF
in
CSI,
is
there
too
and
it
and
it's
ready
to
answer
any
previously
requests
so
see.
If
we
stopped
by
the
very
left,
we
have
the
block
implementation.
So
let's
say
you
have
a
regular
app
and
then
you're
asking
you're,
claiming
a
volume
for
all
wo,
so
read
write
once
essentially.
E
What
you
do
here
is
that
you're
asking
for
block
device
to
be
mapped
on
one
machine
and
exposed
into
a
container
and
then
only
a
single
application
can
run
on
it.
When
you
do
that
request.
This
goes
to
the
orbity
storage
class
and
then
goes
through
the
CSI
or
BD
provider
to
acknowledge
and
create
that
volume
for
the
files.
Then
you
can
well
the
block
implementation
can
do
that
too.
E
It
works
both
ways
you
can
do
or
wrw
works,
but
I'll
explain
that
later
too,
in
the
slides
in
the
file
example,
then
you
can
obviously
have
or
wo,
but
you
can
also
have
all
the
body
wax
readwrite
many
where
you
can
mount
a
filesystem
on
many
nodes
and
then
access
it
and
consume
it
Rhian
in
a
read/write
fashion
through
all
of
your
applications.
So
same
point
same
same
man
points
same
data
across
multiple
hosts
again,
when
you
do
that
claim.
E
This
goes
into
the
storage
class
force
ffs
and
then
it
gets
on
to
the
CSI
driver
to
again
create
that
little
portion
of
the
filesystem.
If
you're
working
at
arrest-
and
you
have
an
app
that
lets
say
talks
as
three,
then
what
you
can
do
is
do
a
bucket
clamp.
So
this
is
something
again
that
is
a
really
unique
book,
and
that
is
something
that
actually
does
not
existence
in
communities
at
all.
There
is
no
such
thing
as
claiming
a
bucket.
The
only
thing
you
can
claim
at
this
point
in
Cuban
Aries
is
volumes.
E
They
can
be
filed
file
based
or
they
can
be
other
block
based,
but
there
is
no
mechanism
in
yet
and
we
hope
to
push
down
to
Cuba
this
course
soon
to
actually
claim
a
bucket.
We
look
has
the
ability
to
bootstrap
gateways,
but
when
your
end
user,
you,
don't
you
don't
really
want
to
have
a
gateway.
What
you
want
is
actually
a
bucket
so
that
you
can
consume
it.
So
in
that
case,
what
you
do
is
you
just
claim
for
a
bucket?
E
This
goes
through
the
search
class
object
and
the
bucket
provisioner,
and
then
it
will
create
for
you
that
bucket
and
generate
credentials
for
user
and
keys
and
store
them
as
secrets,
so
that
you
can
then
mount
it
into
your
pods
and
consume
them
from
your
app
in
terms
of
data
path.
So
now
we
know
what
the
workflow
looks
like
when
you're
claiming
for
data
but
like
underneath
what
is
actually
happening.
So
if
we
start
again
from
the
left,
we
see
that
we
have
an
app
that
has
a
block
device.
E
It's
a
knob
or
the
body
also
read/write,
once
again
essentially
what's
happening.
Underneath
is
that
we
are
creating
a
block
device
and
we
mapping
that
block
device
using
the
kernel
module
and
then
again
we
mount
and
explain
once
that
block
into
a
container.
So
again,
so
the
new
app
can
consume
it
later
on.
E
The
RBD
driver
will
simply
talk
to
the
stuff
cluster
natively,
so
it
will
talk
to
many
OS
DS
and
will
also
have
a
connection
to
the
month
so
that
it
can
get
the
map
of
the
cluster
going
back
to
the
middle
for
the
file
use
case,
so
we
claimed
for
all
the
value
of
x
and
or
other
value.
Well,
what
is
happening
here
is
that
essentially
on
the
host,
where
your
application
paws
are
running,
what's
going
to
happen
is
that
we
will
announce.
E
Oh,
the
CSI
driver
will
mount
a
staff
filesystem
via
a
fiscal
driver
and
again
that
main
point
will
be
interacting
with
the
surf
twisters.
So
essentially
it
will
be
connected
to
the
one
or
many
MTS's
so
that
it
exposes
the
file
system
interface
and
then
again,
one
or
many
OS
these,
so
that
they
can
write
data
know
the
MDS
is
not
actually
storing
any
data.
So
everything
that
comes
to
the
file
system
metadata
or
stored
as
object
in
inner
arrows.
E
E
E
So
now
we're
gonna
see
how
we
can
get
started.
I
can
see
some
of
you
already
are
really
into
it,
so
it
is
really
easy
to
deploy
itself.
So
we
have
three
ml
files,
essentially
so
the
first
one
we
call
it
common.
It's
it
has
all
the
service
accounts
or
the
our
backs
that
all
the
authorizations
that
the
rook
operator
needs
to
run
in
communities.
Then
we
have
the
operator
Yama,
which
will
create
the
aruch
operator.
Once
we
have
done
that,
then
we
will
inject
a
cluster
C
R.
E
So
here
the
SEF
twister
is
a
new
kind,
so
we
we
have.
As
Travis
mentioned,
we
have
to
your
strd
for
a
staff
cluster
and
then
we
now
what
we
do
is
like.
We
are
in
instant
shading
that
CR
CR
D
with
by
injecting
that
CR
via
the
twister
document.
So
it
is
really
easy
to
get
started
with
Brooke
I
wish
we
I
wish.
We
had
put
a
little
description
of
that
just
about
yellow,
but
just
to
give
you
a
brief
overview,
it's
like
really
literally
ten
lines
of
llamó.
E
By
the
way
you
can
create
a
new
storage
class
which
will
either
point
to
or
videos
ffs,
and
then
you
can
go
ahead
and
create
your
first
PVC
and
attach
it
to
your
first
application
pot
and
also
what
what's,
what's
really
I
guess,
what's
very
appealing
with
the
implementation
that
we
have
is
because
we
have
this
root
living
entity
in
the
kubernetes
cluster
upgrades
are
made
so
easy
now.
So
if
you
want
to
upgrade
the
rook
operator,
it's
really
easy.
E
So
we
have
an
image
spanking
the
llamó,
and
then
you
just
you,
can
edit
it
or
just
patch
it
with
a
new
version
of
the
image
and
then
that's
gonna
roll
out
a
new
version
of
the
operator
force.
F,
it's
exactly
the
same
mechanism.
What
we
will
do
is
just
edit
the
CR
and
then
change
the
image
version
which
points
to
a
different
version
of
the
safe
cluster.
So
it
can
be
a
minor
upgrade
or
it
can
be
a
major
upgrade.
E
E
Then
we
check
if
the
mount
is
back
in
courtroom
and
then
we
go
on
and
on
for
the
oysters
that
we
have
a
really
similar
process
to
make
sure
that
teachers
are
reconciling
when
we
restarted
choice,
DS
and
then
we
we
continue
just
like
that,
so
this
is
self
upgrade.
If
you're
familiar
with
staff,
you
should
know
that
surfer
grade
has
always
been
really
easy
to
do
and
really
safe
to
do
as
well,
and
what
we
did
here
is
like
really.
E
We
really
improved
that
over
all
of
good
experience
using
rooks,
so
all
the
little
bits
and
pieces
that
you
have
to
all
the
little
actions
you
have
to
perform
when
an
upgrade
is
done,
then
we
take
care
of
that
too.
So
it's
like
really
transparent
for
you,
there's
no
interruption
of
servers
there
is.
There
is
nothing!
Everything
is
running
upgrade
some
of
the
new
features
that
we
have
been
adding
recently
as
part
of
group.
E
One
one
configuration
in
cron
environments,
I
have
to
assume
it
at
first
I
was
a
little
bit
surprised
that
they
were
such
a
high
demand
of
running
all
of
that
into
the
cloud.
But
so
because
of
that
request,
we
had
to
do
some
so
remember
that
demands
and
the
OSD
they
require
storage.
So
what
we
do
essentially
is
that
we
we
allowed
these
demons
to
run
on
PVC.
E
So
because,
if
you
run
on
a
cloud
you
have
virtual
machines,
then
this
is
where
you
could
banish
crystal
lives
and
then,
if
you
want
to
add
storage
to
it,
then
before
we
did
that
you
had
to
create
block
devices
and
attach
them
to
virtual
machines,
which
was
actually
quite
painful
and
it
it
was
really
killing
the
smooth
experience
that
you
should
be
getting
when
you
get
through.
So
now
we
have
that,
and
so
each
the
each
of
the
little
block
devices
here
or
actually
like
if
you,
for
example,
Amazon.
This
is
maybe
as
volume.
E
So
why
would
you
well?
What
would
you
run
some
rook
and
surf
in
a
client
vironment?
So
this
will?
This
will
really
provide
you.
A
consistent
experience,
iStent
experience,
whether
you
run
on
any
cloud
provider.
So
it's
a
really
reputable
process
that
you
can
apply
to
any
cloud
provider.
So
that's
something
first
is
really
useful
and
then,
by
doing
this,
you
could
also
potentially
overcome
some
of
some
of
the
limitations
that
are
coming
with
the
cloud
providers.
One
of
them
could
be-
and
it's
already
true
for
some
of
the
providers
you
cannot
have.
E
You
cannot
attach
storage
coming
from
different
AZ's,
and
that
is
that
is
made
possible,
because
what
you
can
do
here
for
with
us
is
just
to
stretch
out
your
cluster
on
two
different
AZ's
and
then
consume
block
devices
from
although
easy.
So
what
you
do
essentially
here
is
that
you're,
creating
a
bigger
failure,
failure,
domains
and
the
your
data
should
be
a
little
bit
more
highly
visible,
also
slower.
We
can
more
quickly
respond
to
attach
and
detach.
E
So
if,
if
VM
dies-
and
you
have
to
reschedule
it
and
then
reattach
the
block
device,
it
can
take
minutes
to
reattach
that
block
device
on
to
that
VM.
But
with
us
we
this
this
goes
down
to
seconds
when
the
VM,
if
an
application,
if
at
the
end
that
is
hosting
applications,
goes
down,
then
we
can
reschedule
it
and
then
we
will
reattach
all
the
blog
or
BD
blog
devices
in
a
matter
of
a
sec.
Also,
you
can
also
potentially
overcome
some
limitations.
E
E
So
that's
quite
a
lot
and
you
will
never
probably
reach
that
amount,
but
anyways
and
also
last
but
not
least,
is
that
if
you,
if
you
want
to
use
the
search
class
from
your
cloud
provider
directly
what
you
will
be
getting,
if
you
ask
for
a
10
gig
volume,
you
will
be
getting
I
ops
per
gig,
I,
think
and
then
what's
going
to
happen
here
is
that
you
will
be
limited
by
these
10
Giga
ops
were
in
our
case.
We
are
really
aggregating
terabytes
of
Blagh
Blagh
devices.
E
We
support
all
the
types
of
storage
access
or
W,
so
read,
write
once
read,
write
mini,
read,
write
read
only
many
for
both
snapshots
are
still
alpha
because
of
the
CSI
spec
was
disapointing
flex
driver
because
because
because
CSI
hasn't
reached
feature
parity,
yet
with
Flex
object,
we
can
provisioning.
I
already
mentioned
that
in
the
earlier
diagrams
you
can
now
create
you
can
now
claim
for
buckets
instead
of
volumes
for
Brooke,
oh
wow,
so
external
cluster
connection,
not
everything
is
a
Greenfield.
You
also
have
brownfield
environments.
E
Really
easy:
it's
just
you
just
need
to
to
inject
mons.
Ip
cluster,
FS,
ID
and
I
mean
curing
any
good
to
go
topology
or
nurse.
It's
something
that
we
really
offer
coming
because
of
limitation
from
Cuba
debt
is
accumulate,
only
knows
about
zone
in
regions
will
be
added
more,
so
we
can
have
a
more
filling
grained
allocation
of
where
you
actually
host
or
running,
and
how
your
data
is
being
spread
across
your
cluster.
E
A
D
Great,
take
it
away:
Lia
hi,
my
name
is
Lia
Griffith
co
and
I
manage
a
G
first
project.
So
what
is
Luca
a
fast
right?
It's
deployed
s
kubernetes
operator.
It
provides
a
full
lifecycle
management,
so
installation
update,
installed
reinstalled
rolling
upgrades.
We
do
provide
UI.
This
building
see
our
divisor.
D
We
also
it
comes
with
monitoring
with
Prometheus
graph
Arnhem
transfer
cloud.
Any
cloud
hit
runs
on
premise,
so
it's
multi
cloud
storage
platform.
We
can
support,
we
can
consume
local
ro
disk.
We
consume
directory
teas
directories.
We
can
consume
key
value
storage
as
of
latest
release
and,
of
course,
cloud
resources
as
well.
D
D
D
D
D
D
So
we're
capable
snapshotting
buckets
billion
of
objects,
clone
bike
at
any
time
at
any
connected
segment.
I
can
out
dive
into
it
shortly.
We
recently
added
support
for
key
value
based
storage
right,
so
it
can
run
on
top
of
any
key
value
or
capable
back-end,
and
we
also
support
some
some
key
value
based
SSDs.
D
We
also
support
you
know
using
row
disks
a
hybrid
of
row,
disks
and
s3.
So,
for
example,
you
know
chunks
can
go
into
s3
and
your
metadata
will
see
it
in
your
abs,
for
example,
packet
snapshots,
so
buckle
snapshots
are
instantaneous
within
a
single
segment
and
it's
eventually
consistent
across
other
segments
that
might
see
them
different
clouds,
for
example.
D
So
it
scales
to
billions
of
objects
we
integrate
with
dataflow
topologies,
so
we
have
what
you
call
is
GW,
it's
intersegmental
get
way.
So
the
idea
is
that
you
have
segments
you
know
sitting
across
different
clouds
and
we
replicate
data
across
and
if
we
can
create
very
complex
topologies,
we
can
do
full
mesh,
topology,
start
formation
or
just
a
changing
data
flow,
for
example
to
your
backup
and
to
archive
use
case,
etc
so
operations
we
do
support
snob
snapshot
and
clone
operations,
and
we
support
multiple
object
types
support
s3.
D
D
Okay.
So
what
what
do
we
call
segments
right?
You
might
have
a
kubernetes
cluster
running
in
one
cloud
and
Asia
may
be
in
the
same
cloud
and
as
a
region
or
in
different
cloud,
maybe
some
on-premise.
So
what
we
do
we
deploy
an
edge
of
s
on
each.
You
know
an
in
each
individual
cloud
and
if
you
create
segments-
and
then
we
interconnect
those
segments
to
make
sure
that
your
data
flow
data
flows
from
one
segment
to
another
and
that's
what
I
mean
by
different
apologists.
D
D
So
the
multi
cloud
layer
right
so
gos
capability
right.
So
we
can
really
spin
our
our
storage
across
geo
geo
distributed
sides,
multiple
clouds
or
on-premise.
We
do
use
get
like
architecture
right,
so
everything
is
immutable
with
version.
We
do
support
many
protocols
on
top
again
file
block
object,
no
sequel
and
actually
soon
sequel.
So
it
is
zero
transparency,
it's
always
on
and
it's
bi-directional
access
to
the
same
as
through
bottom.
So
what
does
it
mean?
D
You
have
s3
bucket
in
one
cloud,
you
can
read
right
to
it
at
the
same
time,
it's
being
replicated
to
another
cloud
and
you
can
bidirectionally
read
right
to
it
as
well.
At
the
same
time,
right
so
automatic
last
writer
wins
update
strategy,
keep
in
mind
it's
eventually
consistent
across
multiple
sides.
Multiple
regions
we
do
have
active
caching,
so
metadata
is
always
replicated
that
is
prefetch,
on-demand
cache
locally
for
disaster
recovery.
You
might
want
to
actually
enable
data
to
be
replicated
as
well
by
default.
D
So
what
are
the
use
cases
for
our
project
right
so
use
case
number
one
is
multi-cloud
CDN.
Basically,
with
our
caching
capabilities.
We
also
can
do
cloud
high
availability
right.
We
can
basically
connect
different
clouds
and
you
know
if
you
need
to
fail
over
to
a
different
cloud
and
your
placate.
You
can
do
that
as
rating
cloud,
so
capture
edge
data,
local
cache
and
run
your
machine
learning
in
the
cloud.
D
The
duplicate
data
send
data
synchronously,
so
kubernetes
persistent
volumes
across
clouds,
so
we
have
CSI
support.
We
support
all
the
latest
features.
We
get
bi-directional
TVs
across
regions
fully
replicated
yeah
and
you
get
the
consistency
groups
as
well
survey
data
segmentation
region,
awareness
as
well.
F
D
Essentially,
what
we
are
very
data
fabric
right.
We
help
you
manage
your
data
across
multiple
sites.
We
handle
all
the
data
flow.
We
give
you
multiple
access
across
multiple
protocols.
You
know
bi-directional
access,
we
manage
everything
for
you
and
you
just
go
in
in,
and
you
consume
this
data
obligations.
It
is
a
distributed
system.
Our
metadata
as
well,
is
fully
distributed.
There
is
no
single
knot
that
holds
metadata
can
be
a
failure.
Everything
is
chunked
up
and
spread
out
across
your
entire
cluster,
including
metadata.
So
there
is
no
single
point
of
failure.
A
You
Ilya
so
now
moving
from
ours.
Our
core
storage
providers
on
to
our
database
providers
will
turn
the
time
over
to
you
go
by
DB
who
Sid
from
you
by
to
be
who
and
you
go
by
to
be
just
joined
rook
in
version
1.1
a
couple
months
ago
in
September.
So
he'll
tell
us
all
about
that
and
let's
see
if
we
can
transfer
laptops.
F
Hello,
everybody
really
excited
to
be
talking
about
yoga
by
DB
here
today
to
the
root
community
before
I
get
started,
just
a
show
of
hands
who
has
heard
of
yoga
by
DB
before
oh
wow
I'm
impressed,
we
had
a
newer
project
so
glad
to
see.
All
of
you
are
already
aware
of
it.
I
want
to
sort
of
just
take
a
few
minutes,
lay
down
why
even
create
a
new
database
and
then
we'll
dive
into
the
details
of
our
cooperator,
so
I
think
it's
high
time.
F
We
as
builders
of
applications
and
infrastructure,
ask
ourselves
what
is
the
right
database
architecture
for
the
micro
services
and
multi-cloud
era
that
we
live
in.
If
I
take
the
micro
services
world,
it
essentially
puts
onus
on
its
data
tier
for
two
critical
things.
One
is
data
modelling.
How
do
I
model
the
structures
that
my
my
my
application
logic
depends
on
and
over
the
years
structured
query,
language
SQL
has
proven
itself
to
be
the
lingua
franca
for
modeling.
The
reason
is,
it's
very
powerful.
You
can
start
very
simple
constructs.
F
You
can
model
a
key
value
app
on
SQL,
but
if
you
want
to
go
deeper
and
you
want
to
have
the
data
base
do
little
bit
more
work
on
your
behalf
with
things
like
foreign
keys
joints,
multirow
acid
transactions,
all
those
are
literally
in
almost
every
SQL
database
right
this,
the
biggest
challenge
when
an
SQL
over
the
years
has
been
that
it
has
always
lived
in
the
monolithic
era,
one
writer
node.
That
has
to
do
all
the
hard
work
right.
F
So
as
we
distribute
we
create
distributed
applications,
we
create
micro
services.
Some
of
them
have
to
take
lots
of
processing
lots
of
ingest
and
some
of
them
may
not,
but
doesn't
matter.
Your
database
needs
to
be
able
to
serve
both
that
small
workload
as
well
as
that
massive
workload
right
and
and
hopefully
with
a
clear
linear,
scalable
path.
So
those
two
are
the
needs
from
the
micro
services.
Now,
let's
look
at
the
other
part,
which
is
the
infrastructure
on
which
these
apps
and
databases
run
out.
F
We
are
in
the
multi
cloud
era.
There
is
no
denying
on
that.
All
the
people
here
are
testament
to
that,
and
that
means
that
we
are
all
running
on
commodity
infrastructure,
that
we
are
sharing
with
lots
of
other
people.
That's
how
we
get
economies
of
scale,
that's
how
we're
able
to
instantaneously
spin
up
a
VM
spin
up
a
disk
in
the
cloud
and
you
know,
run
our
applications
on
top
of
it
right
and
the
more
different
clouds
of
we
use
the
more
unpredictable
unreliable.
F
Essentially,
that
infrastructure
is
so
ability
to
tolerate
failures,
whether
it
be
a
disk
failure,
node
failure,
zone
failure,
region
failure
or
a
cloud
failure
needs
to
be
a
fundamental,
constant
built
into
the
database
itself.
You
can
no
longer
rely
on
some
replication
library
to
come
to
your
rescue
at
3:00
a.m.
F
last
but
not
least,
it's
the
whole
aspect
of
geo
distribution.
I.
Think
if
I
combine
the
top
for
cloud
providers,
including,
let's
say
Alibaba
as
well,
the
number
of
data
centers
that
are
programmable
as
app
and
infrastructure
developers
in
front
of
us
is
about
200.
Now
we
can
all
say
we
don't
want
to
build
your
distributed
applications
and
not
exploit
the
infrastructure
that
has
been
provisioned
in
front
of
us,
but
the
companies
that
will
gain
competitive
advantage
is
who
can
build.
F
Those
applications
build
low,
latency
experiences
for
their
users,
whether
it
be
the
retailer's
of
the
future,
the
financial
services
of
the
future,
the
online
gaming
companies
of
the
future.
Those
are
the
ones
that
will
survive
with
that
with
those
four
characteristics
in
mind,
we
are
excited,
be
a
part
of
this
new
class
of
databases
called
distributed,
sequel
databases
which
focus
on
developer
agility
around
the
aspects
of
modeling
and
then
also
on
the
operational
efficiency,
around
scaling
resilience
and,
finally,
those
experiences
for
end-user
facing
applications
that
allow
us
to
build
competitive
advantages
in
our
business.
F
With
that
I
introduce
you
gabbai
DB,
which
is
a
distributed
sequel
database.
On
top
of
that
is
three
additional
things.
It
is
hundred
percent
open
source,
which
is
very
different
than
all
the
other
database
companies
in
in
the
last
one
year.
There
is
no
open
code
project.
There
are
not
two
editions
of
the
database.
Every
enterprise
grade
feature
backup
security
change,
data
capture,
s
synchronous,
replication
into
a
second
region.
All
those
aspects
are
built
into
the
core
of
the
database,
we're
very
proud
of
that,
and
we
have
a
very
growing
fast
growing
community.
F
You
know
helping
us
grow
the
database
even
further.
Secondly,
it's
about
low
latency
applications.
It
has
been
engineered
with
giving
you
millisecond
level
rights
and
some
millisecond
level
reads
in
the
cloud
and
last,
but
now
it's
works
beautifully
inside
an
ephemeral
infrastructure
like
kubernetes
and
I'll
touch
upon
why
it
makes
so
much
more
sense.
F
We
are
a
Google
spanner
inspired
database.
That
means
our
sharding
replication
and
multi.
Shard
acid
transactions
are
modeled
after
the
Google
spanner
papers.
What
that
means
is
the
the
the
data
service,
which
is
the
ybt
server
service
you
see
on
the
top,
is
essentially
the
database
that
is
taking
a
table
and
automatically
sharding
it,
placing
it
across
multiple
fault,
placing
those
shards
across
multiple
fault,
domains
automatically
and
then
creating
additional
crappies
and
placing
them
across
multiple
fault
domains
automatically,
so
that
not
only
you
can
derive
additional
right
scalability
by
just
simply
adding
nodes.
F
If
you
know
stateful
sets
it's,
it
gives
you
those
properties
of
single
identity
or
consistent
identity
that
doesn't
change
across
restarts,
and
it
also
requires
all
the
services
to
be
all
the
parts
to
be
exposed.
Wire
and
headless
service
that
you
would
connect
to
and
you
can
actually
individually
talk
to
each
node
using
that
headless
service.
So
two
stateful
sets
YB
Master
4
y
VT
y
BT
server
and
YB
master
modeled
as
a
model
inside
kubernetes
alongside
their
respective
headless
and
nui
services.
F
Now
comes
the
storage,
and
this
is
where
we
are
very
excited
with
to
be
partnering
with
with
Luke.
You
can
attach
local
volumes
as
well
as
remote
volumes.
Local
volumes
are
great
for
low
latency
applications,
but
obviously
they
will
go
away
if
the
pod
goes
away,
but
with
a
replicated
fully
replicated
strongly
consistent
database
like
yoga
by
DV.
F
Experience
is
very
exciting:
I
saw
the
same
commands
I
think
when
chef
was
showing
their
operator
you
essentially
just
gives
it
will
create
the
OP,
the
operator
gamal
and
do
cubes.
It
will
create
cluster
amyl
and
bingo.
You
have
your
database
cluster
now
running
on
on
whatever
kubernetes
cluster
you
were
deployed
on
and
then
your
application
can
connect
to
the
ybt
server
headless
service.
That
was
provisioned
on
your
behalf
with
that.
Let
me
do
a
quick,
very
short
demo.
F
Okay,
so
here
I
have
a
gke
cluster
running
three
nodes:
I
am
gonna.
Do
first
I
will
install
the
operator
the
deploy
the
operator
I'll
open
the
operator
up
and
show
you
it.
It
has
all
the
custom
resource
definitions,
cluster,
roll
cluster
roll
binding
service
account
all
that
sort
of
the
blue
logic
that
is
necessary
to
bring
the
storage
plus
the
database
come
alive
to
you
as
a
single
construct,
backup
we
do
that
and
then
we
see
that
it
has
come
up
perfectly.
F
Let's,
let's
first
create
the
operator,
its
instantaneous,
it
created
all
those
new
objects
and
then
now
it's
trying
to
create
the
actual
cluster.
Let's
see
what
the
cluster
actually
looks
like,
and
it
has
got
those
two
services
that
I
introduced
to
you:
the
database
service,
which
is
ybt
server.
The
conflict
management
service,
which
is
why
be
master
each
created
with
three
replicas
as
you
scale,
if
you
add
more
replicas,
your
YV
master
does
not
need
to
scale
because
it's
just
a
highly
available
service
doesn't
take
the
database.
F
Actual
application
requests
your
ybt
server
service
scales
horizontally
to
as
many
numbers
as
you
like.
The
beauty
of
the
Google
spanner
design
is
that
there
is
no
single
point
of
performance
or
availability
bottleneck.
So,
as
a
result,
you
can
scale
to
literally
hundreds
thousands
of
nodes
if
you
so
desire.
F
So
my
my
cluster
is
now
up
and
running.
I
can
do
it
describe
and
see
those
those
objects
that
were
that
that
were
deployed
there
you
go
and
then
let
me
speed
it
up.
A
little
bit.
I
will
be
able
to
these.
These
are
the
services
that
were
deployed,
and
now
what
I'm
going
to
do
is
actually
log
into
a
sequel,
client,
command-line,
client
I
will
create
a.
We
are
a
Postgres
compatible
database.
F
So
that's
why
you
see
the
Postgres
prompt
on
top
of
that
I'm,
creating
a
table,
a
very
simple
table
with
work
at
20
as
the
length
I'll
insert
something
and
then
I'll
read
it
back.
I
could
have
read
it
back
from
one
of
the
other.
Replicas
I
would
have
got
the
same
answer,
and
even
if
I
have
loss
of
my
one
of
my
replicas
does
not
matter
the
date.
As
I
mentioned,
the
data
is
still
persisted
in
the
two
other
copies
and
they
would
have.
F
One
of
them
would
have
been
promoted
to
a
leader,
and
the
right
should
have
continued.
That's
all
I
had
as
a
next
step
will
love
for
you
to
try
it
out
yourself.
Give
us
feedback
on
the
rook
Channel
we're
all
members
of
the
channel
on
on
our
own
slack
channel
file.
Your
request
on
github
would
love
to
get
your
experiences
so
that
we
can
to
take
the
integration
forwards
towards
beta
and
then
stable.
Thank
you.
A
Thank
you
said
and
there's
you
good
bite
for
you.
So
last
and
definitely
not
least,
we
have
Yanni's
to
present
Cassandra
the
Cassandra
operator
to
us
if
I
can
get
this
plugged
back
in
and
we
should
have
some
time
at
the
end
for
for
questions
so
stay
tuned.
If
you
have
questions
you'd
like
to
follow
up
on
all
right,
thanks.
G
G
Alright
hi
everyone,
my
name
is
Yanni's
I'm,
a
software
engineer
at
Torito
and
today
we're
going
to
talk
about
the
route
Cassandra
operator.
So,
let's
start
with
a
little
bit
of
an
overview
of
what
Cassandra
actually
is
so
Cassandra
is
a
distributed,
no
sequel
database,
the
smollett
unit
in
Cassandra
is
a
member,
so
multiple
members
will
form
a
rack
and
multiple
racks
will
form
a
data
center
and
multiple
data
centers
will
form
a
cluster
and
this
what
Cassandra
is
now
its
data
center?
G
You
usually
put
in
a
different
region
and
you
have
a
globally
distributed
database.
So,
let's
use
of
the
abstractions
that
Cassandra
is
making.
Let's
see
how
we
map
those
abstractions
to
get
Burnett's
abstractions.
So
a
Cassandra
member
is
mapped
to
a
keeper
near
the
spot
and
to
your
right.
You
can
also
see
the
Cassandra
resource
definition,
and
this
is
what
they
usually,
what
the
user
actually
writes
to
deploy.
G
Cassandra
cluster,
so
I'm
Cassandra
member
is
mop
two
equivalent
this
pod,
a
Cassandra
rack,
is
mapped
to
accumulate
the
stateful
set
and
multiple
Cassandra
racks,
which
form
a
data
center.
Our
for
our
mob
to
multiple
state
stateful
sets
and
finally,
a
Cassandra
cluster
is
mapped
to
the
cluster
custom
resource.
G
So
what
actions
do
we
actually
support?
Right?
Now
we
can
deploy
a
Cassandra
cluster
in
multiple
availability
zones.
We
can
also
scale
it
up
and
we
can
also
scale
down
and
remove
members
in
the
same
way
with
with
redistribution
of
the
data.
This
is
the
rule
issue
that
we
used
to
track
the
functionality
and
I
invite
you
to
take
a
look
so
a
feature
that
we're
kind
of
looking
into
right
now
is
how
we
can
support
local
storage
in
Cassandra.
So
we
have
local
storage
and
we
have
network
at
that
storage.
G
Most
of
you
probably
are
using
the
second
kind
with
like
EBS
or
say
for
Google
persistent
disk,
and
this
is
the
kind
of
storage
that
is
replicated
over
into
the
network.
So
local
storage
is
fast
much
much
faster,
but
its
ephemeral
and
that
works
towards
is
fault
tolerant,
but
it's
a
lot
slower
and
because
Cassandra
takes
care
of
replication
at
the
application
rate
layer.
G
G
So,
let's
see
some
failure,
scenarios
of
the
local
disks
and
how
we're
planning
to
address
them,
for
example,
if
a
disk
misbehaves
in
kubernetes,
for
example,
if
you
have
block
errors
or
bad
performance,
the
keeper
in
this
bill
won't
do
anything
about
it
or
if
a
disk
fails,
the
Mon
Point
disappears
or
anything
like
that
could
burn.
This
also
won't
do
anything
about
it,
but
there
is
a
third
case
which
is
very
common:
the
cloud
the
case
of
a
node
failure.
G
So
if
a
node
fails
in
the
cloud
that
can
be
due
to
a
VM
migration-
or
you
know
a
thousand
different
reasons
really,
but
this
happens
a
lot
in
the
cloud
in
the
cloud.
Usually
your
discs
don't
fail,
usually
you're,
not
Phil's,
first
so
well.
How
can
we
handle
this
type
of
scenario?
That's
very
often,
let's
see
so.
Let's
say
that
you
have
a
Cassandra
cluster
with
three
members
here
and
suddenly
and
no
dies.
What
do
you
do?
Well,
usually
you
can?
You
would
have
an
administrator
or
some
kind
of
fencing
software,
so
fencing.
G
Is
this
thing
that
in
distributed
systems,
if
something
goes
down,
you
don't
know
if
it's
if
it
is
dead
or
if
there
is
a
network
partition,
like
your
network,
isn't
working
so
fencing
is
a
procedure
to
make
sure
that
this
thing
is
actually
dead.
So,
for
example,
is
like
the
the
metaphor:
is
that
you
go
and
you
unplug
it
from
the
power?
That's
what
fencing
does
so
you
have
something
like
that.
G
That
makes
sure
that
thing
is
dead
and
deletes
it
from
the
kubernetes
app
server
after
that
happens,
because
an
operator
is
notified
that
something
changed
and
calculates
this
condition
where
you
have
a
Cassandra
member
with
a
disc
that
points
to
a
node
that
doesn't
exist.
So
this
is
like
the
condition
that
we
kind
of
detecting
and
after
that
happens,
the
operator
will
take
all
the
necessary
steps,
because
a
parent
is
gonna.
G
Do
that
by
default,
to
give
the
member
a
new
disc
and
after
that,
we
kind
of
follow
a
standard
algorithm
to
make
sure
that
Cassandra
will
start
with
the
right
configuration
to
stream
the
data
from
the
remaining
replicas.
So
we
check
with
the
specific
member
is
already
a
part
of
the
Cassandra
ring.
If
it
already
has
a
class
or
membership,
and
then
we
check
its
disk
and
if
it's
empty,
it
means
something
bad
happened.
So
we
start
with
the
right
options
to
make
sure
that
everything
is
trimmed
from
the
other
replicas.
G
G
Another
feature
that
we're
looking
into
is
monitoring
so
Cassandra.
So
what
we're
going
to
walk
here
is
that
we
won't
support
Prometheus,
because
that's
kind
of
the
industry
standard,
but
Cassandra
internally
uses
this
RPC
Java
specific
protocol
called
jmx
that
doesn't
really
expose
anything.
So
the
solution
here
is
to
integrate
the
DMX
exporter
and
that's
what
we're
actually
doing
right
now
and
working
on,
and
there
is
also
a
need
for
a
good
graph
on
the
dashboard,
because
there
aren't
many
in
the
open.
G
So
it's
kind
of
a
call
to
the
community
that,
if
you're
operating,
Cassandra
and
you're
looking
to
run
into
Burnett
is
like
come
see,
ok
come
give
us
your
expertise
like
we
can
become
better
and
we
can
help
you
out
in
your
move
to
kubernetes.
So
this
is
definitely
a
feature
that
could
probably
land
in
1
on
8.
So
the
second
thing
is
repairs.
G
So
in
Cassandra
you
have
like
this
eventually
consistent
model
and
when
you
have,
when
you
don't
have
guaranteed
consistency
so
that
you
have,
for
example,
in
the
other
places
like
or
gigabyte
or
you
name
it,
then
you
have
this
entropy.
That
starts
to
build
up.
So,
for
example,
because
you
have
this
a
synchronous
replication,
it
may
be
that
the
replica
is
down
and
it
doesn't
receive
the
update.
G
So
in
order
to
fix
that
kind
of
scenario
and
reduce
the
entropy
in
the
system,
you
have
this
regular
maintenance
operation
called
repair,
and
this
is
a
very
manual
operation
but
must
be
performed
in
on
a
timely
basis.
Otherwise,
bad
things
will
happen.
Our
plan
here
is
to
integrate
with
a
software
called
Cassandra
Reaper
by
Spotify.
In
the
last
pickle
and
if
you
actually
have
a
better
way
of
doing
this
as
a
Cassandra
administrator,
please
talk
to
us.
G
So
another
area
of
interest
is
backups
and
restore.
So,
as
you
may
know,
we
have
this
new
CSI
interfacing
kubernetes
to
take
snapshots
and
restore
persistent
volumes
and
we're
looking
to
try
and
leverage
that
to
provide
like
backups
and
restores
for
Cassandra.
So,
for
example,
an
interesting
use
would
be
if
you
lose
a
Cassandra
node
instead
of
trying
to
stream
everything
from
the
other
members.
G
Finally,
an
area
that
we
would
like
to
explore
and
then
very
very
much
interested
in
is
multi-region
clusters.
So
this
is
something
novel
like
this
is
something
that
everybody
is
kind
of
figuring
out
right
now.
There
aren't
like
many
operators
in
the
open
doing
that
I
know,
there's
crossplane
that
are
doing
an
excellent
job
from
that.
G
So
you
should
definitely
check
them
out,
but
I'm
really
looking
to
experiment
and
try
things
out
here,
so
see
what
works
and
what's
not
and
I
know
from
talking
to
a
couple
of
people
that
Apple
is
doing
some
interesting
work
there.
So
firm
grants
from
Apple
tell
us
what
you're
doing
let's
go
together
and
finally,
as
I've
been
saying
throughout
the
talk,
we
really
really
welcome
contributors,
especially
for
the
Cassandra
operator.
So
if
you
want,
if
you
like,
I
guess
under
administrator,
you
want
to
move
to
Cooper
netis
you're
wondering
what
are
the
steps?
G
What
should
you
do
like
come
along
and
we'll
help
you
out,
like
the
plan?
Is
that
as
a
Cassandra
administrator
you'll
bring
in
your
expertise,
you'll
bring
in
your
best
practices,
we'll
put
those
best
practices
into
code
into
the
Cassandra
operator,
and
the
operator
will
become
better
and
better
and
work
for
you
and
you
will
let
you
burn
a
this,
will
link
a
Sandra
will
make
something
great
together.
Thank
you.
A
Thanks
a
lot
so
that
there
we
have
all
of
the
well
the
those
who
are
represented
today
as
far
as
storage
providers
in
Brook
glad
to
be
with
you
today,
we
do
have
a
few
minutes,
I
think,
given
the
nature
of
the
different
storage
providers.
If
we
take,
if
you
have
general
questions
about
rook,
we
can
take
a
couple
of
those
and
then
maybe
we'll
we'll
go
ahead
and
complete
and
you
can
come
up
and
ask
questions
for
individual
storage
providers.
So
are
there
any
general
questions
about
rook
before
we
before
we're
done
here.