►
From YouTube: Ceph Orchestrator Meeting 2022-03-01
Description
Join us weekly for the Ceph Orchestrator meeting: https://ceph.io/en/community/meetups
Ceph website: https://ceph.io
Ceph blog: https://ceph.io/en/news/blog/
Contribute to Ceph: https://ceph.io/en/developers/contribute/
What is Ceph: https://ceph.io/en/discover/
A
A
Yes,
I
guess
we
can
just
get
into
that
then.
So.
The
one
topic
we
have
on
here
today
is
a
new
documentation
for
cepheidium.
A
Essentially
it's
supposed
to
be
for
developers
instead
of
users
and
going
over
some
of
the
implementation
stuff
that
you
wouldn't
really
ever
want
to
tell
users
about,
but
for
anyone
who's
trying
to
get
into
that
videom
who
doesn't
know
about
how
it
works
under
the
cover,
it
would
help
them,
and
so
the
first
sort
of
point
there
was
whether
we
should
just
do
it
in
general,
and
we
talked
a
little
bit
about
this
in
the
stand
up
yesterday
and
pretty
much.
A
A
Let
me
let
me
link
the
other
pad
as
well.
What
I'm
talking
about.
A
But
nobody
has
any
issue
with
it
in
general,
so
the
questions
we're
going
to
ask
here
just
so
to
get
a
initial
idea
is
sort
of
what
level
do
you
want
to
go
to
again?
A
That's
sort
of
the
the
balance
points
where,
if
you
make
it
too
detailed,
then
it
becomes
impossible
to
maintain
you
have
to
update
it
after
you
change
anything,
and
if
you
make
it
too
high
level,
then
it
could
just
not
be
very
useful,
and
so
that's
where
the
question
was
at
what
level
we
actually
put
things
at
so
sort
of
things.
We'd
have
in
here
would
be
like
important
data
structures,
important
sort
of
concepts,
maybe
an
outline
of
the
serve
loop
and
like
sort
of
the
main
functions
that
it
has
there.
A
The
general
idea
of
what
they
do,
I
think,
are
some
things
that
could
be
good
and
but
then
not
into
any
actual
details
of
how
those
things
work
just
sort
of
stopping
there.
A
So
those
are
my
initial
thoughts
on
basically
where
it
would
go
to
maybe
some
of
the
data
structures.
Well,
I
know
we're
talking
about
before.
I
think
we're
talking
about
how
things
are
stored
in
the
inventory,
where
we
like
put
things
in
the
json
strings
and
we
put
them
into
the
the
monkey
store
and
all
that
yeah.
A
Yeah,
so
we're
on
the
on
that
portion
of
it.
Do
you
want
to
talk
a
bit
about,
because
I
know
you
were
the
one
who's
going
to
start
working
on
this?
Did
you
want
to
talk
a
bit
about
what
sort
of
things
you
thought
needed
to
be
in
here.
B
B
I
think
to
be
a
good
at
least
to
have
something
at
a
high
level.
Explain
like
the
structure
of
the
code,
the
the
different
components.
We
have
the
classes,
the
relationship
between
them.
B
B
A
So
yeah
yeah,
I
just
want
to
get
like
a
general
idea
of
sort
of
a
starting
point
of
what
everything's
going
to
do
and
like
I
what
I
said
a
minute
ago,
I
think
my
first
I
mentioned
that
I
thought
maybe
could
be
good.
There
is
just
an
overview
of
the
functions
the
servl
loop
is
going.
A
We
have
the
whole
thing
where
we
like
apply
the
services
we
refresh
all
the
posts
and
all
the
information
there,
and
I
think
those
could
be
sort
of
explained
a
little
bit
and
kept
at
a
very
high
level
and
it
wouldn't
be
too
complicated,
because
even
if
we
change
how
we
refresh
the
demons
or
whatever
that
doesn't
have
to
be
in
there,
it
just
has
to
be
so.
This
is
what
the
function
is.
That's
what
we're
doing
there's
the
goal
of
it
anyway,
so
we
could
start
with
that.
A
I
think
you
mentioned
there
we're
keeping
track
between
the
cache.
This
is
basically
things.
We
need
for
manager
failovers
things
that
have
to
sort
of
be
persistent,
no
matter
what
yeah,
I'm
not
sure
what
level
of
detail
you
want
to
go
because
that's
something
that
could
change
sort
of
frequently.
A
I
don't
know
if
you
want
to
like
list
off
all
those
things.
I
could
useful,
though,
to
say
sort
of
how
that's
done
at
least,
and
maybe
we
could
talk
about-
maybe
some
of
the
ones
we
know
aren't
going
anywhere
or
if
we
are
talking
about
things
just
at
a
very
high
level
like
say
something
like
host
information
or
what
else
do
we
have
in
there,
like
which
demons
we
have
on
each
host
and
the
devices
and
things
like
that,
yeah.
B
You
can
also
have
a
section
for
that
great.
I
think
it's
don't
know
if
it's
tricky
or
not,
but
it's
something
that
is
pretty
complicated.
A
Yep
yeah,
I
could
see
a
general
thing
on
that:
the
high
level
of
how
that
sort
of
works
as
well
yeah
exactly.
B
A
All
right
yeah,
so
we
start
by
sort
of
figuring
out
the
topics
we
want
and
then
we
can
go
from
there
and
see
if
somebody
wants
to
write
they
say.
I
know
I've
done
a
lot
of
work
with
upgrade
stuff,
so
I
could
probably
start
there.
A
So
I'm
going
to
start
adding
some
things
here,
so
overview
of
serve
loop
functions.
I
want
that.
B
A
Demons
we
were
talking
about
redeploy
reconfig
and
all
that,
although
that's
more
of
a
user
level
one
and
then.
A
A
Ost,
I
think
that
have
special
things
they're
handled
differently
in
a
lot
of
places,
everything
else
is
mostly
handled
the
same,
probably
a
little
bit
of
the
scheduler
actually
yeah
skinny
parts,
also
they're
kind
of
complicated.
A
B
B
Sorry,
what
exactly
do
you
have
an
example?
Yeah
basically
would
like
to
start
generating
some
documentation
at
this
moment's
high
level
and
we'll
try
to
keep
it
this
way
for
developers.
A
A
Is
basically
that
it's
hard
to
get
into
developing
with
stuff
idiom,
because
there's
so
many
like
topic
or
complex
implementation,
things
and
so
we're
thinking
about
trying
to
get
some
documentation
of
some
of
the
implementation
stuff
that
you
wouldn't
normally
put
in
docs,
because
it's
not
users
don't
care
about
it,
but
for
any
potential
future
developers
or
even
just
us.
We
want
to
go.
A
Remember
things
just
an
overview
of
how
certain
things,
work
and
sort
of
the
discussion
was
at
what
level
this
needs
to
be
kept
at,
because
if
it
goes
too
low
level,
it's
unmaintainable
just
update.
It.
A
Well,
that
actually
is
one
of
the
questions,
but
we
haven't
gotten
to
there
yet
right
now
it
was
we're
actually
going
over
which
things
would
need
to
be
in
here.
I
like
the
topics
that
would
be
involved,
and
I.
C
Yeah
there
I
think,
there's
data,
that's
a
framework
for
creating
diagrams.
There
are
different
tools
in
yeah,
I'm
not
sure
where
those
are
documented.
If
you
check
the
script
for
installing
the
doc
building
environment,
you
can
see
more
or
less
the
plugins
and
extension
that
we
are
installing
there,
and
I
think
one
is
detail.
It's
di
tta
and
I
think
we
have
more
tools
for
creating
diagrams
okay.
B
C
Okay,
we
this
I'm
sharing
the
link
for
our
old
hacking,
rsd
docs.
This
was
later
moved
to
the
general
docs
step
dogs,
but
I
mean
for
a
while.
We
had
this
in
separate,
so
basically
we
could
point
it
was
just
marked
down,
so
this
wasn't
rendered
as
a
septum.
It
was
just
for
developers
and
and
contributors
that
quickly
find
the
that.
C
Yeah,
well
actually,
some
of
these
things.
I
would
assume
that
they
should
be
shared
across
components
right
because,
right
now,
this
video
is
the
prescribed
way
of
deploying
save
right.
So
probably
all
the
different
onboarding
docks
for
for
developers
to
start
covering
that
like
how
to
deploy
as
a
fitting
cluster-
and
we
have
some
stuff
where.
B
B
A
Well,
I
guess
we
do
already
have
this
fidm
developer,
documentation,
bot
in
the
docs,
and
then
we
have
the
developing
cfdm
thing
which
is
like
yesterday.
A
That's
mostly
just
sort
of
developer
environments
in
there
there
actually
is
a
section
in
the
very
bottom
of
that
on
the
service
type
stuff
services
versus
demons.
I
know
this
is
something
yeah.
A
I
thought
that
was
documented
this
summer,
but
I
couldn't
find
it
yesterday
now
we
should
probably
just
reformat
this
as
well
honestly
and
just
move
that
you
probably
just
have
a
section
for
developer
environments,
yep
and
then
a
different
one
or
this
other
stuff.
There's
half
of
this
is
developer
environments
and
then
the
other
half
is
just
sort
of
miscellaneous
things.
A
A
A
Okay,
so
we
already
have
that
it
looks
like
it's
sort
of
started
doing
what
we're
talking
about
it's
just
that
it's
very,
very
bare
bones
only
has
a
very
small
amount
of
topics
I'm
just
going
to
have
the
basically
the
developer
environments,
the
compliance
checks
and
then
host
maintenance
mode.
B
B
I'm
not
referring
to
the
content
itself,
I'm
referring
to
the
location
because
the
dash
team
uses
developer,
underscore
guide
and
then
an
entry
for
the
development.
So
we
can
have
something
similar
there.
D
D
B
B
B
B
Yeah
I
mean,
but
anyway,
this
is
something
that
maybe
somebody
could
need
for
testing
or
anything
that
has
had
to
do
with
the
development.
A
A
Yeah,
so
what
I
was
saying
before
is,
if
you
go
like
one
layer
above
that
we
just
have
this
fading
developer
documentation.
I
think
we
just
put
everything
there
and
I
think
what
we
want
to
do
is
just
developing
with
stuff.
A
damn
section,
I
think,
is
covering
too
many
topics,
and
maybe
some
of
that
should
be
split
up,
but
other
than
that
this
section
looks
like
it's
it's
fine,
so
it
has
like
a
host
maintenance
section
and
a
compliance
check
section
as
topics,
and
we
just
need
to
add
more
topics
to
it.
B
Yes,
I
don't
care
about
the
link
right
now.
So
if
we
already
have
this
page,
we
can
continue
working
on
it.
It
didn't
see
like
that,
one,
okay,
maybe
in
the
future,
we
can
move
it
to
something
similar
to
have
all
the
developer
information
for
chef
in
some
common
place.
But
right
now
we
can
start
using
this.
A
I
mean
that
overarching
place
is
called
fam
developer
documentation.
A
Documentation,
it's
like
an
overarching
category
and
it
has
like
contents
and
as
much
as
subsection,
okay
and
we
basically
all
we
need
to
do
in
order
to
get
this
project
going,
is
take
some
things
from
the
developing
set
video.
They
said,
I
think
that
one's
a
bit
too
broad
yeah,
but
up
but
other
than
that,
it's
just
adding
more
topics,
and
we
have
already
have
a
list
of
topics
we've
got
in
the
other
pad.
D
A
I'm
assuming
we're
gonna
need
like
a
miscellaneous
section,
because
there's
going
to
be
things
that
aren't
big
topics
like
if
we
want,
but
I
think
that
section
actually
could
be
just
like
where
the
most
of
that
section
is,
is
just
developer
environments.
A
They
have
a
lot
of
section
on
vstart
c-start
shared
set,
folder
kcli.