►
From YouTube: Ceph Orchestrator Meeting 2023-03-21
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
All
right,
these
are
the
topics
I
had
in
here
this
week.
It'll
start
off
with
we're.
Gonna
have
to
address
this
one
I
guess
it
found
out
in
the
CLT
call
last
week
that
blue
jeans
is
apparently
going
to
shut
down,
find
other
patterns
a.
B
A
Yeah
so
I
guess
somehow.
This
is
blue
jeans
room
that
we
use
it's
like
some
Universal
room,
that
they
do
all
the
recording
and
stuff
on
and
I.
Guess
this
room
is
that's
what
I've
heard?
A
Is
it's
not
going
to
work
anymore
as
of
April
1st,
so
we
have
to
migrate
over
something
else,
and
so
in
the
CLT
call
they
discuss
Google
meat
and
Jitsu
as
the
Alternatives,
and
then
they
seem
like
the
poor
leading
towards
Gypsy,
because
Google
meet
has
like
permissions
issues
and
you
have
to
like
have
a
Google
account
to
go
under
there
and
everything,
and
so
people
I,
don't
know
it
seems
like
everyone's
going
to
try
to
move
a
religi.
A
A
Oh
anyway,
the
idea
is,
it's
pretty
straightforward.
We
have
to
move
off
of
the
blue
jeans
meeting,
which
is
sort
of
the
obvious
of
the
go-to.
We
already
have
it
sort
of
set
up.
The
only
thing
that's
gonna
be
hard.
Is
we
have
to
figure
out
how
to
do
recordings
on
Gypsy
I?
Don't
know
how
to
do
that
right
now,
I,
don't
know
if
anyone's
totally
figured
out
right
now.
A
My
surprise
was
talking
about
it
a
little
bit
in
the
CLT
call
and
they
seemed
like
there
was
something
with
Dropbox
we
have
to
do
or
the
recordings
up
there
I
think.
We
also
said
we
were
going
to
have
to
manually
trigger
the
recording
not
going
to
do
automatically
like
it
does
in
this
room
right
now,
so
we'll
have
to
figure
that
stuff
out,
but
again
we
sort
of
have
to
it's
it's
kind
of
force,
so
we'll
have
to
do
it.
Is
it
I
expect?
A
A
And
then
the
other
one,
the
question
to
actually
asked
here
is:
as
do
we
actually
want
to
use
blue
jeans
next
week
as
well,
because
it'll
still
should
still
work
next
week
and
the
recording
will
guess
I'll
set
up
everything
or
we
could
try
to
do.
Gt
I,
don't
think
I'll
figure
out
recording
stuff
by
next
week,
but
just
kind
of
transition
to
the
room.
A
A
A
A
The
second
topic,
because
I
said
we're
done
with
that
one
now
is
this
topic
on
universal
timeouts
or
stuff
idiom
mans.
So
we
had
a
tracker
for
that
a
while
ago.
A
You
see
it's
quite
old
at
this
point
we
talked
about.
We
wanted
to
do
this,
I
remember
the
exact
issue
we
had.
That
was
because
that
was
causing
things
to
time
out
back
then,
but
there's
been
a
numerous
ones
over
over
the
last
couple
years
that
have
popped
up
here
and
there
that
could
maybe
cause
one
of
these
things
to
fail,
and
so
the
idea
is
that
we
had
a
universal
timeout.
A
We
could
just
raise
a
health
warning
thing
that
there
is
a
timeout
and
then
the
user
could
go
investigate,
maybe
why
the
command
fails
or
something,
because
usually
it's
something
like
out
of
our
control,
like
that's
a
volume
process
going
to
D
Stage
because
of
hitting
the
amount
points,
we've
had
nodes
that
have
no
face
left
in
their
root
file
system,
so
the
command
just
hangs,
trying
to
get
IO
out
things
like
that.
A
A
So
we
wanted
to
do
that
for
a
while,
and
then
I
have
this
proof
of
concept
pull
request
up
over
here,
and
this
one
goes
through
three
approaches
on
how
we
could
address
this,
and
it
has
hopefully
to
add
some
extra
stuff
as
well.
So
for
the
most
part,
if
you
want
to
look
at
this
three
things,
this
one
is
a
very
simple
one:
adding
the
timeout
flag
to
this
fdm
binary,
there's
just
one
second
commit
adds
a
sort
of
thread
system
or
going
in.
A
It's
basically
spawn
the
separate
thread
that
has
a
Timeout
on
it,
and
then
this
new
one
I
did
I
just
added
in
this
morning
uses
async
IO
it's
a
little
bit
messy,
because
this
commits
removes
the
stuff
for
the
thread
based
one,
but
I
was
trying
to
get
it
so
that,
if
you
like,
look
at
like
the
end
of
this
commit,
you
can
sort
of
see,
at
least
in
the
parts
that
are
added.
A
A
So,
let's
say,
for
example,
this
the
timeouts
lag
in
the
binary
I,
don't
think
we'll
totally
cover
everything
we
want,
because
it
only
does
a
Timeout
on
the
actual
all
calls
which
I
don't
think
would
catch
all
the
cases
that
we've
hit
before
I'm,
that's
kind
of
why
it
went
through
something
a
bit
stronger.
But
I
also
have
this
little
note
in
here
that
maybe
we
want
to
go
back
and
Implement
something
like
that,
like
an
actual
proper
Global
timeout.
A
Eventually,
it
is
still
probably
a
little
bit
trickier
because
we're
now
talking
about
having
to
kill
the
actual
processor
break
out
of
the
actual
process.
That's
hang,
instead
of
having
to
break
out
of
like
RS8
connection
to
the
host
that
is
running
that
process,
so
it
might
be
I,
don't
know
straightforward
to
do
it
in
the
manager
module,
but
maybe
we
could
also
think
about
doing
that.
After
then,
there
is
yeah.
So
there's
a
thread
vessel
here.
A
The
thread
message:
it's
a
bit
heavy
and
it
is
a
bit
weird
going
along
with
our
async
iOS.
If
you
already
have,
because
we
async
SSH
requires
us
to
have
a
bunch
of
these
async
functions
everywhere
and
because
we're
putting
the
Timeout
on
the
SSH
commands,
we
would
have
to
basically
be
spawning
threads.
That
then
call
the
async
functions
and
so
you've
seen
that
they
have
like
multiple
layers
of
functions
in
there
because,
like
say,
threads
can
take
async
functions
as
a
Target,
so
you
have
to
have
the
thread.
A
Take
a
wrapper
function.
That
then
calls
another
async
thing
afterwards
and
there's
a
weird
way
you
have
to
handle
like
the
return
values
and
the
exceptions
and
stuff
that
you've
seen
that
that
patch
there.
If
you
look
through
it
a
little
bit
I
guess
you
have
to
pass
an
immutable
object
to
the
thread
so
that
it
can
then
put
the
results
or
the
exceptions
in
and
it
works.
It
did
all
these
work
when
I
tested
all
the
things
timed
out
properly
and
the
help
warnings
got
raised.
A
But
I
said
it's
just
a
bit
of
an
uglier
implementation
and
then
the
last
one
was
using
the
async
IO.
This
one
looks
pretty
straightforward.
Actually
they
got
into
it
because
it
turns
out
that
what
we
already
had
it
was
pretty
easy
to
pass
a
timeout
when
the
future
that
we
generate
originally,
when
we
do
the
you
call
it
the
results
function
on
it,
it
can
technically
take
a
timeout,
and
so
all
it
took
was
really
adding
a
timeout
into
one
of
our
internal
functions
that
I'll
just
go.
A
Look
at
it,
I
have
it
here.
We
already
have
this
internal
function
in
this
H
dot.
Pi,
let's
get
results
here,
and
it
already
called
this
sort
of
results
function
here,
and
so
all
it
really
took
was
passing
in
a
Timeout
there
and
it
it
just.
It
seems
to
just
sort
of
work
and
there's
obviously
a
little
bit
of
Plumbing
around
it
as
well.
A
Then
you
just
get
one
of
these
timeout
errors
and
you
at
least
this
one,
unlike
the
thread
one
where
I
currently
just
sort
of
left,
the
red
hang
out
afterwards
doesn't
try
to
do
anything
with
it.
We
can't
actually
cancel
the
the
future.
A
We
know
that
it's
stopped
as
well.
It
does
cause
a
little
bit
of
an
issue
with
errors
handling
because
exactly
spits
out
a
big
other
Trace
back
in
the
logs,
because
the
async
SSH
process
I
was
running
in
the
at
Future
that
we
just
canceled
Casey
gets
an
exception
when
we
do
that
use
one
of
these
canceled
errors.
So
I
have
to
do
something
about
that,
but
otherwise
it
seems
pretty
straightforward.
It's
a
much
smaller
patch
than
the
thread
ones.
A
Yeah
and
then
the
rest
of
the
Polar
Express
is
just
adding
some
test
commands.
You
can
see
the
three
cases
I
tried
testing.
Basically,
it's
one
that
just
sort
of
leaps
for
90
seconds
and
comes
back
so
basically
a
normal
thing
that
just
it
returns
normally,
but
it's
a
bit
too
long,
there's
one
that
sleeps
for
90
seconds
and
then
throws
an
exception,
and
the
idea
with
that.
A
One
is
something
that
takes
too
long
and
also
is
going
to
eventually
hit
an
error
and
then
there's
one
that
just
keeps
sleeping
forever,
that
one's
just
one
that
hangs.
Obviously-
and
so
the
point
was
just
to
test
those
three
cases
and
make
sure
they
all
correctly
time
out
and
they
get
the
health
warning
race
which
they
do
in
both
the
second
or
both
the
red
based
and
the
case.
A
And
now
that
I've
talked
for
like
10
minutes,
the
whole
point
is
just
sort
of
intro
all
these
Essence
that
we
formed
so
far
and
then
sort
of
try
to
pick
one
here
that
we
can
move
forward
with
I'll,
be
honest,
I
think
at
this
point,
I'm,
probably
leaning
towards
the
async
I
o
stuff.
A
It
looks
like
it
was
a
bit
simpler
to
implement
that
way
and
I
think
it's
easier
to
cancel
the
future
than
it
is
to
worry
about
killing
the
thread
if
you'd
probably
want
to
do
and
the
results
handling
is
easier
and
the
exception
handling
is
a
bit
easier.
So
I'd
like
that
one
but
I
put
that
pull
request.
So
people
can
look
at
what
they
sort
of
looks
like
and
I.
Don't
know
some
of
they
think
themselves.
C
So
I
generally
like
the
async
io
implementation,
a
little
bit
better,
but
the
one
thing
that
it
was
a
little
bit
concerned
about
is
we're
adding
these
additional
options
for
the
testing
and
the
cyphadian
binary,
and
the
usage
of
that
is
already
too
large.
It
feels
like.
Is
there
any
way
we
can
patch
that
into
the
manager
like
maybe
into
the
Run
stuff,
idiom
command
or
override
the
self-adium
binary
in
the
manager?
For
those
test
cases.
A
You
mean,
like
the
Sleep
90
seconds
things,
yeah
I
mean
the
plan
was
I
was
gonna
just
remove
those
commits
entirely
I
wasn't
planning
to
actually
keep
those
around
anywhere.
They
were
just
there
to
show
you
what
it
is
and
once
we've
picked.
One
of
these
methods
we
want
to
use
I
was
going
to
just
delete
them.
A
B
Maybe
I
don't
know
how
easy
this
is
since,
since
the
manager
module
always
typically
runs
stuff
ADM,
but
if
you
had
a
different
viewer
had
a
kind
of
you
know,
keyword,
ARG,
dependency,
injection
kind
of
approach
to
run
like
a
different
command,
then
you
could
just
run
like
sleep
or
something
on
the
other
side,
then
you
wouldn't
have
to
hack
stuff
ADM,
just
a
thought.
A
Yeah
I
mean
I
could
probably
even
in
theory,
just
run
like
have
the
actual
command
that
runs
be
like
that,
like
maybe
that's
what
you
were
saying.
Actually
it's
like
it
could
just
run
sleep
or
something
I
just
wanted
to
have
a
few
more
closer
to
like
the
original
sort
of
setup
and
I.
Think
also,
when
I
I'll
try
to
test
the
just
the
timeout
flag
as
well,
it
probably
doesn't.
B
A
B
A
Yeah
and
also
tricky
part
is
that
we
almost
always
end
up
having
to
patch
out
the
like
run.
Safety
M
command
in
the
entomology
unit
tests,
but
I
mean
I
could
also
patched
that
with
something
that,
like
times
out
and
then
give
it
like
a
one
second
timeout
and
then
have
the
command
sleep
for
two
seconds
or
something
and
just
basically
have
run
stuff
idiom.
A
Do
that
so
there's
ways
I
could
do
the
unit
tests
that'll
actually
be
a
bit
more
proper
in
the
test
of
timeout,
but
this
was
supposed
to
be
like
a
as
close
to
like
a
real
example
as
I
could,
which
obviously,
when
we
can't
merge
that
in
right,
but
I
wanted
to
sort
of
show
like
that.
I've
I've
tried
all
three
cases
I
think
of
anyway,
at
least
again.
It's
that's.
A
It
returns
normally
after
the
timeout,
it
there's
an
error
after
the
timeout
and
it
never
returns
ever
and
just
make
sure
that
all
three
of
those
work
I
don't
know.
If
there's
a
good
way
to
do
that
with
unit
tests
tested
at
that
level,
so
I
wanted
to
at
least
try
it
once
so
that
it
sort
of
works,
and
then
they
won't
have
I
guess
full
integration
testing
around
that
stuff,
probably,
but
maybe
we
actually
could
it's
probably
possible
I,
think
there
is
a
function
actually.
C
A
Yeah
that
could
be
a
way
we
could
maybe
have
like
an
actual
integration
test
that
run
just
runs.
Shell
commands
that
sleep
or
something-
and
it
could
even
like,
be
like,
because
if
it's
a
full
integration,
they
could
even
maybe
sit
there
for
like
10
minutes
or
something
you
don't
need
it
to
be
only
one
minute,
just
that
actual
like
long
running
tests,
that's
definitely
a
possibility.
I
could
do
an
integration
test
like
that.
A
Just
eventually
calls
the
shell
commands
with
sleep
in
it
or
something
and
then
make
sure
time's
out.
A
A
B
Yeah
I
mean
just
yesterday,
I
think
you
already
know
my
opinion
leans
towards
the
async
io
as
well.
A
Even
I
was
looking
up
a
little
bit
stuff
about
this.
There
were
people
talking
about
how
it's
tends
to
be
hard
to
write
good
code
when
you
mix
threading
and
the
async
io
stuff
as
well.
I
was
running
that
myself
I
actually
trouble
implementing
that
that
threaded
patch,
the
second
one
because
I
was
having
issues
with
the
mixture
of
those
two
things
originally.
A
Yeah
I
mean
if
people
don't
have
that
many
opinions,
I
guess
I.
Simply
the
async
io1
is
nicer.
I,
don't
know
if
I
just
move
forward
with
that
one
and
try
to
actually
Implement
some
proper
test
cases
around
it.
A
Right
and
I
started
I
guess
for
that
topic:
I
guess
it
was
mostly
end
about
picking
out
what
we
could
want
to
do
for
the
approach
and
then,
as
far
as
the
test
and
stuff,
that's
just
more
of
an
implementation
detail
I'll
have
to
sort
of
work
through,
but
it's
awesome
I
think
that
needs
like
a
ton
of
discussion
unless
it
ends
up
being
harder
than
I
expected
to
be
I.
Guess
we
can
end
on
that
one,
and
that
was
all
I
had
for
topics
myself.
A
All
right,
in
that
case
I
guess
we
can
end
here.
Yeah
thanks
for
coming
and
discussing
the
threading
stuff
and
next
week,
we'll
still
be
on
the
blue
jeans
meeting,
but
the
week
after
I
guess
just
make
sure
to
I.
Don't
know.
Remember
this!
This
link
I'll
try
to
update
the
calendar
entry
right
after
the
meeting
next
week
in
the
Seth
calendar.
A
A
Yeah
well
mine's
here.