►
From YouTube: Ceph Developer Monthly 2022-05-04
Description
Every month the Ceph Developer Community meets to discuss current work in the Ceph codebase, and coordinate efforts to minimize collisions and issues.
This monthly Ceph Dev Meeting will occur on the first Wed of every month via our BlueJeans teleconferencing system. Each month we alternate meeting times to ensure that all time zones have the opportunity to participate.
https://tracker.ceph.com/projects/ceph/wiki/Planning
A
All
right,
I
think
we
can
kick
it
off
and
let
me
officially
get
this
cdm
off
so
hello
and
welcome
everyone
to
cdm
for
the
month
of
may.
Today
we
have
a
light
agenda,
I
would
say
we
have
one
topic
and
martin
is
already
here
before
time.
I
would
say
so.
I
think
I'm
going
to
hand
it
over
to
you.
Martin.
B
Hi,
I'm
martin
omar,
I'm
working
for
ibm.
I
have
recently
started
working
on
ceph
within
a
group
that
actually
tries
to
bring
some
cell
devices.
Sorry,
some
ibm
devices,
particularly
these-
are
nvma
nvme
storage
devices
produced
by
ibm
into
a
saf
deployment.
B
These
nvme
devices
have
the
capability
to
do
online
compression,
so
they
basically
provide
a
large
space
like
22
terabyte
of
logical
blocks,
but
this
is
backed
by
only
9.6
terabyte
of
physical
storage
space,
so
their
model.
The
usage
model
is
very
similar,
similar
to
the
vdo
device
that
is
already
supported
within
saf.
B
B
Actually,
I
first
experimented
to
put
in
a
code
basically
just
next
to
the
video
component
into
self,
but
this
didn't
look
right
for
me
because
it
would
just
add
our
device.
So
I
changed
the
strategy
by
adding
a
plugin
system
for
this.
I
basically
copied
the
the
base
structure
of
the
erasure
code
plugin
system
into
basically
a
new
plugin
system.
That
is
basically
in
a
neighboring
directory.
B
And
it's
basically
loads
plugins
that
have
an
interface
that
provides
all
these
side
channels
that
actually
the
vdo
uses
to
provide
physical
block
utilization
up
to
the
sap
layers,
and
I
took
the
vdo
device
and
basically
created
one
first
plugin
to
basically
basically
demonstrate
how
this
plugin
system
works,
have
a
reference
implementation,
and
this
allows
now
us
to
later
add
the
plugin
for
fcm
device.
B
Yeah
yeah,
that's
our
storage
device.
The
problem
is
right.
Now
the
api
for
our
device
is
still
vendor-specific
and
I'm
not
allowed
to
basically
put
it
open,
but
this
plug-in
approach
basically
would
allow
us
to
basically
ship
a
plug-in
to
any
kind
of
customer
who
uses
our
device
or
even
us,
using
the
device
in
our
ibm
cloud
and
later
on.
B
I
hope
that
in
the
very
near
future,
we
actually
get
the
green
light
to
to
open
up
the
interface
to
our
fcm
device
that
allows
the
access
to
the
physical
storage
state
of
the
device
so
that
we
can
actually
put
this
plug-in
also
in
the
base
cell
database.
B
One
is
the
actual
plug-in
system
with
the
vdo
device
or
video
device
plug-in
and
the
other
one
is
actually
a
feature
that
we
need
for
our
specific
device,
which
is
a
commit
that
enables
the
setting
of
the
keep
caps
flag
in
linux,
and
this
keep
caps
flags
maintains
the
capability
set
across
set
uid
system
called.
So
when
you
basically
switch
from
root
to
the
saf
user,
you
can
keep
the
permitted
capability
set
that
would
allow
later
on
a
plug-in
device
or
any
device
drivers
to
activate
capabilities
that
it
needs.
B
So,
for
example,
we
need
ndme
passthrough,
our
basically
your
query
commands.
They
are
lock
queries
for
that.
We
need
sys
admin
capabilities
and
our
plugin,
then
just
flips
in
the
effective
capability
set
the
sys
admin
on
when
we
read
the
state
and
then
turns
it
back
off,
so
that
actually
no
other
part
of
the
set
code
can
access
this
capability.
B
Unless
it's
explicitly
aware
of
that,
this
setting
of
the
of
the
keep
caps
flag
is
also
gated
by
a
configuration
flag.
That
is
by
default
false,
so
you
would
need
to
actually
enable
that
flag
in
order
to
keep
this
capability
set
active
across
set
uid
codes
yeah,
I
think
that's
basically
it
so.
This
structure
of
the
other
commit
that
actually
implements
the
the
the
the
actual
plugin
system
consists
out
of,
of
course,
some
cmake.
B
So
I
added
a
sub
directory
where
the
actual
plugin
system
is
the
sub
directory
is
xblock
device.
So
I
had
to
add
c
make
files
add
in
the
base
c
mac
of
the
source
directory
the
inclusion
of
that
directory.
B
I
had
to
change
the
theft
spec
to
get
these
x
block
devices
also
deployed
when
the
packaging
is
done.
What
else
the
kernel
device
is
actually
that
the
part
that
caused
this
interface,
so
I
basically
changed
the
chords
to
the
vdo
components
by
the
calls
across
the
registered
plug-ins
in
the
plug-in
system.
So
the
plug-in
system
provides
basic
plug-in
registry
via
configuration
strings.
B
This
set
of
plugins
can
be
specified
that
gets
pre-loaded
on
actually
osd
start
time
and
then,
when
a
device
is
opened,
we
go
over
the
set
of
of
plugins
and
find
the
plug-in
that
actually
can
control
that
device,
and
that
is
then
registered
with
this
kernel
device
structure
and
then
later
on
when
utilizations
are
queried,
we
call
the
interface
of
the
plugin.
B
Yeah
and
yeah,
then
there's
the
plugin
system
itself
plug-ins
and
a
the
preload
of
the
plugins
in
global
init,
and
I
think
that's
basically
it.
A
Yeah,
I
guess
a
little
bit
of
background
for
everybody
who's
there
on
the
call
we
discussed
this
briefly
at
the
cdes
session
for
raiders,
and
everybody
thought
it
was
a
good
idea,
but
I
think
that
at
that
time
your
pr
wasn't
structured
in
this
way.
I
think
it's
very
well
structured
at
the
moment
for
review,
so
that's
kind
of
a
follow-up
of
that
and
at
the
moment
so
have
you
been
able
to.
I
know
this.
This
thing
the
existing
video
as
your.
C
B
A
B
A
Yeah,
I
think
I
was
looking
through
the
original
implementation
where
sage
actually
added
it
and
I
was
seeing
how
he
tested
it
and
there's
some
hints
I
got
from
there,
but
I'm
not
sure
if
those
are
still
valid-
and
this
is
the
pr
I'm
looking
at
this
might
be
a
good
reference
to
look
at,
but
I'm
not
sure
all
the
details
will
hold
through
anybody.
D
A
D
A
D
A
D
D
I'm
not
aware
of
anyone
I
mean
even
when
they
put
it
in
this
is
trading
off
cpu
time
for
better
storage
efficiency,
which
is
the
wrong
direction
for
almost
every
step
deployment.
So
you
know
the
the
hardware.
One
is
a
lot
more
interesting
that
that
martin's
group
has.
I
haven't,
I'm
just
skimming
through
this
now.
Certainly
the
shape
of
this
interface
looks
right
to
me.
D
B
So
the
idea
of
the
keep
caps
I
mean
is
a
little
bit
more
complicated
you
basically
in
order
to
you.
Normally,
you
don't
really
use
the
keep
caps.
You
set
a
set
of
capability
flags
on
an
executable
when
that
that
one
is
loaded
and
the
user
itself
has
a
set
of
capability,
then
basically,
the
the
end
of
that
set
is
what
becomes
available
and
that
application
at
that
point
needs
to
be
avail
aware
of
capability
and
set
these
individually.
B
The
kit
caps
basically
takes
a
broad
stroke.
It's
really
when
you
switch
from
root
to
something
else,
to
keep
basically
the
flag
set.
You
can
actually
also
kill
individual
flags
so
that,
after
you
switch
root
yeah,
I
think
that
there
are
more
than
30
different
flags
that
affect
basically
any
some
kind
of
of
root
capabilities.
For
example,
there's
one
specific
for
accessing
raw
sockets,
or
so
you
can
do
a
ping,
for
example.
So
there
is
a
fine
granularity.
The
problem
is
so
you
could.
B
Basically,
I
could
extend
this
patch
to
have
more
configuration
options
so
where
you
could
actually
specify
hey,
I
want
to
keep
capabilities,
but
I
want
of
these
30
plus
capabilities,
only
that
one
to
survive
the
switch
and
then
it
would
also
only
survive
basically
in
this
permitted
set,
which
does
not
still
does
not
enable
you
to
do
system
calls.
You
still
have
to
then
do
specific
capability
calls
to
activate
they
put
it
in
the
effective
set,
and
then
you
can
use
this
capability.
B
C
D
B
So
I
don't
know
if
it
doesn't
make
sense,
if
I
add
more
configuration
options
for
the
keycaps
to
basically
further
trim
down
what
survives,
even
in
the
in
the
permitted
set.
B
Yes,
yes,
you,
you
can
actually
specify
so
the
way
it
works.
The
kid
caps
basically
says
the
the
the
permitted
set
from
the
user
id
that
that
exists.
At
the
point
of
time,
when
you
set
the
key
caps
will
be
maintained
over
the
next
suid
call
right,
but
you
can
flip
all
of
them
off.
You
can
never
flip
them
on.
You
can
only
flip
these
effective
bits
off,
there's
no
way
to
flip
them
on.
C
B
D
D
D
B
C
B
But
I
have
to
make
a
disclaimer
here,
the
the
envy
I
mean
the
the
capability
system
itself
is
not
that
great.
In
the
respect
that
this,
the
individual
capitalist
that
exists
have
been
the
patchwork.
I
don't
know
if
you
read
about
that,
they
have
been
added
basically
on
it
on
need
basis
and
all
the
capability
for
which
not
a
specific
class
has
been
found.
They
have
been
all
swept
into
a
capability
bit
that
is
called
sus
admin.
B
C
C
B
C
B
B
With
basically,
let's
say
a
query
function
where
you
can
return
a
required
bit
set
right.
That
would
automate
that
system.
But
I.
B
B
D
B
But
that
also
actually
means
that,
so
there
are
there's
a
library
that
libcaps
library
that
actually
manage
all
of
that
that
basically
can
create,
sets
and
store,
provides
a
structure
for
that
and
calls
the
kernel
functions
at
that
point
of
time.
I
would
actually
need
the
lid
caps
be
part
of
the
seth
dependencies
set
right.
You
and
nobody
gets
upset.
If
I
add
one
more
one.
D
B
A
B
A
A
B
A
D
C
Danger
is
that
this
merges,
and
then
you
test
it
once
and
then
a
later
mutation
to
blue
store
causes
it
to
stop
working
which
no
one
notices
until
the
next
release
and
some
customer
tries
to
run
on
this
hardware.
So
that's.
Why
that's
why?
The
concern
here
is
about
automated
testing,
not
where
we
literally
able
to
stand
it
up
before
the
pr
merged.
B
A
Video
we
have
bare
metal
nodes,
we
don't
use
vms.
D
C
B
A
And
any
guess
I
don't
think
we
should
stress
over
that.
I
guess
the
next
step
would
be
to
get
some
reviews
and
stuff
going
and
if
you're
able
to
provide
more
testing
details,
that'll
be
great
as
well.
Okay,
take
this
forward.
A
D
Well,
I'd
ask
some
questions
that
I
mentioned
in
the
the
replanting
session,
so
my
understanding
is
that,
like
I
pointed
out,
the
video
integration
is
kind
of
kind
of
weird
in
terms
of
how
it
looks
to
you
know
the
upper
layers
of
the
cluster,
where
it
doesn't
understand
that
you
know
the
space
sort
of
doesn't
really
exist
and
in
terms
of
balancing
and
stuff
is
that
it
sounded
like
that.
Wasn't
something
you
were
too
worried
about
your
initial
deployment.
But
is
it?
D
B
That's
a
good
question,
I
mean
in
theory
it
would
be
nice,
for
example,
to
get
compression
ratios,
propagated
up
and
display
them
and
so
on,
but
all
of
this
doesn't
exist
in
seth,
right
yeah.
So
in
that
part
it
would
be
a
huge
endeavor
and
I
don't
know
what
the
what
the
return
for
that
is
immediately.
I
mean,
of
course,
if
I
had
a
choice
here,
I
would
like
you
to
be
better,
but.