►
From YouTube: Ceph Month 2021: Project Aquarium - An easy-to-use storage appliance wrapped around Ceph
Description
Presented By: Joao Eduardo Luis & Alexandra Settle
Full schedule: https://pad.ceph.com/p/ceph-month-june-2021
Project Aquarium is a new open source project to build an easy-to-use appliance wrapped around the Ceph project. The project started development in January 2021 and has become a passion project for the storage team at SUSE. In this talk, Joao Luis and Alexandra Settle will take you through a demo of what the team has achieved so far, talk a little bit about the architecture of Aquarium, and what's next for the project.
C
B
So
we're
going
to
go
through
today
what?
What
is
this
aquarium
thing?
Why
are
we
doing
this?
What
is
our
objectives?
How
are
we
going
to
do
this?
We're
going
to
go
through
a
little
demo
to
clarify
this
demo
is
pre-recorded,
because
we
don't
trust
demo
gods
and
then
we'll
just
have
a
quick
recap
on
what
our
outlook
is
next
steps
where
we're
going,
what
our
plans
are
and
if
we
have
time
we'll,
have
a
little
q
a
already
let's
dive
in
so
what
is
aquarium?
B
The
million
dollar
question
so
aquarium
is
a
open
source
project.
The
storage
team
at
souza,
who
previously
worked
on
developing
the
souza
enterprise
storage
product,
has
now
been
working
on
a
new
approach
on
ceph
development
and
deployment.
Sorry
and
management.
This
is
an
opinion
version,
opinionated
version
of
a
storage
appliance
and,
to
be
completely
frank,
we're
still
working
on
what
that
opinion
is.
B
B
So
we've
split
this
into
two
clearly
defined
work
streams
at
this
point,
they're
relatively
obvious
and
you'll
get
the
sense
for
the
theme,
but
we're
going
for
gravel,
which
is
our
back
end.
Obviously,
the
base
layer
of
the
aquarium
and
the
glass,
which
is
our
front
end,
what
you
look
through,
how
you're
gonna
check
out
the
aquarium
and
to
be
completely
honest,
we're
really
enjoying
our
own
theming,
so
yeah,
all
right.
Why
are
we
doing
this?
B
Well,
the
perception
is
that
ceph
is
too
complex
to
use
for
the
average
user,
and
this
is
some
feedback.
We've
received
a
lot
being
part
of
the
deaf
community
as
a
product
for
such
a
long
time,
and
this
complexity
stems
from
step,
steph's
flexibility,
which
supports
such
a
huge
matrix
of
use
cases,
and
this
affects
this-
has
on
the
available
capacity,
performance
and
availability.
B
We
believe
in
abstractive
complex,
complex
concepts
with
simple
terms,
so
our
main
goal
is
simplification,
where
a
user
is
not
required
to
configure
individual
demons
or
disk
layouts,
but
we
can
provide
a
high
level
specification
of
what
they
want
in
terms
of
availability,
usable
capacity,
but
basically
that
translates
this
all
into
a
deployment
layout.
We
also
believe
in
a
really
tight
naming
scheme,
so
I
think
that's
always
worth
cutting
out
alrighty
architecture.
B
D
C
Okay,
so
acaramic
itself
is
a
python
backend
serving
an
angular
front-end,
it's
basically
a
systems
system
service.
We
start
the
aquarium
on
boot
and
it.
This
starts
aquarium
on
blood
and
we've
chosen
not
to
containerize
this,
because
aquarium
will
be
relying
on
tools
like
fadm
and
other
system
host
system.
Binaries,
though
containerizing
it
would
make
everything
a
bit
weird
and
the
purpose
of
this
system
service
is
mostly
to
manage
and
monitor
path
and
to
do
some
deploying
we
need.
C
Aquarium
itself
will
be
running
on
every
single
host
in
the
in
the
system,
so
it's
essentially
a
cluster
on
top
of
a
cluster
which
is
always
fun
the
nodes
should
they
need
to
communicate
with
each
other.
They
will
do
so
over
web
sockets,
mostly
because
the
framework
we
are
using
for
the
http
backend
already
supports
websockets,
and
it
was
just
easier.
C
We
we
use
fcd
to
keep
that
state,
mostly
because
xcd
does
what
we
need,
but
also
we
didn't
want
to
implement.
On
top
of
the
fact
that
we
all
we
are
already
having
a
cluster
having
to
also
implement
a
consensus,
algorithm
and
the
key
value
store,
and
all
of
that,
so
we
just
leave
fcd
deal
with
that.
Instead
of
having
to
implement
that
ourselves
and
this
way
we
don't
have
the
concept
of
a
follower
nodes
and
a
leader,
node
and
each
node
can
serve
the
front
end
to
the
user
without
any
particular
constraints.
C
C
This
image
is
where
aquarium
lives
it
starts
on
on
boot,
and
if
we
reboot
it,
the
query
makes
sure
that
all
the
persistent
state
is
kept
on
a
system
disk
that
is
created
upon
deploy,
but
mostly
this
is
meant
for
the
upgrade
path,
so
that
upgrading
aquarium
does
not
mean
re-flashing
a
disc
or
upgrading
an
os.
It
just
means
changing
the
image
and
rebooting
the
server,
at
least
that's
the
hope.
The
hope
is
that
this
will
make
upgrading
aquarium
easier
and
dissociates
aquarium
from
upgrading
aquarium
from
upgrading
saf.
C
C
Gravel
itself
has
three
major
components.
To
some
extent,
one
of
them
is
dealing
with
the
local
node
on
which
that
particular
service
is
running
and
we'll
keep
track
of
disks
gpu
load.
Things
like
like
that
that
can
might
be
interesting
to
have
access
to
and
are
necessary
before
we
actually
deploy
the
the
initial
node
or
deploy
that
node
before
tap.
Adm
actually
has
access
to
that
information.
C
C
We
aim
at
having
an
easy
and
guided
install
and
having
a
blizzard
working
from
the
person
out.
We
are
abstracting
the
these
concepts
like
we
don't
have
pools
or
gateways.
We
are
offering
services,
we
have.
We
offer
a
file
service
which
can
have
multiple
backends,
and
we
intend
at
some
point
in
the
near
future,
to
have
like
use
case
driven
deployment
in
the
sense
that
the
user
will
be
specifying
a
set
of
wants
the
system
and
the
system
will
be
providing
a
solution
on
feasibility
or.
C
Okay,
so
as
as
mentioned
before,
this
is
a
pre-recorded
demo,
see
the
whole
thing:
okay
cool.
So
to
start,
this
is
a
web
browser
we
are
connecting
to.
In
this
case,
it's
a
vm
we
are
connecting
to
to
aquarium
and
when
we
connect
to
the
host
at
the
specified
port,
we
will
get
this
splash
page,
welcoming
the
user
to
aquarium
moving
on.
We
will
go
through
a
guided
edit
steps.
We
are
creating
a
new
cluster.
C
Guys
about
that
yeah
we
we
get
to
to
see
like
the
devices
that
we
are.
We
have
available,
which
was
not
clear
enough,
but
essentially
the
the
service
will
pick
a
solution
for
this,
the
disks
that
we
have
available,
choosing
one
of
them
as
a
system.
That's
where
we
will
persist
all
the
data
we
need
to
persist.
C
C
It's
so
both
nodes
are
basically
being
able
to
perform
tasks
and
see
live
data
in
the
in
the
cluster,
as
as
they
are
operating
it's
it's
a
bit
irrelevant
from
which
node
you
are
actually
doing
anything,
and
this
bit
here
is
just
to
show
that
we
actually
can
write
data
to
the
cluster.
We
provide
you
with
the
with
a
helper
to
mount
points
for
each
service.
In
this
case
and
in
the
background
we've
got
script.
C
B
C
B
I
think
one
of
the
most
important
things
is
testing
and
that's
always
been
such
a
such
a
high
bar
in
the
stuff
community,
and
that's
something
we
want
to
keep
following,
along
with.
In
the
medium
term,
upgrades
are
going
to
become
a
priority
block
service
and
resource
constraint,
solver
and
the
long
term,
world
domination.
Obviously,
no
our
priorities
going
forward
are
going
to
be
community
development.
B
We
want
to
be
you
know,
this
is
a
passion
project
for
our
team
and
we
want
to
be
open
and
honest
everybody
who
wants
to
get
involved,
we're
here
for
a
good
time
and
a
long
time
as
a
bonus,
we're
very
proud
of
how
far
we've
come
in
such
a
short
period
of
time.
We
started
this
project
in
january
and
we've
been
working
with
some
seriously
emerging
engineers
and
we're
open
to
anyone
and
everyone
come
to
check
out
what
we've
got
we're
about
and
provide
some
feedback.
B
B
Subject
to
change,
indeed,
cool,
so
that's
us!
Our
project
is
open.
Links
are
here
or
you
can
contact
either
one
of
us
or
anyone
in
the
storage
team
for
more
information,
we're
on
slack,
we've
got
github
discussions
board.
We
meet
three
times
a
week
to
manage
as
many
different
time
zones
as
possible.
So
we
do
one
that's
more
for
apj
one
for
europe
and
for
the
americas.
B
B
C
What
do.
I
say
this
factoring
in
the
bits
that
are
most
useful
without
actually
copying
the
the
existing
dashboard
right,
because
we
don't
want
this
to
be
competing
with
the
dashboard,
because
I
think
they
follow
two
different
approaches,
at
least
at
this
moment
in
time,
and
they
they
are,
or
at
least
we
are
hoping
that
they
are
helpful
in
two
different
contexts,
one
in
which
we
want
to
have
access
as
much
of
cef
control
as
possible
and
another
where
we
can
afford
to
relinquish
some
control
and
just
use
abstractions
and
whatnot.
C
D
C
D
C
F
F
F
C
If
the
tricky
thing
about
deciding
on
the
actual
hardware
is
that
first
of
all,
one
would
have
to
have
access
to
the
hardware
to
actually
you
know,
validate
it
and
other.
On
top
of
that,
that
seems
a
bit
out
of
the
I
don't
know
it.
It
can
be
tricky
overall,
but
I
don't
think
at
this
point
in
time.
We
are
looking
for
specific,
specific
vendors
models
whatever
for,
for
the
hardware.
B
Yeah
I
mentioned
earlier
that
we're
still
discussing
a
bit
about
what
opinionated
means
and
honestly,
that's
part
of
the
question,
and
I
think
that's
something
that
as
much
as
we,
it
is
quite
like
a
double-edged
thing
right
like
as
much
as
we
can
say
yeah.
This
is
exactly
the
kind
of
excuse.
This
is
the
way
we
want
things
to
go.
We
do
recognize
that
peop,
it's
an
open
source
project
right
people
can
take
that
and
do
what
they
want
with
it.
B
C
C
So
if
we
have
a
cef
outage,
aquarium
needs
to
still
be
working,
be
able
to
at
least
eventually
help
the
user
to
recover
the
cluster,
and,
as
such,
we
cannot
rely
on,
for
instance,
monitor
evalustor
to
store
plate
that
we
need
to
operate
aquarium
as
such.
We
need
something
that
is
not
in
saf
to
keep
that
state
and
the
benefit
of
xcd
is
that
it
already
has
a
consensus,
algorithm
and
already
is
able
to
function
a
clustered
way
so
that
we
don't
have
to
implement
that
in
aquarium.