►
From YouTube: Ceph Month 2021: Open Discussion
Description
Open Discussion for Week 1 of Ceph Month 2021. Add your open discussion topics for the upcoming weeks at https://pad.ceph.com/p/ceph-month-june-2021
A
So
the
idea
is
get
everyone
here
to
hear
the
talks
and
then
have
more
of
a
freeform
discussion
where
we
can
talk
about
whatever
anybody
wants
to
talk
about
so
feel
free
to
put
anything
in
the
pad.
We
have
a
couple
topics
here.
A
A
Is
on
people's
minds?
The
first
thing
I
put
on
there
is
just
the
status
of
file
store.
This
came
up
in
one
of
the
leads
calls,
maybe
a
month
or
two
ago,
I
think
yeah.
We
just
have
to
decide
when
we're
going
to
drop
file,
sort
of
support,
file,
store
support.
We,
let's
see
yuri,
did
put
together
a
a
couple
of
plots
on
the
the
grafana
dashboard
for
telemetry.
So
we
can
see
how
many
remaining
file
store.
Osds
are
actually
phoning
in.
A
It's
a
pretty
small
number.
I
think
total
it's
well.
It's
like
fifteen
hundred
osds
out
of
fifty
thousand.
A
So
like
four
percent
and
dropping
I'm
not
really
sure
I
don't
know,
I
guess
if
you're
curious,
what
user's
feedback
is
like
how
many
people
have
file
store
in
production
and
no
plans
to
migrate,
for
example,
or
the
level
of
concern
here
essentially,
once
we
drop
file
store,
then
we
can
simplify
some
code
and
we
can
clean
up
the
object,
store
interface,
a
little
bit
more
to
streamline
the
communication
between
the
ost
and
the
app
and
blue.
A
B
B
We
do
have
maybe
some
16.0
running
a
16.2
running
a
file
store,
but
I'd
be
really
curious
to
know
what
is
the
level
of
interest?
It's
not
that
it's
a
burning
thing
that
we
want
to
get
rid
of
or
something,
but
we
just
want
to
understand
what
the
real
interest
is
around
there.
In
addition
to
what
sage
said,
we
can
also
simplify
a
lot
of
our
testing,
because
currently
we
do
test
file
store
across
releases.
B
So
if
we
do
not
test
file
store
anymore,
probably
only
the
upgrades
part
is
what
we're
going
to
be
testing
in
future.
B
A
Yeah,
it's
it's
a
little
bit
interesting
that
that
dashboard,
but,
incidentally,
that
I
linked,
I
think,
might
be
only
accessible
here
on
the
vpn,
because
there
are
a
bunch
of
private
dashboards
that
aren't
haven't
been
vetted
as
far
as
like
whether
they're
just
closing
public
information,
but
what's
interesting
is
that
there
are
almost
no
file
store
osds
that
are
on
specific,
in
fact
they're
zero.
So
far,
I
think,
that's
just
because
the
file
store
clusters
haven't
been
upgraded
yeah.
I.
C
B
I
think
dan
had
this
idea
about
warning
about
file
store
deprecation,
so
I
think
we
have
a
pr
outstanding,
at
least
that
aims
to
warn
about
any
existing
file
store
osds
in
the
cluster.
So
maybe
that
can
be
extended
to
talk
about
deprecation
if
required,.
A
I
guess
stefan
asked
the
question
why
we
wouldn't
drop
it.
I
think
the
one
thing
that
file
store
does
do
is
allow
you
to
create
an
osd,
that's
just
backed
by
a
directory
on
an
existing
disk.
You
don't
have
to
dedicate
an
entire
device.
You
can
do
that
also
with
bluestora,
but
it's
a
bit
more
awkward.
You
could
back
booster
with
the
device,
but
the
tooling
doesn't
really
support
it.
So
it's
not
easy
to
do
that's,
but
that's
something
we
can
fix.
We
just
haven't
done
that.
C
B
A
All
right
just
a
quick
comment.
I
know
I
posted
the
pad
earlier
with
our
names,
but
there
wasn't
any
there
weren't
any
options
on
the
pad
before
they're
a
bunch
on
there
now.
So,
if
you
wanna,
if
you
look
before,
maybe
take
another
look
and
you
can
vote
on
other
names
that
aren't
that
aren't
rogan.
A
A
I
need
to
talk
to
that
team
and
see
when
they
can
do
it.
Do
a
presentation.
A
Yep,
so
I
think
there
are
sort
of
three
parts
to
do.
The
first
part
is
a
set
of
radius
or
a
radius
class.
A
That
makes
it
that
streamlines,
storing
deduped
content,
addressable
data
in
raido's,
so
these
are
objects
that
are
named
with
the
hash
and
have
reference
counts
on
them
all
of
the
infrastructure
to
do
that
is
in
place.
But
there
are
no
users,
though
it's
a
matter
of
adding
more
testing
and
actually
using
it
and
making
sure
everything
behaves
the
way
we
think
it's
going
to
behave,
that's
sort
of
the
first
piece
and
it's
basically
done.
A
The
second
piece
is
there
are
a
bunch
of
changes
in
the
radius
tiering
code
that
have
been
accumulating
over
the
last
two
releases
that
allow
rados
objects
to
be
basically
deduped,
where
the
content
gets
pushed
into
another
pool,
and
then
that
object
turns
into
like
a
manifest
link,
link
sort
of
thing
that
does
this
part
of
the
object
is
referenced
by
that
chunk
and
so
on.
That
code
is
entry.
A
That
is
not
the
most
stable
code,
so
I
wouldn't
necessarily
it's
not
ready
for
production
yet
still
under
development
and
that's
complicated.
So
there's
that
and
then
the
third
piece
is,
is
a
plan
to
add
support
for
raido's
gateway
to
directly
store
data
into
a
raido's
youtube
tool,
so
not
not
making
use
of
the
radio
support,
but
just
directly
storing
data
instead
of
raw
chunks
and
that
we're
hoping
we
can
have
that
in
place
for
quincy.
A
Another
question
that
came
up
does
cepheidium
support
large
clusters.
Yet
yes-
and
no-
I
guess
maybe
so
we
haven't-
I
haven't
seen
any
reports
of
where
the
scaling
limitation
is
for
the
current
approach
that
stuff
adm
takes.
Maybe
sebastian
vogter
knows
more.
If
he's
he's
on
the
call
or
somebody
else
on
the
7dm
team.
A
A
So
there's
a
bunch
of
work,
that's
sort
of
in
progress
right
now,
fixing
up
nfs
support
and
a
couple
other
odds
and
ends,
that's
being
all
backboarded
to
pacific.
But
that's
those
are
all
relatively
short-term
items.
They'll
probably
get
wrapped
up
in
the
next
month
or
two
and
then
the
big
thing
is
adding
support
for
these
agents
that
would
run
on
every
node
and
be
sort
of
pushing
pushing
state
to
the
manager
instead
of
having
the
manager
have
to
ssh
in
and
scrape
it.
Every
few
minutes.
A
Let's
see
that's
question
about
long-term
support
for
how
ceph
can
be
deployed
for
stuff
packages
next
to
containers,
manually
and
stuff.
Idiom
is
the
question
whether
or
not
we're
going
to
keep
building
containers
or
keep
building
packages
in
the
long
term
about
the
crux
of
that.
A
So
I
think
we
have
no
plans
to
stop
building
packages.
That's
how
all
the
downstream
or
most
of
the
downstream
users
are
still
dimming
it
like
and
then
ubuntu
and
so
on.
So
those
packages
are
going
to
continue
to
exist.
I
don't
we'll
probably
be
less
aggressive
about
trying
to
support
lots
of
different
distros
that
becomes
less
important.
A
We
have
to
build
the
rpms
as
because
it's
part
of
the
container
build
process
and
the
container
itself
is
based
on
centos,
so
those
I
think
will
never
go
away
and
I
think
there's
we
have
no
plans
to
drop
two,
but
we
probably
won't
support
as
many
of
them
too
and
we're
gonna
stop
talking
about
adding
the
debian
packages,
I'm
guessing.
A
As
far
as
support
for
how
to
manage
the
stuff
cluster
that's
installed
via
packages,
there
are
no
plans
to
make
self-adm
non-containerized.
If
that's
what
that's
asking?
There
is
an
opportunity
to
write
another
manager,
module
that
sits
alongside
step
8m,
that
sort
of
works
with
packages
that
are
installed
directly
in
the
host.
A
If
somebody
is
invested
in
that,
but
I
think
it
was
interesting,
there
was
a
sebastian
went
through
the
user
survey
results
last
week
and
extracted
all
the
comments
relating
to
stuff
adm
and
the
orchestrator
and,
like
basically,
all
of
the
the
fiddium
related
comments
were
asking.
Do
we
have
to
use
containers
packages?
A
I
don't
like
containers,
gainers
are
hard,
and
so
we
had
this
huge
list
of
them
which,
when
we
first
looked
at
it
was
a
little
bit
overwhelming.
But
when
we
looked
back
and
looked
at
the
comments
in
detail,
we
couldn't
find
any
actual
reason
why
the
stuffed
edm
approach
was
problematic,
except
that
containers
were
like
just
different.
It
was
mostly
like
used
to
packages.
A
I
want
to
use
packages
and
not
that
there's
anything
wrong
with
the
container
approach
and
so
we've
yet
to
really
have
anybody
present
a
good
reason
why
containers
aren't
an
option.
I
think
the
only
one
that
comes
to
mind
for
me
is
if
you're
running
previously
or
a
non-linux
operating
system,
then
it
yeah
it's
something
totally
different,
but
I
think
packages
don't
really
help
you
in
that
case
either.
A
A
Stream
8
versus
linux
8
have
builds
changed
to
stream
already
they
have
not.
We
just
recently
got
stream
8
set
up
in
the
lab
so
that
we
can
test
on
stream
8,
I'm
not
sure
if
or
how
that
actually
would
have
changed
the
build
process.
The
containers
could
be
based
on
a,
but
I'm
not
sure,
I'm
not
sure
exactly
what
the
plan
is
there
honestly,
but
I
don't
think
it'll
it'll
it'll
change
our
build
pipeline
a
bit.
I
don't
think
it'll
affect
users
really
notice,
we'll
see.
A
C
Yeah,
I
think
there
are
occasionally
some
build
fixes
from
folks
to
make
more
stuff
build
on
mac
os.
But
if
anybody's
interested
in
trying
to
work
on
that,
I
think
that
people
can
patches.
A
C
C
A
And
on
the
containers
thing,
maybe
it's
the
docs
issue,
yeah
yeah,
I
was
actually
planning
on
doing
a
a
blog
post,
basically
saying
what
I
just
said
that
talking
about
the
container
issue
and
people's
resistance
to
change,
but
I
wanted
to
mention
it
here
too,
because
I
just
I'm
very
curious
to
hear
somebody
who
feels
strongly
about
it
in
here.
Why.
A
A
Okay,
well,
if
there's
anything
else,
we
can
wrap
up
keep
in
mind
that
basically
there's
time
set
aside
after
each
of
these
sessions
to
talk
about
open
topics
whatever
it
is.
So
if
there's
something
that
you
then
think
of
now
or
I'm
prepared
to
talk
about,
feel
free
to
add
it
to
the
agenda
for
next
week
will
be
our
next
session
on
june
10th,
where
we're
gonna
get
the
rgw
update
and
there'll
be
a
couple.
A
Other
oh
there'll,
be
a
couple
birds
of
a
feather
actually
so
yeah
plenty
yeah.
A
A
All
right,
thank
you.
Everybody
thanks
for
joining
thanks,
josh
niha
alessandro
for
presenting
luik
and
we'll
see
y'all
next
week.