►
From YouTube: Ceph Orchestrator Meeting 2020-10-05
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
Yes,
let's
see
patrick
isn't
here,
I
was
hoping
he'd
be
here
too,
but
all
right
yeah,
let's
start
talking
about
it
at
the
so
I
sent
out
an
email
a
few
days
ago
to
the
seth
development
mailing
list,
saying
hey:
what's
the
status
of
the
rook,
the
rook
manager
module,
which
is
was
created
a
long
time
ago
like
two
years
ago
and
hasn't
really
been
used
much
since
it
hasn't
been
in
a
good
maintenance
state.
A
So
my
question
is:
do
we
still
need
it?
What
what's
its
priority
and
all
that-
and
I
was
talking
to
patrick
a
couple
weeks
ago-
and
I
thought
it
understood
that
the
dashboard
didn't
need
it,
but
I
clarified
that
last
week
with
lens.
Yes,
the
dashboard
is
still
interested
in
it.
A
A
A
And
getting
him
back
up
fixing
the
bugs?
Is
it
a
priority
to
do
this
now?
That's
kind
of
the
question
and
having
an
owner
for
doing
it,
because
that
and
just
making
sure
we're
testing
that
scenario
and
that
that
someone
drives
that
scenario,
I
think,
will
be
important.
C
Yes,
once
again,
one
thing
good,
just
just
to
well
to
put
everything
everywhere
in
costa
in
context,
okay.
Well,
I
I
have
heard
what
the
something
about
that
is,
look
is
going
to
be
used
or
not,
or
what.
C
Well,
I
think
that
in
this
moment,
well
there
are
limited
resources,
okay
and
well.
F
atm
is
the
the
main
priority
okay,
so
we
need
to
to
finish
with
the
well
thefdm
in
this
moment.
I
think
that,
well,
everybody
is
interested
in
in
africa
working
as
smooth
as
possible.
Okay-
and
in
this
moment
what
was
the
project
we
have
more
or
less
100
packs,
okay,
open
it.
In
upstream,
we
have
a
part
of
the
of
the
functionality
that
we
need
in
downstream.
C
I
am
talking
from
red
hat
that
we
need
to
to
cover
in
order
to
to
to
get
the
same
functionality
that
we
have
with
the
fancy
work
with
a
fadm,
and
this
is
focusing
on
all
the
work
of
the
people
that
were
at
least
in
jet
hut
is
working
with
the
with
our
status.
Okay,
you
know
that
I
I
was
working
with
a
rook
orchestrator,
but
I
stopped
it
the
work
with
that,
because
we
need
to
to
to
be
completely
focused
in
the
idm.
C
So
the
the
question
is
that
probably
is
our
problem
is
a
problem
of
resources?
Okay,
because
there
is
no
people
available
in
order
to
work
with
a
rook
or
stator,
so
I
think
that
it's
important
to
have
the
functionality
working
okay
and
I
I
treat
well
to
start
that
with
the
with
the
mana
yeah,
the
test,
okay
for
for
the
module
in
order
to
to
detect
as
soon
as
possible
problems.
C
But
the
fact
is
that
I
haven't
got
enough
time
to
in
order
to
do
that,
and
I
think
that
well,
I
don't
know
in
the
case
of
suse
what
is
the
situation
but
from
our
part
in
in
red
hat,
and
we
are
completely
focused
in
for
the
moment?
Okay.
So
it's
just
a
question
that
we
haven't
enough
resources
in
this
moment
to
to
make
the
the
model
work.
C
Okay,
that
is
something
that
obviously
should
work
should
be
fixed
if
we
have
any
kind
of
attack
and
we're
trying
to
to
to
have
exactly
the
same
functionality
with
both
orchestrators.
I
thought
this
is
not
going
to
be
completely
possible,
because
what
the
platform
is
is
different.
Okay,
we
know
that
there
are
some
differences,
so
this
is.
This
is
the
situation.
C
I
have
explained
that
in,
for
example,
next
past
week
in
the
there
was
a
synchronization
meeting
between
well
in
the
dashboard-
and
I
explained
that
this
also
too,
but
I
think
that
lens
is
aware
of
that
and
everybody
is,
is
know
what
what
is
the
current
situation.
So
it's
just
a
question
of
of
resources
that
we
haven't
got
enough
resources
to
cover
or
both
our
status.
Okay,
so
we
are
now
focusing
in
the
fdm.
This
is
the
situation.
A
I
think
getting
parity
there,
you
know,
will
be
a
challenge
and
maybe
not
even
realistic,
just
because
they're
different
right
now
on
sap
adm,
you
need
to
manage
nodes
on
kubernetes,
you
don't
it's
a
kubernetes
task,
it's
not
a
rook
thing
right,
so
there
are
just
fundamental
differences
there.
So
I
think
it'll
be
important
for
rook.
If
going
to
support
the
manager
module
to
identify
what
scenarios
really
make
sense
to
support
it
on
and
then
great,
let's
go
support.
A
D
So
big
picture,
what
we
care
about
is
being
able
to
spawn
some
either
short-lived
or
long-lived
tasks
in
response
to
some
logic
in
the
in
the
manager
modules.
There's
a
few
things
that
we
care
about
from
the
stepfest
side
being
able
to
spawn
cephas
mere
tests
in
response
to
configurations
driven
through
the
manager,
possibly
also
driven
through
the
dashboard
so
being
able
to
replicate
geo-replicates
ffs
file
systems.
We
also
care
about
being
able
to
spin
up
nfs
ganesha
demons.
D
We
made
nfs
ganesha,
first
class,
citizen
and
cfs,
or
you
know
where
we
got
most
of
the
logic
in
there
in
place
for
that
and
it
works
with
septum
the.
D
So
now
we
can
spin
a
benefits,
connection,
clusters
and
separation
for
that
are
exporting
so
fast,
but
the
the
next
step
there
is
also
getting
to
work
with
rook,
and
so
we
need
to
be
able
to
do
the
same
thing
as
far
as
like
looking
inspecting
devices
and
and
whatnot
from
our
our
perspective.
We
don't
care
too
much
about
that,
but
they're
and
I'm
not
familiar
enough
with
the
orchestrated
apis
to
to
say
which
things
we
absolutely
need
for
rook.
D
But
I
do
want
to
note
that
there
was
there
were
attempts
of
a
year
and
a
half
ago
trying
to
figure.
You
know
iron
out
what
the
common
interface
should
be
between
rook
and
septim,
and
I
thought
that
was
agreement
concerning
that.
But
I
I
guess
it's
you
know
as
cfadm
evolved.
Maybe
there's
been
some
divergence
and
we
need
to
spend
some
time
to.
D
You
know
figure
out
what
that
comma
interface
should
be.
If
it
needs
to
be
changed,
then
there
needs
to
be
a
discussion
on
that.
I
know
there's
some
documentation
upstream.
D
As
far
as
what
you
know
what
those
operations
are
and
what's
supported,
and
what's
not
as
far
as
rook
versus
fadm,
and
maybe
that's
since
changed-
I
don't
know
how
up
to
date,
the
document
the
dock
is
now
it's
a
table.
C
Do
you
have
the
the
link
to
do
that
document
in
upstream
I'll?
Take
it.
A
A
D
Yeah-
and
I
forgot
that
was
one
other
scenario
that
we
are
also
interested
in-
is
controlling
the
number
of
mds's
that
are
deployed
initially
just
to
make
sure
that
the
file
system
is
stable,
but
in
the
future
we
would
like
to
be
able
to
add
or
remove
mds's
in
response
to
load
on
the
file
system
and
that's
driven
by
the
mds,
auto
scaler
module.
D
So
I
linked
in
the
chat,
the
documentation.
I
was
talking
about
it's
this
obscure
table
at
the
bottom
of
the
orchestrator
cli
doc,
and
it
talks
about
what's
in,
what's
supported
in
rook,
what's
supported
in
cefadm,
I
don't
know
how
up
to
date
that
table
is,
and
there
might
be,
new
rules
that
need
to
be
added
to
the
table.
C
Right
well,
basically
it
it
seems
that
in
favor
is
everything
covered.
Okay
and
in
rook
is
not
covered
a
lot
of
things,
okay
and
in
rook
there
is
no
work
from
months.
Okay,
I
think
that
the
last
thing
that
it
was
done
in
rook.
It
was
my
my
integration
test,
so
no,
no,
no
common,
no
new
functionality,
okay,
so
this
is
the
at
least
the
the
current
state,
okay
and
a
part
of
that.
Well,
it
seems
that
it
is
covered
mds,
okay,
so
if
it
is
not
working,
probably
is
it's
just
that?
C
C
D
D
As
far
as
you
know
whether
the
rook
orchestrator
should
be
supported,
I
feel
it
should,
I
think,
we're
going
in
a
direction
where
steps
kind
of
managing
itself,
at
least
some
things
even
upgrades,
and
I
think
it
makes
sense
for
it
to
do
that.
There's
still
a
need
for
rook
crds,
and
you
know
there
will
be
some
rook
initiated
storage
management-
that's
not
going
to
change,
but
we
are
going
in
a
direction
where
stuff
manages
itself
more
and
more
and
being
able
to
spawn
containers.
D
To
do
work
is,
I
think,
essential.
So
you
know
if
we
don't
want
to
cover
all
the
these
rows
in
the
table.
You
know
I
I
don't
care,
but
I
do
think
you
know
we
do
need
to
meet
this
need
and
at
the
very
least
there
needs
to
be
testing
because
there's
an
embarrassing
lack
of
testing
regarding
the
this
deployment
tool.
D
A
B
C
Problem
now,
patrick,
is
that,
basically,
you
need
to
to
work
well
to
to
be
sure
that
the
rook
with
mds
servers,
mds
diamonds,
is
working
okay
and
also
the
this
guy.
All
the
operations
in
order
to
escalate
a
number
of
mds
diamonds
is
that
that
was
one.
D
Use
case
yes-
and
I
don't
know
if
that
even
works
right
now,
many
of
the
orchestrator
commands
don't
work.
For
example,
you
can't,
I
think
the
listing
hosts
does
not
work
listing
processes
does
not
work.
You
get
empty
return
returns
back.
Varsha
is
in
the
process
of
fixing
some
of
these
bugs,
but
the
quantity
of
bugs
is
unknown.
D
Because
again
we
have
no
testing
she's
right
now,
working
on
getting
a
very
simple
test,
just
so
in
pathology,
working,
it's
going
to
be
a
simple
shell
script
to
deploy
a
mini,
cube,
root
cluster
and
do
at
least
testing
sufficient
for
her
purposes,
which
is
to
deploy
nfs
ganesha
clusters
in
rook.
D
You
know
I,
I
not
sure
what
her
current
status
is
on,
that
I
think
she's
getting
close,
but
we'll
have
that
basic
testing
in
place.
D
I
think
eventually
we
do
want
to
get
to
a
point
where
we
have
a
way
to
orchestrate
a
rook
cluster
through
mini
cube
and
have
that
be
a
piece
of
common
infrastructure
in
the
testing
suite
and
then
actually
do
more
orchestrator
to
add
more
orchestrated
tests
to
validate
that
it
works
right
now.
She's
completely
focused
on
just
getting
the
nfs
ganesha
clustering
to
work
in
rook,
so
she's
not
going
to
do
the
full
test
coverage
that
we
like,
but
she's,
getting
us
at
least
part
of
the
way
there.
C
Question
one:
yes,
yes,
but
the
the
problem
that
we
have
is
basically
that
we
will
have
enough
resources
to
do
that.
Okay,
so
the
thing
that
we
need
to
to
solve
is
that
it's
basically
that,
okay,
because
there
is
a
there,
is
a.
I
think
that
no
no
other
kind
of
problem
is
just
a
question
of
resources.
C
So,
as
I
don't
know
how
to
solve
that,
okay,
maybe
we
we
should
ask
for
more
people
in
that
hat
in
susan
in
order
to
to
dedicate
to
this
eat
them,
okay
or
well,
to
to
move
resources
from
favem
to
to
rook.
I'm
not.
My
opinion
is
that
this
is
not
correct.
Okay,
because
I
think
that
if
we
want
to
have
something
stable
in
downstream,
we
need
to
be
completely
focused
in
feeding.
C
We
are
only
three
persons
from
red
hat
working
in
downstream
in
theft,
adm,
okay,
so
there
is
not
too
much
people
to
to
move
to
to
rook.
Okay
in
upstream,
I
don't
know
if
suse
has
more
possibilities,
let's,
let's,
let's
try
to
find
a
one
solution,
but
in
that
it's
just
a
question
of
decision
of
what
is
more
important.
What
what
is
more,
critical
and
or
to
what
resources
I
this
there's
a
resource
constraint.
D
The
the
the
amount
of
attention
being
given
to
stephanie
m
is
is
understandable,
but
we
we
do.
I
think
it's
you
know
true.
In
sousa
and
red
hat,
we
do
have
a
large
focus
on
on
kubernetes
kubernetes,
whatever
teflon
kubernetes,
where
we
are
using
rook.
D
So
I
know
that
it's
fairly
common
to
use
crds
to
to
orchestrate
a
lot
of
depth
functionality
in
those
in
those
situations-
and
you
know
obviously
that's
being
tested
by
rook,
but
again
we're
going
in
a
direction
where
death
is
managing
itself
more
and
more,
and
so
you
know
this
gap
with
the
orchestrator
testing
is
going
to
rear
its
ugly
face
in
pacific
and
and
down
and
more
even
more
so
down
the
road.
So
I
think
it
is.
A
Thoughts
too,
on
approach,
I
mean,
as
far
as
design,
making
the
right
design.
There's
I
mean
in
some
cases
we
might
be
able,
or
the
implementation
might
be
so
different
between
the
orchestrators.
Well,
we
could
just
implement
it
in
rook
and
sap
adm
separately.
We
don't
need
to
do
it
in
the
manager
module
or
we
wouldn't
get
much
benefit
of
doing
it.
A
It
may
be
more
overhead
in
the
manager
module
to
do
it
that
way
like
if
brooke
can
watch
for
some
event
in
ceph
and
when
it's
notified
it
goes,
and
you
know,
adjust
the
crds
or
or
maybe
doesn't
even
need
to
create
or
update
crd
that
can
just
change
the
behavior,
because
some
policy
is
already
set
in
a
crd
like
auto,
adjust
the
you
know,
the
nfs
demon
count
when
this
event
happens,
or
or
whatever
you
know.
There
are
different
ways
to
approach
it.
A
A
I
guess
aware
of
versioning
issues,
because
rook
and
steph
are
decoupled
from
a
versioning
perspective,
so
the
manager
module
needs
to
check
what
version
of
rook
is
running
and
whenever
rook
runs
stuff.
It
checks
has
version
checks
depending
on
what
needs
to
happen
so
that
that
versioning
will
be
more
complicated.
A
If,
if
the
manager
module
has
to
worry
about
it,
then
if
brooke
is
just
purely
worrying
about
it
on
the
other
side
on
a
feature
by
feature
basis,
I
feel
like
we
need
to
evaluate
well
what
is
the
right
design
and
if
it
really
goes
in
the
management
module
great,
let's
put
it
there,
and
but
if
it
is
not
needed
in
the
manager
module,
we
can
just
keep
it
in
a
separate
orchestrator.
C
Well,
I
another
another
thing
that
I
wanted
to
comment.
Okay
is
maybe
it's
just
my
metaception
okay,
but
I
think
that
in
the
case
of
parameter
clusters,
okay,
the
theft
manager
or
the
stator
fedm-
is
something
that
is
completely
needed.
Okay,
but
in
the
case
of
a
kubernetes
clusters,
I
think
that
the
orchestra
in
the
orchestrator
module
in
there
in
the
third
manager,
is
something
that
is
maybe
accessory.
Okay,
because
you
can
drive
all
the
functionality
that
you
need
using
rook
with
crds,
okay
and
really
the
stator
is
rook
okay.
C
So
what
is
the
the
functionality
that
is
interesting
for
us
in
from
from
the
rook
orchestrator
module
in
in
the
manager
basically
is
to
allow
the
dashboard
to
to
use
the
functionality
that
we
have
in
the
adventist
cluster
managed
by
a
hook?
Okay.
So
I
think
that
this
is
in
this
moment
the
the
only
place
where
what
we
need
this
functionality-
okay,
so
patrick,
if
you
try
to.
C
D
No,
this
is
the
nfs
clustering
as
part
of
the
volumes
manager
plug-in
that
is
trying
to
get
a
road
cluster
up
and
in
an
automated
in
in
our
qa
suite
and
then
actually
deploy
the
nfs
clusters
through
the
the
staff
orchestrator
through
rook.
C
Okay,
maybe
well,
I
don't
know
because
we
discuss
what
is
the
functionality
that
we
are
going
to
need.
Probably
we
are
going
to
to
have
a
lot
of
surprises,
okay
with
the
rook
orchestrator,
so
there
is
another
possibility.
Okay,
that
is
well
instead
of
create
a
cluster
using
the
the
orchestrator
module.
Okay,
maybe
you
can
provide
this
theft,
cluster
managed
by
rook
as
an
external
resource,
the
to
your
manager
model.
D
You're
you're,
echoing
what
what
travis
has
already
said-
and
I
I
guess
that's
part
of
the
purpose
of
this
meeting-
I
I
suppose
it's
it's
only
natural.
After
all,
the
work
that's
been
done
on
sev
adm
that
we
have
this
fundamental
discussion
again
on
whether
or
not
the
the
step
orchestrator
should
be
orchestrating
rook
in
in
a
way
and
have
this
cyclical
relationship
between
the
two.
D
I
think
that's
a
long
discussion,
it's
it's
one.
We've
already
had
and
we're
now
talking
about
changing
our
our
thought
on
it.
I
think
that
needs
to
be
part
of
a
larger
discussion,
probably
at
the
clt
meeting.
As
you
know,
whether
or
not
we
should
change
our
views
on
that,
I
don't
want
to
have
that
discussion
here,
but
the
current,
as
as
I
understood,
the
the
current,
the
thought
was
that
we
would
have
these
two
orchestra,
these
two
deployment
back-ends,
but
the
orchestrator
interface
should
be
the
same.
D
There
was
a
number
of
reasons
for
that.
The
the
dashboard
would
have
access
to
a
lot
of
information
concerning
the
state
of
the
cluster.
You
know
what
devices
are
available,
we'd
be
able
to
orchestrate
new
services.
We'd
be
able
to
list
the
host
importantly,
the
the
manager
would
be
able
to
or
handle
upgrades,
and
while
you
know
up
to
this
point,
we've
had
the
rook
module.
Do
the
upgrade
process
for
seph
in
a
lot
of
ways.
It
made
more
sense
to
to
manage
that
within
in
ceph
itself.
D
You
know
we
could
make
sure
it
works
across
different
deployment
technologies,
and
I
think
we
still
want
to
go
in
that
direction.
I
know
sep
adm
does
minor
upgrades
already
for
us,
and
major
upgrades
is
sort
of
a
future
task.
We,
you
know,
there's
no
reason.
We
can't
do
that
in
rock,
as
well
or
with
the
rook
deployment
back
in
for
the
orchestrator.
D
It's
just
a
matter
of
actually
making
it
work.
Now
I
realize
that
not
a
lot
of
attention
has
been
placed
on
this,
but
I
thought
those
goals
made
sense
at
the
time
we
we
discussed
them.
You
know
years
year
or
two
back
and
nothing's
really
changed
in
that
regard,
except
you
know
a
matter
of
priority
and
consistency
across
the
the
two
deployment
back-ends,
and
I
think
you
know
back.
Then
we
had
this
concept
of
the
nested
stage
orchestrator
or
an
ansible
orchestrator,
both
of
those
kind
of
died.
D
Now
we
just
have
seth
adm
and
we're
in
a
lot
of
ways:
stephanie
m's,
you
know
re-implementing
a
lot
of
things
that
are
enanciable
and
also
funnily
enough
in
kubernetes.
D
So
you
know:
we've
had
it's:
it's
eaten
up
a
monstrous
amount
of
engineering
resources,
which
I
think
is
one
of
the
reasons
why
the
orchestrator
itself,
with
the
rope
back
end,
has
been
so
neglected.
D
D
A
A
I
feel
like
people
use
the
dashboard
as
a
nice
place
to
view
things,
but
then
they
just
go
to
kubernetes
to
configure
and
drive
the
cluster,
and
I
feel
like
the
dashboard
was
the
primary
driver
for
the
module
and
and
since
the
upstream
community
hasn't
really
latched
on
to
the
dashboard
as
the
way
to
configure
it.
They
just
well.
They
just
do
everything
through
the
crds.
D
Use
of
it
yeah
as
far
as
the
dashboard,
I
I
I
know,
I
told
you
travis-
that
the
dashboard
seemed
to
be
moving
away
from
the
orchestrator.
I
thought
I
heard
that
from
lens,
but
it
seems
in
another
conversation
with
lens
or
at
least
on
the
mailing
list.
It
sounds
like
they
are
trying
to
use
the
orchestrator
more
so
I
admit
I'm
a
little
confused.
C
This
is
this
is
true:
okay,
that
the
the
dashboard
needs
the
orchestra,
the
orchestrator,
in
order
to
to
get
all
the
functionality.
Okay-
and
the
problem
is
that
in
this
moment
the
only
orchestrator
that
is
working
is
the
vdm
okay,
because
nobody
has
worked
in
order
to
to
cover
this.
This
disparity
of
functionality
between
the
two
worker
status,
okay,
but
you
are
patrick,
you
are
right
with
the
disciples
principles
or
the
direction
that
we
need
to
go.
Okay,
I
I
agree
with
you,
but
this
is
the
situation
in
this
moment.
C
What
I
am
suggesting
you
is
just
to
make
a
work
around
trying
not
to
use
the
the
rook
orchestrator
model
directly
in
order
to
have
the
thing
that
you
need
and
if
you
don't
want
that,
but
we
need
to
to
set
the
sources
in
order
to
to
continue
work
with
with
the
rook
orchestrator
okay,
but
for
sure
that
the
dashboard,
the
interface
between
the
dashboard
and
the
theft
cluster
is
the
orchestrator
and
we
have
two
possibilities:
fab
and
the
other
one
is
rook.
Rook
is
not
working
in
this
moment.
A
Well,
I
think
maybe
the
question
of
resources
also
is
tied
to
the
fact
that
downstream,
at
least
a
red
hat
for
rook
scenarios,
we
don't
use
the
ceph
dashboard
right,
there's
the
ocs
dashboard.
So
we
need
a
driver
for
the
upstream
step
dashboard
to
call
the
this
this
module
right
so
that
that's
the
I
need
an
owner.
Yes,
that
sees
the
value.
D
Reach
any
conclusions
here,
it
seems
like
we
got
a
mix
kind
of
you
know.
Yes,
the
crds
are
available.
Yes,
we
also
want
the
orchestra
to
work
with
rook,
but
you
know
there's
a
lack
of
resources.
I
think
you
know
what
we're
currently
doing
makes
sense
with
russia
trying
to
get
something
up
so
that
we
have
some
kind
of
testing
with
rogue.
D
I
mean
that's
something
we
want
an
upstream
pathology,
no
matter
what
decision
is
made,
you
know
we
do
need
to
regularly
test
sef
with
the
and
not
simply
rely
on
rooks
ups
upstream
testing
for
making
sure
that
nothing
breaks,
so
we're
going
to
continue
doing
that.
D
I'm
hopeful,
though,
that
you
know,
as
far
as
you
know
whether
or
not
this
can
become
a
priority
that
you
know,
the
discussion
can
begin
that
you
know
we
do
need
more
rigorous
testing
of
the
the
orchestrator
with
the
back
end
or
at
least
something
simple,
and
it
would
be
nice
if
we,
you
know,
from
a
high
level
perspective.
D
We
had
all
these
commands
in
this
table
with
you
know
some
common
set
of
tests
that
can
be
run
no
matter
which
deployment
technology
we
actually
use
in
upstream
in
the
technology
qa,
and
hopefully
we
can
get
to
that
point.
But
I
think
that's
a
direction
I'd
like
to
see
us
start
moving
towards,
but
I
can't
speak
for
you
know
who
should
work
on
this
and
and
all
that.
A
Right
in
the
short
term,
I
feel
like
yeah,
let's
fix
some
of
those
issues.
Let's
get
the
tests
going,
especially
for
the
scenarios
that
varsas
is
working
on
and
you
know
when
we
have
the
the
dashboard
integration
driver
for
rook
I
mean
before
then.
I
just
don't
see
more
happening
as
far
as
the
remaining
commands
that
aren't
as
directly
needed
for
scenarios
right
now.
C
Well
that,
basically
nobody
is
using
that
okay,
because
in
downstream
we
are
in
northeast
in
ocs,
we
are
using
a
different
thing
or
we
are
using
directory
rook,
okay
and
in
upstream
there
is
nobody
using
this
in
this
mode,
so
is,
is
going
to
be
difficult
for
I
I
think
that
is
just
to
to
take
a
decision
and
to
ascend
resources,
okay,
but
what
is
going
to
be.
F
A
I
guess
is
it
just
in
the
nice
to
have,
or
you
know
what
what's
in
the
need
to
have
category?
That's
where
we
well.
C
So
there
is
no
nobody
working
with
that.
There
is
nobody
maintaining
the
code
or
interesting
in
into
the
code
okay,
so
it
should
be
a
downstream
initiative,
probably
leaded
by
suse
and
by
ourselves.
Okay,
in
order
to
to
make
this
work
okay
and
to
provide
this
functionality,
but
in
upstream
in
this
moment
is
there
is
nobody
working
with
that.
F
Yeah,
it's
gonna
be
interesting
to
see
how
the
market
evolves.
I
mean.
Currently,
you
know
a
kubernetes-based
standalone
deployment.
There
isn't
really
one
right.
So
as
a
result
there
you
know
what
would
your
management
strategy
be
right
and
we're
going
to
have?
I
think
some
interesting
conversations
with
suse
with
their
recent
purchases
once
they,
you
know
integrate
that
company
evolve
a
little
bit.
We're
gonna.
F
We
are,
we
haven't
integrated
the
rest
of
the
infrastructure,
support
in
for
kubernetes
and
a
lot
of
things
you
might
have
to
do
there
as
well.
So
there's
a
lot
more
work.
That
has
to
be
done.
So
it's
going
to
be
interesting
to
see
how
it
plays
out
in
my
opinion,
but
I
mean
I
think,
I'm
a
strong
proponent
for
having
dashboard.
You
know
as
that
standalone
product
moving
forward,
but
I
mean
that's
a
very,
very
limited
subjective
opinion,
so
we'll
see
where
it
goes.
A
B
So
I
can
just
tell
you
that
before
we
were
jumping
on
safety
m,
we
were
actually
contributing
to
the
rook
module.
B
I
think
especially
sebastian
did
and
some
other
guy
from
our
team,
but
for
now
at
least
we
have
a
priority
on
cdm
and
I
honestly
can't
really
tell
you
if
that
is
going
to
change.
That's
some
management
decision
that
I'm
not
not
aware
of.
A
We'll
give
him
a
minute:
are
there
any
other
topics
besides
this
one
for
today,
oh
here
he
comes.
E
School
is
there
federico
yeah?
I
lost
my
connection
and
welcome
back
yeah.
What
we're
gonna
say.
I
just.
I
think
that
it
depends
depends
at
what
level
of
the
future
you're
looking
at
in
the
immediate.
I
think
that
it's
it's
fairly
straightforward
from
the
right
head
point
of
view
where
the
resources
are
allocated.
We
have
a
rook
based
product
and
obviously
we
have
to
maintain
and
enhance
that
we
have
a
sfadm
based
product
coming
next
year,
so
those
have
to
be
the
immediate
priorities.
E
Now
the
adm
based
product
will
basically
be
done
in
engineering
by
january.
If,
at
that
point,
more
work
happens
in
the
orchestrator.
I
I
don't
see
why
not,
but
I
also
don't
see:
what's
the
downstream
priority
downstream,
meaning
red
hat
priority
driving
the
work
on
the
orchestrator
so
yeah,
I
don't
have
a
a
resolution
either.
A
C
Well,
I
I
wanted
to
comment
something,
but
this
is
in
into
the
free
dm
field
directory.
Okay,
it's
about
the
what
the
full
request
that
we
have
opened
about
the
diamond
where
to
get
information
from
the
host
okay,
but
the
last
comments
joshua,
it
seems
that
you
prefer
to
to
change
some
settings
in
order
to
continue
using
ssh
or
the
real
option
to
to
do
the
change.
We
start
to
use
an
https
like
server
in
order
to
retrieve
the
information.
What
is
your
your
position.
B
Though
I
mean
I'm
just
not
so,
let's
maybe
let's
maybe
post
the
pull
request
before
we
start
talking
about
this
here,
because
I
don't
think
that
anybody
or
that
all
of
us
are
actually
aware
of
what
we're
talking
about
now.
Let
me
first
find
that
pull
request.
B
C
B
Right
right,
so,
if
we're
talking
about
that,
then
this
is
the
correct
link.
Let
me
post
it
in
here,
so
if
we
can
somehow
tweak
the
performance
of
the
ssh
connections
and
probably
also
the
worker
pool
size
to
get
a
reasonable
performance,
I
think
this
would
be
preferable.
B
I
do
not
know
if
we
can
tweak
the
performance
to
to
meet
the
requirements
well
to
meet
the
requirements
that
we
have
set
ourselves.
These
are
completely
arbitrary
numbers,
but
this
is
what
seemed
reasonable
at
a
at
a
also
reasonable
note
size.
C
Okay,
that
is
what
I
think.
Okay,
it's
my
my
view
that
probably
I
I
know
that
paul
has
tested
this
with
treyarch
hardware.
Okay,
with
a
lab
of
several
servers.
Okay
and
well,
the
information
that
we
have
from
from
paul
is
what
it
appears
to
to
be
in
a
real
environment.
Okay,
so
I
don't
know
if
your
your
information
coming
from
a
real
test
scenario
or
is
just
a
development
lab.
Okay,
are
you
using
a
development
lab.
B
C
Yes,
it's
what
I
think,
okay,
because
there
is
a
lot
of
difference.
Okay,
so
even
if
you
try
to
to
make
these
modifications,
my
my
feel
is
that
this
no
is
not
going
to
to
reach
the
same
level
of
efficiency
that
we
have
with
the
https
server.
Okay.
So
if
we
we
are
going
to
to
take
a
decision
now
about
that,
okay,
I
prefer
to
to
know
to
have
real
information
about
that.
C
C
Okay,
so
I
think
that
probably
it
could
be
worth
to
test
in
real
hardware,
a
part
of
that
there
are
some
kind
of
security
issues:
okay,
that
I
think
that
we
can
solve
using
the
https
server,
but
basically
what
I
wanted
to
what
to
transmit.
You
is
that
we
need
to
to
have
this
information
the
more
real
or
the
more
near
of
the
of
the
real
situation
in
order
to
to
decide
what
to
do.
Okay,.