►
From YouTube: Ceph Orchestrator Meeting 2020-08-03
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
today's
orchestrator
weekly
meeting,
let's
see
what
we
have
on
the
agenda
today.
We
have.
A
The
first
topic
is
to
display
our
warning
messages.
The
user,
like
leveraging.
A
A
A
I
hope
we
can
improve
things
here
and
this
mic
can
improve
things
you're
a
bit.
I
think
mike.
Your
idea
was
to
basically
just
provide
an
error
message
for
the
spec
for
edition
of
the
speculation
doesn't
work
or
this
fails.
Then
we
propagate
that
as
an
error
to
the
user
using
the
file
right.
I'm
not
mistaken.
B
Yeah,
that's
one
part
of
it
and
then
the
other
part
is
if,
for
whatever
reason,
we
fail
to
redeploy
or
reconfigure
daemon
or
something
else
happens
outside
of
spec
validation.
B
We
need
some
way
to
be
able
to
go
from
maybe
a
point
in
time
in
the
logs
the
event
logs
and
show
any
errors
or
any
context
generate
health
warnings
for
those,
and
so
maybe
that's
a
check
from
create
damon.
Maybe
that's
something
else
to
be
determined,
but
most
of
the
info
is
there.
If
you
do
a
ls
with
the
format
yaml,
you
can
see
in
the
event
logs
the
errors.
It's
just.
This
is
more
making
this
visible
via
health
check.
C
A
C
A
At
least
that's
the
way
health
warnings
work
right.
They
they
are
resolved
as
soon
as
the
problem
is
gone.
A
I
think
that
would
be
okay,
yeah,
okay,
as
long
as
it
gets
resolved
automatically.
I
can
just.
I
can
just
imagine.
C
Not
talking
specifically
about
specs,
I
mean
if
we
leverage
this
health
warning
thing
for
more
than
just
facts.
I
mean
this
could
be
anything
right
and
if
you
have
to
do
something
to
resolve
it
and
you
wait
and
then
well,
it's
still
still
there
and
then
you
do
something
again
and
then
you
wait
six
minutes
and
it's
still
there.
I
can
imagine
that
this
is
getting
quite.
A
Annoying
because
you
you
don't
really
have
a
way
to
call
the
the
surf
loop
thread
automatically.
There
is
no
way
to
do
that.
Right
now
I
mean.
C
So
yeah
this
is
where
I'm
getting
it
right,
so
we
do
have
a
way
to
kick
the
surf
loop
internally
internally.
Should
we
well
give
this
access
to
the
user?
A
I
I
mean
the
the
problem
is
that,
for
example,
if
you
call
you
call
ls
minus
minus
three
fresh,
that
just
doesn't
work,
I
I
mean
it
potentially
can
makes
fadm
completely
unresponsive.
A
Not
really
no,
not
really
steph
art.
A
Ls,
if
therefore
ls
minus
minus
refresh
makes
f
idiom
unresponsive,
we
have
to
provide
an
alternative,
and
that
might
be
that
we
don't
actually
refresh
cf
the
ls.
At
that
point,.
C
D
C
This
might
have
any
side
effects
so
yeah.
If
I
don't
know
this
yeah
and
he
calls
it
like
10
times
after
another
and
then
yeah,
basically
forcing
the
the
refresh
every
time.
And
then
I
because
I
think
we
don't
er,
have
any
kind
of
testing
for
this
scenario
where
the
surf
group
gets
triggered
over
and
over
and
over
again,
I
can
imagine
we
had
some
bucks
there.
B
So
an
alternate
that
needs
to
be
explored.
A
little
closer
is
during
create
daemon.
We
actually
set
a
time
stamp
on
the
daemon
description
and
we
kick
the
circle
and
that's
the
point
in
time
where
we
do
some
action
on
the
daemon,
which
is
the
perfect
opportunity
to
say,
hey
something
has
changed.
Maybe
we
should
reevaluate
this
air
state.
B
A
A
So
we
we've
used
theft,
manager,
failure
already
as
a
as
a
workaround
for
that
missing
feature
of
making
the
the
health
outlets
being
refreshed
because
of.
A
C
C
A
A
C
A
Only
returns
the
the
specs
but
also
returns
the
counts,
for
example,.
A
Yeah,
it's
like
a
state
of
staff
idiom
unless
yeah,
so
it's
more
like
just
a
spec
export,
so
I
think
it's
okay.
C
B
C
C
And
can
we
detect
if
there
is
a
so
if
we,
if
we
kick
multiple
times,
can
we
say
that
there
there
is
already
well
this
process
running,
which
you
know
triggered
serve
and
saying
that
you
know
this
doesn't
need
to
be
cute
again
or
something
muscle.
A
Kick
surfloop
is
just
a,
I
think,
it's
a
mutex
or
something
like
that.
No,
not
not
a
mutex
but
a
an
event,
and
if
you
set
that
event
multiple
times
it
would
just
do
nothing
all
right,
so
it
doesn't
queue
up.
It
doesn't
cure
anything.
C
A
Okay,
travis
osd
remover
designer
command.
E
Yes,
hello,
where
to
start
with
this
one,
so
there's
been
a
lot
of
changes
on
the
philosophy
of
osd
removal
and
rooks,
and
it's
that
design
doc
was
originally
opened.
What
almost
a
year
ago,
and
so
yeah
I'd
be
good
to
talk
through
what
the
new
way
of
thinking
is
around
that
and
see.
If
that
that
works
for
you.
E
So
the
the
latest
thinking
is
okay.
We
don't
want
rook
to
ever
basically
remove
osds
automatically,
because
if
we
ever
misinterpret
the
desired
state
or
the
admin
put
in
the
wrong
desired
state
and
makes
rook
think
that
that's
what
they
desire
to
remove
all
those
decisions,
then
work
would
automatically
remove
lots
of
osds,
and
this
would
be
bad
news
of
course.
E
So
we
don't
want
rook
automatically.
Removing
osd's
is
the
point,
at
least
not
as
part
of
the
operator,
but
the
thought
is
that
okay,
we
still
do
need
to
remove
osds,
sometimes
and
as
long
as
the
admin
makes
a
specific
decision
to
do
that,
then
rook
can
do
a
one-time
operation
where
we
remove
the
osds
based
on
their
osd
id,
for
example.
E
E
Remove
its
deployment
clean
up
with
its
pvc.
If
it's
backed
by
a
pvc,
remove
it
from
the
crush
map
or
do
the
osd
purge
command
and
some
things
like
that,
so
that
way
we
get
a
one-time
operation
that
they
can
remove
osds
with
and
it's
something
that's
a
very
explicit
decision
by
the
administrator
if
they
want
to
run
this
job
to
remove
osds
and
it's
not
something
that
that
the
operator
would
drive
with
desired
state.
It's
just
really
a
one-time
operation
with
this
job.
E
So
that
means
the
you
know
from
the
dashboard.
You
know,
let's
say
the
dashboard,
had
this
option
to
remove
an
osd.
Well,
the
dashboard
could
then
tell
the
orchestrator
module
for
rook,
hey,
remove
this
osd
and
then
the
rook
orchestrator
module
could
kick
off
this
kubernetes
job
to
remove
that
osd
id
and
that
so
that's
the
quick
version
of
of
how
I
see
it
working
and
how
it's
coming
together
so
does
that?
E
C
So
we
have
this.
We
also
have
this
explicit
way
of
removing
things,
so
we
call
this
ceph
orchestrator,
osd,
rm
and
then
a
set
of
osd
ids
by
the
looks
of
it.
You
are.
C
Okay,
well,
we
kind
of
do
the
same
thing,
so
we
have
some
safeguards
in
place
like
was
the
okay
to
stop
and
safe
to
destroy,
and
then
we
also
drain
the
osd
before
actually
taking
any
action
on
it
or
we'd
also
have
a
force
flag
which
does
not
drain
before.
C
C
C
E
C
E
Action,
it
would
be
just
a
new
osd.
A
C
E
Right,
I
guess,
with
this
new
proposal,
should
we
just
close
that
that
design
pr
and
go
with
what
we're
already
doing
with
this
other
or
or
you
want
to
update
that
design
dark
it's
up
to
you.
A
E
E
A
C
There
was
a
design
dog
once
and
well.
Funnily
enough,
I
created
actually
a
standalone
manager,
module
that
handles
the
draining
and
well
actually
the
parts
that
are
orchestrator
agnostic,
but
it
turns
out
to
be
not
so
nice
and
it
has
a
lot
of
overhead
and
that
vadim
was
always
the
only
user
of
this
manager
module.
So
I
got
rid
of
it.
C
Ago
so
yeah
I
will
post
you
the
link
to
the
code.
It's
pretty
self-explanatory.
E
A
E
A
C
C
E
Not
for
me,
maybe
one
quick
note
on
rook,
though
we've
got
the
1.4
release
planned
later
this
week.
If
we
keep
on
schedule
so
we're
just
testing
upgrades
and
other
things
and
hoping
to
get
that
out
so
yeah.
A
A
A
Next
epidemium
topic,
unfortunately,
jamaica,
is
on
vacation.
Today,
as
far
as
I
know,
there
is
an
open
tracker
issue.
That's
four:
three:
seven:
zero:
zero!
A
That's
about
refactoring
the
fdm
to
make
it
a
proper
python
packet
or
making
it
properly
developable
the
developer
experience
for
this
film
binary
is
really
bad
right.
Now,
I
think,
as
first
remember,
miguel's
idea
was
to
make
it
possible
to
have
a
minus
minus
version
flag
and
a
proper
cli
that
is
compatible
to
multiple
meter
versions.
A
We
just
have
to
to
do
some
groundwork,
firstnets.
The
steps
that
I
outlined
here
in
the
other
pad
that's
removing
injected
acid
in
and
then
make
it
a
proper
python
package
plus
finally
releasing
cfdm.
So
right
now,
folks
are
directly
downloading
the
self-adm
binary
from
github,
which
is
super
awkward,
because
that
means
that
we
can't
do
proper
releases
of
civ
adm
binary.
C
A
A
I'm
I'm
talking
about
deploying
in
your
theft
cluster,
how
it
is
documenting
if
you
go
into
the
documentation.
C
A
Yeah,
I
think
the
the
root
mode
is
going
to
be
the
default,
at
least
for
a
while
until
we
have
properly
and
thoughtfully
figure
it
out.
I
figured
out
what
you
want
to
do
with
the
package
mode.
Yes,
but
having
that
is,
I
think,
really
a
prerequisite
in
order
to
get
rid
of
the
root
mod.
If
we
ever
go
to
that
point,.
A
But
in
any
case,
people
are
downloading
selfie
name
from
github,
which
is
super
awkward,
that's
and
we
we
really
have
to
push
the
fading
to.
I
don't
know
download.io
somewhere.
A
And
that
will
make
it
possible
to
add
a
minus
minus
version
flag
to
70m,
because
right
now,
that's
virtually
impossible
without
synchronizing
the
source
code
of
cipherdm,
with
a
version
of
diff.
A
A
A
Now
the
last
topic,
or
at
least
from
my
side,
is
that
I'm
getting
requests
from
from
multiple
people
that
we
need
to
have
a
way
to
use
one
container
image
throughout
the
cluster
and,
as
far
as
I
know,
sef
ansible
converts
the
tag
to
to
a
digest
using
the
repo
digest.