►
From YouTube: Ceph RGW Refactoring Meeting 2022-11-09
Description
Join us every Wednesday for the Ceph RGW Refactoring meeting: https://ceph.io/en/community/meetups
Ceph website: https://ceph.io
Ceph blog: https://ceph.io/en/news/blog/
Contribute to Ceph: https://ceph.io/en/developers/contrib...
What is Ceph: https://ceph.io/en/discover/
A
I've
been
putting
some
thought
into
how
we
want
to
organize
dependencies
for
for
Sal,
specifically
out
of
tree
cell
drivers,
so
I'm
trying
to
just
think
about
really
what
shape
things
are
going
to
need
to
be
in.
In
terms
of
where
the
library
boundaries
are,
how
we
organize
dependencies
so
that,
like
in
in
Caleb's
loadable
modules
PR,
we
we
can
kind
of
work
towards
that
as
a
goal.
A
A
I,
don't
think
it's
ideal
to
have
out
of
tree.
Drivers
depend
on
that,
so
I'd
like
to
avoid
it.
If
we
can
but
I,
don't
know
if
that's
really
attractable.
B
A
Okay,
so
yeah
I,
it
could
just
mean
splitting
some
things
out
of
self
common
into
something
else
and
and
kind
of
standardizing
that
yeah
exactly.
A
B
I
suspect,
they're
well
so
there's
definitely
the
encode
and
decode
stuff.
A
Json
stuff
I
guess
that
kind
of
Falls
in
that
category
too
yeah.
What
about
config.
B
A
C
C
C
Right
well,
okay,
but
we
could
make
it
so
that
we
could
encoding
decode
can
be
lifted
out
of
header
only
maybe
that's!
Okay,
it's
not
I
I
still
have
a
doubt
that
that's
that
that
that's
like
the
the
performance
performance
limiting
Step
at
the
moment-
yeah-
that's
that's
the
least
traditional
C
plus
plus
way
to
do
it,
but
but
but
basically
putting
out
things.
C
We
don't
splitting
out
decoupling
more
stuff
to
be
such
that
you
know
coming
up
with
a
weight
with
or
come
up
with
other
ways
to
to
staple
these
things
together,
maybe
so
that
we
can
get
access
to
to
types
but
but
not
drag
but
not
drag.
Stuff
internals,
especially
rados
internals
into
South,
seems
like
a
good,
a
good
Axiom
to
try
to
be
going
for
I.
B
Tend
to
agree,
one
thing
we
haven't
talked
about
is,
is
what
exactly
do
we
mean
by
out
of
tree
and
how
out
of
tree?
Do
we
mean
right.
C
B
D
B
Right
I
mean
yeah,
that's
in
the
middle.
Definitely
right.
The
question
is:
where
do
we
want
to
fall
on
this
Continuum
of
all
the
way
on
one
end,
they
basically
stick
it
in
the
tree
and
build
it,
which
is
what
we
have
now
right
and
then
all
the
way
on
the
other
end.
Is
they
don't
need
anything
from
Seth?
That's
not
provided
by
packages
and
then
there's
all
kinds
of
states
in
the
middle
that
we
that
we
could
get
to
question
is
where
do
we
want
to
fall
on
this
continuum?.
C
C
C
Think
I
think
these
ideas
in
the
middle
are
the
best
are
the
likely
good
places,
but
I
want
to
avoid
making
it
going
to
a
great
effort
to
build,
to
build,
to
build
some
sort
of
a
peer
interface
that
that
ridiculously
adds
work
and
breaks
a
lot,
but
I
don't,
but
at
the
same
time
I
would
I
would
say
we
would
like
to
have
some
this.
C
You
know
like
like
that
paper
that
I
remember,
most
of
which
was
a
splatter,
but
but
but
the
people
that,
but
the
key
observation
I
had
going
back
a
year
ago
or
in
2020
was
most
of
there
doesn't
really
need
to
be
this
complex,
circular
dependency
between
CLS
and
this
other
stuff.
We
could
decouple
these
and
we
should,
and
we
should
try
to
do
something
similar
to
his
album.
We
put
the
types
addition
to
the
cell
types,
be
careful
about
not
just
leaking
stuff
in
there.
A
A
How
we
organize
this
I
think
affects
how
we
can
support
drivers
against,
like
Upstream
stable
releases
right.
Ideally,
third
parties
can
ideally
they'd
be
able
to
build
their
own
drivers
against
whatever
we
provide
and
those
drivers
would
hopefully
work
against.
C
B
I'm
I'm,
not
against
the
idea.
Casey
I
mean
we
effectively
do
that
in
Ganesha,
but
I
think
we're
a
long
way
from
being
able
to
support
that.
A
Right,
yeah,
I've
I've
definitely
put
thought
into
versioning
the
cell
API
itself,
but
I
think
it's
all
of
the
dependencies
of
cell
like
the
the
types
and
the
right
the
stuff
stuff
is.
B
B
C
C
In
addition
to
having
also
version
the
cell
API,
you
can
just
say
type
for
all
the
tags.
We
have
some
type
of
personing
strategy
where
we
should
go
with
that,
but
I
mean
I
I,
like
both
of
these
things.
I
mean
I,
like
the
strong
proportion
of
this
proposal,
but
I
wouldn't
build
the
but
I
wouldn't
put
the
cardboard
the
horse,
so
I
think
we're
successfully
approximating
successful
approximations
and
we
should
stop
when
we
run
on
this
team,
but
we
should
not
be
starting
from
the
from
the
first.
C
You
know,
I
mean
no
one
I
bet,
no
one
thinks
so.
I
mean
we're.
Not
the
the
the
position
of
the
out
of
tree
driver
guy
is
is,
is
is
not,
is
we
shouldn't
destroy
that
person's
life
but
or
that
company's
life,
but
but
that's,
but
that,
but
that,
but
but
that's
but
that's
a
commercial
activity
and
and
and
and
then
and
if
it's
serious
it
can
it'll
be,
the
resources
will
be
available
to
support
it.
If
not
it's
not
on
the
project
design.
First,
for
that.
A
Okay,
so
effectively,
users
that
are
using
how
to
treat
drivers
like
motor
or
something
would
wait
to
do
upgrades
until
motor
was
updated.
With
that
point
release,
for
example,
yeah
exactly.
A
Okay,
well,
the
I
drew
a
little
diagram
there
and
I.
A
But
maybe
for
now
just
treating
rgw
base
and
rgw
cell
as
the
same
thing
will
be
most
expedient.
A
A
That's
kind
of
most
involved
with
this
kind
of
linkage
is:
is
this
structure
essentially
what
you're
going
for
am
I
missing
pieces.
E
I
think
that's
fine,
I
haven't
really
given
it
a
whole
lot
of
thought.
Actually.
C
C
C
If
there's
like
someone,
some
some
notion
of
a
some
emotional
external
view
that
Casey
I
think
I
heard
Casey
kind
of
going
for
I
like
that
I
think
I,
think
I
think
common
is
I,
think
I
think
if
common
meant,
if
common
meant
that
that'd
be
fine.
But
to
me
at
the
moment
it's
not
I,
still,
remember
it
as
the
thing
that
I
don't
want
to
include
most
of
the
time,
because
it's
crazy.
A
C
Okay,
I
mean
maybe
you're
right,
I
mean
also
also
I
mean,
maybe
maybe
I'm
just
on
the
wrong
track.
I
mean
if,
if
we
can
always
construct
the
the
the
sorry
the
RW
develop
based
on
this,
and
it's
always
and
it's
always
there
for
the
major
point
or
made
for
for
a
point
release
and
and
that
maybe
that
maybe
that's
exactly
what
we
want.
E
That's
right
so
I've
been
playing
with
it
a
little
bit
he's
not
allowed
to
report
other
than
apart
from
it's,
not
really.
It
doesn't
really
work.
There's
not
it
blows
up
on
Boost
headers
and
it's
a
known
problem.
E
It's
a
known
problem
that
it
has
has
problems
with
complicated
headers
for
quite
some
time,
so
I'm,
not
not
holding
my
breath
that
it'll
get
fixed
anytime
soon,
since
it
hasn't
been
fixed
in
five
years,
so
that
just
leaves
us
leaves
doing
it
by
Brute
Force
unless
unless
somebody
else
knows
that
was
of
another
tool
that
maybe
actually
works.
D
Maybe
we
can
try
and
just
remove
the
psychic
include
check.
D
D
E
E
Yeah
I
don't
know
how
much
time
to
spend
on
this
and
and
we
need
to
get
the
need
to
get
the
zipper
loadable
plugins
done.
A
I
think
it
would
be
a
minor
compilation,
speed
increase
but
I'm
more
interested
in
figuring
out
how
to
break
up
dependencies
so
that
we
just
don't
have
everything,
including
everything
else.
E
A
Currently,
DB
store
is
has
kind
of
a
weird
cyclical
dependency
with
the
rest
of
rgw.
C
B
C
C
C
I,
don't
think
I,
don't
think
necessarily
but
I
think
going
forward
I'd
like
us
to
make
some
rules
to
write
them
down.
They
don't
have
to
be
very
complicated
at
first
but
like
the
basic
stuff,
and
then
we
can.
If
we
find
things
we
think
we
definitely
should
be
controlled.
We
should
we
should
avoid
pollution
at
that
point
and
deep
pollute
foreign.
A
Or
to
to
tackle
the
DB
store
part
specifically
I
think
maybe
a
good
first
step
would
be
to
formalize
this
rgw
cell
library
and
make
it
so
that
DB
store
can
build
only
depending
on
that
piece.
A
But
to
Dan's
point
the
rgw
app
layer
is
kind
of
at
the
top
and
so
I
think
it
I.
Don't
think
it's
really
a
problem
for
it
to
have
dependencies
on
other
stuff
as
long
as
they're,
not
specifics
of
like
the
art,
the
radio
as
well.
A
Right
but
Caleb's
loadable
modules
PR
is
essentially
making
the
radar
cell
like
a
plug-in,
so
it
shouldn't
even
link
if
we
have
dependencies
in
the
wrong
place
right.
C
Basically,
within
limits,
yes,
there
should
be
some
headers.
Maybe
there
should
be
some
things
you
shouldn't
at
least,
especially
as
we
get
things
cleaned
up
more.
There
should
be
some
things,
you
didn't
you,
don't
you
don't?
You
don't
include
in
a
Cell
driver,
I,
don't
know
if
we
know
exactly
which
things
those
are.
E
So
looking
at
looking
at
Casey's
diagram,
I
mean
we've
got
a
rgw
common
and
I've
got
in
our
rattle
Sal
librarian,
a
rattles
plug-in
and
I
was
kind
of
thinking
that
everything
that's
in
rattles
cell
would
actually
moved
to
the
rattles
plug-in.
So
then
it's
a
question
of
slice
and
dice
and
moving
things
creating
a
rgw
cell
layer
that
Casey
has
on
his
diagram
and
figuring
out
what
what
things
that
need
to
move
there
and-
and
this
is
not
actually.
This
is
not
even
to
do
with
the
headers.
A
And
an
idea-
let's
see
it,
talked
about
this
in
context
of
how
we
break
things
up
as
Library
Targets
in
cmake,
but
there's
also
the
directory
structure
of
source
rgw
and
we
have
an
rgw
store
subdirectory
with
a
rados
and
a
DB
store
underneath.
So
maybe,
as
we
move,
radio
specifics
under
store,
rados
it'll
be
easier
to
catch
includes
that
are
in
generic
code.
E
So
maybe
that's
the
way
to
think
about
this.
Okay.
A
Caleb
on
about
your
your
current
PR
for
low
loadable
plugins
I'm,
just
it
feels
like
we're
still
a
ways
off
of
being
able
to
to
build
and
Link.
All
of
that
are
there
pieces
that
we
could
split
out
into
their
own
PRS
that
we
could
merge
in
the
meantime,
so
that
you're
not
just
carrying
this
and
rebasing
the
whole
thing.
E
A
big
part
of
my
PR
is
is
breaking
things
up
into
different,
shared
libraries.
I.
Don't
think
we
really
want
to
do
that.
Another
big
part
is
having
besides
breaking
things
up
in
the
libraries
is
breaking
things
up
into
the
the
shared
libraries.
It
would
be
the
plugins
we're,
definitely
not
ready,
I,
don't
think
we're
ready
to
do
that.