►
From YouTube: Ceph Orchestrator Meeting 2022-04-26
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/contrib...
What is Ceph: https://ceph.io/en/discover/
A
So
I
don't
have
a
ton
of
stuff
to
talk
about
the
first
topic
on
here.
You
could
have
to
push
back
again
because
we
kind
of
need
mike
rich
here
for
that
discussion.
That
work
requires
a
pull
request.
He
said
open
for
a
while
who
zips
the
binary.
We
actually
have
the
link
for
that
find
that
real,
quick.
A
A
Yeah,
it's
the
link
in
the
other
pad
there,
the
pull
requests,
so
that
work
is
like
a
pretty
important
like
first
step.
You're
doing
that
and
michael's
doesn't
have
one
working
on
that
they
put
on
pause.
A
I
think
around
the
quincy
release
time,
and
so
our
plan
was
to-
or
I
guess
so-
the
point
of
this
being
in
the
discussion
during
the
topics
is
that
we
need
to
have
a
good
plan,
we're
getting
that
in
for
reef
that
what
happens
again,
we
have
quincy,
where
doesn't
quite
get
done,
and
then
we
just
have
to
push
it
back,
because
we
don't
want
to
put
it
in
a
minor
release,
so
figure
that
out-
and
I
think
we
can
push
that
topic
back
until
next
week.
A
So
second
thing
we
have
on
here
is
stand-up
frequency.
This
is
something
that
came
up
a
little
bit.
A
Before
I
was
talking
with
somebody
about
this
offline
that
maybe
we
have
the
stand-ups
a
bit
too
often
so
right
now
they're
every
day,
besides
tuesday,
because
we
have
we
have
this
on
tuesday,
I
thought
was
maybe
that
it's
too
close
together.
Sometimes
so
maybe
people
don't
have
things
to
talk
about
and
each
one
that
we
could
remove
some
of
them
and
then
just
you
know
there
was
important
things
you
probably
just
talked
about
in
the
chat.
Anyway,
you
don't
need
a
stand
up
for
that.
A
You
know
two
or
three
times
a
week
would
be
enough
updates
for
everyone
to
be
cut
up
and
everything,
and
I
think
the
proposal
we
had
we
talked
about
it.
There
was
to
have
them
just
run
monday,
thursday.
I
think
reason
being
that
wednesday
they're
already
at
a
weird
hour,
because
they
conflict
with
the
other
things
with
a
normal
time
and
friday.
People
just
tend.
A
You
know
not
really
want
to
do,
meetings
and
stuff
as
much
so
it's
like
monday,
thursday
for
the
stand-ups
and
have
this
weekly
on
tuesday,
that
it
might
be
enough
with
everything
and
then
again
the
important
stuff.
B
A
A
So
does
everyone
have
any
thoughts
on
that?
I
mean
I'm
personally
open
to
it
to
lowering
the
amount
I
do
feel
like.
There's
often
people
go
in
there
and
they're
like
I.
Don't
really
have
a
lot
of
hours
only
doing
some
downstream
stuff
maybe
had
a
few
less
of
them.
Then
they
would
be
more
productive.
A
All
right
probably
try
to
see
if
we
get
everyone
who's
in
the
stand
up,
but
I
want
to
I
don't
know
we
share
it
with
people
before
we
just
start
removing
it
from
the
calendar.
Maybe
they'll
bring
it
up
as
well
in
the
stand-up
itself,
maybe
one
of
the
few
times
where
it's
not
actually
a
proper
stand-up
topic,
but
maybe
it's
we
talked
about
there
a
little
bit
anyway.
A
Of
course,
I
also
have
to
figure
out
how
to
I
don't
even
know
how
to
remove
things
from
the
stuff
calendar
and
change
that
stuff.
So
I'd
have
to
figure
that
out
anyway,
so
I
don't
think,
there's
something
that
would
happen
this
week
regardless,
but
I
mean
it
doesn't
make
there's
going
to
be
a
much
push
back
on
that.
A
All
right,
what's
in
there
yeah
anything
else,
I
want
to
say
about
the
stand-up
stuff,
any
opinions
by
just
moving
on.
A
So
yeah
I
wanted
to
give
a
quick
update
on
hnfs
stuff,
so
we
had
they
backboarded
all
of
the
work
that
we
thought
we
were
going
to
need
for
that
specific.
A
few
weeks
back
and
so
mike
rich
was
doing
some
testing
with
it.
A
I
think
it
was
late
last
week,
or
maybe
it
was
yesterday-
I'm
not
sure
his
messages,
but
what
he
said
is
it
seemed
like
it
was
working
pretty
well
actually,
just
like
he
said,
30
to
60
seconds,
to
detect
offline
host
cases
and
one
to
three
minutes
to
redeploy
the
nfs
demon
when
toast
was
offline
and
things
in
the
generally
be
working
with
the
the
mounting
and
the
h2
proxy
keep
alive
and
all
that
stuff.
A
So
it's
not
good
was
going
well,
and
that
being
said,
we
still
do
have
that
bug
open
from
the
openstack
team
related
to
h.a
proxy.
Some.
What
I
think
we
need
to
do
is
probably
have
some
sort
of
sync
up
figure
out
why
it's
happening
to
some
people
and
not
to
other
people.
A
So
I
already
have
I
sent
an
email
something
earlier
to
ramana,
who
was
testing
it
for
the
openstack
team
to
figure
out
what
was
going
on
there.
I
think
we're
gonna
have
to
compare
the
steps.
People
are
using
to
configure
this
and
see
if
it's
a
really
configuration
issue
or
if
there
is
some
real
bug
there,
but
at
the
very
least
the
update
is
that
it
seems
to
be
mostly
working
and
at
least
for
for
mike
it
was
working
entirely.
A
A
The
third
topic
we
have
in
here
is
for
this
upgrade
ordering
stuff-
I'm
not
yeah.
So
basically
we
have
this
upgrade
order.
We
have
sort
of
enforced
in
the
upgrade
for
a
long
time,
but
part
of
it
is
just
that
it
was
also
the
way
we
sort
of
looped
through
the
demons
to
upgrade
them.
So
we
needed
every
single
demon
type
to
be
in
the
upgrade
order,
but
now,
with
the
staggered,
upgrade
it's
sort
of
that
this
now
more
than
just
the
way
we're
doing
it.
A
It's
also
just
enforcing
the
way
you
can
do
the
staggered
upgrade
as
well,
where
we're
saying
well,
you
can't
actually
upgrade
your
you
can't
upgrade
your
like.
Ffs
mirror
demons
after
your
eyes
because
of
demons.
It
has
to
be
the
other
way
around
or
whatever,
and
I
feel
like
it's
probably
not
relevant
up
to
a
certain
point.
A
So
I
guess
the
open
question
here
was
sort
of
how
deep
do
we
need
to
enforce
this,
so
the
obvious
ones
like
manager
monitor
those
first,
two,
that's
definitely
important
and
then
I'd
say
maybe
up
through
the
mds
demons.
It'd
still
be
relevant
to
you
know,
block
people
if
they
try
to
do
that
out
of
order,
but
I
don't
know
after
rgw
it
does
feel
like
it's
sort
of
just
a
bunch
of
it
shouldn't
really
matter
yeah.
A
B
Sounds
good
to
me:
I
don't
know
if
this
helps
or
not,
but
maybe
in
the
code
or
something
you
could
just
create
a
concept
of
something
like
a
group
or
batch
and
say:
oh,
you
know
they
mon
and
manager,
they're
they're.
They
belong
to
their
own
upgrade
match,
but
the
other
stuff.
You
know,
the
one
that's
really
jumps
out
of
me
is
like
stephiffs,
mirror
and
rbd
mirror
like
they
have
no
relationship
to
each
other.
They
could
be
blocked
around
and
I
don't
care
so
that
could
be
just
the
you
know.
General
badgers.
A
Yeah,
that's
what
I
was
wondering
is,
after
is
rgw
onway.
It
seems
like
it's
more
like
these
gateway
sort
of
demons,
where
they're
using
them
to
interact
with
the
cluster,
but
they're
not
like
you
know
the
core
things
like
the
osd
and
the
mds
that
you
need
and
like
the
manager
I'm
out
of
there.
So
that's
why
I
was
wondering
out
up
the
mds,
maybe
is
where
we
want
to
have
our
limits,
and
after
that
like
does
it
matter.
A
A
A
Yeah,
that
could
also
be
a
good
plot
for
it,
like
the
devil's.
Many
people
have
opinions
on
it.
C
A
A
All
right,
yeah,
that
was
all
the
stuff
video
topics
there
was
kind
of
a
light
week
of
things
to
talk
about.
So
I
see,
there's
one
rook
thing
in
here
is
that
yours,
one
of
me.
D
Yeah,
hello,
everybody
well
just
to
comment
that
I'm
going
to
retake
the
the
work
on
the
record
stator
part,
okay,
but
I
wanted
to
to
follow
a
different
approach
that
the
the
the
one
that
we
followed
in
the
in
the
past.
Okay,
we
try
it
to
to
mimic
or
to
have
the
same
functionality
the
same
ap
in
both
our
status,
and
I
think
that
this
has
no
sense.
Okay,
we
have
various
meetings,
commenting
this
this
this
part
of
what
is
the
the
rationale
behind
this
this?
D
This
thing
that
what
probably
is
it
has
no
sense
to
to
try
to
to
have
exactly
the
same
interface.
So
the
the
new
approach
that
I
want,
I'm
going
to
try
to
follow
is
just
to
discover
what
is
the
functionality
that
is
going
to
be
useful
for
kubernetes
users
and
try
to
implement
this
part
in
indoor
state.
Okay,
obviously,
all
the
part
about
managing
infrastructure.
C
D
What
kind
of
orientation
could
be
useful
and
very
well
welcome,
so
this
is
all
from
my
back.
A
D
Yeah,
yes,
the
the
idea
is
to
to
use
the
the
the
starter,
the
stator
module,
that
we
are
that
we
have
now
in
rook,
okay
and
adding
functionality
in
this
in
this
model.
Okay,
I
think
that
what
probably
we
can
even
to
add
a
new
interface
or
maybe
we
can
start
to
think
in
using
another
new
model
or
for
another
kind
of
functionality,
but
I
think
that
the
the
functionality
the
that
is
proposing
that
the
orchestrator
is
proposing
is
correct.
D
A
A
I
guess
we
could
just
leave
a
bunch
of
them
unimplemented
in
one
or
the
other
like
right
now.
There's
songs
that
are
implemented
in
sephidim
that
aren't
like
they're
not
implemented
in
rook
in
terms
of
like
this
command
is
not
used
there.
So
we
just
do
it
the
other
way
as
well.
I
guess
where
we
just
have
root
commands
that
cephem
doesn't
implement
because
there
kubernetes
specific-
and
I
guess
that's
fine
as
long
as
they're
all
documented
and
everything
which
ones
are
important
in
each
one.
D
Okay,
I
I
think
that
well,
the
target
should
be
to
to
provide
more
functionality
to
final
users,
okay
and
well,
to
provide
the
kind
of
functionality
that
a
kubernetes
user
is
is
going
to
expect
to
have
okay,
not
something
completely
artificial,
and
I
think
that
in
the
case
of
the
orchestrator
ap
there
are
things
that
are
directly
not
applicable
to
government
environments.
So,
let's,
let's
skip
the
the
modules.
I
think
that
the
the
architecture
is
right.
We
can
use
that
okay,
but
maybe
we
can
even
would
be
needed
to
add
new
ap
endpoints.
D
B
Yeah
that
sounds
good
to
me
too.
I
think
it
could
come
up
in
one
of
the
previous
meetings
or
said
something
like
I
tried
to
suggest
that
you
know
maybe
the
orchestrator
if
api
today
is
too
maximal,
it's
too
close
to
what
adm
wants.
D
D
A
Yeah,
all
right,
don't
have
anything
else
stay
on
that
topic.
A
All
right
in
that
case,
that
was
the
last
topic
we
had
in
the
past.
Does
anybody
have
any
other
topics
I
want
to
bring
up
here.
B
This
is
tangentially
related,
but
just
because
it
annoyed
me
the
other
day,
why
is
the?
Why
do
we
use
a
get
sub
module
to
bring
the
rook
python
package
into
the
tree
and
then
have
like
a
funky
shell
script
to
copy
things
around
and
I'm
curious?
If
anyone
knows
what
the
history
of
that
is
and
who
maintains
this
rook
libra?
If
it
can,
if
we
could
get
someone
to
do
a
release,
can
we
stop
doing
the
sub-module
dance.
D
Are
you
talking
about
the
library
that
allows
us
to
connect
directly?
Okay?
Yes?
Well,
this
was
our
started
as
an
idea
in
order
to
to.
D
To
make
easy
for
other
projects
to
use
the
rook
operator
ap,
but
it
hasn't
been
very
successful
and
it
has
a
a
layer
that
makes
more
complicated
for
us
for,
for
the
fulcrum
orchestrator
for
the
orchestrator
mode
to
do
work.
Okay,
so
maybe
it's
something
that
I
think
that
is
suitable
of
to
have
a
new,
a
new,
a
new
approach:
okay,
and
to
maybe
the
directory
to
to
implement
these
disconnections.
This.
This
library,
in.
B
B
D
Yeah,
it's
a
nice
programming
exercise,
okay,
but
the
the
thing
is
that
nobody
is
using
that
and
it
is
having
a
an
external
diet
that
needs
to
be
updated
correctly,
properly
updated
in
order
to
be
usable,
so
it
adds
well,
maybe
some
kind
of
complexity
to
to
the
project.
Okay,
it's
it's
not
bad,
obviously,
a
way
to
do
the
things,
and
there
is
a
way
to
make
possible
to
to
have
another
project
using
the
the
rook
operator.
B
Yeah
I
mean
if
it
was
something
like
it
had
releases
and
versions
and
stuff.
It
might
be
better,
but
it
seems
like
a
kind
of
a
code
drop
that
was
stitched
into
the
tree
with
the
modules,
and
I
I'll
admit
it.
I
personally
do
not
like
sub
modules.
When
I
see
them,
I'm
like
oh
boy,
so
yeah,
I'm
just
curious
kind
of
how
it
came
about.
B
A
Right,
that's
like
maybe
something
we
could
look
into
changing
at
some
point.
It
doesn't
seem
like
it's
worked
out
super.
Well,
I
don't
wanna
say.
B
D
D
D
A
I
think
cool
does
that
have
anything
else
to
talk
about
here.
A
All
right
yeah,
we
can
call
it
then
for
the
week.
So
thanks
everyone
for
coming
and
I'll
see
you
all
next
week,
bye,
bye,
see
you
goodbye.