►
From YouTube: Ceph Orchestrator Meeting 2022-02-15
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
That'll,
be
pretty
good,
I
mean,
I
know
the
main.
The
main
topic
today
is
the
manager
rook
stuff.
I
think
we
have
most
people
here
with
that
discussion.
At
least.
B
Yeah
yeah
with
this
topic,
I
think
there's
a
bunch
of
people
that
we
really
should
have
to
go
in
in
depth
around
it
from
dashboard,
like
you
said,
and-
and
I
didn't
get,
people
noticed
that
I'd
be
bringing
up
the
topic
here,
but
I
thought
I'd
give
it.
Maybe
we
could
give
a
preview
to
the
topic.
B
So
if
we
spend
time
briefly
on
it
today
and
cover
it
next
week
or
if
we
want
to
go
through
today
and
next
week,
I'm
open
or
call
a
separate
meeting
so
anyway,
so
I'll
give
an
overview
of
of
the
thoughts
around
this.
Unless
there's
any
other
questions
before
we
get
started.
B
All
right
I'll
go
for
it,
so
the
the
manager
module
for
rook
was
created.
You
know
three
or
four
years
ago
and
the
the
idea
behind
it
was,
of
course,
that
we'd
have
a
common
interface,
orchestrator
interface
to
work
with
the
different
orchestrators
and
now
we're
down
to
those
beings,
fadm
and
rook,
and
the
challenge
has
always
been
that
rook
when
running
on.
B
Kubernetes
really
does
things
differently
than
other
platforms
like
ceph,
adm
and
so
some
of
the
orchestrator
apis,
then
just
don't
don't
make
sense
for
rook
or
the
dashboard
may
need
to
have
a
slightly
different
experience
for
kubernetes
clusters
or
lots
of
questions
around
this.
So
the
question
is
what
what
should
we
be
doing
for
the
rook
manager
module?
Should
we
be
putting
effort
into
it
and
is
it
worth
it
or
is
there
maybe
a
different
approach
we
should
be
taking,
especially
with
dashboard
integration
and
there's
a
lot
of
questions
around
around
that
area?.
B
Because
this
was
kind
of
spurred
by
a
month
or
two
ago,
when
joseph
created
a
a
blog
and
he
was
about
to
post
the
blog
getting
feedback
on
it
about
the
manager
module
and
it's
joseph
here.
I
don't
see
him
today
so
and
nicely
written,
but
then
it's
like
wait.
Do
we
want
to
tell
people
about
the
rook
manager
module
because
you
know?
Is
it
really
supported?
B
What's
its?
Is
it
really
something
we
want
people
to
use
or
do
we
want
to
back
up
and
and
have
do
something
differently
and
not
and
not
officially
support
it?
Because
upstream
we
don't
see
people
using
it
really.
They
want
to
use
the
dashboard
for
many
scenarios
like
monitoring
but
they're,
just
not
using
it
for
things
that
they
can
use
the
crds
for
for
managing
their
desired
stake.
C
B
D
Probably
well
in
in,
in
any
case,
I
think
that
what
the
thing
is
that
is
being
recorded,
okay,
but
everybody
here
is
from
the
hat,
I
think,
just
to
add
some
some
points.
Okay
to
what
travis
has
pointed
at
us,
I
think
that
he
he
has
the
to
a
very
good
summary
in
in
the
document.
Okay,
but
well.
I
think
that
this
is
the
second
time
that
we
have
a
meeting
about
more
or
less
the
same
same
topic.
D
D
Okay,
and
I
think
that
the
the
the
main
problem
that
we
have
with
the
stator
mode
is
that
we
have
tried
to
to
to
follow
the
orchestrator
ap
okay,
and
what
we
have
found
is
that
the
environment
that
we
have
the
platform
that
we
have
behind
is
not
the
same.
It's
not
it.
It
is
not
compatible
with
the
same
happy
end
points
that
we
are
going
to
use
that
we
use
for
forcefidm,
okay,
the
orchestrator
ap,
the
the
beginning
of
this
orchestrator
and
the
design
of
the
ap
was
thinking
in.
D
We
want
to
have
a
common
ap
to
use
different
kind
of
tools
that
all
these
tools
are
going
to
act
over
a
platform
that
is
a
parameter
cluster,
okay,
with
access
to
the
device
to
the
to
the
hardware
and
and
the
infrastructure.
Okay
and-
and
the
problem
is
that,
okay,
the
the
state
already
could
be
valid
for
this
situation,
but
if
we
change
completely
the
the
end
platform,
in
this
case
using
kubernetes,
when
what
we
are
seeing-
and
this
is
something
that
is-
is
what
is
being
demonstrated
every
month.
D
The
first
problem
I
see
that
is
that,
for
example,
in
the
in
the
current
ap
we
are
there
are.
I
think
that
the
50
percent
of
the
effort
has
been
done
in
trying
to
provide
a
test
cluster
and
to
install
a
third
cluster
from
scratch,
and
this
is
something
that
is
completely
different
in
group
in
internet
environment,
the
governor's
environment.
D
This
is
done
using
a
crt
with
with
a
structure,
okay
and
the
people
that
wants
to
deploy
theft
clusters
in
kubernetes
environments
they
want
in
in
any
case,
what
they
want
is
something
that
could
make
easy
the
customization
of
this
file,
but
what
we
have
it
is
completely
different.
Okay,
because
our
approach
is
is,
is
thinking
that
we
have
behind
a
hardware.
There
are
an
infrastructure
cluster
that
is
different
from
what
the
platform
coordinates
platform
is
offering
us.
D
Second
part:
we
have
the
rest
of
functionality
for
day
two
operations.
Okay,
and
even
in
this
case,
things
are
very
different
because
in
fedm,
when
we
have
tried
to
to
go
to
to
provide
a
desired
state
of
the
things,
but
it's
a
decided
state
of
the
things
very
light:
okay
and
not
really
well
tested
okay,
so
we
are
not
in
the
same
state
that
we
can
found
in
government
as
clusters.
Incurrent
clusters
is
more
it's
more
easy
to.
D
D
So
again,
what
we
have
in
the
stator
now
is
something
that
is
not
similar
to
what
we
have
in
we're
not
discussing.
If
we
want
to
change,
for
example,
the
shape
the
the
kind
of,
for
example,
the
number
of
diamonds
of
this
type
or
change
the
configuration
is,
is
different
in
government
and
different
in
this
idea,
and
the
last
part
is
okay:
let's
go
to
the
part
of
management
commands
of
the
cluster
in
order
to
to
do
any
kind
of
theft
command.
Okay.
D
Well,
in
this
case,
we
we
can
simulate
the
functionality
in
both
places,
but
this
is,
I
think,
that
one
only
a
ten
percent
of
the
functionality
so
for
for
in
my
in
my
vision.
What
I
I
think
is
that
ninety
percent
of
the
functionality
that
we
are
providing
with
the
orchestrator
happy
is
not
valid
for
queerness
environment,
so
maybe
we
can
change
the
api
or
we
can
design
as
a
different
clause
in
order
to
to
make
happy
the
the
government
as
a
user.
B
Yeah,
I
agree
thanks
for
all
that,
and
I
I
think
the
way
I
would
summarize
it
too
is
we
want
every
orchestrator
to
be
fully
featured
so
step
adm.
We
want
fully
featured
rook
to
be
fully
featured
and
the
way
they're
they
get.
Their
features
is
just
fundamentally
different,
so
trying
to
treat
solve
them
both
with
the
same
api
is
just
proving
that
it,
it
just
doesn't
work.
Well,
it's
not
working
yeah.
B
E
D
Even
even
the,
for
example,
well,
jeff
has
started.
Sorry.
Jeff
has
started
with
me
no
document
about
two
years
old
document
about
some
flow
I'm
going
to
share.
I
think
that.
D
D
It's
about
well,
there
is
a
part
that
is
talking
about
a
flow
of
osd
creations.
One
me
that's.
D
C
D
A
D
Yes,
in
the
in
the
in
the
chat
is
only
the
league,
okay,
but
well.
What
I'm
saying
is
that
the
workflow
that,
in
this
case
is
offensive
people
is
is
suggesting,
is
completely
different
from
the
flow
that
we
follow
in
order
to
create
ost
in
theft
adm
with
a
with
parameter
infrastructure.
D
So
this
is
a
good
example
of
what
I'm
saying,
okay,
that
if,
if
we
want
to
go
ahead
with
that,
probably
we
need
to
be
focused
in
what
are
the
things
that
a
rook
user
could
would
be
happy
to
to
to
found
to
find
a
in
order
to
create
clusters.
Okay
and
how
to
to
add
the
requirements
class
that
user
to
create
the
the
theft
cluster
crd.
F
D
C
Throw
out
you
know
my
thought
process
very
abstractly,
you
know
I
mean
if
we
want
to
deploy
a
product
on
bare
metal
versus
cloud,
so
this
is
a
cloud
versus
bare
metal.
I
think
a
lot
of
what
we're
talking
about
is
probably
cloud-based.
A
lot
of
the
workflows,
don't
make
a
heck
of
a
lot
of
sense.
I
agree
100,
but
if
someone
wants
to
deploy
a
product
on
kubernetes
on
bare
metal
which
again
upstream
community
a
standalone
product
on
bare
metal,
I
mean
with
kubernetes,
is
probably
questionable,
I'm
not
sure
if
the
market
will
transition.
C
If
it
does,
then
would
they
want
the
ability
to
control?
You
know
the
kind
of
level
of
drive.
You
know
configurations
that
we
do
today
in
the
standard,
dashboard
environment.
I
would
think
the
answer
would
be.
Yes,
in
my
opinion,
and
you
know
I
think,
we're
seeing
an
example
of
that
with
something
else
that
is
showing
that
that
is
a
desire.
You
know
you
know,
so
that's
all
I
mean
so
travis.
What
do
you
think
of
that
is
that
you
know
something
we
should.
You
know
is
that
how
does
your
thought
process?
C
B
Right,
well,
I
mean
ideally,
I
definitely
agree
that
you
know
whether
you're
in
rook
or
wherever,
using
this
dashboard
you'd
like
you'd,
like
your
experience
to
be
in
the
ui
people
like
ui,
better
than
command
line
or
yaml
files
or
whatever
for
sure
the
to
me
it's
more
of
a
maybe
a
resource
question
like
do.
B
We
have
resources
to
to
dedicate
to
this
to
make
it
a
good
experience
in
the
dashboard
and
and
interface
well
with
rook
and
design
it
around,
because
I
think
we
have
to
design
it
around
rook
instead
of
saying
stuff,
adm
and
rook
will
look
the
same
right,
yeah
and
so.
C
And
that
was
our
ultimate
goal
and
that's
why
we
had
that
rook
manager
to
be
compatible
with.
I
had
someone
over
there
working
on
it
until
we
had
another
priority,
we
had
to
move
them
off
for
a
little
bit.
I
always
intended
to
move
someone
back,
I
mean
so
it's
like.
I
think
it's
a
you
know,
and
that
and
that's
the
reason
why,
for
these
kinds
of
environments,
right
I
mean,
and
if
we
forget
them
now,
we
forget
that
tool.
Now,
then,
I
think
we
have
a
problem.
B
Yeah
another
point:
I
was
going
to
bring
up
here's
a
link
to
the
ceph
docs
that
show
the
comparison
of
rook
to
sephadm
with
the
orchestrator,
and
it
just
I
mean,
even
though
rook
and
sepia
dm
are
both
what
I'd
call
fully
featured
like
the
rook
column.
Just
like
looks
like
it
doesn't
work
right,
so
maybe
just
because
it
doesn't
a
lot
of
those.
Don't
apply.
C
B
D
Or
or
maybe
even
even
remove
completely
the
the
column
for
rook.
Okay,
if
we
reach
the
conclusion-
or
we
accept
that
the
group
manager
module
is
not
an
orchestrator,
it's
a
provider
of
functionality
of
the
rook
operator.
That
is
a
completely
different
thing.
Probably
it
has
no
sense
to
have
this
column
here,
because
what
this
this
table
in
italy,
this
table
was
told
in
order
to
compare
the
different
orchestrators,
the
fidm
and
civil
ssh.
D
It
was
a
salt.
I
think
that
for
sushi
okay,
it
was
several
tools
in
order
to
start
test
clusters,
environmental
environments,
but
at
the
end
the
only
orchestrator
available
is
definitely
and
what
we
are
comparing
is
rook.
They
something
that
we
we
wanted
to
to
become
an
orchestrator.
That
is
the
root
variable
model.
D
F
Should
one
of
the
first
steps
be
to
start
kind
of
looking
at
the
functionality
group
by
group
and
saying
hey
this
bucket?
This
actually
works
for
both
this
bucket.
Maybe
if
you're
talking
bare
metal
and
discs
this
bucket,
you
know
service
management,
maybe
that
doesn't
work.
You
know
kind
of
trying
to
group
it
into
areas
of
functionality.
D
D
I
think
that
nobody
is
going
to
change
this
configuration
using
the
orchestrator
the
thing
whoever
enters
the
the
rook
operator
users.
What
they
are
going
to
do
is
to
change
the
cluster
crt
or
to
patch
the
cluster
crd,
but
they
are
not
going
to
do
the
operation
using
aptly
mode
from
the
stator,
because
they
are
going
to
lose
the
control
and
they
are
going
to
what
not
to
have
no
idea
about
what
is
the
configuration
of
monitors
in
the
in
in
the
root
cluster.
D
G
Seems
to
me,
like
the
use
case
I
mean
talking
out
of
the
ignorance,
seems
to
me,
like
the
use
case
in
the
kubernetes
environment
is
very
different
from
the
bare
metal,
and
we
are
trying
like
to
imitate
the
same
support
on
safe
adm
on
the
rock
side
when
sometimes
it
doesn't
make.
Even
it
has
no
sense.
C
But
this
is
where
I'd
ask
questions
yeah
in
the
long
run,
if
people
want
to
deploy
standalone
products
on
kubernetes,
is
it
missing
functionality
that
they
need
in
the
long
run?
For
you
know
the
the
drive
you
know
drive
caching,
all
the
you
know
ssds
and
nvmes
for
this
ssds
for
this
tiering
I
would
think
yes,
you
know
so
is
rook
going
to
be
deployed
on
bare
metal.
You
know
kubernetes
on
rook,
you
know
with
rook
on
bare
metal
if
it
is,
and
we
want
to
have
a
stand-alone
product
built
on
that
in
the
future.
C
C
D
Is
it
right?
The
problem
jeff?
Is
that
what,
for
the
moment
uses
in
kubernetes
environments,
they
want
to
do
the
things
taking?
What
using
crds,
okay
and
jammer
files
in
order
to
configure
their
products,
because.
C
They're
deploying
on
cloud-
and
they
don't
need
that
level
of
control.
You
know
they
don't
have
to
configure,
they
don't
have
to.
You
know,
optimize
their
appointments.
If
we're
going
to
get
there
and
we
need
to
get
there,
then
taking
this
away
is
not
going
to
allow
that
we'll
need
another
mechanism
to
do
it.
You
know
we
have
something
today,
the
intent
was
that
that's
all
I'm
saying
I
mean
is
that
am
I
missing
something
I
mean.
Wasn't
that
what
it
was
all
about.
C
Yeah
because
I
mean
because
you're
going
to
want
to
users
to
be
able
to
configure
and
control
or
they're
going
to
want
to
go
through,
you
know
the
cli.
The
cli
will
still
need
some
type
of
you
know
api
as
well,
and-
and
you
know
so,
is
it
that
same
api
like
it
uses.
You
know,
cdm
today,
correct
me
if
I'm
wrong,
the
cli
goes
through
that
that
you
know
manager
as
well
correct.
So
it's
like
so
it's
I'm
just
saying
I
mean
you
know:
do
we
wanted
I'm
just
bringing
up
that
point?
C
We
we
aren't
there.
Will
we
get
there?
I'd
say
yes,
that
was
a
you
know,
some
desires
around
that
you
know,
and
you
know-
and
I
think
the
upstream
will
get
there
eventually
you
know
so
when
they
do
then
we'll
have
to
reinvent
this
I
mean
that's,
you
know.
So
I
I
don't
know,
that's
that's.
That's
my
two
cents
I'll
shut
up.
B
So
but
then,
as
far
as
cli,
I
don't
think
we'd
want
to
document
the
cli
in
the
rook
docs,
even
if
it's
available
just
because
we
would
tell
people
to
go,
use
the
crds
directly
instead
like.
Why
would
we
tell
them
to
go
use
the
toolbox
to
do
this
if
they
can
just
do
it
with
the
crds
and
and
have
more
control
over
it
that
way,
but
for
dashboard
integration?
D
B
Specific
to
a
rook,
only
module
that
doesn't
apply
to
fadm.
In
that
case,
even
that's,
I
guess
an
implementation
detail
that
might
or
might
not
be
in
a
common
api.
G
G
You
shouldn't
like
be
providing
different
functionality
for
staff.
If
you
have
kubernetes
it's
like
a
deployment
or
bare
mirror,
that
would
be
very
confusing
to
use
the
same
interface
and
end
up
with
a
different
behavior
depending
if
you
are
deploying
on
bare
mineral
or
if
you
are
interplaying
kubernetes,.
G
B
I
think
what
kamigail
and
I
are
saying,
is
that
we,
since
they
are
very
different
platforms,
bare
metal
or
kubernetes
the
the
ux
around
it
will
fundamentally
need
to
be
different.
Sometimes
it's
not
always
going
to
be
the
same.
Ux
like
how
to
configure
nodes
like
you,
you
if
you
want
to
configure
nodes
and
kubernetes.
Well,
you
you
need
to
go
to
the
kubernetes
dashboard,
and
why
would
we
expose
nodes
even
at
all,
in
the
seth
dashboard
or
node
configuration,
for
example?
B
D
But
we
cannot
do
that.
Okay,
we
can
try
to
make
things
easy,
but
in
one
of
the
things
that
is
important,
okay-
and
I
think
that
the
final
user
is
is
completely
aware
of
that.
Okay,
it's
about
what
is
the
environment
that
you
have?
Okay,
for
example,
you
can
implement
a
steering
wheel:
okay
and
the
steering
wheel
is
the
same
in
a
car
and
in
a
boat,
okay,
but
obviously
the
people
that
is
driving.
F
A
G
I'm
thinking
on
the
thing
from
the
point
of
view
not
only
of
the
user,
but
the
implication
for
us.
Imagine
that,
like
you,
have
to
create
a
different
documentation
for
everything
that
has
to
do
with
rook
and
have
like
a
part
of
documentation,
and
that
means
like
documentation,
training
and
everything
will
be
different
for
build
metal
if
we
can
have
like
the
same
interface
for
both
products,
regardless
of
the
the
deployment
environment
bare
metal
of
kubernetes.
D
F
D
D
G
I'm
not
talking
about
like
the
implementation
details,
I'm
talking
about
like
the
interface
to
provide
to
the
user.
If
we
have
to
do
things
differently
like
behind
the
scenes
to
make
it
behave
simpler,
then
that
would
be
more
work
for
us
in
the
implementation,
but
less
work
for
us
in
the
long
term.
From
the
maintenance
point
of
view.
D
Not
all
the
operations
that
you
need
in
a
parameter
environment
are
needed
in
the
government's
environment,
for
example,
what
we
have
commented
about
the
day,
one
operation,
installation
of
the
cluster-
in
order
to
install
the
cluster
with
fdm.
You
have
a
lot
of
steps
in
order
to
wait
to
include
the
up
nose
to
prepare
the
nodes,
so
we
start
fvdm
to
to
and
to
start
to
to
create
the
fixed
monitor
fees,
manager
and,
after
that,
all
the
all
the
rest
of
diamonds
in
the
kubernetes
cluster.
This
is
completely
different.
D
It's
only
one
file
that
is
with
all
the
definition
or
of
all
the
cluster.
What
what
do
you
want
to
have
in
the
cluster?
And
you
upgrade
that
that
file
that
crt?
So
it's
very
different
the
day,
one
operations
that
we
have
in
a
parameter
environment
and
in
aquarius
environment?
So
all
the
operations
that
we
have
for
this
this
use
case
are
not
valid.
G
F
G
B
Even
that
that
day,
one
just
deploying
your
cluster
even
to
bring
the
dashboard
up
there
there
there
options
you'd
have
in
kubernetes
that
you
don't
have
in
staff
adm
like
yeah,
specifically
creating
pvs
pvcs.
Do
you
want
to
run
your
storage
on
some
dynamically
provisioned
storage
behind,
like
if
you're
running
in
the
cloud
just
tell
us,
which
the
name
of
the
storage
class,
which
is
only
a
kubernetes
concept
right?
B
And
if
you
tell
us
the
storage
class,
then
we'll
go
provision,
the
storage
for
mons
and
osds
on
that,
and
then
you
don't
even
need
you
know.
It's
not
bare
metal.
There's
no
dis,
just
statically
available
like
they're
dynamically
provisioned,
but
I
mean
that
specific
scenario
is
very
unique
to
the
kubernetes
cloud,
but
and
that
pattern
also
applies
to
bare
metal
with
kubernetes.
You
just
have
a
different
storage
class
and
pv
provided.
G
I
mean
like
if
we
can
have
like
this
different
specific
stuff
like
isolated
and
well
documented
like
in
the
dashboard
okay.
So
if
you
are
installing
for
kubernetes
for
sorry
for
rook,
we
have
like
some
new
functionality
and
dashboard
that
you
can
use,
but
the
other
functionality
is
the
same
for
perfect.
I
mean
this
is
okay,
have
something
different
and
it's
well
documented.
The
users
who
use
this
virtuality
will
go
there
and
use
it,
and
the
other
user
should
shouldn't
care
about
it
because
they
will
just
not
use
it
or
they
will.
G
D
The
the
problem
is
that
the
flow
is
completely
different
and
what,
when
it's
user,
expects?
My
my
view
is
completely
different
of
what
we
have
in
this
moment
in
the
in
the
task
in
order
to
creation
of
the
cluster.
When
we
are
talking
about
creation
of
the
cluster
for
other
operations,
for
example,
user
management,
or
you
want
to
create
to
the
data
pool
okay
or
this
kind
of
things.
I
think
that
is
exactly
the
same.
D
Okay,
we
can,
we
can
do
exactly
the
same
flow,
but
for
day
one
operations,
the
flow
is
completely
different
and
if,
for
example,
for
creating
osds,
what
is
expected
in
in
a
kubernetes
environment
is
to
have
a
possibility
to
define
or
to
or
to
use
a
storage
class
storage
classes.
D
Okay,
and
this
is
something
that,
if
you
do
not
provide
this
possibility
to
the
to
the
final
user,
the
final
user
is
going
to
be
completely
confused
about
what
is
doing
the
the
dashboard
in
order
to
create
osd
so
in
in
in
in
the
case
of
creation
of
osds
and
deploying
of
the
the
physiologist,
the
the
startup
cluster,
okay
and
even
creation
of
services.
What
is
the
configuration
of
the
cluster?
I
think
that
the
flows
are
very
different
and
probably
we
will
need
to
change.
D
Also
the
look
and
feel
that
we
have
in
the
dashboard
in
order
to
make
it
more
friendly
for
kubernetes
users
and
to
understand
better
what
is
happening.
Okay,
this
does
not
mean
maybe
well
I
I
think
that
probably
we
are
going
to
to
share,
I
think
50
40
percent
of
the
orchestrators
ap
in
the
root
manager,
module
and
in
the
theft
avm
model,
but
the
problem
that
we
have.
D
D
C
Well,
you
know
we
have
to
look
at
the
desired
workflows.
What
we're
trying
to
accomplish
you
keep
saying
you
know
no
on
day
one,
but
I
think
we
still
have
to
look
at
that
what
it
means
you
know
we're
deploying
kubernetes
on
bare
metal.
You
know
what
kind
of
control
do
you
want
from
a
drive
selection
perspective
and
you
know
resource
perspective.
You
know
we
don't
have
you
know
that
today
probably
well,
we
do,
I
guess,
but
in
a
different
form,
not
through
the
dashboard.
C
C
Oh
great
great,
so
I
mean
yeah,
we
have
a
lot
of
you
know,
so
is
it
you
know?
Is
it
premature
to
you
know,
go
change
what
we
have
or
just
wait
till
these
things
evolve
a
little
bit
more.
I
mean
I,
you
know,
you
know,
no,
no,
no
harm,
no
foul,
it's
not!
You
know.
If
it's
not
no
one's
calling
it
you
know.
Dashboard
is
the
only
thing,
that's
calling
it.
I
mean
at
this
point
I
mean:
does
it
confuse
people
it
could
I
mean
you
know,
that's
something.
That's
hanging
out
there.
F
B
World
the
dashboard
would
be
able
to
do
everything
with
rook
too,
but
in
reality
you
know
I'd
say:
let's
prioritize:
what
scenarios
are
important
to
rook
users
from
the
dashboard
and
I'd
say
if
day,
two
experiences,
monitoring
and
and
some
you
know,
basic
configuration
that
yeah
day
two
and
then
as
a
lower
priority.
It'd
be
nice
to
get
to
day
one
someday,
but
maybe
you
know
just
maybe
we
won't
get
there.
Maybe
or
maybe
we
will.
E
G
And
I
mean
in
general
we
never
could
make
it
like.
Not
I'm
not
talking
about
implementation,
I'm
talking
about
like
the
user
experience
from
the
outside.
Whenever
I
make
it
more
similar
the
usage
for
both
scenarios,
it
will
save
us
more
time
for
everything
for
documentation,
for
training,
for
people
like
transitioning
from
bare
mineral
to
the
kubernetes
like.
If
we
make
it
similar,
then
the
users,
if
we
ask
them
at
some
point
like
okay.
G
Now
it
is
more
recommendable
like
to
use
kubernetes,
then
it
will
be
more
easier
for
them
to
go
and
use
the
new
environment
because
they
don't
have
like
to
change
their
mind
to
change
their
to
change
the
interface
change,
everything
they
are
already
used
to
and
to
start
like
using
something
newly
because
whenever
the
users,
whenever
there
is
some
change
interface,
the
user
normally
starts
like
claiming
about
everything
that
that
that
is
new.
So
we
never
make
it
whenever
we
make
it
easy
for
the
user.
H
I
I
think
what
we
have
seen
with
the
rook
upstream,
is
that
that's
like
like
that,
is
the
the
intention
behind
why
the
orchestrator
module
was
developed.
But
that
is
not
the
case
of
the
real
world.
People
who
are
on
kubernetes
don't
take
a
set
storage,
specific
viewpoint
on
their
storage.
They
take
a
kubernetes
centric
view
of
their
kubernetes.
Cluster
and
storage
is
only
a
small
part
of
it.
So,
like
the
orchestrator
is
a
very
self-focused
like
piece
of
design,
but
in
the
kubernetes
world,
people
don't
really
want
that.
H
We
have
found
like
for
day
two
operations
like
that.
Those
things
are
helpful,
but
for
deployment
like
for
actually
modifying
like
the
the
crds
they
they
they
use,
kubernetes
tooling,
for
that
so
like
I,
I
think
we
have
to
like
really
consider
like
what
are
the
users
who
are
actually
benefiting
from
the
sentiment
of
a
storage
specific
like
similarity
there
and
like.
Are
there
enough
of
those
users
for
us
to
to
really
put
in
the
effort.
C
Yeah
yeah
and
that
question
goes
right
back
to:
where
does
the
business
businesses
go
because
it's
an
upstream
conversation
where
do
they
want
to
go?
Do
they
want
to?
You
know,
have
a
replacement
of
their.
You
know
standalone
products
with
this
technology.
If
they
do
do,
they
still
need
the
same
levels
of
control.
I
think
we're
way
ahead
of
that,
probably,
but
I
mean
at
some
point
we'll
get
we'll
probably
get
there.
You
know
it's.
G
H
There's
not
a
lot
of
like
standard
things.
There
are
I'm
sure
travis
also,
like
can
remember
some
names.
The
big
one
I
can
think
of
is
ranchers
longhorn.
I
think
that's,
what's
called
longhorn,
which
is
a
block.
Only
storage,
there's
also
like
mineo,
for
I
think,
object,
storage.
A
H
There's
like
cockroach
db,
for
like
a
like
there.
There
are
several
databases,
I
think,
and
then
there
are
some
closed
source
black
solutions
as
well.
B
Yeah
there's
lots
of
competitors
for
sure
before
deploying
ceph
and
kubernetes,
though
I
mean.
G
G
This
way,
if
the
users
transition
at
some
points
to
safe,
it
will
be
much
easier
for
them
like
this
is
the
same
thing.
Podman
people
do
with
docker,
it
just
provided
the
same
interface.
So
if
you
want
to
transition,
you
don't
have
even
to
you
know
the
main
page
you
just
put
an
alias
and-
and
you
are
good
to
go,
but
if
there
is
no
competitor
in
this
area,
then
we
have
more
freedom
in
at
least
like
design
how
the
users
will
use
the
storage
in
this
kind
of
environment.
F
Yeah,
that's
kind
of
the
point
of
the
whole
custom
resource
thing
to
begin
with,
which
is
like
no
one's
gonna
be
exactly
the
same.
The
kubernetes
people
have
realized
that,
and
now
it's
like
okay,
you
can
define
your
own
custom
resource
definitions
to
fit
your
use
cases,
there's
the
standard
interfaces
for
things
like
pv
pvc
that
covers
the
stuff
that
is
expected
to
interoperate
and
then
you're
left
to
do
whatever
you
want.
E
C
I
I'd
just
be
curious,
michael
I
mean
you
know
is
what
does
susan
talk
about
when
they
discuss
these
things?
You
know
from
an
upstream
perspective.
C
C
By
your
level
of
control,
is
it
very
you
know,
are
you
are
you
you
know
looking
at
you
know
those
really
tight
levels
of
control
where
you're
allocating
things
or
is
it?
You
know
you're
doing
it
from
a
kubernetes
current
method.
Are
you
thinking
of
other
things?
I
mean
I'm
just
curious.
If
what
you
could
talk
about,
if
anything,.
I
C
I
The
underlying
theme
becomes
that
yeah
yeah
little
new
deployments
and
just
kubernetes
type
native
things
to
play
longhorn
there's
another
project
going
on.
I
think
aquarium
that
you've
seen
and
that's
investigating
how
we
can
better
integrate
staff
in
some
of
these
kubernetes-based
things,
but
that's
pretty
early
in
development.
C
Okay,
interesting
to
see
what
they
think
as
well.
I
mean
yeah
still
the
same
people
on
it.
We
could.
We
could
chat
with
them
if
need
be,.
D
I
D
Decide
to
use
testing
kubernetes,
probably
they.
I
think
that
they
are
going
to
use
the
recoverator.
I
No,
not
necessarily
we
don't
really.
We
have
a
little
bit
of
that
from
the
old
says.
Susan
enterprise
storage,
based
deployments.
E
A
So
I
think
the
sort
of
important
thing
I
think
was
brought
up
earlier
is
sort
of
finding
who
actually
needs
this
and
what
do
they
need
to
work
in
between
the
common
things?
I
know
off
the
top
of
my
head:
it's
mostly
just
the
dashboard
that
I'm
worried
about.
When
we
talk
about
this
common
api.
A
I
know
I
think
it
seems
like
there's
not
a
ton
of
crossover
in
users
from
kubernetes
clusters
to
the
bare
metal
clusters
right
now.
Anyway,
I
was
hoping
there
would
be
someone
from
the
dashboards
here.
I
don't
have
anyone
here
right
now
and
basically
thinking
about
how
deprecating
this
could
affect
them,
but
I
also
know
there's
an
issue:
I
don't
know
the
details
of
it
with
something
with
consistency
between
making
changes
in
the
dashboard
and
making
changes
with
the
crds
directly
in
rook.
A
A
I
don't
know
I
mean
from
my
point
of
view,
if,
if
rook
really
feels
like
there's
not
enough
sort
of
common
operations
that
we
we
want,
this
api
to
sort
of
be
between
us
and
we
can
get
it
in
a
state
where
the
dashboard
is
happy
with
it.
We
can
so
then
we
really
have
no
reason
to
sort
of
worry
about
manager.
Rook,
that's
just
my
viewpoint.
Basically
again,
I
just
feel
like
we
need
to
dashboard
people
and
make
a
sort
of
final
decision
on
this.
A
I
think
they're,
the
main
people
who
would
be
affected
by
having
or
not
having
a
common
api.
B
I
think
that
yeah
I
mean
agreed,
I
don't
want-
and
I
think
it's
all
about
what
is
that
makes
sense
for
what
makes
sense
for
the
dashboard
in
rook
scenarios,
and
so
that's
that's
really
the
long-term
discussion
they
have.
What?
What
do
we
want
to
focus
on
in
the
dashboard
for
rook
then,
and
I
would
say
day,
two
scenarios
have
higher
priority
and
day
one
we
even
potentially
take
off
the
table
for
now,
but
we
need
to
talk
with
dashboard
folks.
D
A
Other
than
that.
I
don't.
If,
like
brooke,
is
it's
easier
to
use
without
the
orchestrator
api,
then
I
don't
see
any
reason
to
support
all
these
extra
things.
The
dashboard
also
doesn't
need,
as
if
there's
not
a
lot
of
crossover
users.
There's
no
there's
no
reason
to
have
a
common
api
unless
the
dashboard
needs
it
for
something.
C
C
Where,
where
do
we
want
to
be,
you
know
where's
the
puck
going
to
be,
and
you
know,
for
you
know
four
quarters
so.
B
C
B
G
C
Where
we
need
to
be,
you
know,
and
I
don't
think
everyone's
there
and
you
know
the
yeah
and
I
don't
think
we
will
be
there
until
it
falls
in
our
lap.
But
that's
just
a
differing
opinion
as
well.
So
right.
C
Ernesto
the
people
that
own
the
code,
just
like
just
like
you,
they
you
know
they
only
they're
in
control,
so.
A
A
So
maybe
we
had
to
organize
a
separate
meeting,
mostly
between
the
dashboard
and
the
brook
team,
and
I
guess
some
people
inceptivity
and
themselves
should
be
there.
This
relevant
orchestrator
talk
about
this
specifically.
A
Okay,
is
there
anything
else
we
want
to
go
into
in
this
topic
for
today,
there's
everybody
in
a
good
spot
here.
A
All
right,
yeah,
thanks
everyone.
There
was
one
other
topic
I
had
on
the
agenda:
there's
only
five
minutes,
so
I
think
it's
not
long
enough
to
go
into
it.
A
Does
anybody
have
anything
quick?
They
want
to
sort
of
bring
up
here
before
we
end
the
meeting
off.
A
All
right,
in
that
case
thanks
everyone
for
coming
and
see
whoever
wants
to
show
up
next
week,
we'll
see
you
next
week,
bye.