►
From YouTube: Ceph Orchestrator Meeting 2021-03-16
Description
B
A
So
so
we
have
users
out
there
with
with
at
least
thousand
euro
osds.
B
Nice,
okay,
that's
great,
but
in
any
case
the
I
think,
but
I
think
the
main
thing
I
said
was
that
the
next
step
is
to
get
the
exporter
thing.
Working
yeah.
B
A
Yeah,
okay,.
A
So
I
have
at
least
three
people
that
are
that
contacted
me
by
by
email
and
when
I
look
into
low-hanging
fruit
issues,
beginner
tasks
and
yeah.
Let's
see
how
it
goes.
D
D
Yeah,
please
check
check
your
linkedin
as
well,
because
I
receive
a
couple
of
this
so
candidates
through
linkedin,
so.
A
Okay,
yeah
the
next
backpack
per
request.
B
Yeah
I
it
was
like
a
horrible
experience,
because
I
didn't,
I
didn't,
have
the
the
the
scripts
that
you
normally
use
to
identify
what
backboards,
and
so
I
did
it
like
one
and
a
half
times
and
then
ended
up
restarting
from
scratch
and
like
walking
sequentially
through
get
k
stuff,
but
I
eventually
found
it
and
then
this
morning
realized
that
there
was
a
bunch
of
typing
stuff
that
was
in
a
different,
unrelated
stuff,
adm,
and
so
I
ended
up
backboarding
a
bunch
of
like
prometheus
and
some
stuff
from
kifu,
and
I
cherry-picked
basically
just
enough
to
make
the
test
pass
and
didn't
really
try
to
capture
the
full
pull
request
of
the
stuff
that
keepy
was
doing,
which
was
adding
type
annotations
to
like
every
other
module.
B
Yes,
I
think
that's!
Okay,
but
anyway
the
talks
test
passed
now
and
I'm
running
it
through
the
qa
suite
right
now.
So
we'll
see
what
happens.
A
Okay,
yeah,
then,
let's,
let's
continue
using
the
the
script.
To
put
those,
I
didn't
know
where
it
was.
B
A
E
E
Well,
that
is
sure
that
you
are
not
to
to
leave
any
pull
request
behind,
because
it
is
very
difficult
to
to
know
that.
So
maybe
I
I
I
think
that
we
need
to
to
to
think
a
little
bit
about
that.
Okay,
in
order
to
just
to,
for
example,
to
prepare
or
to
to
have
a
a
reference
to
the
last
pull
request
that
we
have
were
packported,
okay
and
started
with
that.
E
Use
the
script
okay
and
and
tried
not
to
lose
any
any
animal
requests,
but
in
any
case,
is,
is
incredible.
B
What
I
ended
up
doing
is
just
diffing
that
part
of
the
tree
against
master
and
so
at
the
end
of
the
whole
thing
they
match,
except
for
like
one
line,
which
is
don't
remember
why
I
didn't
chase
that
one
down
it
was
whatever
it
didn't
seem
important.
There's
basically
like
one
line
difference
right
now,.
B
Okay,
anyway,
okay.
A
A
B
We're
good
to
go,
let's
see
the
other
one
was
okay.
So
on
the
lab
cluster,
I
actually
saw
something
similar
on
on
mine
when
I
was
upgrading.
There
are
all
these
old
monitoring
containers
that
don't
have
the
podman
command
to
remove
the
container
before
they
start.
D
B
System,
cuddle
restart
rows
errors,
and
so
it
was
doing
that
in
the
midst
of
the
upgrade
doing
the
redeploy
manually
fixed
it.
But
I
think
we
should
make
it
so
that
upgrade
can
try
to
detect
that
situation.
Maybe
and
do
a
redeploy
before.
A
B
B
C
Yeah
well,
this
was
mostly
for
I
guess
at
the
end
of
the
upgrade,
if
unit
iron
needed
to
be
upgraded,
but
it
wasn't
because
that
demon
wasn't
redeployed
during
upgrade.
I
don't
know
if
it
does
anything
for
things
in
the
middle
of
the
upgrade.
D
A
At
least
those
daemon
types,
but
I
think
it's
super
trivial
to
extend
your
code
to
also
redeploy
the
monitoring
parts,
because
it's
a
very
same
mechanism.
If
it's
not
if
it
wasn't
deployed
with
the
current
container
image,
then
just
re-deploy
it
again.
B
Yeah,
I
don't
know
if
it's
I
don't.
I
didn't
look
at
your
pull
request
closely
yet,
but
I
wonder
if
you
can
do
it
as
it
walks
through
all
the
demon
types
so
that
you
know
the
first
phase,
it
does
the
managers,
if
it's
done
with
the
managers,
they're
all
running
the
right
versions,
but
they're
deployed
with
previous
versions
like
do
the
redeploy
then
so
it
sort
of
does
top
down
instead
of
waiting
until
the
very
end
of
the
whole
cluster
being
upgraded
and
then
redeploying
much
of
managers.
C
B
Yeah,
maybe
well
I
I
don't
yeah
I
mean
that
part
yeah.
I
don't
feel
strongly
about
that,
although
it
seems
like
it
would
be
easier
to
just
do
it's.
C
B
List
yeah
reconfig.
B
A
A
And
then
next
thing
would
be
to
extend
your
pull
request
to
also
upgrade
the
monitoring
stack.
B
C
B
B
Yeah
I
just
started
seeing
these
errors.
I
think
it
was
yesterday.
It
was
the
first
time
I
saw
it,
but
it's
when
I
run
the
stuff
adm
suite.
It
seems
to
be
just
the
smoke
rollers
ones,
and
I
think
the
difference
is
that
those
ones
are
deploying
the
monitoring
stack.
B
But
there's
just
like
a
wall
of
like
hundreds
and
hundreds
of
sd
linux,
denials
which
is
at
first,
I
was
like,
oh
maybe
it's
just
that
we
haven't
been.
B
Maybe
it's
just
that
we
haven't
been
running
the
the
monitoring
stuff
in
pathology,
but
that's
actually,
we
have
first,
but
also
mixed
in
with
these
monitoring.
Ones
are
also
theft,
demons
also
getting
denials.
A
Interesting
smoke
rollers
was
pretty
stable
for
me
last
month.
B
Yeah
and
all
it
does
is
just
deploy
stuff,
and
then
I
guess
the
only
the
other
thing
I
noticed
is
that
those
runs
are
pretty
long
like
the
a
lot
of
these.
Other
tests
are
like
20-minute
30-minute
tests
and
smoke.
Rollers
is
like
an
hour
and
a
half
20
minutes,
but
maybe
these
just
don't
happen
until
you've
been
running
for
a
while.
B
B
B
A
B
The
rjw
ports
pull
request.
I
ran
through
qa
again
last
night
and
it
passed
again
except
for
these
sd
linux
errors,
which
I'm
guessing
aren't
related,
but
I'll
confirm
that
today,
so
I
think
it
just
needs.
The
final
review
make
sure
the
first
half
of
these,
the
first
set
of
patches
that
had
all
the
scheduling
stuff.
I
did
merge
because
that
was
approved
earlier,
but
this
that's
the
the
ports
tracking,
so
it
needs
to
it
needs
to
go
in
next.
B
It
does
have
limitations
right.
It
doesn't
like
to
or
doesn't
detect
port
conflicts
across
different
services
or
anything
like
that-
and
it
does
have
this
issue
where,
if
you
try
to
change
the
ports,
it
doesn't
the
the
way
that
the
the
scheduling
stuff
works
it.
B
B
Oh-
and
it
includes
that
ssl
thing
that
I
mentioned
the
other
day
anyway,
yep
and
then
the
the
second
one
is
the
adding
the
subnet
part
and
that
one
does
need
work,
but
I
could
use
some
guidance
on
what
to
do
there.
So
I
added
the
networks
as
a
property
of
the
rgw
spec,
because
that's
the
only
thing
that
needs
it
at
the
moment,
but
you
mentioned
that.
Maybe
you
should
just
go
on
service
spec,
but
once
I
started
thinking
about
it,
I
was
wondering
if
we
should.
B
Actually,
we
should
put
it
on
placement.
Spec.
B
Along
with
even
ports,
possibly
because
it's
like
I
don't
know-
I
mean
it's,
it
almost
feels
like
this
is
a
general
concept
and
that
this
whole
allocating
eyepiece
and
ports
for
services
is
something
that
is
like
more
like
placement
than
a
property
of
the
service,
and
it
like
moves
us
closer
to
host
placement
spec,
which
has
that
weird
thing
for
the
monitor
ip,
which
is
not
quite
the
same
thing,
but
it's
very
similar.
B
I
think
it's
sort
of
the
intersection
of
the
two
right:
it's
where
you
want
the
services
to
run
right,
like
in
the
in
the
open
stack
case.
You
want
the
services
to
be
bound
to
a
certain
network,
which
is
a
host
property,
like
whatever
expects
to
be
uncertain
like
in
that.
If
you
think
about
what
how
these
systems
are
like
deployed,
you
would
have,
you
might
have
a
whole
step
cluster,
and
then
you
have
a
set
of
nodes
that
are
attached
to
a
different
physical
network.
B
That's
like
the
outside
world
and
they're,
actually
literally
gateways,
and
so
it's
almost
like
a
constraint
placement
constraint
like
one
way
you
could
do
that.
The
way
you
do
that
today
is
you
would
label
those
specific
nodes
with
a
host
label,
and
so
you
would
map
the
services
onto
there,
but
you
could
imagine
you
would
also
just
say
like
they
should
be
serving
on
subnet,
whatever
that
public
network
is
and
then
we
would
just
sort
of
implicitly
identify
those
as
the
only
hosts
that
have
access
to
that
subnet.
A
B
B
C
B
E
E
Okay,
so
I
for
me
my
view
is
a
a
service
attribute,
so
putting
that
in
the
placement.
I
think
that
they
say
is
the
right
place
to
go
to
the
host
placement.
I
think
that
this
is
to
to
try
to
to
give
the
possibility
to
to
place
different
diamonds
in
different
halls
with
different
networks,
and
it
has
not
not
too
much
sense
for
me.
So
I
think
that
the
placement
spec
is
there
is
the
right
placement.
A
E
E
The
subnet-
I
am
referring
to
the
subnet
okay
to
to
put
an
attribute
into
the
placement
about
the
the
subnet.
Okay,
a
part
of
the
host
or
a
part
of
the
labels,
is
another
attribute
of
the
placement,
and
this
means
that
all
the
the
diamonds
that
are
going
to
be
deployed
with
that
placement
must
use
the
same
subnet.
B
Because
in
for
a
spine
leaf,
I
think
they're
calling
it
whatever.
Then
they
have
basically
a
they
have
a
ip
subnet
per
rack,
but
a
particular.
B
Of
hosts
is
spanning
multiple
racks,
so
for
this
for
a
logical
service,
that's
like
replicating
and
distributed
across
racks,
there's
actually
a
list
of
subnets
that
are
of
that
of
the
correct
type
that
they
need
to
and
you
need
to
choose
whichever
an
ip
and
whichever
one
is
appropriate
on
whichever
host
is
in
the
right
rack.
So
if
it's
in
whatever.
B
It's
in
yeah,
I
think
the
I
think.
Maybe
the
distinction,
though,
is
that
the
networks
is
a
is
a
it's
a
filter,
and
that
is
limiting
the
number
of
posts
that
we
can
consider.
But
it's
not
actually
telling
us
where
to
place.
The
daemon
right,
like
just
specifying
networks,
is
not
sufficient.
Like
you
still
need
of
all
the
existing
fields,
you
need,
you
still
need
some
of
those
or
whatever,
whatever
the
rules
are
like
either
count
or
count
by
host
plus
a
label
or
whatever,
like
you
still
need
all
that.
B
D
E
B
A
But
we
should
still
put
it
on
the
placement
if
we
want
a
filter
like
if,
if
you
wanna
have
something
like
count,
eight
and
only
network,
like
five
count,
eight
and
network
yeah,
do
we
wanna
place.
A
B
A
A
B
B
A
On
the
other
hand,
we
are
still
already
have
some
filter
properties
on
our
side
of
the
placement
spec
we
are.
We
are
filtering
the
mind
networks
that
are
not
part
of
the
placement
spec
for
the
monitors.
Right
now
for
h,
a
r
t
w
we
are
filtering
for
a
kernel
property
and
only
deploy
host,
that
method,
kernel,
property.
B
B
Note
yet
I
guess
I
guess,
for
the
monitor
network
you
do
like
you,
can
imagine
this
network's
mapping
to
whatever
the
mon
public
network.
B
A
B
Okay,
I
think
that's
it.
I'm
really
hoping
this
back
port
batch
is
gonna
pass.
Looking.
Okay,
so
far,.
B
Past
three
passes
and
one
failure
on
that
stupid
cubic
oddman
error
whatever
so
far
so
good,
because
then,
if,
if
I
guess,
if
we
can
prioritize
getting
that
that
backport
thing
reviewed,
I
can
merge
it
and
then
I
can
deploy
it
on
the
lab
cluster
and
if
that
goes
well
today,
then
we
can
release
the
do
the
release
candidate
for
pacific
tomorrow.
B
That's,
like
my
that's
the
the
goal,
because
we
really
want
to
get
this.
We
want
to
have
the
final
pacific
release
in
about
a
week
and
a
half
two
weeks,
so
we
got
to
get
this
if
this
works
also,
I
can
run
the
the
upgrade
tests
upgrading
to
pacific
and
make
sure
all
those
test
suites
are
in
good
shape.
A
I
was
working
on
the
we
are
having
a
health
warning
in
the
ffs
mirror
test.
C
A
B
Yeah
here
it
is
run.
That
was
the
one
that
included
the
the
fixes
I
merged
yesterday
or
all
this.
B
The
like
re,
rejigger
change
whatever
or
is
updating
the
caps
and
it
included
the
rgw
thing.
B
A
Regarding
the
dashboard
test
period,
my
idea
was
to
just
put
it
into
the
dashboard
suite
because
it
in
in
the
past
it
was
more
like
dashboard,
related
issues
and
that's
caused
by
self-adm.
I
thought
that
happened.
Didn't
it
or
did
we
just
there?
There
was
an
open
pull
request,
but
it
was
never
not
nothing
too
much.
B
D
Yeah,
I
remember
that
one,
but
I'm
not
sure
if
it
was
merged
yeah.
This
is
right.
It
says
renaming
the
moving
the.
B
D
That
specific
one,
okay,
let
me
check
the
url.
A
Maybe
a
back
end
only
test
having
some
kind
of
cluster
deployed
by
sfdm
and
then
run
one
of
those
dashboard
passing
test.
D
Yeah,
I'm
checking
the
link
you
share.
So
it's
where
I
don't
see:
okay,
yeah,
the
second
one.
That's
a
configure.
D
B
B
Are
there
so
beyond
this
rgw
ports
and
networks?
Subnets
thing:
are
there
any
other
blocking
things
that
we
need
to
fix
for
pacific.
B
A
We
we
have
to
to
continue
investigating
that
failure.
Example,
one
another
directory
thing,
yeah
and
all
the
variants
yeah.
A
A
A
Might
be
related
to
specifying
desktops
in
it.
A
B
B
B
B
Okay,
so
the
the
thing
that
I
was
noticing
is
that
when
especially
with
services
like
the
rgw
service,
we're
setting
config
options
for
services
that
we
and
individual
demons
that
we
deploy.
B
B
B
That's
in
the
database,
and
so
if
we
can
link
it
back
to
the
the
service
spec
or
whatever
it
is,
whether
it's
I
don't
know
if
it's
going
to
be
the
service
name
or
the
demon
name
or
something
we
can
link
it
back
back
to
stuff
8am
so
that
it
knows
that
it
previously
said
it
and
is
allowed
to
clean
it
up.
A
So
we
are
already
cleaning
up
mds,
underscore
joint
underscore
fs.
A
B
D
B
D
A
A
A
A
B
B
I
think
that
that
solves
the
removal
case,
but
it
doesn't
solve
the
case
where
first
you
apply
one
that
has
bass
equals
whatever
and
then
a
day
later,
you
reapply
one
that
just
has
food
bar.
A
That's
a
general
problem
we
have
if
you
are
removing
removing
options
from
a
server
specification.
We
are
not
properly
creating
a
diff
between
those
compared
to
rook
rook.
Does
it
right
if
you're,
if
you're
reapplying
a
a
cr,
a
cube
and
a
cr,
then
a
kubernetes
will
create
a
diff
between
the
old
version
and
the
new
version.
A
B
Right,
but
we
we
are
still
storing
the
new
desired
state
and
like
trying
to
achieve
that
desired
state.
So
I
think
for
most
options.
It
doesn't
matter
like
if
you
change
the
placement
and
drop
a
property,
we'll
just
store
it
without
that
and
we'll
recalculate
our
scheduling,
based
on
that
and
it'll
end
up
with
a
different
like
we'll
still
converge.
B
C
A
And
pretty
old
pro
request
by
matt
we're
here,
where
he's
storing
all
the
ice
calzing,
I
see
yeah
things
into
the
config
database
into
the
config
key
database
and
those
are
no
not
getting
cleaned
up
if
we
are
just
dropping
a
property
from
that
yeah.
B
I
agree,
but
they
I
mean,
are
they?
Are
they
prefixed
by
the.
B
B
Yeah,
the
config
ones
are
a
little
bit
different
because
they
are
arbitrary,
config
options
that
could
be
well
no
they're
scoped
to
the
service.
I
guess
actually
so
so
we
could
do
that.
But
then
the
thing
is
that
if
I
don't
think
we
should
have
the
the
def
adm
like
look
at
all
config
options
that
are
scoped
to
the
service
and
delete
any
that
it
isn't
responsible
for
setting,
because
that
prevents
the
user
from
going
and
setting
other
options
themselves.
B
A
A
We
we
get
the
div
the
specs
and
see
if
options
got
removed,
that's
still
possible,
even
without
touching
the
conflict
database.
E
One
thing
what
I
would
do
to
store,
but
if
we
have
a
set
of
settings
that
we
are
going
to
change,
the
first
thing
to
do
is
to
get
these
settings.
What
are
the
current
settings
in
this
moment
and
store
that
in
the
service
and
after
that,
what
we
can
apply
the
the
config
options
from
the
spec
file,
and
if
we
delete
this
service,
then
the
thing
to
do
probably
is
just
to
restore
the
previous
values.
B
A
B
I
wish
I
had
another
octopus
cluster.
That
was
an
actual
cluster
that
I
could
upgrade.
Oh
my.
My
local
cluster
is
fully
upgraded.
Now,
like
I
fix
enough
bugs
that
it
completed
the
lab
cluster
still
just
started
so
once
this
big
backport
pull
request
merges,
then
I
can
rerun
the
upgrade
there
just
make
sure
everything
works
properly,
but
I
I
don't
have
enough
optical
cluster.
A
And
that's
up
I'm
going
to
turn
written
on
april.