►
From YouTube: Ceph Orchestrator Meeting 2021-08-03
Description
B
Yeah
francesca
so
yeah
thanks,
so
basically
in
the
ospci,
we
are
using
this
as
fantable
style,
the
our
tribal
ansible
roles
to
deploy
7fs
instead
of
using
cipherdm,
and
we
are
basically
creating
the
systemd
unit
and
starting
it
using
the
container
provided
by
ceph
the
things
we
we
found
while
we
were
trying
to
promote
the
pacific,
beats
to
the
16
to
5
released.
Recently,
we
found
that
cfnfs
is
not
starting
anymore,
and
it's
probably
because
this
new
container
build
is
based
on
the
demon
based
image
instead
of
the
demon
image.
B
This
means
that
the
docker
file
has
no
entry
point
at
the
end
and
the
start
nfs
bash
script
isn't
called
this
means
that
when
you
run
the
system,
the
unit,
the
the
the
container
image
exits
without
any
log
or
issue,
because
there's
no
issue
actually
it's
just.
There
is
no
entry
point,
because
it's
a
demon
based
image
used
for
core
demons
and
that's
yeah.
So
this
means
we
cannot
use
the
core
demon's
image
for
osp.
C
D
Yeah
yeah.
B
D
D
C
Yeah
on
this
nfs
topic,
we
were
talking
about
keeping
those
around
or
at
least
doing
things,
the
old
way
for
stuff
at
nfs.
Until
we,
if
you
recall
this,
adm
def
nfs
discussion,
for
you
know
a
future
version
of
openstack.
C
Do
we
wrap
keeping
those
old
images
into
part
of
the
original
agreement
where
we're
standing
up
cepha
nfs,
basically
using
some
ansible
calls
and
we're
going
to
move
to
the
new
way
right.
So
can
we
can
use
the
old
stuff?
Should
we
then
keep
the
old
stuff
until
we
can
move
wrap
it
into
that
understanding?.
D
Yeah
did
I'm
not
I'm
I'm
missing
where
the
the
old
ones
went
away,
did,
aren't
they
still
being
published
on?
Are
they
just
not
on
clay
they're?
Only
on
docker.
A
They
should
be
on
client.
I
just
pasted
the
link
here
in
the
the
bluetooth
instead.
B
B
So
but
I
mean
six
zero
four
sounds
like
it's
an
old
image
that
doesn't
know
the
new
beats.
We
backported
to
pacific,
for
example,
the
safe
dashboard
ep
addresses
and
parts
binding.
We
recently
added,
I'm
not
sure
it's
there.
A
C
B
C
So
we
have
two
container
formats
or
or
two
you
know
two
types
of
of
containers
and
for
seven
fs.
We
need
the
entry
point
which
the
new
container
format
doesn't
have
we're
doing.
We
intend
to
do
seth,
nf
s
which,
for
which
we
could
use
the
new
containers,
but
we're
not
ready
to
do
cephenfest
the
new
way
yet,
so
we
need
a
plan
to
get
us
by
until
then
it
was
suggested.
C
We
continue
to
use
the
old
containers,
we're
just
concerned
about
getting
new
builds
for
them,
in
other
words,
the
old
container.
If
we're
going
to
use
the
old
containers,
they
would
need
to
be
maintained
for
a
little
longer.
E
As
them
as
I
know,
actually,
the
six
dot
o
dot
x
series
will
continue
to
be
maintained
because
stephanie,
but
still
use
it
for
switching
to
safe
adm.
So
you
will
have
new
reviews
for
that.
E
Okay
and
you
have
actually
6.0.4,
which
is
the
latest
one
based
on
60.
E
I
should
mention
is
that
we
will
probably
drop
this
container
past
pacific,
because
second
symbol
is
not
supposed
to
be
used
after
that,
and
we
will
have
only
the
theft
images
so
frequency
we
will
probably
we
won't
have
these
images,
but
from
a
triple
o
perspective,
I
don't
see
why
you
could
not
change
the
7fs
form
to
use
the
set
image.
C
I
mean
we
do
have
a
plan
to
move
so
that
manila
would
call
would
interface
with
fading
and
we,
but
until
then
we're
sort
of
doing
things.
The
way
we
did
them
with
stephanie
just
having
triple
o
ansible,
call
that
instead,
I
don't
know
francesco.
If
you
want
to
look
into
twitching
that
so
you
can
use
the
new
container
or
if
you'd,
rather
it
sounds
like
we're
going
to
have
the
pacific
containers
for
a
bit
longer.
As
long
as
we
can
get,
I
think
we
gave
up
the
right
way.
B
We
we
agreed
at
the
beginning
to
avoid
having
big
changes
in
terms
of
ansible,
because
manila
has
a
plan
long-term
plan
to
move
into
the
sephidian
style.
So
the
agreement
was
that
we
can
just
keep
the
sensible
style
approach
to
deploy
itself
nfs
and
we
can
keep
using
the
demon
image
until
the
the
new
manila
part
is
ready.
B
E
B
C
It's
like
we
lose
the
benefit
of
the
existing
testing
it
could
it
could
drift,
but
that's
one
risk
where
you
know
what
I
mean
it's
one
thing
we
got
to
look
out
for,
but
today
it
works,
fine
and
therefore
we'd
only
use
one
container.
I
really
don't
want
to
introduce
two
containers
for
our
users
to
you
know
for
the
triple
o
user
to
deal
with,
like
the
ceph
nfs
deaf
container
versus
the
regular.
A
At
least
for
this
fci
we
are
not
really
building
the
demon
containers,
because
that's
only
something
for
ansible,
so
we
can't
really
test
the
daemon-based
containers
the
demon
containers
in
in
totality,
but
as
as
long
as
those
demon
containers
just
add
stuff,
like
shell
scripts
and
an
entry
point
and
stuff,
I
don't
see
the
danger
of
them
breaking
or
developing
too
much.
E
Just
for
your
information,
the
demon
image
is
based
on
the
demand
based
image,
which
is
the
same
that
than
set
set.
So
it's
just
a
layer
on
top
of
the
binary
on
the
container
image
and
which
adds
a
shelf
script
and
stuff
like
this.
So
the
base
will
be
tested
by
safe
adm
and
the
sephora
chipset.
I,
the
demon
part,
will
be
tested
by
stephan
sibo,
at
least
for
pacific.
C
G
B
So
we
can
just
use
six
zero.
Four,
as
the
latest
stable
pacific,
released
content
right
right.
D
G
All
right,
I
just
have
a
maybe
a
quick
update
there,
but
maybe
some
more
discussion
we
could
have
so
taking
the
requirements
pad
that
we
talked
about
before
and
had
been
written
up
meeting
with
lso
on
friday.
They
said
hey.
Can
we
just
get
a
google
doc
where
we
can
collaborate
more
on
this
on
the
requirements
and
just
be
clear
about
everything
in
a
place
we
can
discuss
it.
G
G
So
yeah
I've
already
had
feedback
from
sage
and
said
so,
thanks
for
that
and
I
think
we'll
we
haven't
shared
it
with
the
lso
team,
yet
just
want
to
make
sure
we
have
our
own
internal
thoughts,
clear
on
the
topic
and
then
we'll
get
back
to
them,
hopefully,
on
friday
by
friday.
We'll
share
this
talk
with
them.
I
think
we
think
it's
ready.
G
Otherwise
I
mean
there's
still
big
questions
about.
Is
it
lso?
Is
it
topol
lvm?
Is
it
something
else
I
have
not
caught
up
yet
with
subterror
from
topo
lvm
just
been
really
focusing
on
the
1.7
release
this
week,
so
that's
due
out
by
tomorrow,
it's
looking
like,
then
I
think
more
focus
will
turn
into
this.
G
Right
yeah,
we
in
that
dock.
It
covers
that
too,
like
we
want
it
to
be.
An
upstream
project
needs
to
be,
you
know,
so
the
community
can
contribute
kubernetes
first
and
then
yes,
we'll
take
it
downstream
as
part
of
the
product,
but
not
streaming
upstream.
First.
G
E
F
F
D
The
only
update
for
my
end
is,
I
have
a
short
meeting
with
duncan
scheduled
for
thursday
just
to
touch
page
with
him.
F
So
we
were
like
just
trying
to
circle
back
as
well,
but
yeah
hammond
said
he
wasn't
pto,
because
we
do
also
have
some
customer
stories
for
sure.
So,
hopefully
that
helps
to
bump
priority
in
this
yeah.
D
A
D
I
think
my
question
is
just
what
is
next,
I'm
trying
to
decide
what
I
should
be
working
on
for
the
next
couple
of
weeks,
wondering
if
I
should
start
looking
at
smb
or
if
I
should
switch
to
something
unrelated
could
do
the
smr
stuff
at
blue
store
or
whether
you
should
look
at
the
agent
stuff.
A
Currency
and
beyond,
at
least
by
default,
at
least
for
at
least
for
sister
right.
D
D
G
Right
yeah
for
crimson,
so
the
so
it's
a
different
build
of
the
container
image
that
has
some
build
flag
enabled.
So
it's
the
same
binaries
everything
is
just
a
different
image
with
those
flags
enabled,
and
so
I've
been
meaning
to
test
the
latest
one
for
the
last
week
or
two
to
see
what
the
latest,
if
it's
working
any
better
than
I
was
a
couple
months
ago,
I
don't
don't,
have
an
update
yet,
but
yeah
same
it
looks
the
same
to
rook.
It's
just
a
different
image
with
those
build
flags.
D
And
the
the
arguments
for
cephalus
demon
are
slightly
different
right.
A
Okay,
do
you
have
a
link,
or
is
it
an
internet
container,
but.
E
A
E
I
don't
think
so.
No
it's
only
on
the
that
one.
A
Only
on
the
yeah
but
right.