►
From YouTube: Ceph Orchestrator 2023-02-28
Description
Join us weekly for the Ceph Orchestrator meeting: https://ceph.io/en/community/meetups
Ceph website: https://ceph.io
Ceph blog: https://ceph.io/en/news/blog/
Contribute to Ceph: https://ceph.io/en/developers/contrib...
What is Ceph: https://ceph.io/en/discover/
B
A
I
know
this
first
one
was
your
thing
John.
Do
you
want
to
intro
this
yeah
sure.
C
So
I
have
been
kind
of
trying
to
chip
away
at
the
backlog
of
unit
tests
for
the
various
functions
side
of
Seth
Adam
and
as
I've
kind
of
gone
along
I've
been
avoiding
certain
functions,
especially
the
command
functions,
because
it's
a
lot
of
mocking
now
I'm
not
going
to
suggest
that
we
avoid
all
of
them
but
I'm
starting
to
wonder
if
there
is
a
lot
of
value
in
getting
coverage
unit
test
coverage
for
those
when
we
have
integration,
test
coverage
with
toothology
and
it's
all
big
exercise
in
writing.
C
A
lot
of
mocks
so
I
think
it's
a
lot
of
value
to
try
to
cover
some
of
the
simpler
lower
level
functions
with
unit
tests,
but
these
higher
level
ones
the
command
functions.
I'm,
not
as
convinced
now
as
when
we
made
the
list
that
there's
a
lot
of
value
in
doing
those.
So
looking
for
feedback,
I.
C
We
take
them
off
the
list,
but
I'm
I'm,
suggesting
that
if
you
look
at
it
and
say
this
is
not
worth
covering,
maybe
just
put
a
comment
saying
you
know
not
going
to
cover
and
then
in
the
code
doing
a
pragma
no
cover
for
now,
because
we
can
always
remove
the
no
cover
in
the
code
later
that
way,
when
we
run
the
coverage
report
after
running
the
tests,
we
know
what
we've
not
got
to
versus
what
we
explicitly
decided
not
to
do
for
now.
A
Yeah
I'd
have
to
go
through
some
of
these
like
I
know.
Some
of
these
are
like
super
short,
just
call
one
other
function
anyway,
right.
C
C
Also
yeah
I
think
when
we
spoke
yesterday,
I
said
something
like
if
the
function
is
like
twiddling
repo
files,
that
might
be
one
we
can
cover,
because
all
it's
doing
is
like
writing
files
to
a
directory,
but
some
of
these
other
ones
that
are
just
like
I'm
going
to
call
800
container
commands
it's.
It
just
becomes
an
exercise
in
mocking
everything
and
what
does
that
prove.
B
C
A
All
right,
yeah,
that
makes
sense
to
me
I
mean
we
can
Mark
some
of
them
like
that,
as
we
go
through
them
say
like
I.
Don't
think
this
is
like
one
we
should
do
and
I
guess.
A
We
should
try
to
see
when
we
do
that,
if
there
is
integration
tests
for
them
or
that
involve
them
in
some
way,
just
to
make
sure
they're
still
tested
like
say,
like
I
can
bring
up
this
LS1,
because
I
have
to
know
that
one
like
that
one,
because
we
use
the
ls
commands
to
get
the
demons
on
the
host
like
at
all
times
like
that
one's
constantly
being
used
like
you
can
be
pretty
confident
that
one
generally
works,
maybe
there's
a
specific
case
that
I
could
be
broken,
but
generally
it
should
work,
whereas
some
of
these
other
ones
I,
don't
know
who
we
use
as
much
so
we
might
have
to
maybe
introduce
integration
tests
later.
A
If
okay
good
point
do
that
at
least
yeah
I
think
at
least
because
this
documents
really
just
for
checking
the
unit
tests.
That's
that's
the
point
of
it.
So
I
think
we
should
still
this
Market,
as
you
said,
so
we're
not
gonna
write
unit
tests
for
this
one.
A
Let
me
go
through
later
and
check
for
the
integration
test,
but
as
far
as
the
process
of
getting
the
unit
tests
done
before
we
pick
up
this
file.
Okay,
we
can
just
say
we're
not
gonna.
Do
it.
B
A
I'm
fine
with
that
I
think
it's
just
about
a
matter
of
going
through
each
one,
obviously
offline,
not
here
yeah.
Oh.
C
Yeah
and
the
other
thing
is,
there's
definitely
stuff
in
this
list.
That's
not
sorry,
there's
definitely
things
in
the
file
that
are
not
in
this
list.
I
was
just
working
on
call
and
call
is
not
in
this
list,
for
whatever
reason
so
I
I
should
add
it
to
the
end
of
the
list,
but
yeah
yeah,
if
you're,
just
looking
at
it
and
go
oh
I,
want
to
cut
I,
want
to
write
some
coverage
from
XYZ
and
it's
not
in
the
list.
B
C
Yeah
I,
don't
worry,
I,
don't
think
check
units
for,
for
instance,
I,
didn't
put
a
PR
number
and
I
didn't
I,
got
lazy
and
didn't
finish
remarking
on
that
yeah.
A
A
All
right,
that'll
make
sense,
I
think
everything
you
said
back
here,
yeah
all
that.
C
B
C
A
Was
an
easy
one:
yeah
I
mean
I,
don't
think.
There's
gonna
be
a
lot
of
pushback
on
I
mean
not
the
unit
tests
or
tests
or
for
functions
where
it's
not
useful
through
unit
tests.
C
Go
back
like
I
said:
if
you,
if
you
look
at
it
and
go
oh,
this
is
not
bad.
It's
not
it's,
not
a
low
value.
You
know
not
just
mocking
exercise.
C
A
Unfortunately,
there's
a
lot
of
that,
because
this
tool
is
meant
for
interacting
with
the
host
system
and
stuff,
but
yeah
yeah.
We
keep
finding
a
handful
of
things
that
are
good
to
test
that
we'll
we'll
eventually
get
to
the
end
of
this.
A
We
can
go
back
at
the
end
and
see
like
all
right
things.
We
skipped
maybe
revisit
them
just
to
make
sure
once
over
that.
A
C
A
All
right,
yeah
I,
don't
think
there's
gonna
be
any
pushback
on
that
I
think
we're
all
gonna
sort
of
agree.
You
know
we
can
we
definitely
Mark
things
as
being
skippable
if
Steve's,
probably
making
a
few
too
many
calls
to
things
via
them
up.
C
B
D
I
think
as
we
do,
that
we
had
to
like
maybe
go
through
and
check
off
like
where
the
functional
tests
or
where
the
integration
tests
exists
like
is
it
in
the
run
unit
yeah
somewhere
else,
because
some
of
these
like
revoke
SSH
key
I'm,
not
sure
where
we
have
coverage
or
things
like
that
good
point,
we
probably
had
to
confirm
that
that's
explicitly
tested
somewhere
the
output,
that's
expected
by
the
manager,
the
same.
C
So
the
coverage
report
that's
generated
by
the
unit
tests
is
just
generated
by
unit
tests.
So
you
don't
you
if
you
really
really
want
to
like
we
could
mess
around
with
the
whole
infrastructure
and
you
can.
You
can
get
a
regular
Python
program
to
do
to
generate
coverage,
but
it's
a
big
pain.
In
my
opinion,
it
might
be
an
investment
for
the
future,
but
it's
not
a
small
task.
In
my
opinion,
okay.
A
C
You
basically
would
have
to
in
basically
enable
like
the
the
cephanium
that
gets
run
off
in
the
toothology
nodes
to
generate
coverage
in
like
a
directory
somewhere
and
then
run
a
coverage
report
on
that
afterward
and,
like
I,
said
it's
doable,
you
can
like
pie
test
is
invoking
the
coverage
module,
but
the
coverage
module
can
be
used
on
its
own.
It's
just
it's
an
infrastructure
job,
okay,.
A
And
maybe
in
the
future,
once
we
haven't,
if
you
have
like
a
lot
of
stuff
done,
and
maybe
we
can
go,
look
at
that
I
think
we
still
have
probably
like
a
bunch
of
things
that
we
know
need
to
be
tested
and
aren't
tested
at
all
and
they
don't
even
have
any
coverage
all
right.
Unless
you
have
more
stuff
we're
closer
to
the
end,
we
can
revisit
that
and
see
if
we
can
figure
out
where
some
of
these
things
are
covered.
C
C
A
B
A
We
at
least
know
that
the
ones
that
are
on
this
list
that
getting
marked
assessed
as
we
know
where
they
came
from
and
stuff,
so
there's
an
explicit
test
for
them.
C
D
B
B
All
right:
do
you
want
to
go
into
the
call
function,
stuff.
C
Yeah
I'll
try
to
be
a
little
faster
with
this,
because
it's
it's
more
like
we
we've
got
two
sets
of
patches.
They
both
build
on
top
of
a
existing
PR
that
I
have
where
I
wrote,
tests
for
the
call
function.
While
I
was
writing
test
coverage
for
the
call
function.
I
noticed
that
the
timeout
parameter
just
doesn't
work.
C
You
can
tell
it
to
time
out
after
five
seconds,
and
the
thing
will
just
sit
there
happily
for
60
seconds,
waiting
for
the
process
to
exit,
took
a
detour
into
learning
a
little
bit
more
about
async
IO,
because
I
really
never
used
it
in
Anger
before
the
at
least
two
patches.
These
two
two
series
are
alternative
versions
of
the
same
fix.
One
of
them
adds
an
additional
feature.
C
C
B
C
C
Yeah
and
it's
it
is
for
what
it's
worth
in
the
comment
of
the
second.
It
message
on
the
second
Branch
I
do
note
that
the
T
option
is
slower
by
about
two
seconds
on
the
on
the
slowest
running
test.
C
So
it's
it's
not
the
worst
thing
in
the
world.
If
we
really
like
the
feature,
but
it
is,
there
is
also
a
performance
difference
which
I
felt
like
pointing
out.
E
A
I
know
exactly:
we
talked
about:
I
ended
up
linking
John
the
exact
Packer
for
that
I.
Don't
have
it
on
hand
now,
okay,
but
he
saw
that
like
what
we
ended
up
to
figure
out
is
that
that
was
happening.
A
A
C
The
the
issue
is
await
really
says
block
on
this
and
don't
move
forward
until
they're
all
done.
So.
What
what
we
really
need
to
do
is
process
the
standard
out
and
standard
error,
while
waiting
for
the
thing
to
exit
I
had
an
intermediate
version
that
I'm
not
showing
here,
because
it's
this
is
simpler,
where
T
continued
to
exist
and
it
basically
said
gather
TT
wait
for.
If
you
do
that
at
all,
it
actually
does
work,
but
then
I
some
further
simplified.
The
the
patch
to
use,
communicate.
E
Yeah,
but
the
first
chance
you
introduced
just
it
should
be
good
to
make
sure
that
it
works
for
a
very,
very
long
outputs,
because,
yes,
that's
the
case.
C
Adam,
can
you
right
so?
Can
you
scroll
to
this
very
long,
yeah
yeah,
it's
right
there,
6
23.,
so
I
don't
know
if
this
number
is
insufficient.
We
can
certainly
bump
it
up
some
more,
but
this
thing
tries
to
write
whatever
a
hundred
thousand
line.
I
can't
count
zeros
on
Adam's
screen
a
million,
but
it
okay
thanks.
C
So
it
tries
to
generate
that
many
lines
of
output
in
a
simplistic
way,
and
that
test
is
the
one
that
takes
like
either
three
or
or
six
ish
seconds,
and
hopefully
that's
sufficient
I
don't
know.
So
if
you
you
have
a
case
where
a
command
is
generating
more
more
output
than
that.
E
I,
remember
and
that's
in
in
that
cluster
in
the
dense
cluster.
If
my
memory
is
good,
the
line
was
160,
something
a
kilobyte.
B
A
A
But
that
was
a
separate
thing.
That's
already
been
fixed
elsewhere
and
then
I
I.
Don't
we
never
fully
figured
out
what
was
causing
that
issue?
Rhett
I
was
talking
about.
It
could
have
either
been
something
with
the
thing
timing
out,
but
the
fact
that
the
the
time,
the
wait
for
thing
was
before
The
Gather
meant
that
when
it
timed
out
it
never
fully
returned
or
it
could
have
been
something
with
there
being
too
much
output.
We
don't
actually
know
which
one
it
was
the
timeout
or
the
output
that
was
causing
the
problem.
C
If
we
kept
the
T
function,
then
yeah,
maybe
the
buffer
could
fill
up
waiting
for
a
long,
long
long
long
line,
but
if
you've
already
resolved
it
I,
don't
think
I.
These
patches
change.
Any
of
that.
C
I
can
do
and
find
before
filing
the
pr
what
I
could
do
is
I
could
take
the
long
running
test
and
you
know
bump
it
up
to
even
more
let
it
run
for
whatever
30
minutes
or
I.
Wouldn't
I
don't
want
a
unit
test
that
runs
more
than
like
this.
One
already
feels
slow
when
you
run
the
test.
You're
like
oh,
what's
going
on,
oh
yeah,
it's
the
five
second
test.
C
I!
Don't
really
want
to
increase
it
Beyond
this,
but
I
could
do
it
by
hand
and
say,
oh
by
the
way
I
bumped
it
up
to
you,
know
a
million
or
whatever
it
is
I,
don't
know
yeah
and
bytes
and
see
if
it
chokes
on
that
and
just
do
it
by
hand
yeah.
Would
that
be
sufficient.
A
Yeah,
that's
probably
as
good
as
we're
gonna
get
with
testing
with
unit
tests,
all
right
so
I
think
so.
I.
E
C
Right,
because
that
was
one
of
the
first
things
Adam
warned
me
about
when
we,
when
I
mentioned,
that
I
found
that
Carl
had
a
yeah
timeout
wasn't
working.
So
if
you
don't
mind,
can
we
I
just
want
to
rewind
a
little
bit
to
the
the
main
question
I
have
which
is
do
you
would
you
prefer?
Would
the
group
prefer
that
we
add
a
feature
of
being
able
to
partially
log
find
out
commands,
or
do
we
prefer
the
more
simple,
possibly
better,
performing
option?
C
Because
again
we
don't
have
this
feature
but
I
kind
of
went
ahead
and
implemented
anyway,
because
I
wanted
to
but
I'm
leaning
towards
not
doing
that
now,
but
I
wanted
to
give
everyone
the
opportunity
to
chime
in
and
say.
Oh
actually,
we
really
want
to
know
we'll
say
why
a
command
light
of
hung.
So
we
want
that
logging.
A
I'm,
leaning
towards
using
just
using
communicate,
yeah
I
was
thinking
that,
even
with
the
things
that
we
normally
run
that
we're
hanging
they
log
some
things
eventually
that
and
maybe
give
some
some
information
like
that
volume
stuff.
But
I
don't
know
if
that
even
doesn't
even
show
up
as
output
I
think
I,
don't
think
that
ever
ended
up
in
any
of
this
stuff
that
he
was
doing
before
so
I.
A
Don't
know
how
much
we'd
actually
get,
and
this
on
top
of
being
faster,
is
also
probably
a
bit
safer
for
using
a
proper
Library
thing.
Somebody
who
knows
what
they're
doing
with
this
as
well
Hunter
T
works.
Okay,
but
I
mean
it
is
still
something
we're
sort
of
doing
ourselves
and
try
to
make
sure
it
works,
and
all
that.
C
Yeah,
that's
generally
my
my
feeling
now
as
well,
and
we
can
always
come
back
and
add
locking
back
in
later.
If
we
decided,
we
do
need
that.
A
Yeah
but
as
you
said,
we
already
removed
it
because
it
didn't
exist
at
one
point:
I
ended
up,
removing
it
and
I
didn't
even
notice
at
the
time.
A
So
I
would
say
it's
probably
definitely
not
probably
not
worth
it
for
now.
Unless
we
we
find
a
specific
use
case,
or
we
find
it
easier
way
to
do
it.
I
guess
yeah.
C
The
only
thing
I'll
add-
and
this
doesn't
matter,
whichever
version
is
that
when
we
try
to
time
out
the
process
and
we
kill
it,
and
then
we
wait
for
it
if
the
process
isn't
d-state
or
something
we
still
get
stuck
here,
there's
not
much.
We
can
do
about
that
at
this
time,
like
massively
rewriting
call
which
I
don't
think
we
want
to
do,
but
I
just
figured
I'd
mention
that,
because
it
came
up
in
the
discussion
yesterday
as
well.
A
Yeah
I
mean
eventually
we
do
kind
of
want
to
do
that,
because
I
think
the
the
end
goal
is
to
whenever
something
for
whatever
reason
fails
like
it
hangs
or
or
something
we
want
to
be
able
to
raise
a
health
warning
in
the
manager
which
would
require
coming
out
of
this
band
eventually,
because
the
manager
is
just
waiting
for
this
to
finish,
we
would
have
to
Implement
some
sort
of
timeout
there
as
well
like
at
the
managers.
I.
A
Have
that
call
some
out
of
time
out
and
not
get
stuck
on
this
or
we'd
have
to
have
this
be
able
to
return
at
some
point,
but
that
was
being
able
to
kill.
C
C
Okay,
because
maybe
stick
that
in
the
in
the
dock
and
I
can
refer
back
to
it
later
again,
I
kind
of
lean
towards
doing
the
simpler
thing
now.
But
if
that's
a
real,
if
it's
a
real
desire
to
have,
we
can
I
think
the
easiest
thing
might
to
be
passed,
some
sort
of
callback
to
call
and
say
you
know
if
you
time
out,
do
this.
C
That
might
be
the
simplest
alternative.
C
C
Keep
I
keep
I,
have
a
tendency
to
go
off
on
tangents.
The
main
point
of
this
meeting
is
just
Gathering
feedback
on
that
approach.
One
versus
approach
two.
So
if
anyone
has
any
strong
opinions,
let
me
know
otherwise:
I'll
probably
go
with
approach.
One.
E
A
C
Vote
for
one
all
right,
that
is
what
I'll
go
with
then
so
I'll
follow
up
my
existing
PR
with
another
PR
that
actually
fixes
the
the
function
and
I'll
delete
the
speculative
test
that,
what's
in
the
middle
of
that
of
screen
right
now,
okay.
A
B
A
C
Okay
and
then
the
last
one
and
hopefully
I
will
I,
can
stop
talking
and
stop
wasting
everyone's
time
is
while
I
was
looking
at
the
async.
I
o
docs
I
noticed
that
there
is
a
newer
I
think
it's
called
a
Handler
I
forget
the
Watcher,
so
newer
Kernels
have
a
concept
called
pitfds
at
the
python
docs,
even
call
it
a
Goldilocks
child
Watcher,
as
in
sort
of
the
ideal
one.
C
It's
only
supported
on
newer
kernels
I
checked
this
morning
and
I
proved
to
myself
that
the
Rel
or
Centos
8
kernel
does
not
support
this,
but
I
do
believe.
Nine
does
which
is
not
tested
and
Fedora
definitely
does
so.
It
might
be
nice
to
have
something
and
optionally
enable
this.
So
so
do
like
a
probe
of
the
kernel
version,
and
that
is
what
I
linked
to
in
the
gist
my
hacky
script
show
how
we
might
enable
that
alternative
Watcher
for
newer
kernels
and
newer.
B
C
Yeah
so
basically
I
first
checked
to
see
if
the
kernel
is
new
enough
and
then
oh
I
already
see
a
mistake,
but
that's
okay.
This
is
just
a
hacker
demo.
C
So
basically
looks
to
see
if
the
kernel
version
is
new
enough
and
if
it
is,
it
tries
to
use
it,
and
if
that,
if
that
name
doesn't
exist,
the
attribute
error
we
just
use
whatever
the
default
is:
okay,
I'm
not
saying
I
would
do
it
this
way
in
actual
proper
stuff
ADM.
But
this
this
is
like
a
partial
cut
and
paste
of
the
pieces
of
idiom
I
needed
to
proved
myself
that
it
was
a
workable
and
B.
You
know
we
could
conditionally
do
it.
C
I
was
actually
hoping
that
when
we
instantiated
bit
of
the
child
watch,
it
would
Rave
us
raise
a
specific
exception
itself,
like
your
kernel
version
is
too
old,
which,
unfortunately
it
didn't
do
so
I
did
the
you
name
decking
stuff.
What
is
that,
if
there's
a
simpler
way
to
do
that?
Let
me
know
I
just
hacked
that
together,
I'd
like
to
I
think.
A
C
What
I
did
is
I
ran
this
script
on
my
laptop,
which
is
Fedora,
36
or
7,
doesn't
really
matter,
and
then
I
also
ran
it
on
a
Southwest.
8Vm
and
I
ran
it
on
the
base
version
of
python,
and
then
I
ran
a
fedora
37
container
on
that
version
of
Centos,
so
that
we're
basically
using
the
latest
Python
and
an
old
kernel
and
yeah
that
was
successfully
used.
The
the
native
async
run
but
skipped
using
the
pitify
Watcher
because
it
successfully
used
detected
that
was
on
or
on
an
old
kernel.
A
In
this
case,
you're,
are
you
importing
this
from
somewhere?
Are
you
just
using
python39
so
just
I'm
doing
things
I
know
for
this
threaded
child
Watcher,
which.
C
I
saw
right
so
if
I
run,
if
I
run
the
script
on
the
python
version
that
comes
with
Centos
8,
it
I
see
the
print
using
fallback,
async
run
because
it's
whatever
Python
3,
8
I,
think
and
then,
if
I
run
it
in
the
Fedora
37
container,
it
runs
line
37
and
goes.
Oh,
your
Kernel's,
too
old
I'm
not
going
to
execute
the
if
block
and
then
when
I
run
it
on
my
desktop,
it
is
able
to
print,
enabled
async
IO
pitfd
child
watch.
B
A
I
think
about
the
outside
of
the
kernel
version
right,
because
I
know
for
the
threaded
child
Watcher.
We
have
right
now.
We
we
just
have
that
code
copied
into
the
binary
right.
It's
not
like
Yes,
actually
importing
it,
because
it's
on.
C
Python
well,
it'll
I
think
it
tries
I,
think
it
tries
to
do
it
and
then
otherwise
falls
back
to
the
copy
and
paste
it
version,
because.
B
C
Yes,
so
that's
the
that's!
The
CIS
version
info
check,
which
is
checking
the
version
of
python
I
personally
like
to
try
and
import
things
first,
and
rather
than
use
explicit
version
checks,
but
whatever
we,
what
am
I
trying
to
say
the
kernel,
is
different
from
the
python
version,
so
the
kernel
version
I,
don't
see
another
way
to
do
that
right
now,
the
python
version
I
I
opted
for
a
try,
except
rather
than
a
is
my
version.
X
I
hope
that
all
makes
sense.
A
B
A
C
Oh
sorry,
I
wasn't
planning
on
doing
the
copy
and
pasting.
I
was
basically
going
to
say
if
the
version
of
python
is
new
enough
and
the
version
of
use
the
built-in
one
so.
C
Actually
fixes
some
bugs
where
this
is
just
a
purely
efficiency
thing.
The
threaded
child
Watcher
has
to
create
threads
to
watch
the
child.
The
pitfd
basically
creates
a
special
FD
to
monitor
the
state
of
the
child
and
sticks
it
in
the
e-pole.
Slash
select,
slash
whatever
underlying
thing.
The
async
io
Loop
is
using
okay.
A
A
C
A
What
I
was
thinking
I'm,
not
sure
what
I
guess
the
only
problem,
I
guess
is
inside
of
our
containers,
they're,
so
bad.
They
built
on
Centos
eight,
they
probably
for
a
while,
but
I'm
I,
don't
I.
Imagine
that's
still
going
to
be
an
issue
we're
going
to
build
uses
anyway.
If
I
had
to
wait
until
I
guess
they
start
building
the
containers
using
and
yeah.
C
B
A
C
Sense,
yeah
I,
don't
know
I'm,
not
totally
on
top
of
what
red
hat,
Downstream
or
rhcs
Downstream
is
doing,
but
I
thought
things
were
moving
towards
nine
and
I.
You
know
at
some
point
I'm,
sorry,
so
we'll
do
something
similar
with
their
Enterprise
stuff.
So
yeah
eventually
we'll
have
kernels
that
are
newer
or
more
widespread.
A
C
E
E
The
three
that
the
other
child
Watcher,
because
I'm
reading
the
binary
code
and
I
see
that
we
are
using
like
special
class.
A
E
A
A
You
know
it
sounds
good
well,
especially
if
we're
not
going
to
do
anything
weird
with
it,
we're
just
going
to
be
like
important
and
stuff,
we'll
just
throw
it
in
there.
If
it's
usable,
we'll
use,
it
seems
like
it's
a
slightly
better
version.
B
All
right,
You
can
go
on
to
this
last
one.
A
So
the
idea
of
this
pull
request
is
that
we
want
to
split
up
the
host
training
into
two
separate
things:
where
are
you
training
the
demons
off
a
host
and
draining
the
unfagen
gearing
we
Deploy
on
the
host
are
slightly
different
things,
so
you
can
do
one,
but
not
the
other,
and
for
doing
that
we
need
to
introduce
a
new
label,
you'll
Mark,
the
config
and
key
Rings
being
drained,
and
so
yesterday
it
seemed
like
people
were
a
bit
confused
with
the
naming
and
stuff,
and
since
these
are
really
hard
to
change
after
they're
sort
of
in
an
actual
release,
we
sort
of
want
to
talk
about
a
little
bit
here.
A
So
I
have
some
some
stock
changes
in
the
pull
request
here.
That
sort
of
explains
what
the
labels
do
well,
this
is
part
typically
is
talking
about.
What
drain
will
do
when
what
drain
will
do
is
add
both
labels
by
default,
no
schedule
which
stops
it
from
putting
demons
on
that
host,
gets
them
all
removed
and
no
conflict
key
ring,
which
will
stop
you
from
putting
any
config
and
keyring
files
on
the
host
and
remove
any
that?
Are
there
and
then
down
here?
A
There's
extra
parts
that
explains
what
this
label
does,
but
it
basically
just
sort
of
piggybacks
off
the
no
schedule
label
description
up
here
and
then
just
says
that
this
one
applies
to
config
and
keyrings,
and
then
there's
also
the
naming
of
the
flag,
I
guess
as
though
the
flag
that
gets
it
to
not
put
this
label
on
the
host
so
that
you
can
only
join
the
demons
but
not
the
conflict.
Gearing
is
this:
keep
configuring
lag.
A
Yeah
we're
basically
just
talking
about
how
we
want
to
name
these
things,
make
them
a
bit
less
confusing,
more
so
for
for
users,
I
guess
than
us,
even
though
it's
nice
for
us
to
be
able
to
easy
understand
as
well.
It's
most
important
that
it
makes
sense
to
users
how
these
things
are
named
and.
E
The
users
normally
handle
these
levels,
I
mean
these
are
like
internal
levels
for
safety
and.
A
C
You
have
a
somewhat
silly
question:
no
conf
key
ring
doesn't
make
sense
on
its
own
without
no
schedule
right,
like
one
is
kind
of
stream
of
the
other.
A
A
So
it
can't
exist
on
its
own,
like
most
of
the
time.
I
expect
them
to
be
paired
up
together,
because
you
probably
want
to
you're,
usually
training
hosts,
because
you
want
to
get
rid
of
them
or
move
them
from
the
cluster.
A
The
key
ring
management
in
general
is,
but
if
we
can
find
the
doctor
for
that
as
well,
just
we
can
look
at
a
little
bit,
but
basically
it's
like
any
hearing
you
want
like
so,
for
example,
if
you
need
some
client
keyring
for
some
client
demon
on
the
host,
for
whatever
reason
right,
you
could
have
Stephanie
deployed
that
on
every
host
that
matches
like
X
label,
for
example,
or
like
every
host
that
matches
or
I
know
any
placement.
Basically,
you
just
put
some
placement
for
it.
A
Okay
and
so
I
guess
you
could
use
this
one
to
say
like
I
added
on
all
these
hosts,
but
this
one
host
right
now
I
want
to
not
get
those
constant
key
rings
and
you
can
put
the
label
on
manual
but
again,
I
expected
to
mostly
just
be
used
as
part
of
the
drain.
C
A
A
As
a
topic
for
sure
yeah
there's
this
part
talks
about
the
the
keyrings
and
stuff
and
what
it
does.
Basically,
you
put
pretty
much
any
key
ring
there.
A
And
then
it'll
just
put
it'll
deploy
that
key
ring
into
the
Etsy
stuff
directory
on
all
the
hosts
that
you
match
the
placement
again,
if
you,
if
they're,
like
I,
want
for
whatever
reason
like
this
host
can
I
don't
want
to
have
the
key
Rings
anymore,
you
could
put
the
label
on
and
it
would
even
off
of
that
specific
host.
Well
still
put
it
on
the
other
ones
that
match
the
placement
but
use
it.
That
way.
A
A
A
If
you
mean
before
this
change,
no
schedule
would
basically
cover
both
of
these
cases.
So
it
is.
These
were
both
encompassed
under
the
one,
no
schedule
label,
and
so
no
schedule
would
cause
it
to
remove
the
demons
and
the
config
interior.
A
So
this
color
price
is
splitting
it
up
into
two
things
and
the
reason
behind
that
all
is
because
somebody
wanted
to
be
able
to
drain
hosts
with
from
demons,
but
leave
the
keyrings.
A
They
wanted
to
do
that
on
some
of
their
nodes.
I,
don't
remember
exactly
why.
E
A
Because
they
want
to
remove
all
the
demons
from
the
host
and
the
easiest
way
by
far
to
do
that
is
to
drain
the
demons
they
do
the
host
drain.
But
the
ocean
would
also
remove
the
config
in
key
ring.
So
then
they
were
forced
to
like
manually
edit
their
placements
to
exclude
that
host
or
something
which
is
a
pain.
So
this
would
allow
them
to
keep
those
onto
the
key
rings
that
they
want
on
the
host,
while
still
getting
rid
of
all
the
demons.
A
A
The
label
is
how
we
do
it
internally,
because
we
basically
we
need
to
know
which
hosts
we
need
to
drain
whatever
we're
doing.
E
A
Yeah,
so
this
is
the
drain
host
function.
I
don't
want
to
go
super
depth
of
this
stuff,
but
it's
not
very
long.
Oh
no,
it
doesn't
matter
stuff
it.
It
also
will
Mark.
So
OCS
are
special,
so
we
have
to
mark
those
as
be
drained
as
well,
and
then
it
prints
out
a
list
of
all
the
demons
on
the
host.
So
there's
some
extra
little
things,
but
as
far
as
handling
the
north,
the
non-osd
demons.
A
C
A
C
A
Yeah
and
even
with
osds
it'll,
try
to
start
draining
them,
but
obviously
the
OC
removal
process
is
a
bit
more
in
depth
than
the
other
demons
yeah,
so
that
one
has
to
do
some
other
stuff,
but
for
yeah
non-osds
it'll
just
put
that
label
down
and
then,
when
the
it
does,
the
normal
apply
spec
stuff.
A
Does
it
that
way?
And
then
the
client
keyrings
actually
use
the
exact
same
placement
system
for
putting
those
down,
and
so
because
they
do
that.
Then
those
people
also
affected
them,
and
so
they
would
also
get
removed
in
the
exact
same
fashion,
because
I
think
literally,
what
we
do
when
we're
calculating
where
to
put
those
is.
B
A
We
just
make
a
placement
here
yeah
and
then
we
just
make
it
a
mod
spec,
so
we
just
basically
fake
that
we're
placing
a
demon,
a
mon
demon,
but
actually
this
is
the
placement
we're
going
to
use
for
the
client
key
rank
stuff.
So
it's
exactly
the
same
system.
It's
just
that,
although
this
Polar
Express
is
sort
of
doing
is
saying
it's
using
a
different
list
of
things
to
figure
out
which
hosts
are
draining
and
which
ones
are
available
and
stuff,
because
this
is
a.
A
A
Yeah
I
mean
I'm,
confident
all
this
stuff,
at
least
Works.
With
this
pull
request,
it's
just
a
matter
again.
How
do
we
want?
What
do
we
want
to
call
these
things
like?
No
configuring
I
mean.
Does
that
conflict
any
better
for
a
label
to
say
like
we're,
going
to
remove
all
the
configuring
keyring
and
then
keep
const
keyring
for
the
flag?
I
know
that
comes
confusing
because
they're
they're
so
similar
in
name
and
they're
opposites.
A
E
A
E
What's
what
happens?
Okay?
We
don't.
When
you
don't
have
the
flag,
it
means
that
you
have
to
remove
sorry.
You
have
to
keep
the
files
right.
A
If
you
don't
put
the
flag,
then
we
put
both
the
labels
and
then
everything
gets
removed.
If
you
do
put
the
flag,
it
puts
only
this
label
and
not
this
label,
and
then
the
config
hearings
will
be
left,
but
the
demons
will
still
get
removed.
A
B
A
E
C
E
A
I
guess
so,
it
would
now
put
the
cardigan
keyrings
back
on
the
host.
I
was
sort
of
just
considering
that
as
very
unlikely,
because
I
don't
know
why
you
just
leave
the
hosts
around
with
no
schedule
on
it,
not
remove
it.
There's
no.
C
A
E
Yeah
like
if,
if
the
only
secondary
risk
is
what's
John
commented,
then
I
want
I'd
like
more
gold
in
migrations
like
in
the
worst
case,
you
will
end
up
with
some
host
with
only
confusion,
fights,
but
you
know
nothing
brand
new
on
it.
Yeah.
A
E
E
A
C
C
Admonition
saying
something
like
you
know:
these
these
labels
are
they're
meaningful
to
the
system
and
they're.
Not
you
know,
oh,
how
do
I
say
it
they're
subject
to
change
over
time,
and
so,
if
you're
doing,
if
you're
playing
around
with
them
manually,
because
this
is
more
Upstream
like
Downstream,
we
can
just
say:
don't
do
this,
but
Upstream.
You
should
just
warn
people
like
hey,
be
aware
that
the
the
exact
semantics
may
change
between
versions.
E
A
All
right
now,
I
could
also
note
because
I
when
you
talk
about
it
also
the
other
thing
others
about
removing
the
labels.
I
had
no
saying
like
be
careful
about
adding
these
labels
and
just
leaving
them
around
else.
You
don't
want
to
remove
because
of
it
could
change,
but
also,
if
you
want
to
cancel
draining
a
host,
you
want
to
remove
these
labels.
E
A
E
E
C
B
A
And
give
a
point:
yeah
all
right:
yeah
I
got
a
lot
of
warning
in
general
or
I.
Guess
a
lot
in
this
section
that,
like
you'll,
be
careful
with
these
and
I.
Think
up
here.
I'll,
add
something
that
says
like.
If
you
want
to
stop
the
draining
whatever
you
can
remove
these.
B
E
Yeah
I
think
a
general.
We
should
avoid
like
giving
the
user
the
possibility
to
touch
in
internal
labels
and
provide
commands
for
whatever
they
need,
because
this
way
we
reduce
the
risk
of
something
going
back
because
they
are
manipulating
internal
labels.
A
I
mean
we
could
always
go
through
and
add
commands
for
all
the
other
ones
as
well,
but
I
think
that's
a
I,
don't
know,
it'll
take
a
few
more
pull
requests
and
things
so
I
think
I
may
both
start
for
this
one,
adding
some
sort
of
warning
about
the
label.
Yeah
yeah.
E
Just
like
to
be
consistent
this
way,
if
the
user
knows
that,
please
don't
touch
whatever
label
starts
with
underscore,
then
nobody
will
go
and
try
to
do
anything
with
this
labels
just
have
like
consistency
like,
but
don't
touch
them
at
all
or
can't
what
we
can't
have
like
a
mix.
Okay,
you
can't
touch
this
one
button
or
this
one.
That's
that's
could
be
very
confusing
to
the
user.
A
All
right
and
we
don't
go
in
that
direction.
I
don't
have
to
mind
that
having
commands
for
I
don't
know
something
like
admin
label
or
no
auto-tune
or
something.
A
But
I
think
I'll
start
with
the
warning
here
and
then
we'll
that'll
be
some
sort
of
follow-up
work,
yeah
and.
E
Actually
add
in
this
new
comments
as
two
months,
it
shouldn't
be
like
very,
very
big
task,
because
it's
very
trivial
it
just
it
just
the
label.
Okay,.
D
That
makes
sense,
let's
see
what
we
want
to
do
here.
A
A
All
right,
in
that
case,
yeah
we're
a
little
over
time.
So
we'll
end
it
here
and
I'll
see
you
guys
all
next
week.