►
From YouTube: Ceph Orchestrator Meeting 2020-06-08
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).
B
A
Blue
store
on
disk
format
changes
everything
it
needs
to
be
implemented
in
the
upgrade
hi
Travis.
Well,
how
do
you
do
these
kind
of
upgrades,
this
kind
of
major
upgrades
and
rook?
Is
it
all
manual
right
now.
C
Great
so
I
mean
the
the
approach
for
upgrades
major
upgrades,
so
say
right
from
Nautilus,
doctopus
right
you
just
it's
really
the
same
process
from
the
users
perspective
as
even
a
patch
release.
You
just
update
the
version
of
step
that
rook
is
supposed
to
deploy
and
then
rook
is
supposed
to
handle
all
of
the
anything
that's
needed
during
the
major
upgrade
we
yeah.
Actually,
we
don't
too
often
have
special
steps
for
the
upgrade.
C
We
just
update
the
individual
components
in
order
and
it
seems
to
work
pretty
well
and
but
like
when
we
deploy
octopus,
we
have
to
run
certain
commands
to
to
enable
thing,
okay,
which
we
have
to
do
for
new
deployments
anyway,
if
it's
octopus,
but
in
general,
though
it's
just
kind
of
built
into
the
whole
upgrade
process,
just
set
the
version
and
we're
it's
supposed
to
handle
it.
Okay,
finish
it
that
answer
your
question:
yeah
yeah,.
A
D
D
E
D
A
I
was
I
was
thinking
change
the
scheduler
a
bit
more.
A
D
A
One
thing
that
I
don't
know
is
that
we
will
always
have
some
kind
of
in
transparent
part
of
the
scheduler,
especially
if
we
really
go
into
resource
aware
scheduling,
scheduling
based
on
existing
occupied
pod
stuff,
like
that,
so
it's
getting
ever
more
complicated
step
by
step
and
I
wonder
if
we
really
should
aim
for
a
hundred
percent
solution
like,
for
example,
this
that
was
will
be
deployed
on
those
specific
host
or
or
should
we
just
be
okay
with
it
will
deploy
I,
don't
know
to
demons
on
on
those
hosts,
basically
like
just
give
a
rough
estimate
of
where
services
are
going
to
get
deployed
instead
of
exactly
telling
people
what
is
going
to
happen,
I
mean
we
can.
D
We
can
just
be
somewhat
accurate
right
because
this
planning,
previewing
or
whatever,
is
always
for
this
very
moment,
currently
the
likelihood
that
the
cluster
changes
is
well
without
knowing
without
the
administrator,
knowing
it's
very
little
and
so
and
therefore
we
can
really
say
so.
The
the
planning
that
you
did
like
ten
seconds
ago
is
nineteen
ninety
nine
percent
accurate
to
what
the
outcome
would
look
like
like
they're
right
in
a
bigger,
let's
say,
hundred
two
hundred
no
cluster.
D
This
is
definitely
a
different
story
because
there
can
be,
you
know,
drives
where
discs
are
being
replaced,
left
and
right.
There
is
new
new
nose
popping
up
and
environments
change,
and
maybe,
even
if
the
environment
is
hyper-converged,
things
will
definitely
change,
but
until
that
happens,
and
until
we
have
a
resources
of
a
scheduler
that
really
changes
its
outcome
on
on
small,
because
this
approach
is
more
than
fine,
it
yeah
and
right
now
we
can
be
really
precise,
with
just
small
adaption.
D
Well,
the
plan
is
independent
of
the
seed,
it's
just
so
I
don't
actually
know
if
the
seed
will
be
refreshed
when
you
restart
the
manager
or,
if
you
or
if
the
module
gets
reloaded,
and
that's
that
will
probably
happen.
If
you
issue
a
you
see
a
like
on
and
that
I
don't
know,
but
why
don't
we
just
keep
a
consistency.
This
is
not
about
being.
You
know
accurately
random.
This
is
about
you
know
getting
something
out
of
a
list
and
then
which
is
not
alphabetically.
This
I
mean
the
whole
point.
D
A
A
D
Comment
in
there
it
might
be
branch
saying
that
a
resource
aware
scheduler
is
probably
evil
ready,
a
new
scheduler
and
not
even
a
simple
schedule
anymore,
because
we
we
have
code
that
looks
into
the
demons
and
then
decides
based
on.
If
the
House
already
has
demons,
it
will
then
remove
or
add
new
demons
to
that
holster
right,
that's
not
happening
in
the
scheduler.
D
C
D
D
D
D
Yeah
I
mean
probably
next
week:
I
will
have
something
that
is
actually
prison,
able
and
then
I
can
I
can
show
it,
and
we
can
discuss
it
a
bit
more.
Okay,
yeah.
The
only
the
only
thing
that
I
wanted
to
mention
here
is
that
we
should
have
a
way
to
uniquely
identify
specifications,
for
example,
because
currently
we
don't
enforce
service
ID
to
be
set.
That
means
that
you
can
apply
to
service
packs
specifications
for
it.
D
Let's
say
Oh
STIs
that
have
no
placement
and
that
have
only
specific
a
today,
only
the
key
service
type,
and
so
they
look
identical
and
they
are
or
they
are
both
being
stored
on
the
on
the
monster.
And
then
we
have
a
conflict
of
either
we
should
and
for
service
ID,
or
we
do
internal
tracking
of
whatever
IDs.
A
D
For
those
kind
of
services,
it's
probably
fine,
because
you
shouldn't
have
more
than
two
anyways
and
more
than
one
anyways
yeah,
but
there
is
valid
use
case
for
I,
think
rgw
or
these
probably
an
offense
I
scuzzy.
Before
those
you
can
have
multiple
and
currently
we
do
not
enforce
ferzetti.
That
makes
it
a
visual
track.
B
Well,
one
question
this
one:
just
because
I
don't
understand
very
well:
why
do
we
need
a
new
command
keyword
plan
in
order
to
do
this?
Okay,
because,
basically
I
think
that
we
can
do
the
same
I
think
we
we
must
do
the
right
thing
using
the
applying
common,
though
I
don't
understand
very
well.
Why
do
we
need
this?
This
new
command
table.
D
B
B
But
what
you
are
telling
is
that,
with
a
plan
K
world,
what
you
are
going
to
see
is
o
is
deployed
the
service
in
this
moment
in
which
host
and
in
level
supply
of
it
to
to
the
host
and
even
attributes
of
the
service
that
are
added
in
this
moment.
So
what
we
are
want,
what
we
really
want
is
just
to
know
what
is
the
calendar
state
of
one
and
run
in
service
in
our
cluster?
D
D
You
set
up
your
yellow
file,
your
specification,
yellow
file,
put
all
the
information
in
it
right,
yeah
and
then
people
have
problems
identifying
of
what
tough
ADM
would
do
when
they
apply
this
specification
and
then
they
they
anticipate
that
you
know,
m
DSS
will
be,
will
be
spawned
and
not
one
and
all
do,
but
due
to
whatever
reason
it
was
not
the
case.
Oh
I
think
it's
a
good
idea
to
give
them
the
possibility
to
have
a
command
feed
in
the
yellow
specification
and
then
return
that
the
command
will
return
you.
B
D
B
Yes,
yes,
but
in
any
case,
I
think
that
it
is
going
to
be
difficult
to
understand,
because
what
we
are
using
in
order
to
set
up
new
services,
for
example,
this
ahem
MDS,
is
an
average
common.
If
we
add
just
a
new
parameter
in
the
upright
command,
for
example,
preview
we
can
obtain
the
same
dress
with
the
same
functionality
and
I
think
that
is
not
needed
to
what
a
new
important
game
work
come
on.
Okay,
like
plan
they
do
the
set
of
commands
that
we
have
in
this
moment.
B
So
I
I
think
that
is
probably
more
easy
to
understand
that
if
we
are
using
the
up
I
command
in
order
to
do
certain
kind
of
things
and
I
want
to
know
what
is
going
to
happen.
If
in
this
moment,
I
used,
this
command
is
more
easy
to
understand
that
just
adding
a
ministry
knows
we
will
preview,
for
example,
is
more
easy
to
understand
that
to
have
to
to
use
another
completely
different
common.
In
order
to
to
see
what
is
going
to
happen
with
all
your
comment,
I
get.
D
That
right,
but
the
thing
is
that
when
you
use
plan
or
preview
or
whatever
that's
called
in
a
future,
you
you
are
not
always
interested
in
what
will
happen.
If
you
apply
a
new
set
of
specifications,
there
is
also
the
possibility
to
ask
the
cluster
what
will
happen
to
existing
specifications,
and
then
you,
then
you
would
need
to
write
things
like
self
purge
and
then
the
turbine
whatever
right,
and
then
you
have
to
do
this
preview,
but
at
that
point
you're
no
longer
applying
anything
yeah,
but
this
verb
doesn't
make
sense
anymore.
A
B
In
any
case,
let
me
insist:
okay,
the
only
thing
that
I
don't
like
is
just
a
the
nuke,
a
war
plan.
Okay,
it
seems
like
a
new
command.
Okay,
but
I
think
that
the
same
functionality
can
be
included
in
the
apply
commands
that
we
have
with
a
new
parameter.
Okay,
and
if
we
use
this
new
parameter,
for
example,
meet
review.
What
we
should
do.
B
What
we
must
do
is
to
present
the
old
information
that
we
have,
for
example,
in
the
case
of
OS
T's,
all
the
arrestees
that
were
previously
created,
okay
plus
the
new
OS
these
that
are
going
to
to
create
it
using
the
right
group
that
you
are
using
in
the
common
directory.
Even
in
the
output
we
can
especially
or
or
children,
to
outline
what
OS.
These
are
going
to
be
created.
New,
ok,
I
think,
but.
D
B
Yes,
but
but
you
understand
my
my
point
of
view,
I
think
that
is
a
good
idea
and
really
we
need
to
provide
this
information
to
that
to
the
final
user.
I
think
that
is
very
useful.
Ok,
but
I
think
that
this
is
going
to
be
very
strange
to
use
a
different
command
a
plan
common
in
order
to
see
this
information
in
instead
of
using
just
a
a
parameter
like
preview
in
the
in
the
in
the
comment
that
you
are
useful,
you
are
usually
to
use
for-
or
do
this
this
this
axiom,
although.
D
A
A
E
A
B
Yes,
I
have
quite
this
okay,
and
this
is
because,
when
I
have
seen
well
disapproved
request
from
Patrick
okay,
that
I
think
that
III
had
to
to
solve
the
problem.
Okay,
in
order
to
to
use
a
specific
persons
for
the
monitor
in
a
stack
containers.
But
what,
in
any
case,
I
think
that
what
happened?
If
you
use
the
bootstrap
command,
it
seems
that
the
vessels
that
are
going
to
be
used
are
the
the
one
that
we
have
are
coded
in
the
safe
ADM
file,
and
this
is
lattice
vessel
for
all
the
monitoring
containers.
E
I'm
sure
about
the
bootstrap
command,
but
Jared
is
this.
This
is
just
those
are
just
default:
values
and
they're.
Not
those
are
not.
The
latest
versions
of
the
software
available
I
mean
might
be
the
case
for
now,
because
we've
pinned
the
divergence
to
be
fixed
by
now,
with
the
exception
of
sarahvani,
but
we're
working
on
that
too,
so
that
the
latest
version
at
some
point
will
not
be
installed
anymore,
but
only
the
versions
we
have
tested-
and
this
is
those
are
the
versions-
are
the
conversions
of
the
containers
that
I
used
by
default.
E
B
B
Okay,
I,
think
that
this
is
an
an
arrow
and
I
think
that
what
we
really
need
is
just
what
spec
files
for
all
the
services
for
all
the
diamonds
that
we
are
using
and
to
have
the
possibility
of
the
user
to
define
in
the
aspect
file
the
different
attributes
or
properties
that
the
user
wants
in
to
be
added
in
that
service.
For
example,
ports
in,
for
example,
dashboard.
It
could
be
if
we
want
to
use
SSL
or
not
the
port
that
we
want
to
use.
B
If
we
want
to
use
any
of
that,
we
have
in
the
Buddhist
turret
command,
for
example,
to
define
the
user
that
I
want
to
use
to
define
if
I
want
to
skip
the
reference
state.
The
admin
password
this
kind
of
things
and
I
think
that
what
we
really
need
to
what
aspec
files
and
you
said-
modify,
modify
world
aspect
files
for
for
all
the
services
that
we
have.
Okay,
so
I
think
that
in
this
moment
we
need
to
change.
I.
E
They
ask
a
question,
though,
hurt,
and
they
might
have
understood
that
it's
about
not
having
those
fixed
versions
in
the
code.
Okay,
but
yes
is
it?
Is
it
about
it's
just
just
as
I
mean
as
a
clean
up
to
have
them
elsewhere,
or
is
it
to
to
enable
the
user
to
use
a
certain
configuration
file
and
apply
that
instead
of
what
we
provide,
because
I
think
that
those
versions
are
our
recommendations
and
the
users
should
mean
he
can't
change
that,
but
I
hope
in
most
cases
he
won't
and
he
won't.
A
E
A
On
the
other
hand,
if,
if
you
are
using
the
apply,
spec
command
that
Daniel
created
or
if
you
don't
disable
monitoring,
you
still
need
to
be
able
to
use
a
different
meteors
antenna,
image
or
graph
on
a
container
monitoring
container
images,
because
that's
not
really
possible
right
now,
right,
if
you,
if
you
bootstrap,
and
do
not
disable
the
deployment
of
monitoring,
then
the
user
basically
doesn't
have
a
chance
that
change
chance
to
modify
the
container
image
before
it
is
applied,
as
that
was
huge,
wouldn't
what
you
have
in
mind:
Omega,
yes,.
B
Yes,
yes,
and
a
part
that
well
we
we
should
start
to
work
in
order
to
separate
codification
from
configuration.
Ok
configurations
should
be
completely
a
part
of
the
code
and
in
different
files,
and
these
files
stood
to
be
what
general
you
said
should
be
able
to
modify
and
reduce
this.
This
configuration
file
that
is
there
a
normal
way
to
do
the
things
I
think
and
even
even
in
the
case,
that
we
know
that
there
is
only
13.
B
For
example,
persons
of
the
monetary
nested
containers
that
are
working
for
example.
It
is
possible
that
in
downstream
in
Susa,
you
decide
to
use
a
different
version,
but
in
Red
Hat,
maybe
we
can
use
another
different
lesson.
Ok,
and
this
is
possible
if
we
are
using
configuration
files.
So
it's
important
to
start
to
to
make
this
this
breed
of
configuration
and
qualification.
E
There's
a
I
think
there
are
some
I
mean
I
mean
I,
think
there
are
some
things
we
can
can
differentiate
between
the
configuration
of
the
self
class
there's
one
thing
and
how
the
user
is
capable
to
configure
what
is
being
bootstrapped
in
a
separate
in
another
configuration
file.
This
is
another
thing
because
the
user
could
could
could
very
well
say
at
the
point
where
he
is
not
yet
deployed
any
any
monitoring
that
he
wants
to
use
different
images.
E
E
The
the
fixed
versions
in
the
code
is
something
that
user
should
never
touch,
that
this
is
just
for
developers,
I
mean
yes,
of
course,
we
could.
You
have
the
versions
in
a
separate
file
or
soap,
but
still
that
would
be
something
the
user
is
not
supposed
to
touch,
because
those
are
just
the
default
we
provide
for
for
its
same
setup,
something
we
have
tested,
and
now
that
works.
A
E
Depends
on
the
test
we,
the
tests
we
currently
have
for
source
FIDM,
but
there's
a
test
that
needs
to
be
adapted
or
removed.
Yes,
we
could
basically
the
manager,
the
safe
area
manager,
module
just
always
specifies
which
image
is
to
be
used
when
deploying
for
different
components.
Yeah.
This
is
just
a
fallback
for
for
the
case,
then
the
manager
module
force
FIDM
would
not
be
used,
but
maybe
the
source
safe,
EDM
script
is
used
manually.
It
was
tested
in
an
automated
fashion,
yeah.
E
Well,
Safari
M
is
very
narrow
in
its
purpose.
If
it's
just
about
testing,
if
it
deploys
in
any
container,
but
it
does
not
test
how
those
configurations
are
deployed
and
how
those
containers
work
together,
then
it
doesn't
matter
much,
but
I
did
a
point
that
it
might
be
confusing
to
have
also
some
fixed
versions
in
there.
Yeah
I
think
it's
about
confusion.
D
B
A
B
A
The
reason
is,
for
example,
if
you
have
a
dedicated
version
of
the
manager,
then
then
we
can
put
all
configuration
values
into
the
manager
module
configuration
because
the
manager
is
invoking
Safari,
my
interview
and
if
you
try
to
have
another
set
of
configuration
values
just
for
safe
IDM,
on
the
on
the.
B
A
But
it
skips
so
simple
from
an
architectural
point
of
view
like
like,
for
example,
removing
the
affordance
sadm
really
make
sense,
but
because
then
we
don't
need
to
care
about
it
about
them.
B
A
B
A
D
D
B
B
D
B
A
A
Anyway,
let's
move
that
to
to
the
mailing
list
or
the
chat.
A
Maybe
we
can
discuss
it
with
our
Travis.
There
was
a
meeting.
There
was
a
meeting
discussion
regarding
making
making
drive
groups
work
for
work
and
Travis
idea
was
to
write
a
function
that
take
the
placement
specification
and
returns
a
Cuban
at
this
kind
of
placement
specification
using
node
affinities,
etc
and
I,
like
it
I
like
it,
and
we
need
it
anyway.
That's
what
I
said
in
the
rain.