►
From YouTube: Ceph Orchestrator Meeting 2021-08-31
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
Yeah,
I
think
sage
just
got
back
from
a
couple
of
weeks
being
up
and
maybe
he's
still
catching
up
on
other
things.
So
here
we
are
yeah.
On
the
topic
of
local
storage,
I
added
a
link
there
to
a
document
from
another
weekly
meeting.
We've
been
having
the
last
few
weeks
with
our
with
just
with
our
internal
ocs
team
around.
What
do
we
want
to
do
with
local
storage?
What
are
the
requirements.
A
And
but
oh
hey
sage,
I
don't
know
that.
I
have
a
lot
of
update
today
on
local
storage,
but
there's
a
link
to
the
notes
on
on
where
we
are,
but
maybe
it'd
be
good
to
talk
through
stage.
If
you're
interested
on
that.
C
A
A
Trying
to
think
what
the
what's
happened
in
that
time-
but
I
mean
to
summarize
in
my
mind
where
we
are-
is
that
the
for
dynamic
provisioning
top
lvm
seems
like
the
obvious
approach
to
start
with
yeah
and
base
things,
because
lvm
gives
us
things.
We
know
that
will
really
help.
They
don't
want
to
do
partitions
and
for
a
lot
of
reasons
for
dynamic
provisioning,
so
topple
lvm
looks
good
the
had
a
chat
with
satoru
and
they're
really
open
to
contributions
to
getting
new
maintainers
from
other
companies.
A
B
B
B
Okay,
I'm
just
looking
at
the
notes
here.
So
this
first
part
the
idea-
or
the
idea
is
basically
that
the
existing
total
vm
operator
could
reuse
some
of
the
lso
code
to
do
the
raw
device
discovery.
A
Yeah,
I'm
not
clear
really
what
what
that
is
there,
because
we
want
topo
lvm
to
work
in
the
same
cluster
as
like
lso,
so
we
can
get
the
benefits
of
static,
provisioning
and
dynamic
provisioning,
but
then
yeah,
which
one
lso
already
has
discoveries.
So
can
we
just
use
that
device
discovery
with
lso
and
have
a
new
operator
or
there's
this
top
lvm
operator
that
exists?
B
B
I'm
confused
about
the
the
this
idea
that.
B
C
B
A
Right
because
agreed,
if
you
have
dynamic
provisioning,
it
gives
you
all
the
flexibility
of
the
other.
I
think
there
are
two
advantages
in
my
mind.
One
is,
if
you
have
scenarios
that
only
need
day,
zero
provisioning,
then
lso
is
just
simply
just
define
it
and
you're
done.
You
never
need
diamond
provisioning.
And,
second,
if
you.
B
B
I
mean
the
first
one
is
basically
saying
that
it
works
now
without
any
work.
Right
like
that's,
that's
the
advantage
exactly
you
don't
have
to
you,
don't
have
to
implement
dynamic
provisioning
if
that
exhibition
and
you
have
it
already,
but
for
I
guess
what
I
understand
is
why
the
second
one
well
for
the
first
one
I
mean
that's,
not
an
argument
not
to
add
dynamic
provisioning,
it's
just
that
you
might
not
have
to,
but
for
the
for
the
lvm
piece,
why
not
just
implement
or
why?
B
Couldn't
you
implement
dynamic
provisioning
with
raw
devices
as
well
like
I
was.
I
was
assuming
that
we
would
have.
Basically,
you
would
have
like
two
storage
classes,
one
one
storage
class
would
be
or
lvs
or
like,
and
it
would
give
you
an
lvm
based
pv
or
whatever,
and
then
the
other
storage
class
would
be
a
raw
device
storage
class,
and
it
would
give
you
a
raw,
a
raw
device
and
both
would
be
controlled
by
the
same
operator
or
could
be
controlled
by
the
same
operator.
Right.
A
B
So
I
mean
there's
this
automate
vg
creation
thing
like
I
guess
I
would
assume
that
topo
obm
would
have
some
understanding
of
which
devices
it's
allowed
to
use
and
that's
maybe
that's
just
like
all
devices
whatever
it
is,
and
if,
but
it
wouldn't
do
anything
with
the
devices
initially
and
if
it
gets
a
request
for
a
raw
device,
it
would
find
one
of
the
raw
devices
and
it
would
give
it
to
you
and
if
you
released
it,
it
would
put
it
back
in
the
pool
or
whatever
the
reclaim
policy
says,
and
if
you
get
a
request
for
a
partial
device
like
an
lv,
it
would
either
look
at
one
of
the
existing
lvm
devices
and
put
it
there
and
if
it
doesn't
fit,
then
it
would
pick
a
new
grab,
another
full
raw
device
and
it
would
add
it
to
the
vg
and
then
put
the
lv
on
it.
C
C
If
we
want
the
entire
device,
then
we
could
tell
talkball
that
we
want
to
acquire
device
and
if
they
don't
really
want
to
change
the
logic
too
much,
then
they
could
simply
create
a
big
lv
on
that
device.
Instead
of
just
giving
us
the
roblox,
I
think
that's
also
an
option,
but
it's
it
has
a
downside.
C
I
guess
that
we
still
have
the
lvm
layer
on
top
of
it,
but
maybe
we
should
just
at
some
point
really
talk
with
the
lvm
team
and
see
if
there
are
really
issues,
I
guess
interacting
with
spm
through
containers,
because
that's
the
actually
the
biggest
problem
we
can
have
or
or
just
because
we
don't
like
having
another
layer,
because
another
layer
always
introduces
some
potential
problems,
but
there's
also
that
that.
B
Think
that
the
I
think
that
the
lvm
thing
is
is
a
little
bit
it's.
They
don't
have
quite
the
same
issue
because,
at
least
on
the
stuff
side,
the
problem
we
had
before
is
that
we
were
running
cyst
volume
and
we
were
creating
the
lvs
and
doing
all
that
work
inside
our
container
that
doesn't
mess
the
os.
B
That
same
problem
exists
on
the
topolovium
side.
I
guess
that
we
would
have
if
it's
doing
lvm
stuff,
it
would
have
to
make
sure
that
somehow
cooperating
with
the
host
version,
but
on
the
step
side
it
wouldn't
be
a
problem,
because
the
lb
would
already
be
pre-created
and
we
would
just
be
passing
it
through.
C
C
You
use
a
parameter,
and
then
you
say:
okay
when
we
use
that
storage
class
and
we
specify
that
vg,
we
always
get
the
entire,
like
the
full
size
of
that
vg
and
in
the
vg,
is
just
like
one
pb,
which
in
a
physical
volume
which
equals
just
one
disk.
That's
that's
also
one
plus.
B
I
think
that's
an
option
in
the
short
term
in
the
longer
term
that
that
won't
be
sufficient,
because
we
have
to
think
about
crimson
and
zns
devices,
which
won't
be,
which
won't
support
lvm
at
all.
Right
and
possibly
other
types
of
devices
might
come
into
play
like
if
we.
If
we
need
to
why.
B
B
B
I
mean
there
are
things
that
lvm
and
or
device
mapper
can
do
with
dns
devices,
basically
trying
to
create
a
standard,
looking
block
device
on
top
of
like
an
smr
zns
thing.
But
it's
not
working.
Oh.
B
B
B
The
only
difference
would
be
that
complete
devices
would
just
not
put
lvm
on
there
and
it
would
not
do
that
extra
setup
that
does
pass
as
an
ld
or
whatever
yeah
yeah.
I
think
it.
I
don't
know
that
it
might
be
a
little
bit
more
complicated
because
you
have
to
deal
with
two
classes
of
devices.
I
guess,
but
there
are
ways.
C
B
I
don't
know
yeah,
it
seems
like
we,
you
should
make
it
clear
what
the
like
end
goal
is
like
these
are
the
set
of
functions
that
we
want
and
make
sure
that
that
total
lvm
folks
are
sort
of
on
board
with
that
like
having
a
raw
mode
to
get
raw
devices,
for
example,
and
adding
the
discovery
into
topologium
and
moving
triplobium
into
the
work
project.
C
Yeah,
I
just
think
it's
a
huge
milestone
for
them
and
even
to
the
point
of
rebranding
like
topical
vm.
If
they
have
robot,
then
is
it
really
topology
anymore,
which
is,
I
guess,
like
not
a
big
concern,
but.
B
B
The
branding
part
isn't
necessary,
but
it
seems
like
it'd,
be
more
expedient
for
them
to
get
into
cncf
anyway
and
probably
get
them.
It
seems
like
this
will
get
the
more
users
I
guess
so
they
would
benefit
from
all
the
stuff.
A
A
A
B
A
That
does
well,
the
csi
driver
would
just
have
to
own
creating
the
or
adding
devices
to
the
vg's.
At
that
point
too
yeah
which
yeah
it
doesn't
do
today.
B
Yeah
but
yeah,
but
that
would
if
I
understand
right,
that
would
dovetail
nicely.
I
mean
that's
something
that
we
want.
It
should
do
anyway,
because
it's
otherwise
just
like
tedious
manual
stuff
that
users
have
to
do
and
you
don't
you
don't
want
that
right,
but
it
would
detail
nice
into
the
dynamic
provisioning
of
raw
devices,
because
that's
something
I
would
have
to
own
that
decides
that
this
available
raw
device
is
going
to
be
used
by
the
dynamic
things.
A
C
A
B
B
So
I
guess
your
afternoon,
travis
would
be
this
morning.
Yeah
my
late
afternoon
is
when
they're
waking
up,
but
it's
it's
around
midnight,
central,
european
or
yeah.
It's
european
time.
A
A
C
What
that
means,
so
we
should
also
investigate
that
a
little
bit.
A
C
A
A
C
But
yeah
okay!
Well,
we
also
have
to
think
if
the
topolo
vm
team
has
like
says
no
to
raw
devices,
there's
something
like
a
backup
plan
to
that,
because
it
is
kind
of
likely.
I
think
that
they
might
say.
No
really.
A
B
A
B
A
B
Yeah
I
have
a
hard
time
imagining
why
they
wouldn't
want
to
do
that.
I
guess
because
then
you
have
like
yeah,
you
do
all
the
things
and
then
it's
like
more
useful
and
it's
more
flexible
and
it
satisfies
more
use
cases
with
one
great
it.
It
seems
like
that.
Would
that
would
make
it
into
like
a
nice
rust
like
I
didn't,
want
anything
fancy
going
on.