►
From YouTube: Ceph Orchestrator Meeting 2021-06-08
A
I
guess
today
is
a
rook
day.
At
least,
let's
see
how
much
we
can
discuss
about
the
rook
manager,
module.
B
Language
is
simply
a
similar
to
a
natural
language
where
we
can
define
our
test
scenarios
easily
and
very
for
not
requiring
very
technical
people
to
also
define
it
easily
to
how
the
system
should
work
and
it
simply
uses
given
and
and
when
kind
of
keywords,
to
run
the
scenario
and
assert
the
outcome
of
the
scenarios
and,
as
you
can
see,
I
have
provided
a
sample
scenario
that
will
be
implementing
saying
that,
even
as
I
log
into
a
nod
as
a
root-
and
I
execute
a
specific-
I
run
this
cdm
adm
version
command
so
that
I
then
we
assert
that
it
should.
B
We
should
match
with
the
version
we
get
and
what
the
version
we
expect.
Yeah
and
one
of
the
main
yeah
tool
for
this
integration
framework
will
be
kcli.
B
Jcli
enables
us
to
create
virtual
machines
in
few
seconds,
using
the
cmd
commands
and
get
it
up
and
running
and
running
in
few
minutes
as
well,
and
we
can
define
a
environment
that
we
wanted
to
run
a
specific.
B
This
scenario
that
we
define
and
we
can
simply
using
defining
it
in
the
future
and
we
use
the
behave
to
pass
these
specifications
and
create
using
the
kcli
plans
and
kcla,
uses
a
simple
ml
file
to
define
these
variables.
We
can
modify
this
number
of
nodes
and
number
of
cpus
as
required,
and
then
we
create
this
environment
and
after
creating
this
environment,
we'll
be
able
to
run
those
the
test
scenarios.
We
want.
B
And
as
the
dependency,
we
will
be
using
a
python
behavior
based
framework
as
behave
and
vi
uses
videos
to
the
the
korean
language,
to
define
jerk
and
sorry
jerking
language,
to
define
the
test
scenarios
and
using
the
python
implementation
to
execute
these
scenarios.
B
We
can
define
multiple
features
and
in
each
feature
we
have
multiple
scenarios
and
using
the
kcli
to
create
and
manage
and
interact
with
with
this
virtual
machines.
B
And
yes,
here
is
a
sample
structure
of
the
feature
files
that
we
define
in
the
feature
initially,
given
a
description,
what
the
future
is
and
we
define
the
environment
where
we
are
going
to
execute
these
test
scenarios,
as
you
can
see
with
and
for
this
example,
it's
three
nodes
with
four
gigs
of
ram
and
two
cpus,
and
this
here
we
use
the
behave
to
pass
these
specifications
and
using
the
kcli.
B
We
create
create
a
plan
and
get
the
kcra
tool
as
to
create
the
virtual
machines
and
get
the
machines
up
and
running,
and
then
there
will
be
multiple
scenarios
similar
to
these
scenarios.
Here
we
are
using
a
defining
joking
language
and
we
provide
that.
We
can
say
that
we
provide
this.
B
B
How
the
project
is
how
we
are
going
to
implement
in
this
project,
and
we
wanted
to
discuss
with
the
community
that
we
are
in
what
folder
structure
we
will
be
able
to
create
this
implement
this
project.
A
A
D
It
might
be
helpful
or
anything
non-technology
actually
would
be
like
bootstrap
tests,
where
having
a
virtual
machine
and
this
leaner
environment
would
give
us.
D
Like
you
know
the
example
of
the
ssh
user
thing
right,
it's
just
like
annoying
environmental
changes
that
we
want
to
make
sure.
C
They
there
here
is
that
what?
If
you,
you
have
the
code
and
you
run
the
test.
This
kind
of
test
is
possible
to
be
run
in
your
laptop
okay
or
in
your
development
machine,
okay.
So
it's
a
way
to
to
execute
in
a
quick,
fast,
efficient
way,
integration
test,
okay,
that
in
this
moment,
when
we
need
to
do
a
lot
of
manual
steps
in
order
to
achieve
that
and
was
to
wait
for
at
least
one
day
in
order
to
to
get
a
result.
Okay
with
the
tautology
trans,
so
just
is.
C
This
is
just
another
another
way
to
to
execute
this
integration
test.
The
important
thing
is
not
where
the
tests
are
going
to
be
executed,
because
you
can
execute
this
test
and
directly
in
your
in
your
laptop,
for
example.
The
important
thing
here
is
just
to
to
to
have
a
place
where
we
can
put
the
in
the
implementation
okay
in
order
to
well
to
to
make
easy
execution
of
this
test
or
or
all
day
already.
A
I
mean
why
not
you
mean
it's
it's
a
personal
framework
and
can
we
integrate
that
can
or
behavior
behave
framework
into
tux?
Does
it
would
it
work?
I
mean
I
I
wouldn't
certain
I
I
don't
think
it
makes
sense
to
run
it
on
make
check
right.
D
B
C
C
To
write
text,
okay,
in
order
to
to
make
this
possible
to
write
tests
for
people
that
is
that
are
not
developers.
Okay,
the
thing
is
that
what
the
steps
that
you
have
in
the
in
into
the
working
language,
the
different
features
that
you
want
to
test.
You
need
to
implement
some
things.
For
example,
you
need
to
implement
some
way
to
execute
a
command
and
to
get
the
output
and
to
compare
this
output
with
an
expected
output
in
order
to
to
see
if
the,
if
the
test
is
passed
or
not
okay.
C
So
what
the
the
target
of
the
kerkin
language
is
just
to
to
provide
an
easy
way
to
do
the
scribe
test.
D
I
guess
I'm
just
wondering
what
the
what
the
goal
then
is
I
mean:
are
we
trying
to
expand
the
number
of
people
who
can
write
tests
because
I'm?
I
worry
that
if,
if
it's,
if
it's
a
natural
language
description,
but
the
actual
behavior
is
precise,
like
we're
still
comparing
we're
still
running
specific
commands
and
checking
specific
output
like
that
seems
dangerous
to
me,
because
if
there's
a
failure
in
the
like
natural
language
processing,
then
you
have
to
debug
that,
as
opposed
to
have
something
that
is
very
explicit
about
exactly
what
what
it
is
that
we're.
C
Well,
it
it
depends
of
the
things
that
we
implement.
Okay,
because
the
natural
language
that
you
put
in
the
in
the
test
should
be.
C
A
Resources,
but
I
yeah
the
thing
that
really
strikes
me
is
that
we
have
gaps
in
totality,
so
the
the
third
goal
is
really
to
to
build
those
gaps
like
bootstrapping
oc
deployment,
where
we
don't
have
anything
right
now,
we
don't
have
any
target.
A
Any
any
any
proper
unit
testing
we
don't
have
anything
so
yeah.
D
Yeah,
that's
something
that
I
care
about
the
most:
it's
I'm
I'm
I'm.
It
feels
like
there's
like
the
set
of
people
who
are
going
to
be
like
motivated
and
inclined
to
write
tests,
but
who
can't
handle
like
talks,
python
or
whatever,
to
write.
Those
tests
is
like
very
small
compared
to
the
total
number,
so
I'm
a
little
bit
skeptical
on
that
about
the
natural
language
part,
but
the
gaps
like
I
really
want
to
fill
the
gaps
with
all
the
osd,
especially
with
the
oc
deployment
scenarios.
I
feel
like
those
are
the.
C
Okay,
that
that
could
be
nice,
okay,
but
well,
in
any
case.
I
think
that
we
do
not
forget
that
this
is
a
just
a
good
summary
of
code,
appropriate,
okay
and.
D
C
D
It
would
be
great
but
like
the
reality
is
that
we
can't
do
that,
and
there
are
lots
of
other
reasons
so,
but
so
I
think
if
we,
but
if
we
focus
around
like
things
that
toothology
doesn't
test
and
and
make
take
advantage
of
things
that
kcli
and
virtual
machines
do
provide,
for
example,
all
the
device
management
scenarios
that
we
want
to
be
able
to
cover
like
that
would
be.
That
sounds
like
time
very
well
spent.
C
Okay,
just
to
in
order
to
well
to
to
to
make
easy,
I
don't
want
to
start
with
a
with
a
project.
We
need
a
place
where
to
store
the
code
so
sebastian
you
have
proposed
the
the
docs
folder.
A
There
there
is
a
volume
in
in
the
theft
volume
module,
there
is
an
integration
test
and
that's
hooked
into
talks.
C
Yeah,
I
think
that
what
I
think
that
is
more
related
okay
and
even
we
can
start
just
with
the
fdm
test.
So
maybe
I
I
like
more
inside
thefadm
in
a
separated,
folder,
okay,
in
order
to.
A
Yeah
have
a
look
at
have
a
look
at
this
folder
here
as
an
example
as
a.
A
Don't
put
you
use
it
as
a
template,
use
it
as
a
similar
way
to
integrate
functional
testing
into
self-idea.
C
Okay,
so
we
can
use,
for
example,
into
the
folder
src.
Okay.
We
can
create,
for
example,
a
new,
for
example,
behave,
test,
okay,
folder
and
inside
that
folder
create
our
infrastructure.
A
Having
it
executed
without
having
it
executed,
mandatory
on
per
request
or
having
the
possibility
to
run
on
per
request,
is
kinda
pointless
right
tests,
written
without
automatic
verification
of
the
tests
are,
are
pointless.
So
how
do
you
want
to
integrate
that?
Do
you
want
to
integrate
that
inner
totality,
or
do
you
want
to
integrate
that
into
a
jenkins
job?.
A
D
C
D
Topic
should
we
talk
about
the
zap
thing?
Really,
quick,
yes,
I'll
just
take
a
minute.
I
basically
won
me
that
that
change
that
you
made
to
call
orchestrator
zap
whatever
it
adds
an
extra
destroy
when
it
calls
the
volume
which
destroys.
C
D
C
D
Not
I'm
not
quite
sure
how
we
should
proceed.
I
I
think
that's
probably
the
right
behavior
for
that
zap
we
could
add
a
flag
to
the
orchestrator.
That's
like
no
destroy
lv,
or
something
like
that
that
maybe
I
don't
know
that
seems
kind
of
awkward.
D
We
could
go
back,
go
back
to
what
we've
done
before,
but
then
have
like
a
a
device
refresh,
but
the
problem
with
that
is
that
device
refresh
is
asynchronous.
It
just
triggers
a
refresh,
but
it
doesn't
block
for
the
refresh.
You
don't
have
a
blocking
command
that
waits,
but
we
probably
should
right.
C
D
Yeah,
what
if
we
do,
if
we
do
a
stuff
adm
refresh
devices
command,
that's
blocking,
and
then
we
could
call
that
because
I
think
right
right
on
the
orchestrator
interface,
there's
no
blocking
command.
C
D
A
I
mean
when,
when
dealing
with
stuff
volume,
we're
going
to
have
the
same
measure,
so
if
we
just
expose
the
ali
options
of
volume,
I
think
they're
good.
We
just
have
to
think
about
persistent
volumes.
If
that
being
persistent
volumes,
I
don't
think
that's
a
thing
right.
It's
that's
just
gone
afterwards.
D
D
C
A
D
C
So
finally,
we
are
not
going
to
add
the
that's,
that's
no
destroy
we
are
going
to
avoid.
If
we
do
not
use
force,
we
are
not
destroying
the
the
the
device.
A
Yep,
let's
keep
the
volume
cli
and
the
f
li
compatible.
Okay.
If,
if
you
want
to
change
that
right,
then
we
should
also
change
it
and
say
volume
having
having
two
different
commands
that
are.
A
A
D
D
I
basically
asked
him
to
look
into
lso
and
just
battle
with
it
understand
how
it
works.
It
doesn't
work
just
if
you
want
to
summarize
what
you
found
so
yeah.
F
So,
basically,
what
I
I
I
very
simply
I
I
just
tried
to
to
get
rook
working
using
lso
to
provision
pvs,
then
rook
rook
consuming
those
lsos
or
those
pvs
and
yeah.
I
mean
it's
not
very
complicated.
You
just
run
the
lso
first
and
then
you
run
rook
and
it's
actually
quite
simple.
F
The
lso
has
kind
of
this
automated
way
of
creating
pvs
based
on
whether
a
device
is
valid
or
not,
and
it's
just
super
easy
to
like
to
create
those
pvs
in
the
storage
classes
and
then
rook,
depending
on
how
you
set
up
your
cluster,
you
can
just
tell
it
to
consume
those
evs
and
it
does
it
and
yeah
it's
not
very
complicated,
but
yeah.
That's
about
it.
A
D
I
think
yeah
I
mean
I
would
be
a
little
bit
hesitant
to
like
completely
remove
the
old
support,
but
I
think
we
should
focus
all
of
our
efforts
on
the
new.
Basically
I
have.
I
have
one
sort
of
lingering
question
about.
Well,
I
have
a
couple
lingering
questions
about
just
making
sure
that
lso
is
really
gonna
fit
the
bill.
D
So
I
think
the
the
first
is
that
the
test
that
joseph
did
was
basically
telling
rook
to
consume
pvs
when
creating
the
cluster
crd
like
on
startup,
and
I
think
when
you
do
that,
you
just
say
I
want
you-
just
basically
specify
how
many
osd's
you
want
to
create
right,
like
it's,
the
number
and
the
storage
class
and
it'll
go
and
provision
that
many
different
pvs
from
that
storage
class.
F
What's
that
right,
I
don't
think
you
actually
specify
the
amount
of
os
e,
I'm
not
entirely
sure
I
don't
completely
have
a
grasp
over
it,
but
okay,
if,
if
you
look
at
the
pad
that
I
I
linked
and
then
if
you
go
down
to
the
contents
of
lsoclustertest.yaml,
so
that's
actually
like
the
kind
of
stuff
cluster
definition
and.
F
F
Chat,
if
you
can't
see
now,
I've
had
it
to
the
pen.
Yes,
yes,
yeah!
So
you
basically
from
what
I
understand
yeah,
you
do
you,
you
define
a
storage
class
device
set
and
then
you
tell
it
like
how
many
osd's
you
want
to
set
up
in
that
set
and
then
that
set
also
has
like
characteristics.
So
you're
saying
like
I
don't
want
devices
with
less
than
like
five
gigs
of
storage,
so
yeah.
D
Like
if
you're
using
eds
or
something
like
that,
but
I
think
that
the
case
where
this
matters
is
when
you're
running
this
on
bare
metal,
where
you
have
better
machines,
you
have
like
specific
devices
and
specific
slots,
and
you
want
to
like
create
an
osd
with
like
this.
D
Common
db
device,
what
about
the
common
yeah
yeah?
That's
the
second!
That's
that's
my
second
question,
but
ignoring
that.
First
of
all,
like
let's
say
like
just
the
case
where
I
have
a
machine,
it
has
10
slots.
I
have
these.
Are
the
devices
like?
I
just
want
to
see
the
inventory
see
the
specific
devices
that
are
in
there,
like
with
their
model
and
serial
number
and
hopefully
like
all
that
metadata
about
them.
D
D
We
have
to
figure
out
how
you
actually
do
that,
like
can
you
tell
rook
to
consume
like
a
specific
tv?
Is
that
something
is
that
something
that
we
need
to
add
to
rook?
Or
is
it
something
that
it
already
does,
but
you
can
say
like
create
an
osd
on
this
device.
So
I
guess
that's
that's
the
first
thing
and
then.
A
D
I
think,
that's
one
mode
of
operation
that
users
would
want,
but
I
think
a
different
mode
of
operation
would
be
like,
I
guess
more
towards
like
a
day
two,
where,
like
there's
a
disc
that
failed
or
I
had
to
pull
it
out,
I
removed
it.
I
put
a
new
one.
In
now,
I'm
gonna
rebuild
an
osd
on
that,
like
a
more
like
imperative,
whatever
manual
process.
D
And
maybe
it's
just
my
paranoia,
but
it
like
feels
like
we
want
to
be
able
to
do
both,
even
if
the
manual
process
is
just
a
building
block
for
the
automated
process,
but
I
don't
know
if
maybe
maybe
we
should
just
not
be
thinking
about
that.
It
should
all
be
automated.
It
just
makes
me
nervous
when
it's
too
it's
there's
too
much
automation
going.
D
Yeah,
but
I
guess
I
guess
that's
sort
of
the
maybe
that's.
This
is
something
a
discussion
to
have
with
rook.
The
second
part
of
this
is
like
an
lso
question,
and
that
is
if
we
want
to
do
the
carbonyl
me
up
the
login,
for
if
you
want,
if
we
want
to
carve
up
a
an
nvme
into
a
bunch
of
pieces
to
use
as
the
db
device
for
a
bunch
of
hard
disks,
I
don't
think
that
lso
does,
that,
like
lso,
doesn't
create
a
bunch
of
lv's
it
doesn't.
D
C
But
I
I
I
think
what
I
think
that
said
you
have
presented
your
first
question
or
your
first
point.
I
think
that
is
the
important
in
this
moment,
because
we
need
to
decide
what
to
do.
Okay,
because
the
current
interface
that
we
have
in
the
orchestrator,
we
have
creation
of
osds,
and
we
need
to
do
a
couple
of
things
host
and
physical
devices.
C
And
this
is
not
the
thing
that
is
needed
in
in
rook,
okay
on
in
cluster
in
kubernetes,
because
they
are
using
directory
pvs.
Okay.
So
maybe
I
don't
know
if
it
is
worth
to
what
to
to
assume
that
this
is
not
going
to
be
possible
to
work
directly
in
the
orchestrator
with
the
devices,
and
maybe
we
should-
or
we
must
add,
a
new
new
endpoints
in
order
to
create
pvs
or
to
to
ask
for
pvs
and
to
create
osds
in
this
previous,
okay,
I'm
not
trying
to
to
to
make
work.
C
C
We
only
can
the
only
possibility
that
we
have
is
just
to
request
resources
to
have
clarinets
and
add
a
new
set
of
endpoints,
just
yeah.
D
Well,
I
I
think
you're
right,
that
for
an
environment
like
aws
we're
consuming
pvs
from
like
a
dynamic,
a
real
dynamic,
provisioner
like
ebs,
then
I
think
you're
right.
I
think
we
need
new
interfaces.
D
A
The
the
problem
is
that
the
bare
metal
way
of
dealing
with
devices
in
rook
is
super,
incomplete
and
nowhere
near
what
you
can
do
with
drive
groups
and
what
you
can
do
with
sephora.
So
even.
D
A
Yeah
that
that's
kind
of
the
bare
metal
way
of
doing
things
with
rook,
it's
still
anything
but
comparable
to
to
say
volume
or
to
to
self-idea.
A
A
That's:
okay,
if
you,
if
you,
if
you
really
care
about
performance
right,
if
you
really
care
about
performance
and
you
you
really
want
to
have
host
networking,
you
really
want
to
have
the
volume
directly
accessed
and
what's
what's
the
use
cases
between
cfidm
and
and
rook
is?
It
is
as
at
a
point
where
you
really
are
interested
in
bare
metal?
A
D
A
D
Well,
I
wonder,
then,
if
the
place
to
start
with
just
bringing
the
rook
stuff
up
to
date
is
not
on
a
season
but
on
all
the
other
stuff.
So
somebody
put
this
paste
bin
here
that
has
links
to
like
a
whole
bunch
of
it
just
went
through
like
every
cli
command.
It
looks
like.
C
C
There's
a
lot
of
lot
of
things
to
do,
okay,
but
I
think
that
what
the
the
most
important
thing
in
this
moment
is
just
to
decide
how
we
are
going
to
manage
west
is
okay
in
rook
environments.
C
So
we
need
to
to
take
a
decision
about
that,
and
I
think
that
in
environmental
environments,
I
think
that
if
somebody
is
going
to
use
a
parameter
environment,
a
dedicated
host
set
of
hosts
in
in
home,
okay,
probably
they
are
going
to
decide
to
to
use
theftm.
Okay,
if
you
decide
to
use
kubernetes
it's
because
you
do
not
want
to
have
a
real
control
or
detailed
control
of
the
physical
devices
that
you
are
going
to
have.
C
D
A
Adding
hosts
removing
hosts,
I
don't
think
that's
in
scope
for
for
the
rook
manager
module
because
it
would
mean
going
outside
of
kubernetes
and
that's
a
bit
older
scope.
I
don't
think
it.
D
I
well
the
way
I
interpreted
that
would
be
if
the
rook
deployment
is
constrained
to
a
label
on
nodes
like
a
rooks
label,
then
it
would
add
that
label
to
more
nodes.
So
it's
basically
controls
the
subset
of
the
kubernetes
cluster
that
rook
is
running
on.
That
was
the
way
I
would
interpret
that
command.
A
The
problem
is
that
this
is
maybe
not
a
user-defined
label
in
kubernetes,
so
you
you
would
kind
of
have
to,
or
that
was
a
year
ago.
I
don't
know
if
that's
still
the
case,
you'd
have
to
that.
A
D
D
We
don't
let
you
scale,
managers
and
rook.
We
don't
let
you
all.
The
demon
commands,
won't
work,
oc
device
ls
would
work
if
you
run
that
discover
pod,
but
just
all
lots
of
questions.
D
A
D
D
But
I
mean
we're
still
sort
of
kicking
the
can
down
the
road.
It
seems
like
the
really
big
questions
are
if
and
how
we
deal
with
osds
with
bare
metal
devices
and
or
how
do
we
extend
the
orchestrator
interface
so
that
we
can
talk
about
dynamic,
provisioners
and
first
distance
volumes,
and
if
we
create
an
interface
to
do
that,
like
would?
D
A
Rook,
even
for
pvs,
by
no
means
any
filter
so,
but
I
think
the
general
approach
of
using
drive
groups
is
independent
of
if
we
use
pvs
and
lso
or
if
we
use
pm
it
turns
out
that
we
we
already
could
we're
able
to
integrate
the
existing
way
of
doing
bare
metal
with
rig
already
with
trash
groups.
A
A
Yeah,
I
think
drive
groups
are
so
flexible
that
we
can
definitely
support
subtype,
a
subset
of
the
features
of
drive
club
with
pvs
yeah.
Maybe
we
need
to
add
stuff,
but
I
think
they're
flexible
enough.
D
E
Hello,
can
you
guys
hear
me
yes
now
I
can
hear
you
yeah
beautiful.
I
I
sorry
I
would
think.
Yes,
in
the
case
of
you
know,
ocp
ocp
does
have
some
interest
in
bare
metal,
you
know
so
as
a
result,
in
those
cases
rook
will
be
required
and
I
think
you
know
I
think
it
will
be.
You
know
something
that
will
be
needed
right.
So
you
know
so.
Yes,.
A
Bare
metal
via
lso
metal
via
direct
vms
and
volume.
E
D
There's
probably
a
discussion
that
we
need
to
have
with
somebody
from
rook,
probably
bash
and
honor
travis,
and
then
somebody
on
the
lso
side
and
just
understand
what
the
path
forward
for
carving
up
an
nvme
into
multiple
lvs
should
be,
because
that's
not
something
that
elsa
does
today.
I
understand
it.
E
Yeah
this
brings
me
backstage
to
a
conversation
we
had
a
while
ago
about
sort
of
the
solution
level
discussions.
We
a
lot
of
times
talk
about
it
component
level,
stuff
we're
going
to
set
up
meetings.
You
know
follow
on
this
would
be
a
nice.
You
know
type
of
topic
for
that.
You
know
agenda
right.
I
mean
you
know
from
the
point
of
view
of
end
and
solution.
No,
I
mean,
or
is
it
because
it
really
does
cross
a
lot
of
boundaries
right.
D
Yeah
yeah,
I
guess
I'm
not
I'm
not
remembering
what
what
discussion
that
was,
but
I
mean
we
just
need
to
get
these
like
three
groups
to
talk.
E
Well,
I
agree
great,
but
I
mean
overall
we're
going
to
set
up
a
venue.
I
was
in
the
context
of
the
solution
and
stuff
more
or
less
dashboard
related,
but
it's
all
encompassing
you
know,
and
we
wanted
to
have
discussions
occasionally
on.
You
know
the
solution
level
stuff,
because
a
lot
of
times
we're
still
piped
in
the
components
remember,
and
that
was
yeah
yeah.
We
had
a
conversation
a
month
ago
or
is
it
even
longer
I'm
losing
track?
And
I
can't
remember
yeah
yeah
that
yeah
this
sounds
like
a
good
idea.
E
D
Okay,
thanks,
okay!
Well,
so
in
the
short
term,
I
think
we
have
a
whole
bunch
of
questions
to
answer
on
osds
on
both
fronts,
bare
metal
and
not
bare
metal.
But
in
the
meantime,
joseph,
maybe
the
next
steps
are
to
look
at
orange,
ls
and
rgps
and
just
figure
out
why
the
time
stamps
are
screwed
up,
it's
probably
whatever
the
date
time.
D
Conversion
is
that's
happening
and
the
manta
rook
module
isn't
agreeing
with
whatever's
being
done
in
the
orchestrator
or
something
I'm
not
sure
exactly,
but
hopefully
that
one
isn't
too
hard
to
track
down
just
starting
with
our
mini
cube
environment,
going
into
the
sandbox
and
making
sure
those
commands
work
or
if
they
don't
work
tracking
down
with
the
looking
at
the
trace
back.
Hopefully
it
will
be
enough
and
then
we
can
move
on
to
rgw
from
there
and
the
rook
huddle
is
not
quite
done
yet.
D
Maybe
just
jump
over
there
really
quick
and
just
see
if
they
know
do.
We
know
who
the
right
person
to
talk
to
on
the
also
site
is
sebastian
han
gave
me
a
couple
names.
D
E
D
Okay;
okay,
not.
D
A
A
We're
done
yeah,
perfect
and
yeah
and
check
it
next
week.