►
From YouTube: Ceph Orchestrator Meeting 2022-04-18
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
A
Not
do
that
today
and
we'll
just
go
over
the
these
minor
topics
we
have
and
we'll
do
the
brief
stuff
next
week
or
some
other
week,
okay
yeah,
so
I
think
you
put
all
these
in
here
right
now.
Do
you
want
to
talk
about
these
issues.
B
Yeah,
basically,
these
should
say
boots
are
related
to
some
problems.
I
was
investigating
the
last
days.
The
first
of
them
is
the
usage
we
give
right
now
to
the
configuration
file.
The
main
corporation
file
get
it
at
etcsef.com.
B
B
So
he
was
wondering
to
which
point
we
really
need
the
compression
file
and
what
is
the
the
the
usage
with
the
the
modern,
the
basic
containers.
A
Yeah,
so
I
think,
like
I
was
saying
then
or
before
talking
in
chat.
The
main
thing
we
do
with
them
now
is
just
we
need
them
for
the
mon
addresses,
because
you
can't
do
a
proper
shell
command
unless
you
know
where
the
ips
of
the
monitors
are
at
least
one
of
the
monitors
is,
and
so
you
need
the
conflict
for
that.
That's
why
we
put
them
on
all
those
admin
hosts
is
so
you
can
do.
A
Shell
commands
there
connect
to
the
cluster
before
there
was
containerized,
I'm
pretty
sure
they
used
to
actually
just
read
from
etsy.com
on
the
host
directly
and
demons
would
get
all
their
conflicts
from
there,
and
so
it
was
super
important
to
follow
that
out,
but
nowadays
the
containerized
one
one
will
usually
what
we'll
do
so
it'll
be
looking,
sometimes
in
etsysaffsef.com,
but
they
don't.
Instead
of
just
having
directly
used
one
on
the
host,
we
usually
will
give
them
their
own
config
and
then
mount
it
into
the
container
in
the
right
spot.
A
That's
what
that
that
non-configure
talking
about
how
they
have
their
own.
That's
where
it's
getting
that
from
is
where
it's
we're
putting
it
there.
So
that
we
can
then
mount
it
into
etsy.com
inside
the
mod
container,
and
so
as
for
the
actual
one
on
the
host.
It's
mostly
just
for
that
purpose.
Now
of
you
use
doing
shell
commence,
this
is
it
doesn't
matter
as
much
now
that
we're
containerized
and
the
mod
store
has
all
the
config
options
in
it
yeah
I
see.
B
I
think,
maybe
in
the
long
run,
and
supposing
that
we
will
have
the
confirmation
available
for
cluster
on
the
bar
lab
bar
leap-
sorry
cf,
ssid,
config,
new
directory,
then
at
some
point
we
will
not
need
this
file
anymore.
A
It's
possible
yeah
one
day,
we'll
be
able
to
get
rid
of
it.
We'll
have
to
see,
because
I
think
there
are
still
some
things
that
will
try
to
use
it,
and
obviously
we
still
look
for
it
as
like
our
default
in
certain
places
as
well.
I'm
not
sure
if
we'll
be
able
to
completely
remove
it
anytime
soon,
because
I
I
don't
know,
there's
probably
some
legacy
things
that
still
look
at
it.
I
just
I
don't
know
what
all
of
them
are.
A
I
think
that
maybe
some
stuff
volume
stuff
that
still
uses
it-
at
least
I
think
I
remember
there
was
some
issue
where
there
was
some
setting
that
they
wanted
to
set
for
subsequent
volume
command,
but
you
couldn't
set
it
in
the
mod
store.
There
was
no
option
for
it
there,
and
so
the
only
way
to
do
it
was
to
run
the
volume
on
the
host
and
you
had
to
mount
or
you
could
have
volume
on
the
host
with
that
option
in
the
csaf.com.
A
Now
we
obviously
we
can
also
do
stuff
volume
commands
in
a
container,
and
so
you
could
technically
mount
an
etsy
stepstep.com
put
that
stuff
into
the
container.
Instead
of
having
the
one
in
the
host
have
the
options,
so
you
could
probably
get
around
it,
but
I'm
not
sure
we're
going
to
totally
remove
it
anytime
soon,
but
yeah.
It's
definitely
it's
important
to
sort
of
been
diminished.
Don't
need
to
worry
about
it
too
much
anymore.
A
B
There
any
sort
of
reason
you
what
what
I
keep
going
and
basically
this
comes
because
I
was
investigating
this
minimize
cephalon
probation
issue,
which
seems
to
be
broken
right
now,
because
it
just
overrides
the
file
content
just
after
the
bootstrap,
and
they
didn't
really
understood
why
this
user
was
using
the
or
once
the
the
complete
configuration
file.
Maybe
he
he
had
an
old
version
of.
A
C
A
Yeah,
so
they
have
some
reasons.
I
guess
they
want
to
do
it
that
they're,
I
guess
using
the
directly
that
outfit,
my
sort
of
idea
for
it
for
dealing
with
that
as
far
as
the
bootstrap
flag,
getting
that
working
was
just
to
not
apply
the
admin
label
if
they
pass
that
flag,
because
then
we'll
won't
overwrite
it.
Basically
you
don't
pass
it.
That's
the
only
reason
where
the
writing
is.
A
We
won't
update
the
conf
on
the
host
or
the
key
ring
on
the
host.
So,
like
the
admin
key
ring,
that's
you
we
put
in
fcsef
when
we
bootstrap
will
be
right
there
in
the
config
file
at
csfsep.com
I'll
host
our
marked
admin.
We
write
out
a
basic
version
of
that,
and
basically
the
idea
of
it
is
that
any
host
that
has
those
two
things
on
it.
You
can
then
shell
into
the
cluster
with
that
information.
A
So
if
we
don't
write
it
there,
if
they
were
to
say
move
all
their
monitors
around
and
so
like,
whatever
mod
addresses
were
in
that
class,
that
config
were
not
right
anymore
and
there
were
no
mods
on
that
host
to
infer
from
then
they
wouldn't
affect
the
cluster
from
that
host
or
they'd
have
to
like
manually,
provide
what
those
addresses
are
because
we're
not
managing
it
for
them.
But
the
thing
is:
if
they're
going
to
use
the
cons
themselves,
they
want
to
have
full
control
over
all
of
that
stuff.
A
A
Yes,
we
can't
really
be
overwriting
their
content;
they
want
the
full
control
over
it
and
really
the
only
time
where
we
sort
of
do
it
ourselves
or
like
where
we
just
mark
a
host
is
like
we're
going
to
manage
this
one
instead
of
the
user
having
to
explicitly
do
it
is
in
the
bootstrap
with
that
admin
label.
B
I'm
wondering
if
the
users
in
this
case
will
expect
to
have
like
the
complex
conversion
file
only
on
the
house
that
was
used
for
the
bootstrap
or
they
are
expected
to
have
the
same
configuration
file
in
all.
A
You
know,
notes
well
the
way
it
used
to
work.
Is
it
wasn't
like
automatically
copied
all
those
or
anything?
I
don't
think
so.
If
they're
going
to
manually,
maintain
it
like
that,
I
think
they
would
expect
they
have
to
put
it
on
all
those,
but
also
it
could
be
different
in
all
the
hosts.
They
don't
necessarily
want
an
identical
one
on
all
the
hosts
either.
That's
why.
A
Their
replication
settings
is
that
they
and
why
they
don't
like
the
normal
database.
Is
they
want
the
different
settings
on
each
host?
Oh
see
now
you
can.
You
can
do
that
with
the
database
as
well.
Database
allows
host
granularity
when
you
set
conflict
settings.
If
you
don't
have
a
symbol,
you
have
the
global
setting,
then
you
have
like
a
demon
type
there's,
also
like
civic
demon
or
a
demon
host
combination
whatever.
A
So
you
can
do
all
that
stuff
with
the
database
as
well.
I
guess
they
prefer
to
use
the
config
file,
maybe
they're
just
used
to
it
either
way.
It's
you
know,
that's
up
to
them.
I
think
they
want
to
do
that,
but
I
think
all
we
really
need
to
do
on
our
site
is
make
sure
we
don't
overwrite.
The
configuration
typically
ask
us
not
to
do
that,
and
that
really
just
means,
don't
add
the
admin
label
to
the
first
host.
If
they
does
this
flag.
B
A
Yeah
all
right
anything
else
for
that
topic,
or
I
guess
the
first
two
flag.
The
first
two
points
are
sort
of
the
same
topic.
B
A
All
right,
yeah
we'll
move
to
that
one
then.
So,
where
do
you
want
to
introduce
this
topic
as
well.
B
B
The
program
comes
when
you
have
a
mix
of
registries,
but
at
least
that
was
what
I
saw
on
a
bunch
of
them.
You
have
a
mix
of
registries
and
most
recent
image,
maybe
the
old
one,
because
you
just
pick
image
from
different
registries
and
each
one
of
them
has
a
different
creation
date.
B
So
my
proposal
is-
and
I
was
also
discussing
this
with
adam-
is-
is
why
not
use
the
demons?
Because
you
have
this
information,
so
why
not
use
the
self
demons
in
order
to
transfer
the
image
if
possible?
If
not,
then
we
just
fall
back
to
the
legacy
behavior
to
just
pick
the
latest
one,
because
we
don't
can't
do
much
in
this
case,
if
you
can
add
them
at
the
same
sequence,.
A
Yeah,
so
my
thoughts
were
basically
that
we
treated
exactly
the
same.
We
do
for
inferring
the
config,
so
we
have
like
started
chile
like
a
priority
list
for
that,
like
there's
the
explicit
conflict,
if
you
provide
it-
and
we
use
that
one-
not
always
there's
the
name
flag
for
the
demons
that
we
use,
we
use
that
demon's
config.
A
If
you
provide
that,
then
it's
the
monitors-
and
I
think
we
also
now
have
there's
the
fsid
directory
on
and
then
there's
the
etsy
steps.
So
we
have
this
whole
like
list
of
things
and
like
this
one
takes
priority
over
this
one
and
we
just
go
down
the
line
until
we
find
one
that
matches
or
we
give
up.
A
I
guess
there's
none
of
them
by
the
edge
of
the
idea
was
we
could
do
a
similar
thing
with
the
the
demon
type
or
the
into
the
image
name
where
the
defaults
would
they're
the
highest
priority.
One
maybe
like,
if
there's
a
monitor
on
the
host-
and
we
know
the
fsid
like
they've,
already
inferred
the
fsid.
A
If
you
find
a
monitor
that,
where
the
fsid
matches
we
can
use
that
one
then,
with
the
managers,
those
ones
should
be
pretty
high
priority
and
then,
like,
I
guess,
osu
would
be
third
and
after
that,
it
really
just
like
all
the
other
demons
are
sort
of
equal
in
terms
of
how
high
priority
we
do
and
then,
if
there's
no
demons
on
the
host,
I
guess
you
would
then
have
to
go
back
to
our
old
strategies
of
just
picking
the
most
recent
one.
A
C
B
A
A
A
Yeah
like
if
you
want
to
specifically
say
like
I
want
this
image
in
your
my
shell,
like
we
have
that
option
and
if
you
want
to
say
like
I
want
this
specific
demon
name,
I
want
it
to
match
that
demon.
Do
we
have
that
option
and
other
than
that,
we'll
just
we'll
do
like
a
best
best
attempt
to
guess,
based
on
what
demons
you
have
on
the
host.
A
A
Version-
and
we
can't
really
do
it
by
version
just
because
getting
the
version
is
still
super
slow.
We
don't
have
a
good
way
to
do
that.
You'd
have
to
exec
into
the
container
and
do
like
a
cf
version.
Call
right
now
and
imagine
if
you
have
to
do
that,
so
you
had
like
seven
different
set
of
images
on
your
host.
We
had
to
check
all
of
them
to
make
sure,
like
you
know,.
B
Just
as
a
note,
I
tried
this
to
get
the
safe
version
by
just
running
the
image
and
sometimes
it
works.
Sometimes
you
just
get
an
error
because
for
whatever
reason
and
that's
the
image
it
gets
yeah.
A
But
I
know
that's
always
the
fallback
that
you
have
to
have
just
because
sometimes
it's
all
you
can
do
is
to
just
exec
into
the
container
and
do
some
sort
of
call
to
get
the
version
so
you're
always
going
to
prepare
for
the
possibility.
You
have
to
do
that
for
all
of
your
images,
so
we
really
only
want
to
do
that
when
we
have
to
which
is
for
ls
you
have
to
because
you
want
to
get
the
version.
That's
one
of
the
important
things,
but
for
a
shell
command
it'd
be
nice.
B
A
Yeah
and
common
inspectors
are
even
batch.
Those-
I
don't
remember
for
sure
I
don't
remember
yeah,
I
didn't
like
pop
mps
or
pubmed
and
specs
they're
much
quicker
than
any
sort
of
pubmed
exec.
I
want
to
be
doing
those.
A
The
contact
from
the
monitors
you
might
as
well
pull
the
image
the
only
time
where
you
wouldn't
want.
That
is
when
I
guess
you're
in
the
middle
of
upgrade,
you
haven't
upgraded
your
monitors
or
something,
but
in
which
case,
like
that's
weird
scenario,
you
could
pass
the
image
flag
you
really
needed
to.
I
think
it's
unlikely
that
they
would
have
a
newer
image
than
whatever
their
monitors
are
on
so
they're
so
early
in
the
upgrade
process.
B
A
B
Yeah
I
saw
his
he's
going
to
basically
ask
if
we
can
edit
the
image
idea,
I
think
which
is
good
idea,
but
I
also
think
that's
having
the
creation
dates
could
be
helpful
also
on
scenarios,
because.
A
A
B
A
A
A
B
I
introduced
some
unit
testing
for
first
step,
but
since
I
wasn't
sure
at
the
beginning
what
this
was
really
testing
or
what
was
checking
for
it's
like
chicken
for
image,
but
not
that
just
as
the
end
you
have
to
have
to
refresh
this
because
in
weeks
let's
say
it
worked
or
not.
A
A
B
I
cannot
do
some
new
test
and
I'm
gonna
if
we
could
leave
that
test.
There.
A
A
All
right,
yeah,
so
yeah
leave
that
one
in
and
then
we'll
add
that
one
with
the
the
weird
cases
that
the
old
test
had
just
so
we're
covering
everything
and
then
just
yeah,
add
the
image
id
to
the
output.
And
I,
like
everything,
everyone
has
that
pr
would
be
covered.
Guess
what
yeah.
B
A
All
right,
I
see
there's
this
other
stuff
here.
C
C
I
was
fighting
with
etherpad,
I
I
haven't
used
it
enough
to
get
used
to
how
it
formats
things,
and
so
I
tried
to
copy
and
paste
the
old
date
title,
so
it
wouldn't
lose
the
formatting,
and
then
I
forgot
to
go
back
and
change
the
actual
number.
C
C
Now
we
can
don't
need
to
go
into
details
is
because
this
is
like
a
long
thing
like,
as
you
mentioned
last
week,
it's
a
multi-stage
thing
and
you're
concerned
about
doing
a
lot
of
it
early
in
the
cycle,
because
that
will
make
back
ports
difficult
blah
blah
blah.
C
My
suggestion
is:
let's
come
up
with
a
game
plan
and
document
the
phases
and
stuff
so
that
we
know
when
things
need
to
get
done.
It's
it's
one
of
these
things
that
before
sebastian
left,
he
kept
talking
bringing
up
to
me.
So
I
feel
like
I
don't
want
this
to
just
get
a
slip
and
you
know
end
up
not
getting
prioritized
or
whatever
so
yeah.
C
C
If
we
had
like
a
a
branch
where
people
could
file
their
prs
against
the
special
like
you
know,
stefan
adm
split
up
or
whatever
you
want
to
call
it
as
opposed
to
having
to
get
everything
you
know
into
you
know,
master
or
reef
or
whatever.
A
Yeah,
it's
a
good,
interesting
idea
to
see
how
we
want
to
work
it
because
there
is.
A
A
C
Right
so
one
suggestion
I
have
is,
if
that's
a
if
that
branch
is
like
a
forward
porting
branch
as
opposed
to
a
backboarding
branch,
what
I
mean
by
that
is
it
regularly
takes
a
merge
from
master
or
whatever,
and
so
every
time
you
do
that,
if
there
is
a
true
merge
conflict
get
your
version.
Control
system
is
going
to
say:
oh
hey,
there's
a
there's
a
merge
conflict
here.
C
It
might
make
cherry
picking
out
of
that
branch
harder,
but
I
think
you
would
at
least
have
the
advantage
of
knowing
that
the
approach
has
been
validated.
You
know
it
might,
it
might
just
be
the
minimal
structural
changes.
I
don't
know
this
is
this
is
a
big
food
for
thought
thing.
This
isn't
like
hey.
Let's
come
up
with
a
plan
today,
it's
more
like,
let's
plan
for
a
plan.
C
A
Yeah,
we
definitely
need
to
do
it.
Obviously,
just
how
many
questions
we
have
right
now,
yeah.
I
think
I,
interestingly,
I
should
push
back
the
topic
until
mike's
here,
because
he
still
has
to
work
sort
of
his
thing
yeah
and
then
it's
sort
of
part
of
also
the
the
reef
priority
planning
and
all
that
which
is
again.
I
wanted
to
push
back.
Some
more
people
were
around
yep,
so
maybe
we'll
just
copy
paste
that
onto
an
april
26
thing
on
the
other
pad
and
we'll
just
I'll.
A
Let
you
do
it
so
I
don't
have
to
mess
up
the
dating
I'll
paste
that
in
there
that
is
an
important
topic,
because
it
would
be
nice
to
have
it
sort
of
all
there
earlier.
So
it's
all
ready
and
everything
for
reef
at
the
same
time,
yeah
I
don't
know
I
was
we
wanted
to
push
it
back,
so
we
don't
have
to
worry
about
the
back
parts
and
everything.
So
it's
a
bit
of
a
tricky
topic
so.
B
Probably
we
can
have
like
some
intermediate
branch
on
like
with
the
current
binary
as
it
is,
and
then
once
we
start
with
the
refractory,
then
we
keep
like
the
new
stuff
in
master.
So
this
way,
if
we
want
to
fix
something,
we
just
go
to
this
intermediate
branch,
we
fix
it
there
and
then
literally
pick
blackboard.
A
B
A
C
A
You
wonder
that
so
the
differences
with
like
with
what
john
was
saying
is
that
if
we
have
the
main
mastermind
is
just
still
the
unrefactored
one
and
that
makes
like
the
backboards
or
whatever.
Then
we
just
have
like
a
forward
system
for
actually
bringing
all
that
stuff
to
the
new
one.
And
then
we
have
this
sort
of
refactor
when
we
keep
building
up
over
over
time,
and
we
just
especially
swap
over
to
that
as
like
the
official
one
near
the
end
of
the
end
of
quincy
like
right
before
the
reef
release.
A
So
in
that
case
it
makes
sort
of
sense
to
have
all
three.
But
I
think
if
we
have
the
main
master
branches
refactored,
then
at
that
point,
you'd,
almost
just
you'd
do
away
with
the
middle.
C
A
C
Yeah
at
some
point,
there's
going
to
be
some
amount
of
pain
anyway,
because
there's
no
there's
no
way
to
avoid
it,
whether
you
try
to
make
it
painful
now
or
you
try
to
make
it
painful
right
before
the
reef
branches
cut
or
whatever
there's
gonna,
be
some
level
of
pain.
The
other
thought
I
had
and
I'll
just
share
this
again.
It's
just
food
for
thought
of
what,
if
we
had
some
kind
of
automation,
tooling,
to
try
and
help
with
these
ports.
C
A
C
Yeah,
so
it
might,
it
could
be
like
hey.
You
know
at
some
point,
this
file
is
going
to
get
chopped
up,
but
you
know
you
can't
add
dependencies
yet
or
all
of
the
all
the
pieces
have
to
be
in
this
particular
directory.
C
I
don't
know
that
there
would
have
to
be
some
restrictions
on
what
you
could
do,
so
I
don't
know
how
easy
or
hard
it
is.
It's
just
a
stray
thought
that
I
had
last
week
after
the
meeting.
That's
basically
what
this
topic
is
stuff,
I
thought
about
after
the
meeting
I
did
not
want
to
I'd
track
the
reef
meeting
with.
B
Yeah
yeah
and
I
think
it
would
be
helpful
also
to
try
to
close
as
much
issues
as
we
can
so
this
way
we
we
are
closing
them
on
the
current
version
of
the
binary
and
then
start
the
fracturing
if
we
have
a
bunch
of
them,
there's
no
problem.
B
A
A
So
it's
inevitable,
we'll
have
big
changes
there,
but
at
least
we
can
get
as
many
things
as
we
can,
especially
things
that
are
changing
existing
code.
That's
one,
if
maybe
you're,
adding
a
new
demon
method
to
be
easier.
Do
that
in
the
refactored
version
and
original
one
compared
to
stuff
that,
like
changes,
existing
functions
that
we're
gonna
have
to
move
around
later,
maybe
we're
gonna
split
them
up
in
the
different
files
or
whatever
yeah,
so
at
least
yeah
the
existing
bugs
at
least
nice
to
prioritize.
A
I
was
also
thinking
back
of
year
year
and
a
half
ago
or
something
there
was
one
other
sort
of
big
refactor.
Where
that
served
up.
Pi
file
used
to
not
exist.
Actually
it
used
to
be
the
module
that
pi
had
both
the
stuff.
That's
in
the
module
now
and
also
the
certified
stuff
and
then
sebastian
split
that
into
two
different
files
and
had
served
that
pie.
A
So
there-
and
I
was
wondering
oh-
is
that
the
example
we
could
look
at
for
how
maybe
they
do
this,
but
I
think
actually
that
just
got
end
up
getting
back
ported
all
the
way
back
anyway.
So
we
can't
really.
We
don't
really
want
to
do
that
here,
so
it
doesn't
really
help.
But
that
was
something
I
was
thinking
of.
A
It's
the
problem
that
we
can't
really
the
reason
we
can't
backboard.
This
refactoring
is
just
because
it
changes
the
way
you
have
to
like
get
the
binary
or
you
have
to
like
to
use
like
a
proper
package
whatever
in
the
zip
and
everything
yeah,
and
so
we
can
retain
the
user
experience
now.
We
only
want
to
do
that
in
a
major
release
so
that,
unlike
where
the
served
up
by
refactor,
where
it
only
changed
in
implementation,
detail
and
users
didn't
have
to
do
anything.
A
C
There
might
be
some
tricks
we
can
do.
We
should
definitely
have
that
as
part
of
that
bigger
discussion,
you
know,
let's,
let's,
let's
have
like
a
separate
ether
pad
or
google
doc
or
something
that's
just
like
you
know.
What
are
the
challenges?
What
are
the
you
know
the
goals?
C
You
know
intermediate
steps
that
we
might
go
through
to
get
to
the
end
goal
and
then
like
when
they
occur
like
yeah,
we
cannot
do
x
until
you
know
there
is
a
brief
branch
or
we
cannot
do
y
until
you
know,
we've
cleaned
up
x,
number
of
tracker
issues,
whatever
yeah
yeah.
C
It
always
annoying
because
it's
it
feels
like
you're,
not
doing
real
work,
but
for
something
long
term
it
usually
pay
off
to
do
some
upfront
planning.
A
Yeah,
all
right,
that's,
okay,
yeah!
I
guess
I
just
stopped
again
we'll
bring
it
up
next
week
when
mike
is
here.
They'll
know
a
bit
more
about
like
stuff,
like
I
always
talk
about
like
oh,
is
it
actually
possible
to
have
some
way
that
makes
it
the
process
the
same,
so
we
could
backboard
it.
I
think
mike
would
probably
know
more
about
that
he's
working
on
the
actual
stuff,
but
we'll
talk
we'll
bring
up
briefly,
I
guess
with
him
in
the
stand.
Ups,
I
guess
over
the
weekend,
assuming
he's
back
tomorrow.
A
A
All
right-
and
that's
it's
for
earlier
today-
I'll
move
this
stuff
over
to
the
26.