►
From YouTube: Ceph Orchestrator Meeting 2022-02-07
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
So
there's
two
topics
in
there
and
they're
they're,
both
things
I
added
them
a
little
bit
ago
and
they're
both
upgrade
related
and
they're
from
paul
kuzner.
A
If
you
guys
know,
him
is
being
an
like
a
large
scale,
cluster
doing
some
testing
for
us
kind
of
like
the
the
posi
experiment,
but
it's
exactly,
I
think
larger
than
that,
and
one
thing
he's
trying
to
test
is
the
upgrade
procedure,
and
so
both
these
points
are
things
sort
of
related
to
that
some
decisions
we
have
to
make
maybe
optimize
the
upgrade
procedure
or
some
larger
clusters
I'll
start
playing
the
first
one.
A
So
the
osds
have
a
dependency
of
the
mod
map,
which
normally
that's
that's
good.
You
know
we
want
that
to
do
that,
but
it
causes
an
issue
during
the
upgrade
where,
after
you
upgrade
the
monitors,
all
the
osds
now
need
to
be
reconfigured,
because
the
bottom
map
changes
and
that's
if
you
have
like
a
lot
of
osds
like
in
this
case
it
was
like
3,
900
osds.
A
It
really
slows
everything
down
because
it's
just
sitting
there
re-configuring
osds
for
like
over
an
hour
and
then
that
time
it
doesn't
give
you
any
updates
on
the
upgrade
or
what's
going
on
there.
So
it's
like
a
bad
user
experience
for
that.
It
also
just
generally
slows
everything
down,
probably
more
than
it
needs
to
there's.
The
question
here
would
be
guess
what
we
want
to
do
about
it.
A
The
one
idea
I
have
was
under
there
is
that
maybe
we
could
just
push
it
off
until
the
upgrade
is
over.
I'd
have
to
look
into
it
a
bit
more.
I'm
thinking
that!
Maybe
if
we
do
that,
like
it,
wouldn't
do
anything
bad,
like
the
oc,
didn't
get
the
new
mod
knob
immediately,
we
were
able
to
just
upgrade
them
all
first,
because
they,
when
we
upgrade
them,
they
will
get
the
new
mom
up
anyway.
A
B
They
wouldn't
have
the
new
map
so
I'll
admit
to
knowing
very
little
about
this
topic.
But
what
are
the
downsides?
A
A
It
is
basically
in
between
we
put
the
monitors
and
we
upgrade
the
osd's,
which
is
just
the
crash,
upgrade,
I
think,
all
right,
and
instead,
what
we're
doing
is
we're
just
going
through
and
reconfiguring
all
of
them
immediately
just
so
that
we
can
then
later
redeploy
them
all
again
when
we
upgrade
them,
but
it
does
feel
like
it
feels
like
a
bit
of
a
time
waste-
and
I
said
it's
a
bad
user
experience,
because
the
upgrade
status
or
anything
doesn't
show
any
of
this
happening.
B
A
B
If
everything
happens
quickly,
I
think
your
intuition
is
probably
correct
concern
I
have
is
say
that
it
is
taking
a
long
time
for
some
reason
you
know
osdx
gets
upgraded
on
tuesday,
but
it
doesn't
until
wednesday
that
osdy
gets
upgraded.
B
A
Yeah,
I
thought
about
being
like
mia
or
team
asking
them.
What
danger
is
and
also
maybe
looking
at
the
way
ansible
did
their
upgrades
because
I
think
they
did
it.
They
just
upgraded
individual
roles,
one
at
the
time,
and
so
obviously,
in
that
case,
then,
if
the
monitors
change,
they
wouldn't
necessarily
have
all
the
osds
immediately
being
reconfigured
or
anything.
They
just
then
upgrade
the
osds
one
rule
at
a
time.
A
So
I
think
it
actually
would
be
sort
of
similar
to
what
they
were
doing
there,
but
I
do
want
to
check
one
yeah,
but
I
just
want
to
bring
it
up
here.
First
see
if
anybody
had
anything
just
because
it
is,
I
guess
it
changed
the
way
our
reconfiguring
system
is
going
to
work
and
bridge
gonna
work
not
a
big
deal,
but
I
think
overall
would
be
a
positive
change.
B
A
Right
in
that
case,
I
guess
we'll
just
go
forward
with
that
I'll
see
if
I
can
get
that
stuff
sort
of
working
and
the
second
topic's
also
an
upgrade
topic.
It's
related
pretty
much
the
same
thing
now
this
one's
for
more
granular
upgrades,
and
this
is
also
an
issue
for
like
larger
clusters.
A
Essentially,
if
you
have
like
somebody
who
has
a
really
huge
cluster,
they
may
not
like
the
idea
of
I'm
just
going
to
like
set
this
command
up,
and
then
it
just
runs
for
like
two
days
or
something
so
some
people
have
a
desire
to
sort
of
have
the
upgrades
be
maybe
buy,
hosts
or
buy
like
demon
type
or
something,
and
that
way
they
can
just
upgrade
a
few
of
the
demons
at
a
time
make
sure
everything's
working
okay
before
they
keep
going.
A
It
would
be
a
step
away
from
the
way
our.
Currently
we
do
our
upgrades,
because,
right
now
we
just
do
them
all
at
once
and
there's
a
bunch
of
things.
You
have
to
be
really
careful
about
doing
that.
A
A
However,
it
already
works,
which
is
like
you
just
do
the
managers
and
the
monitors
and
stuff
we
could
just
say
like
you-
can
provide
just
one
of
those
types
and
we'll
do
it
the
one
thing
we
need
to
be
careful
about
doing
something
like
that
is
we
still
have
to
enforce
the
ordering.
We
also
want
the
managers
before
the
monitors,
so
we
say,
like
you,
can
provide
the
command
saying
just
do
the
managers
just
do
the
monitors,
but
you
haven't
done
the
earlier
types.
First,
we're
going
to
probably
block
it.
A
B
Yeah
well,
it
makes
sense
too,
because
you
might
say
say
you
have
your
cluster
split
up
by
like
rack
or
something
like
just
organizationally
like
on
monday.
I'm
gonna
do
rack
a
tuesday,
I'm
gonna
do
rack
b
or
something
like
that
yeah.
The
question
I
had
when
I
read
the
pad
originally
right
before
the
meeting
I
was
curious,
is
like
say,
you're
running
the
command
today,
your
time,
you
know
your
bullet
says
something
like
you
know,
this
long
running
command
might
take
days.
B
The
funny
thing
that
popped
into
my
head
was
some
tooling,
like
I've
used
like
rh
pkg,
I've
seen
some
stuff
from
the
pulp
project.
Where
you
know,
if
your
command
line
command
is
running
and
you
know
say
your
ssh
gets
connected
or
you
control
c.
Is
there
like
a
reattach
where
you
can
actually
kind
of
reattach
to
what
like
the
server
might
be
doing?
Is
it
all
there's
most
of
the
logic
in
the
command?
B
B
Yeah,
that's
that's
one
way
I
was
thinking
more
like
you
were
just
saying
like
already
today,
the
command
sort
of
has
phases.
B
If
you
knew
like
you're
in
phase
a
you
know,
I
don't
know
if
the
logic
is
kept
inside
the
manager
itself
or
if
it's
more
in
the
command
line,
tool,
you're
running,
say
it's
in
the
server
and
the
command
line
command
was
disconnected
if
you
could
say,
reconnect
to
the
server
and
continue
polling
status
of
the
upgrade.
You'd
know:
oh
okay,
it's
in
phase
a
it's
doing
months
or
whatever.
Oh
it's
phase
b,
it's
doing,
osds,
etc,
etc.
A
B
C
A
Which
we
already
have
that's
what
I
was
wondering
here.
We
do
have
a
pause.
It's
just
that
it's
kind
of
hard
to
use
it
properly
because
you
have
to
like
go
watch
the
logs,
see
what
it's
doing
and
then
like
you'd
have
to
like
stop
it
at
the
exact
moment.
It
redeploys,
like
the
last
of
this
type
or
something.
B
Yeah
so
like
creating,
like,
I
don't
know
from
back
of
a
better
word
like
phases
for
each
upgrade
step.
You
could
say:
okay,
you
know
we're
in
phase
a
when
phase
a
is
complete.
Then
you
can
move
on
to
phase
b.
But
if
you're,
you
know
whatever
is
driving
the
process
at
the
at
the
user
level
says:
oh,
I'm
still
in
phase
a,
I
can't
push
the
system
into
phase
b.
B
Yet
again,
I'm
kind
of
speculating,
because
I
don't
know
enough
about
the
or
architecture
of
the
system,
but
I'm
doing
a
poor
job.
I
think,
but
I'm
trying
to
share
a
user
experience
from
some
other
things
that
I've
seen,
which
are
pretty
nice,
where
you
can
so
normally
get
back
in.
D
D
Like
it
makes
more
sense
to
to
give
them
more
control
on
this
space,
this
specific
phase,
because
the
most
time
consuming.
A
C
But
we
still
need
to
enforce
that
by
type
so
the
ordering
matters,
so
we
have
to
be
cognizant
of
the
migrations
that
are
occurring
in
the
manager,
so
you
have
to
do
one
complete
service
on
all
of
the
hosts
before
you
can
progress,
yeah.
A
That's
what
I
was
thinking
is:
if
we
did
do
this,
we
would
have
to
make
sure
that
all
of
the
demons
of
the
previous
types
are
upgraded
first
and
then
we
say
all
right:
it's
okay!
Do
this
so
you're
like
no
like
right
now.
The
way
that
upgrade
works
like
it
like
leaves
the
function.
It
comes
back
and
it
checks
like
the
measures
and
mods
again
and
then
it
like
eventually
gets
to
the
right
demon
type
that
it
needs
to
upgrade.
A
D
So,
like
normally
in
a
cluster,
we
normally
have
several
different
services
running,
for
example,
nfs
or
rgw,
and
then
in
our
line
we
have.
We
have
other
demons
giving
service
to
this
to
these
services
a
little
bit
redundant.
D
A
A
But
yeah,
so
it's
really
just
by
type
rather
than
the
actual
service.
Like
underlying
that
so
say
you
had
a
bunch
of
rgws.
They
were
in
different
services.
We
would
just
get
to
a
point
where,
like
our
run,
upgrade
rgw's
now
it
wouldn't
matter
which
service
they're
in
we
just
their
rgw
circuit
kind
of
get
upgraded.
We
don't.
C
A
Yeah
I
mean
it
could
be
slower,
but
I
mean
when
we're
doing
like
they
buy.
I
don't
expect
doing
it
by
host
to
ever
make
it
faster.
It's
really
like
what
like
the
aim
is.
I
think
the
aim
is
just
like
people
feel
a
bit
better
about
it.
They're
like
I,
can
just
upgrade
the
demons
on
this
host
and
like
that
gets
done,
maybe
in
like
20
minutes
rather
than
running
one
command,
that
it
sits
there
for
like
a
day.
A
So
I
don't
think
it
would
ever
speed
it
up,
even
if
we
had
it
like
somehow
perfectly
in
parallel.
So
we'd
do
like
all
the
osds
on
this
host
at
once,
or
something.
B
A
A
Yeah,
I
mean
that's
basically
the
idea
of
it.
It's
just
we
were
seeing
if
we
do
that.
Basically,
like
john,
was
saying
to
decrease
the
latency,
you
could
just
say
I
want
up
here
just
the
osu's
in
this
host
and
you
can
see
that
completes
and
you
can
just
go
into
the
next
one.
It's
a
bit
less
intimidating,
because
the
problem
is,
I
guess
what
paul
was
just
worried
about.
Is
people
are
going
to
get
a
bit
jumpy
if
you
give
them
a
huge
cluster?
A
And
then
you
report
like
nothing
really
for
a
long
time,
they
might
run
something
that
they
shouldn't
be
running
or
something,
whereas
if
you
give
them
this
command,
that's
going
to
finish
in
like
10
minutes,
like
just
upgrading,
say
like
a
bunch
of
osd's
in
one
host,
and
even
if
it
is
a
bit
slower
overall,
do
the
whole
upgrade
as
long
as
that
command
is
returning
or
finishing
fairly
quickly,
then
it
could
still
be
an
improvement
and
if
they
don't
want
to
use
that
they
want
to
just
do
it
as
fast
as
possible.
B
B
Periods
yeah,
it's
like,
oh,
our
maintenance
window
starts
at
like
8
p.m
and
then
runs
to
say
3am
and
then
you
don't
really
want
a
lot
of
churn
happening.
D
A
Yeah,
I
guess
if
you
only
were
worried
about
just
having
it
not
doing
anything
any
upgrade
while
it's
like
in
your
downtime
and
you
wanted
to
start
again
later,
you
could
do
that
with
the
pause
and
particular.
I
still
think
it
could
be
desirable
people
to
just
say
like
I
want
to
upgrade
like
this
thing
today
and
like
just
let
that
go
and
then
do
something
else
tomorrow,
rather
than
having
it
positive.
Some
random
points.
B
The
only
other
wrinkle
I
would
add
to
that
is-
and
this
is
just
partly
my
own
ignorance,
so
feel
free
to
inform
me,
like
you
know
how
many
versions
different
are
people
allowed
to
you
know
upgrade
or
how
many
different
versions
of
stuff
running
in
one
single
cluster.
Can
we
tolerate?
So
that's
something
we
will
probably
want
to
keep
in
mind,
especially
if
they're
here
we're
creating
a
wider
window.
B
So
if
we
know
that
you
know,
oh,
you
know,
16.5
and
16.6
stuff
work
perfectly
well
together
great,
but
if
we
start
to
worry
that,
oh
well,
you
know
the
upgrades
taken
so
long
that
now
16.7
is
out.
I
I
yeah,
I'm
not
I've
kind
of
lost
my
train
of
thought,
but
I
think
you
get
what
I'm
trying
to
say.
Yeah.
A
I
don't
think
that'll
be
a
problem.
I
mean
it's
going
to
be
like
if
you're
on
a
big
cluster
anyway,
it's
going
to
be
pretty
slow.
It's
going
to
be,
like
I
said,
like
a
whole
day.
Maybe
where
you're
just
have
some
of
your
osd's
are
on
the
new
version.
Some
of
them
aren't
right
and
I,
as
long
as
they're,
up
into
a
stable
tag,
which
I
hope
they
would,
if
they're
out
on
a
huge
cluster.
I
don't
there's
any
worry
of
like
the
image
changing
or
something
like
there's
no
problem
with
like.
A
Oh,
they
have
this
one
on
16.7
and
like
something
else
comes
out
that
shouldn't
affect
anything
not
as
much
about
that.
B
Yeah
I
just
I've
seen
clusters
where
people
were.
These
were
kubernetes
clusters,
though
they
were
using
like
the
latest
tag,
so
they
could
accidentally
consume
the
you
know,
versions
that
they
weren't
really
wanting
to
necessarily
opt
into.
They
were
just
kind
of
opting
into
it
by
default.
B
Eventually,
the
the
cluster
ansible
openshift
stuff
changed
that
behavior,
so
the
latest
tags
weren't
being
used,
but
there
were
people
in
the
field
that
had
them
for
a
long
time.
A
C
Well,
so
that's
exactly
why
we
convert
the
latest
tag
into
a
digest
and
then
we
enforce
that
right,
just
across
all
of
the
container
nodes
and
so
until
everybody's
consistent.
They
can't
you
know
this.
D
E
D
A
That
was
actually
one
of
the
questions
it
didn't.
We
really
talked
about
that
part
of
it,
but
that
was
actually
one
of
the
things
we
were
talking
before
about,
like
oh
by
demon
type
by
host,
whatever
one
of
the
things
paul
asked
about
was
if
we
should
do
it
by
service,
because
so
many
people
could
maybe
they
specify
their
own
services
for
like
how
they
want
to
organize
like
their
osu,
something,
maybe
they
want
to
upgrade
just
the
ones
in
that
service.
C
So
I
encountered
something
kind
of
like
this,
where
I
wanted
to
update
prometheus
just
for
a
security
fix,
but
I
didn't
want
to
upgrade
the
entire
cluster
to
do
this,
which
forced
me
to
set
a
config
key
and
then
do
a
redeploy
that
instance.
Instead,
I'm
going
to
get
around
that.
D
And
I
guess,
if
we
do
it
like
per
servers,
we
can
get
like
some
stats
at
the
beginning
of
the
impacted,
especially
number
first,
that
will
be
upgraded,
the
the
more
the
number
of
usds
the
longest
it
will
take.
So
this
way
you
can
provide
some
kind
of
feedback
to
the
user,
that
some
kind
of
driver
and
to
say,
okay,
if
you
upgrade
this
service,
so
be
aware
that
you
will
be
upgrading
this
number
of
usds.
A
And
there's
an
idea,
I
don't
think
we
have
anything
like
that.
A
dry
run
for
upgrade,
but
we're
like
this
is
how
many
demons
will
get
upgraded.
If
you
do
this
yeah.
That
would
be
something
interesting
sort
of
like
a
tangential,
maybe
useful
thing.
C
The
other
thing
to
keep
in
mind
is
we:
we
build
everything
in
the
same
container,
so
like
ganesha
ice,
because
everything's
all
the
exact
same
container
image
and
digest
so
we're
still
restricted
by
that
order,
where
the
managers
must
come
first,
he
can't
play
upgrade
ganesha
by
itself.
B
C
B
A
If,
if
we
are
going
to
do
like
this,
I
know
obviously
we're
saying
we're
definitely
going
to
for
seth
type
demons
enforce
this
ordering
it's
super
important
to
make
sure
nothing
breaks.
But
for
like
we
played
monitoring
stock,
demonstrating
a
special
case
like
if
you
say
I
want
to
upgrade
prometheus
like
I'll.
Just
do
that,
for
you
sort
of
a
side
topic
almost
not
really
super
important
in
terms
of
large-scale
upgrades,
but
yeah.
A
C
I
think
the
complexity
is
too
high
for
the
that
narrow
use
case
right
now.
Maybe
we
just
document
that
case
it
seems
like
for
this
thing
it's
mostly
useful
for
osd
types,
but
not
really
any
of
the
other
services
osds
that
are
really
the
problem.
We
just
want
to
target
a
host.
C
Yeah,
because
we
definitely
want
to
keep
the
scheduling
as
simple
as
possible
here.
D
In
a
normal
I
mean
probably
different
customers
have
different
configurations,
but
in
general,
from
your
experience,
you
managed
to
have
like
a
lot
of
osds
for
hosts,
or
you
may
have
different
configuration.
We
have
like
fewer
stays,
one
host
a
lot
of
them.
Another
host
I
mean,
does
it
make
sense
to
do
it
per
host
or
like
per
batch
or
dispatch
like
generously
or
100
or
whatever.
A
I'm
not
sure
about
just
limiting
by
number,
because
I
don't
know
like
what
the
ordering
is
going
to
be
on
that,
like,
I
don't
think
we
guarantee
anything
in
terms
of
ordering.
So
like
you're
saying
I'm
going
to
limit
just
upgrade
100
osds
we
could,
but
I'm
not
sure
it
just
seems
odd,
because
you
don't
know
which
osc's
are
going
to
get
upgraded.
You
just
say
gotta
upgrade
a
random
100
osds,
not
the
other
ones.
It
feels
a
bit
weird
to
me.
C
A
Yeah,
because
the
way
I
was
kind
of
thinking
about
this,
I
guess
remember,
we've
gotten
to
now.
Is
you
kind
of
love
all
three
of
them
almost
and
then
you
just
like
for
the?
If
you
really
want
to
do
it
granularly
you
just
do
the
first
three
types
take
the
manager
in
one
of
their
crash
by
the
type
when
you
get
to
those
ds.
Maybe
you
start
going
to
more
detail.
You're
like
I
want
to
use
one
by
host.
I
want
to
do
this
one
by
the
service
or
something
yeah
yeah.
C
Yep,
I
think
I
think,
in
the
upgrade
stuff
we
just
have
a
bunch
of
validations
to
ensure
the
migration
order.
Actually
is
saying
stuff
like
this,
but
when
we
reach
like
say
this
step
like
they
start
an
upgrade
on
osds
for
host
3
and
when
that
completes,
then
we
just
simply
pause
the
upgrade.
Let
them
resume
somehow
in
the
next
upgrade
step.
A
A
D
B
Yeah,
usually
a
lot
of
software,
you
know
downgrade,
isn't
supported
or
it's
very,
very
risky,
because
you
don't
know
what
new
metadata
say
got
written
into
your
door
or
whatever
usually
helps.
If
you're
like
a
developer,
can
do
it
because
you
know.
Oh,
I
know
that
there
no
metadata
change
has
happened
in
you
know:
release
13.4.
A
C
A
We
just
yeah
the
progress
bar
would
have
to
get
out
of
adjusting
a
bunch
yeah.
We
definitely
guess
we
could
clear
it
when
we
get
to
the
point
where
we
like
did
what
they
wanted
to
do
like
they
want
to
just
do
like
their
monitors.
We
clear
it
after
they're
done.
A
The
bar
will
look
weird,
though,
because,
like
we
still
we'd
have
to
format
it
to
say,
like.
Oh
we're
only
going
to
upgrade
this
many
demons,
but
we
could
definitely
work
around
all
that
stuff.
I
think
an
upgrade
status
wouldn't
be
too
bad.
If
we
like
know
exactly
what's
going
to
get
upgraded.
B
Right,
that's
what
I
was
trying
to
imply
with
that
ux
talk
at
the
earlier
on
was
like.
What
do
you
do?
You
know?
What's
the
workflow
look
like?
Can
you
just
no
okay,
there's
a
status
command
great,
we
run
it
and
it
gives
you
some
sort
of
status
report
about
the
overall
upgrade,
but
if
you're
only
asked
for
a
partial,
you
know
what
does
that
look
like?
Does
it
even
make
sense
to
have
a
progress
bar
or
should
you
have?
You
know
just
bullet
points?
You
know
I've
done.
A
A
It'll
tell
you
how
many
of
the
total
number
of
set
demons
have
been
upgraded
and
if
there's
like
a
status
there
like
it
gives
like
a
generic
message
field
that,
like
usually
it'll,
say
like
oh
we're,
pulling
this
image
on
this
host
right
now
or
we're
currently
upgrading
like
this
type
of
demon
or
something.
A
So
if
we
do
do
this,
we're
going
we'd
have
to
adjust
that
to
probably
like
safely
the
number
of
demons
that
says,
gonna
upgrade
like
change
the
that
number
to
say
we're
only
gonna
upgrade
like
this,
many
of
them
over
many
of
this
type
or
just
be
a
bit
more
specific
there.
There
have
to
be
some
some
changes
to
the
upgrade
status,
and
I
guess
the
progress
bar
is
always
one
of
the
parts
where
it's
smaller.
A
A
All
right,
one
thing:
I
guess
I
don't
know
if
he
analyzes
this
go
back
to
it.
So
if
we
do
get
reached
this
point
where
we
finish
what
they
told
us
to
do
like
say
they
just
said
they
already
the
managers.
These
want.
The
monitors
done,
there's
like
five
of
them
and
we
do
all
five
of
them.
A
Do
we
just
pause
everything
or
do
we
fully
say
we're
gonna
stop
the
upgrade
and
you
have
to
start
a
new
one.
Basically
to
I
feel,
like
the
upgrade
start
command
is
where
we're
going
to
add
these
arguments
in,
to
like,
say
like
specify
the
demon
type
or
the
host
or
something
I
don't
know.
If
it's
better
just
to
stop
the
upgrade
or
if
we
should
pause
it
leave
it
there,
just
let
them!
A
I
don't
know
what
a
resume
would
mean.
That's
the
one
that
would
be
worried
about
is.
If
we
just
did
the
monitors,
we
had
to
then
add
to
resume
basically
say
like
what
demon
types
I
want
to
do
now
or
something
I
feel
like
it
might
be
better
to
keep
it
all
and
start
and
then
just
stop
the
upgrades
when
we
reach
whatever
it
is.
They
told
us.
C
D
Do
we
have
any
mechanism
right
now?
Like
imagine,
I
have
cluster
accidentally.
I
I
powered
up
a
note
which
has
like
old
version
of
code
of
images
in
it.
So
how
would
it
detect
this
case
and
do
we
upgrade
the
images
automatically
in
this
case
or
not.
A
Right
now
you
get
at
the
end
of
failing
when
we
get
you
get
hit
offline
host.
That
is
a
good
question
as
well.
I
think
it's
actually
a
totally
different
topic
than
what
we're
on
it's
just
what
we
should
do,
how
we
should
handle
offline
hosts
during
upgrades,
we
block
the
whole
upgrade
and
say
you
have
to
have
all
the
hosts
online,
because
it's
sort
of
dangerous,
then
again
one
could
go
offline
in
the
middle
of
the
upgrade.
A
I
think
right
now,
if
you
were
to
say,
upgrade
the
other
host
and
then
you
added
add
this
quest
post
back
to
the
cluster.
If
the
query
was
still
going
on,
it
would
just
start
upgrading
the
demons
on
that
host
if
their,
if
upgrades
already
over-
and
they
won't
do
anything-
you
have
to
run
the
upgrade
again
to
tell
it
to
go
upgrade
that.
A
A
Yeah,
I
guess
we
should
probably
that
as
a
health
warning,
there's
not
an
upgrade
in
progress,
and
we
have
that
for
deaf
demons
of
different
types,
which
probably
should
raise
a
health
ring
yeah.
I
don't
think
we
check
that
explicitly
right
now.
I
probably
should.
D
A
Stop
the
upgrade,
so
I
guess
sort
of
finalize
here
he
said
we're
good
with
doing
it
by
the
demon
type,
the
host
the
service
type.
You
probably
want
all
three
for
making
it
easier
for
osd
service,
get
exactly
what
you
want.
A
Whenever
we
hit
that
point,
we
just
stop
the
upgrade
and
we'll
let
them
start
it
again
with
new
arguments,
whatever
they
want
up
right
now
and
we
have
to
make
sure
we
strictly
enforce
the
ordering
so
that
there's
always
manager
mon
whatever
the
migration
order
as
mike,
I
think,
posted
and.
A
Oh
yeah,
and
we
want
to
make
some,
maybe
a
dry
run
command
or
something
for
a
bit
more
transparency.
So
you
know
exactly
what
an
upgrade
is
going
to
do
so,
as
you
do
stuff
or
upgrade
osd
with
a
certain
service
type,
then
you
do
a
dry
run.
We'll
say
like
these:
are
the
demons
in
that
service
that
are
not
on
the
right
version?
This
is.
A
All
right
does
that
sound
good
to
everyone,
or
is
there
still
something
I'm
missing
discuss.
C
About
that,
out
of
curiosity,
how
does
rook
handle
this
type
of
scenario?
Is
there
any
insight
you
can
give
us
at
that
point.
A
I
don't
really
remember
how
rook
does
their
upgrading
honestly
there's
been
a
whole
thing
about
like
work
with
manager,
rook
and
stuff,
so
I
don't
even
think
if
there
is
an
upgrade
thing
in
manager,
rook
they're,
probably
using
it
right
now.
A
I
don't
know
I'd
have
to
ask
travis,
I
guess
they're
doing
there.
Actually
lane
is
in
here,
yes,
yeah
rook's
upgrades
are
handled
pretty
much
on
the
the
daemon
level
with
the
osd's
we
do
check
the
like.
We
get
the
like
batch
of
osds
that
we
can
update
in
parallel.
A
But
that's
that's
kind
of
the
only
real,
crazy
thing
we
do,
otherwise
we
yeah.
We
know
that
we
need
to
upgrade
if
we
see
that,
like
there's
like
a
cluster
versions
command
that
we
issue
that
gives
us
like
json
output
of
like
what
versions
of
what
demons
are
running
in
the
cluster
and
if
those
are
not
all
running
the
same
imported
version
that
we
have
great
to
do
it's
how
we
detect
that
we
need
to
upgrade
all
right
and
what
what's
kind
of
like
the
actual
user
interface
of
doing
that.
A
Do
you
just
tell
it
like?
I
want
to
do
an
upgrade
now
and
it
just
goes
and
figures
everything
out.
Yeah
I
mean
effectively.
It's
just
update
the
the
ceph
image
in
the
the
kubernetes
manifest
for
the
subcluster,
and
it
just
goes
and
does
okay,
that's
almost
kind
of
similar
to
what
we
have
right
now
for
our
set
podium
upgrade
where
we're
just
using
the
specify
an
image.
We
want
to
be
the
new
image
and
then
it
just
goes
and
does
everything.
A
A
Okay,
explain:
is
there
anything
else,
okay
points,
I
think
we're
missing
here.