►
From YouTube: RGW Refactoring Meeting 2022-09-28
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/contribute/
What is Ceph: https://ceph.io/en/discover/
A
So
last
week,
I
had
a
meeting
with
some
other
members
of
the
stuff
Community
Yvonne,
who
runs
the
ex
who's
written,
the
ceph
exporter
and
Ilya
who's.
The
RBD
lead,
and
we
talked
about
the
labeled
perf
Counters
work.
I
have
something
that
does
have
labeled
rgw,
perf
counters
and
I
learned
in
at
least
in
the
short
term.
In
ilya's
case.
A
He
doesn't
need
to
have
that
many
labeled
perf
counters
going
out
from
his
demon,
but
the
one
thing
that
Casey
and
I
in
the
group
at
least
chatted
about
briefly,
was
what
happens
when
we
have
an
explosion
of
perf
counters
and
discussion.
I
was
hoping
to
have
was
how
could
we
do
do
some
filtering
so
that
only
the
perf
counters,
the
user
would
want
to
see
or
the
metrics
the
user
would
want
to
see,
is
getting
sent
to
the
exporter
instead
of
everything,
foreign.
A
Thorny
solution
to
this,
which
was
trying
to
figure
out
who
the
hot
users
and
hot
buckets
are
and
then
only
enabling
those
labeled
perf
counters
to
be
set
or
used.
If
a
user
is
quote
unquote,
hot
or
a
bucket
is
hot,
but
I
don't
know
if
you
had
any
thoughts
past
that
Casey
or
what
are
the
both
the
other
people
on
the
call
think.
B
B
C
C
A
B
Have
to
filter
into
the
the
perf
counter's
logic
to
decide
whether
or
not
ignore
certain
labels
right.
C
C
C
C
B
A
Okay,
I'm
trying
to
I,
want
to
have
like
V2
of
my
work,
with
whatever
feedback
was
there
last
week
and
to
present
whatever
the
newer
interfaces
would
be
by
by
next
week.
So
I
will
keep
that
in
mind,
but
it
sounds
like
for
the
near
term.
I
should
just
focus
on
that
and
then
we'll
continue.
This
discussion
a
little
bit
later
once
those
once
that,
whatever
perf
counters
interface
changes
I
make,
if
any,
are
our
set
in
stone
for
the
quote-unquote,
dumb
method.
A
E
Yeah,
so
the
process
of
modularization
I
worked
on
the
admin
apis
and
there
are
apis
that
are
currently
specific
moving.
Those
out
was
simple
because
that's
at
the
Handler
level,
and
so
I
can
just
create
one
API
method
in
the
store.
That
says,
add
my
stores,
admin,
API
handlers,
piece
of
cake,
we're
almost
done
with
modularization,
and
one
of
the
big
things
left
is
the
pub
sub
Ops.
E
Now
these
apps
are
not
at
the
handle
of
the
level
they're
part
of
the
normal
S3
level
of
Ops,
so
they're
at
the
app
level,
which
means
they're
mixed
in
with
all
the
other
S3
Ops.
So
there's
post,
Ops
and
put
Ops
and
delete
Ops,
and
everything
like
that,
makes
it
more
complicated
to
do
what
I
did
before
of
just
having
a
add
my
Handler
to
the
admin
apis,
so
I'm
wondering
if
anyone
has
a
better
idea
of
how
we
can
break
this
up
and
make
it
sort
of
cleaner
to
implement.
D
So
some
of
the
sub
apis
are
S3.
Apis
are
like
bucket
Ops.
When
you
add
a
notification
to
a
bucket.
It's
a
bucket
up
right,
the
others
that
are
not
SV
apis,
like
anything,
has
to
do
with
topics.
D
This
is
not
a
three.
This
could
be
split
to
something
else,
they're
also
like
Legacy
apis
there
that,
to
be
honest,
we
can
just
remove.
We
don't
need
to
support
them.
Okay,.
E
D
Identification
that
I
should
be
S3
Ops
I
mean
in
AWS.
There
are
S3
Ops,
so
the
topics
should
should
be
should
not
be
there.
I'm,
not
sure
why-
and
there
are
a
couple
of
that
are
kind
of
Legacy
from
some
old
interface
that
we
had.
That
was
not
compatible
with
anything
and
we
can
just
delete
them.
Okay,.
E
D
D
D
B
And
it's
separate
from
like
the
bucket
objects
that
I'll
kind
of
operate
on,
so
we
would
we'd
need
to
build
support
and
and
to
sell
itself
for
that.
D
D
Or
something
like
that,
yeah
I
mean
this
is
the
this:
is
the
most
logical
place
to
store
them.
That
would
also
like
we,
we
fixed
lots
of
things
like
we
had
all
kind
of
issues
with
kind
of
cascade
delete.
When
you
delete
the
bucket,
then
you
have
to
go
and
delete
all
the
on
the
rest
of
the
configuration
information.
If
everything
is
is
really
tied
to
the
bucket
as
it
should
be,
then
this
is
not
a
problem.
I
I
guess
making
this
change
is
not
too
difficult.
D
I
mean
everything
is
stored
per
per
bucket
per
topic
when
it
comes
to
the
processing
of
notifications
themselves.
D
But
this
is,
this:
is
the
actual
sending
the
sending
of
the
notifications
are
done
per
bucket
per
topic,
but
the
the
configuration
information
is
stored
in
system
objects
that
are
kind
of
per
bucket
per
notification
like
whenever
we
Define
notification,
you
create
a
system
object
that
has
the
bucket
name
and
the
topic
name,
that
together
they
Define
identification,
and
this
is
a
system
object
that
we
have
to
manage.
D
This
is
what
the
problem
is.
This.
The
information
in
theory
could
have
been
just
stored
inside
the
the
bucket
information.
D
But
again
the
the
main
problem
is
not
to
re-implement
the
data
structure.
It's
pretty
easy.
The
main
problem
would
be
to
to
figure
out
the
migration
path.
I'm,
not
sure
how
to
do
that.
I
mean
this
week,
like
tons
of
code
for
just
doing
the
migration.
B
So
I
guess
my
my
question
is:
what's
easier:
finding
adding
a
cell
API
to
enable
or
disable
per
app
or
adding
a
cell
API
to
do
whatever
call
it
is
that
we
need
to
to
write
these
objects.
E
B
I
mean
I
I
feel
like
our
S3
layers,
should
support
any
back
end,
less
clear
on
admin,
apis
and
and
other
stuff.
E
C
C
D
Mean
the
code
the
code
says:
Pub
sub,
like
in
those
it's
just
a
code
set
that
so.
But
this
is
what
the
confusion
is.
B
C
D
C
I
know
totally,
but
it
is
the
fact
that
it
just
it
has
happened
this.
This
also
uses
the
people
as
it
lexically.
It's
notification,
structural.
B
To
me,
it
feels
like
these
would
be
bucket
apis
and
cell
to
write
or
read
these
config
objects
and
at
some
point
in
the
future
we
could
Converge
on
using
the
existing
attributes
to
store
them.
But
for
now
just
adding
a
separate
API
that
only
rados
implements
based
on
the
current
code.
It
might
be
the
easiest
way.
E
D
Maybe
the
as
a
preliminary
step
I'll
try
to.
We
already
said
that
you're
going
to
remove
some
some
Legacy
functionality,
maybe
in
beef,
so
maybe
the
preliminary
stage
we
can
do
I
can
do
the
the
cleanup
so
there's
less
apis
to
implement.
Then
we
need
to
implement
only
the
thing
that
really
matters.