►
From YouTube: 2020-01-27 :: Ceph Orchestration Meeting
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
Okay,
stuff
on
this
Josh
was
not
going
to
join
us
today.
I,
don't
know
if
the
state
is
coming.
The
most
of
the
terms
is
about
a
few
minutes
late,
so.
A
A
What
would
be
nice
to
come
to
a
conclusion
today
about
what
you
want
to
do
with
it
so
Ostia
you
had
a
concern
that
you
would
like
to
have
it
as
an
external
dependency
right.
C
B
B
Yeah
I
guess
I've
gone
back
and
forth
myself
on
this
question
because
it
feels
like,
if
so,
clients
I
mean.
Basically
it's
a
client
API
for
working
with
rooks
er
DS
right,
yeah
yeah,
if
it's
in
the
repo,
it's
nice,
because
it's
just
versioned
exactly
with
what.
However
rook
changes,
but
if
the
like,
we
have
a
go
going,
client
that
code
generation
is
in
the
repo
with
the
code,
so
it's
yeah
whenever
the
code
changes
the
client
changes
with
it,
so
that
that's
the
nice
thing.
B
And
I
guess
I
was
thinking
if
well
the
client
code
I
mean
the
client
code
isn't
actually
running
as
part
of
Brooke.
Obviously,
clients
just
need
to
pick
it
up
and
know
what
version
it
belongs
to
something.
So
they
can
work
with
wrote,
and
this
seemed
to
follow
in
the
same
pattern
with
the
the
going
client
where
we
generated
it
with
the
code,
and
so
that's
why
I
was
thinking
all
this
just
put
it
in
the
repo.
So
it's
all
version
together.
B
C
I
guess
that's
the
issue
like
the
more
client
you
start
adding.
Then
they
will
all
request
that
or
maybe
they
won't
because
they
want
to
have
their
own
CI
and
they
think
they
can
be
more
productive
if
they
have
if
they
had
their
own
repos.
So
they
can
purge
things
more
quickly.
They
don't
need
to
wait
for
any
person
that
has
the
right
ownership
to
merge
their
their
code,
yeah
and
I.
Think
like
because
it's
because
it's
an
addition
and
rook
is
already
there.
C
Then
if
we
have
concerns
maybe
around,
what's
which
version
supports
which
which
version
of
group,
then
perhaps
the
libraries
should
directly
go
with
the
latest,
supported
version
or
or
have
different
tags,
even
if
it's
the
same
code,
so
that
you
know
that
the
version
1/2
of
the
library
supports
versions,
1
2.
So
if
we
follow
the
same
same
versioning
kima,
then
you
know
it's
always.
C
Very
few
people
have
the
right
access
to
repo,
as
well
as
the
CI
and
yeah
I,
guess
it.
It's
probably
I
think
it's
probably
easier
if
we
separate
the
concerns
and
having
having
your
own
repo,
for
this
will
likely
bring
to
you
more
flexibility
and
then
less
less
issues.
I
guess
that's
that's!
That
was
my
idea.
I.
D
Agree
with
Dan
and
there
is
another
and
if
you're
not
same
thing,
that
I
think
that
is
important.
That
is
probably
the
root
client
shouldn't
change
changed
us
with
the
same
frequency
at
the
root
code.
Okay,
because
the
line
is
only
going
to
change
if
we
introduce
new
properties
in
the
C
artist.
So
probably
this
is
something
that
is
going
to
tend
to
to
be
something
that
is
not
going
to
change
very
frequently.
Okay,
so
probably
we
don't
not
need
one
version
of
a
client
kind,
libraries
for
each
of
the
releases
of
the
group.
D
B
Think
I'm
not
concerned
about
separating
the
into
a
separate
repo
if
we
want,
if
we
decide
on
that
approach,
because
we're
always
making
sure
that
any
updates
to
this
see
ours
are
backward
compatible
because
we
have
to
support
the
different
version
does
vary.
Upgrading
like
new
settings
or
just
our
settings
that
aren't
recognized
or
just
ignored
by
the
operator,
for
example,
I.
Think
from
that
perspective
that
the
client
API
isn't
in
perfect
sync
with
the
client
code.
It
shouldn't
be
a
problem
because
we
have
that
that
philosophy
around
backward
compatibility
at
the
same
time.
B
C
B
C
Yeah
I
think
it's
yeah,
maybe
if
you
want
to,
if
you
want
to
build
like
a
pack
heads
also,
you
only
needs
to
fetch
that
repo-
you
don't
have
to
told
the
world
world
people
just
to
get
that
little
library
to
so
it's
probably
more
straightforward
for
people
to
find
there
is
any
year
any
library
were
to
pick
it.
I
guess.
A
B
C
B
B
D
A
B
A
B
You're,
okay,
the
wall
so
you're
blocked
until
it
we
find
at
home.
For
this
yeah,
you
can't
make
yep
okay
yeah
all
right
now.
Let
me
I'm
gonna
sink
up
with
Jared
and
Alexander
as
well
and
I
guess
maybe
process
this
a
bit
more
myself,
just
to
confirm
that
yeah
what
it
means
to
add
a
new
birth
creep.
Oh
we've,
never
really
added
a
new
rook
repo.
Besides
the
operator
kit,
which
we
don't
have
a
dependency
on
anymore,
though
okay
I'll
take
that
action.
That
okay.
B
D
A
D
B
C
We
won't
likely
get
it
in
the
cloud.
So
that's
that's
that
PR
is
in
isn't
flights
in
set
volume.
Hopefully,
we
can
have
it
in
this
week
and
backward,
but
for
that
you
know
that
US
I,
think
14
to
2.7
batch
for
stem
volume
is
going
to
be
really
interesting
for
herself
because
it
brings
supports
for
to
to
partitions
as
well
something
we
really
need
in
work
so
that
people
can
can
really
can
really
really
do
that.
Their
their
transition.
D
C
C
B
C
B
C
A
A
E
A
E
Yeah
I
have
this
full
request
at
it
changes
a
few
things,
but
the
service
LS
already
returns
immediately,
and
so
that's
already
there
and
has
an
age.
So
this
PR
caches,
yes,
H
connections,
so
that
it
reuses
them
and
then
it
it
makes
it
so
that
periodically
it
will.
Every
time
the
serve
loop
comes
around,
which
is
normally
every
10
minutes.
E
It
will
do
a
check
host
and
every
host
to
make
sure
that
they're
those
are
valid
or
whatever
and
if
not
over,
is
a
warning
and
then
also
it'll,
refresh
the
it'll
to
read
you,
the
service
LS
inventory
service
inventory
and
every
host.
Also.
So,
if
you
just
don't
do
anything
and
you
do
you're
watching
service,
LS
you'll
see
that
the
last
updated
we'll
go
up
to
ten
minutes
and
I'll
go
back
to
zero
new
ten
minutes
whatever,
and
that
seems
to
work.
Fine,
except
when
I
ran
just
that
through
QA.
E
It
failed
because
it
turned
their
internal
callers
to
good
services
that
are
run
right
after
we
deploy
deploy
things
that
expect
to
see
the
thing
that
they
just
deployed,
and
so
there's
one
more
patch
that
also
after
you
deploy
something.
It
just
adds
something
to
the
cache
I've
done.
The
entry
that
has
basic
information
about
the
container
that
should
have
just
been
created,
but
without
actually
having
to
refresh
the
inventory
necessarily
and
so
I'm
gonna,
run
that
through
QA
and
just
see.
E
So
that's
what
I've
gotten
so
far,
I
think
the
larger
goal
here,
I
think,
is
to
I
think
a
couple
things
I
think
we
need
I
think
we
need
to
better
define
what
the
error
handling
should
be
when
we
have
problems,
refreshing
service,
State
or
running
a
command
on
the
host
like.
Should
it
just
get
out
of
error
on
the
command
line?
Should
it
raise
the
Health
Alert
and
that
the
periodic
refresh
raises
a
helpful
area
that
fails
to
refresh
services,
pretty
sure
the.
E
A
E
E
I
think
yeah
yep,
agree
well,
I
think
I
think.
Basically,
this
bull
request
is
a
good
step
forward,
but
I
think
there
still
she
that
we
have
to
look
at.
One
of
the
things
that
I
was
running
into
is
just
like.
I
want
a
log
that
I
can
look
at
to
actually
see
what's
happening.
This
have
some
transparency
into
what
the
status
of
a
DM
is
sort
of
being
errors
or
something's,
not
refreshing
or
command.
A
E
A
E
A
A
C
Yeah
I,
just
just
just
one
thing:
real,
quick,
it's
just
like
FYI.
We
have
been
discussing
this
many
times
and
I
I
guess
I
just
witnessed
it
at
some
point.
Several
is
like
so
fast
now
with
white
on
three.
C
E
Okay
on
on
that
note,
I
wanted
to
bump
that
request.
One
of
the
slowest
parts
of
the
giving
the
service
inventory
is
for
every
container.
It
runs
SEF,
be
inside
the
container
and
that's
because
the
container
doesn't
have
a
label
on
it.
That
tells
you
what
stuff
version
is
installed
inside
of
it.
So
I
really
really
want
the
container
to
have
a
label
on
it.
D
C
E
C
Yeah
I
guess
because
I
at
least
like
it's
like,
if
you
do
set
be
because
you
pulled
the
image,
then
it's
a
100%
true.
But
if
you
look
at
the
labels,
then
we
we
might
have
made
a
mistake:
yeah
I,
guess
the
the
only
good
thing
is
that
we've
partnered
you
we
don't.
We
don't
use
pod
meant
for
this
so
hard
to
see
how
we
can
do
it,
but
with
pod
man
you
can
look
at
the
metadata
of
an
image,
even
though
you
haven't
pulled
it
yet.
I'm.