►
From YouTube: Ceph RGW Refactoring Meeting 2023-02-15
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
A
There
was
a
lot
of
discussion
in
the
d4n
meeting
yesterday
that
didn't
quite
get
resolved,
so
I
was
hoping.
We
could
continue
that
here,
although
if
Matt's
not
here,
then
I
would
prefer
him
to
be
present.
A
All
right,
well,
I
think
we
should
probably
reschedule
that
discussion.
What
else.
A
How
about
how's
Reef
looking
for
you
guys
are
there
things
that
features
that
we
need
to
fit
finish
or
important,
fixes
that
haven't
merged
yet.
C
A
So
I
I
have
a
fix
for
the
Ragweed
issue
earlier
today
and
managed
to
get
to
that
Jabs
through
I,
just
scheduled
single
jobs
at
p50,
and
they
ran
in
a
timely
fashion.
Alrighty.
A
Who
knows
what'll
happen
if
you
schedule
a
full
Suite,
but
the
Ragweed
failures
are
gone,
so
things
look
promising.
A
Yeah
so
Matt
we
were
waiting
to
discuss
the
S3
proxying
stuff
until
you
joined.
Are
you
still
in
the
program
call
or
are
you
available
no.
A
B
B
A
D
Yeah
I
don't
think
it
was
the
intent
of
of
of
zipper
to
to
sort
of
districtly
mirror
what
what
Raiders
does,
but,
but
it
was
a
way
to
get
things
going
and
it
useful
for
anyway,
a
couple
a
couple
of
Independent
Drivers
and
maybe
maybe
before
as
many
as
four
I
think
there
should
be
a
model
where
we,
where
we
can
build.
So
it's
something
like
us
like,
like
the
S3
filter
and
and
and
and
not
lose
the
ability
to
to
treat
it
like
a
storage
packet.
D
In
some
way
they
say
that
how
do
you
think
came
up
here?
Just
didn't
make
it
come
to
our
firmware.
They
certainly
haven't
come
to
the
firmware
designed
for
that,
but
I.
Don't
think
I,
don't
think
that
zipper
is
intended
to
be
strictly
relying,
for
example,
graveling
on
attributes
and
sitting
there
and
thereby
sort
of
leaking.
D
What
I
think
are
are
sort
of
rate
of
abstractions
upward
them.
There
might
need
to
be
some
way
to
unify
that.
Is
it
acceptable
leakage
for
obviously
some
back
ends,
but
so.
D
Well,
I
agree
with
that,
but
we
made
it,
but
something
we
did.
We
did
kind
of
agree
on
our
at
least
I,
think
I
I
think
it
probably
I
think
the
progress
was
made
in
the
discussion
that
the
notion
that
we're
that
we
just
wanted
to
do
proxying
and
kind
of
tunnel
requests
across
is
not
you
know.
It's
probably
not
the
case.
That's
not
what
what
what
at
least
for
end
is
trying
to
do
with
this
three
but
yeah,
so
that's
correct
in
some
other
way.
D
Yes,
third,
we
went
the
the
opposite
that
we
would
be
that
we
would
be
passing
it
through.
The
the
the
the
stack
are
are
don't
it's
currently
designed
yeah
I
mean
look
doing
verify
permissions
by
looking
at
local
information
or
locally
cached
information
is
not
is
not
the
intent
yeah
being
coerced
to
doing
that.
A
So
my
thinking
on
this
is
that
maybe
we
don't
actually
want
it
to
be
a
zipper
abstraction,
but
we
want
to
build
a
new
abstraction
for
use
by
d4n
and
potentially
other
things
that
looks
a
lot
more
app
oriented,
that's
easier
to
proxy.
That
way
and
I
know,
there's
interest
in
d4n
being
able
to
use
other
zipper
stores
like
rados
or
otherwise,
for
its
cash.
But
maybe
the
app
oriented
interface
would
map
pretty
easily
to
a
zipper
store
in
that
case,
but
for
the
S3
proxy
it
would
be
its
own
implementation.
D
Quite
I
mean
so
I
understand
how
you're
saying
that
I
mean
if
you
wanted
to
do
like
an
S3
proxy
like
S3
mirror
or
that
framework
that
was
contributed
that
but
like
what
do
you
mean
by
the
the
way
d4n
would
use
S3
being
amenable
to
being
a
zipper
story,
and
the
other
usage
copy
I
mean
I,
mean
I'm
interested
in
that
and
I'm
interested
in?
How
that?
How
that?
How
that?
D
How
that
other
one
that
would
be
that
would
be,
that
would
match
up,
would
would
work,
or
maybe
a
mister
saying
what
you're
saying
I
mean
as
long
as
if,
if,
if,
if
there's
a
different
interface,
but
that
interface
can
consume
zipper
back
ends,
you
know
that
may
also,
or
at
least
or
or
sorry
I
mean
deferranean
is
a
consumers
of
their
back
ends,
but
the
deeper
ending
stability
brand
on
S3
it.
It
may.
A
D
D
For
example,
let's
let's
it
write
or
read,
objects
onto
S3
I
mean
that
that
just
becomes
maybe
its
own
thing.
Is
that
fair?
It's
a
zipper.
It's
a
zipper
filter.
It
does
it
off.
It
authorizes
the
request
coming
in
and
when
it
needs
to
store
something
or
retrieves
something
it
uses.
Something
that
isn't
zipper
is
that,
where
is
that?
Partly?
Is
that.
A
D
A
Well
right
so
one
of
the
targets
for
d4n's
I,
guess
it's
the
caching
layer
that
it
wants
to
proxy
to
S3
and
is
that
the
right
terminal
terminology?
Well,
this
new
thing.
This.
D
Newer
thing:
well,
yeah
I'm,
not
sure
I
mean
I,
mean
I,
mean
Iran
and
the
students
brought
in
like
at
the
end
of
last
year,
or
maybe
sometime
last
year,
this
a
use
for
the
S3
filter
where
they,
where
they
just
kind
of
want
to
proxy
a
large
number
of
things.
But
then
they
want
to
prototype
new
behaviors
in
the
middle.
Somehow
I
don't
know
if
that's
quite
the
same
as
deep,
it's
not
what
d4m
was
originally
doing
and
I'm,
not
exactly
sure.
D
A
A
C
D
A
A
B
A
C
B
C
A
A
B
So
you're
severely
limiting
the
S3
API
to
just
data
yeah,
okay,
so
then
there's
no
reason
you
couldn't
do
that
as
a
zipper
as
a
zipper
filter.
It's
just
that
S3
has
to
be
on
top
of
whatever
other
store
holds
the
real
data
and
it
just
intercepts
the
data
stuff
and
does
with
it
right,
which
is
how
we're
developing
it
now.
D
B
Yeah
I
mean
the
issue
is
right:
what
I'm,
what
I'm
misunderstanding
or
I
think
is
that
once
we've
broken
the
opcalls
down
into
zipper
calls
we
can't
re-create.
The
original
op
calls
right,
and
so
we
have
to
then
be
doing
a
subset
of
actual
S3
Ops
based
on
the
zipper
calls
well,
and
at
that
point
you
can
do
it
via
the
zipper
API
you
just
Implement.
Only
those
calls.
B
D
D
At
all,
but
I
also
sort
of
think
well
that
would
work
I
mean
if
to
be
fair.
My
you
know
my.
D
Is
it
zippers
interface?
Zipper
was
always
conceived
by
me,
at
least
as
being
as
being
a
kind
of
an
and
I
think
I
think
it's
name
implies.
That
was
you
know,
but
when
we
talked
about
it
in
general
terms
before
we
typed
all
of
it
that
it's
sort
of
an
interlocking
piece
below
the
app
layer,
it
it
and
and
I
always
assumed
that
it
knew
something
about
Ops,
so
that
made
some
but
but
as
it
developed,
you
know
it's
it's
not
it
hasn't.
D
D
Could
understand
basically
what
it
was
doing
and,
and
it
could
more
easily
I
don't
know
from
everywhere,
but
that's
right
term
is
more
more
easily
mask
variously
report.
The
the
response
of
the
upper
layer
in
a
way
that
allowed
it
to
continue
basically
until
until
I
got
to
the
point
where
it
wants
to
do
whatever
it's
going
to
do,
but
I
think
I'm,
not
sure
I'm,
not
sure,
that's
really
it's
I
mean.
Maybe
maybe
we
need
an
audit
of
what
zipper.
So
you
can
see
and
see
whether.
D
B
B
D
A
D
D
B
Mean
all
of
these
attributes
are
created
and
stored
above
the
line
right,
they're
they're
not
created
within
rato,
store
or
anything
like
that.
These
are
all
op
layer
attributes
right.
If
the
problem
is
that
the
namespace
is
conflated
with
the
actual
user
attributes,
then
maybe
we
need
a
separate
namespace
for
them.
But
you
know
this:
this
is
a
generic
data
store
that
the
app
layer
is
making
use
of
to
store
its
generic
data.
B
And
maybe
that
generic
data
needs
to
look
like
something
else,
I
mean
clearly
the
data
types
that
we
are
storing
in
these
things
came
from
rados
there's
no
question
of
that
right.
Well,
but
but
these
are
our
data
that
that
we
created
above
the
line
and
stored
above
the
line
and
are
checking
above
the
line
and
using
above
the
line.
D
D
That
has
to
be
true
can
actually
be.
It
has
to
be
possible
to
usefully
virtualize.
A
D
D
D
D4N
wants
to
be
able
to
be
above
above
other
stores
and
it
wants
to,
and
it
wants
to
be
able
to
redirect
accesses
for
data
and
attributes
are
presented
as
S3
results
back
back
up
to
clients,
if,
if
I
want
to
make
sure
that,
if
we,
you
know
that,
that's
that's
still
that
that's
still
the
case
that
the
the
the
the
the
zipper
is
suitable
for
that.
D
Converse,
you
know,
separately
or
or
collaterally
I
mean
d4n,
wants
to
be
able
to
store
and
retrieve
basically
objects
and
and
and
it
doesn't
care
about
Ops.
But
you
know
accepting
symptoms
as
far
as
that
makes
makes
the
workflow
work
for
d4n.
So
in
D3
and
the
same
so
you
know
we
want
to
be
able
to
say
well
this
the
subject
is
in
cash
and
go
get
it
from
there
with
its
attributes,
go,
go
to
a
head
on
it
there
or
go
check
the
data.
D
You
know
the
the
other
cache
information
and
decide
whether
we
should
store
it
in
cash
or
whether
we
should
rewrite
it
somewhere
else.
It
wants
to
be
able
to
do
those
things
on
on
various
backends
it
again
yeah
it
doesn't
that
that
doesn't
that
doesn't
require
that
that
actually
isn't
based
on
on
S3
Ops.
It's
based
on
get
input
and
delete,
and
maybe
a
list.
C
D
B
B
D
B
I,
buy
I,
buy
I,
buy
that,
and
but
the
zipper
is
not
designed
to
be
able
to
work.
That
way,
you
can't
you
cannot
have
that
without.
You
cannot
cannot
do
it
without
also
having
bucket
objects
and
user
objects
right
and
all
this
other
crud
that
has
to
exist
in
memory,
because
the
app
layer
uses
that
memory.
D
But
I
always
assumed
that
the
the
consumer
of
like
the
S3
layer,
would
would
present
users
and
bucket
user
and
bucket
handles
appropriate
to
doing
the
operation,
but
not
not
that
they
would
always
be
sort
of
flowing
through
from
above
all,
the
time
I
assumed
that
it
would
that
it
would
impersonate
those
things
in
some
cases,
maybe
always
in
the
case
of
like
users.
B
B
Implementing
S3
as
a
filter,
it
has
to
have
all
these
things
because
we
have
to
be
able
to
run
it
and
use
it
and
test
it.
Okay,
right,
and
so,
if,
if
we
really
want
to
have
all
of
these
things
impersonated
by
the
layer
above
S3,
then
we
need
to
stop
working
on
S3
and
finish
d4n
before
we
can
work
on
S3.
Well,
that
might
be
appropriate.
D
D
B
C
D
Variables
that
I'm
losing
track
here
but
but
I,
know
that
I
I
see
two
pass.
They
both
come
from
from
a
mass,
open,
Cloud
and
our
project
is
more
I
I'm
only
really
I'm,
mostly
interested,
not
in
S3
proxying,
although
around
speak
I'm
interested
in
that,
but
I'm
interested
in
making
d4n
work
and
making
d4n,
excellent
and
so
I
need
to
I
need
the
ability
to
interpose
something
that
that
you
know
that
that
allows
us
to
do
what
d4n
did
Upstream,
but
do
it
in
a
in
a
manageable
extensible
manner.
A
D
D
An
extra
detail,
but
it
could
do
right
it
should
it
shouldn't,
be
required
to
have
right
and
I
mean
the
simple
and
the
simplest
model
enough
people
to
say
Consulting.
The
directory
is
the
place
where
the
decision,
or
at
least
state
statement
required
by
the
caching
algorithm
tells
us
whether
it
is
resident
whether
it
should
be
resident
and
if
either
of
those
where
and
it
needs
to
be
able
to
redirect,
and
it
could
in
addition
to
that,
it
could
be.
We
could
we
could.
We
could
optimize
it
various
ways.
D
B
With
a
caveat,
so
the
cash
version
of
the
object
has
to
have
all
of
the
data
and
metadata
for
that
object.
Otherwise,
you're
going
to
have
to
call
and
do
the
normal
back
end
anyway,
and
there's
no
point
in
using.
D
D
A
D
That's
true,
then,
that's
a
huge
win.
If
that
that's
a
huge
step
forward,
if
that's
possible,
you
always
assume
that
would
be
possible.
I
mean
that's
been
sort
of
how
I
imagined
it
all
worked.
Then
it
could
fake
up
that
that
the
cat
that
catch
layer
could
fake
up
things
and
and
make
the
workflow
eventually
continue.
D
A
D
D
D
I
I
want
to
say,
I,
know,
I'm
not
trying
to
make
it
harder,
but
I'm
trying
I'm,
trying
I'm
trying
to
preserve
the
mental
model
here
where
d4n
has
a
has
hasn't
hasn't
hasn't,
has
a
has
a
has
a
set
of
of
strategy,
as
has
a
strategy
there,
where
I
can
do
or
different
things
it
it
shouldn't
it.
Should
it
shouldn't
it
shouldn't,
be
biased
towards
thinking
that
rados
is
local
and
or
not
or
or
not,
local
or
something.
D
So
if
the
data
is
is
if
the
data
is
invados,
then
it
has
to
be
able
to
use
radus.
That's
that
we
treat
that
as
magical,
because
it's
our
thing,
but
but
then,
but
if
the
data
is
in
memcached
here,
if
data
is
in
an
S3
or
whatever
what
it
has
to
go,
get
that
with
whatever
mechanism
that
for
authorization.
That
thing
has.
A
D
D
C
D
Temporal
cash
at
best
right
now,
but
I
don't
disagree
with
you.
I
mean
that
what
you're
saying
is
more
is
the
most
correct.
You
know
when
we
could
do
it,
but
we
could,
but
we
could,
but
we
could
probe
and
get
get.
You
know,
get
attributes
or
something
with
with
a
git
app
but
you'd
have
to
factor
in.
You
know
that
it
could
be
different.
The
next
time
I,
don't
I,
don't
I,
don't
know,
I,
don't
know
how
that
hasn't
even
been
thought
through
by
d3n
to
be
honest
or
d4n.
D
Well,
zipper
should
be
I,
mean
I,
think
I.
Think
we
made
progress
on
that
yesterday,
I
mean
zippers
should
be
well
the
zipper
the
d4n
driver
should
be
deciding
whether
it
wants
us
to
do
whether
it
wants
this
request
to
succeed
whether
it
wants
to
make
the
attempt
to
go,
get
or
go
put
or
go
or
go
list
date.
A
D
It
all
depends,
but
let's,
but
but
some
of
them
will
and
some
of
them
won't
and
that's
really
the
one
that
will
I
mean
we
presumed
yesterday
too,
that
there'd
be
some
credential
mapping.
So
we
presume
that
we
are
gonna,
impersonate,
somebody
or
or
or
or
whatever
we're
gonna
use.
Some
quick
and
it's
like
some
S3
credentials
that
we
expect
to
work,
but
it
may
not
and
go
do
whatever
the
app
is
thus
far.
Yes,
right.
A
I'm
thinking
about
more
along
the
cases
where
the
back
end
is
rados
cluster
or
a
DB
store,
or
something
that
currently
expects
us
to
happen
in
the
app
layer
instead.
Well.
B
A
B
Because
it
has
to
know
what
back
end
it's
authenticating
to
and
that
may
be,
it
may
have
different
results
based
on
what
authentication
backend
it
has
right.
I
mean
it
may
have
suppose
it
has
four
different
stores
right
and
you
know,
two
caches
and
different
users
have
different
access
to
different
combinations
of
stores
and
caches.
D
B
D
B
And
the
way
the
way
zipper
is
set
up
right
now
it
has
to
because
the
stack
of
blah
blah
blah
blah
blah
that
results
in
that
cell
object
has
to
know
ahead
of
time,
which
the
branch
to
call
down
to
create
the
correct
you
know
object.
You
can't
can't
swap
around
Stacks
Midstream
for
an
object,
the
way
it's
currently
designed,
and
that
would
be
work
to
to
be
to
enable
that.
A
So
you
still
think
that
the
S3
proxy
could
be
a
full
zipper
implementation,
so.
D
B
A
D
A
So
is
S3
as
the
cache
d4n
like
that's
a
requirement
of
it,
or
is
it
just
any
any
back
end
that
can
function
as
a
cache?
Maybe
the
S3
thing
is
just.
D
B
D
I
agree:
yes,
mathematics,
developed
computer,
Computer
Engineering
agrees
with
us,
but
but
but
it
shouldn't,
but
computer
science
size
weekend
or
programming
says
we
can
make
them
abstractions.
That
can
be
stacked
any
way
we
want.
That
could
be
a
graph
yeah.
A
I
I
still
have
some
on
some
unanswered
questions
about
exactly
what
the
zipper
read
and
write
paths
look
like
and
how
we
would
map
those
both
to
HTTP
requests
and
to
the
d3n
work.
That
pritha
is
working
on.
B
D
B
D
B
B
D
I,
don't
know
I
I,
don't
I,
don't
think
that.
Well,
maybe
maybe
it's
possible
to
make
a
sub
driver
or
I.
Don't
know
to
do
a
use,
a
subset
of
one
of
one
driver,
I
I,
don't
I,
don't
I,
don't
think
it
should
be
necessary
for
the
for
the
posix
file
driver
and
and
this
data
cache
thing
to
be
the
same
it
doesn't.
B
D
And
if
that
could
be
a
subset
of
zipper,
that
would
be
ideal
because
then
it'd
be
easy
to
type
one
I
thought:
that's
I
thought
that's
what
you
kind
of
got
when
you
had
when,
like
a
store
driver
inherited
from
something
generic
that
provided
the
basic
stubbed
up
operations.
D
D
D
You
want
a
rich
layer
that
lets
you
implement
things
like
rados
and
new
and
back-ends,
and
and
potentially
the
zip,
the
d4n
layer
itself,
but
when,
when
D
foreigners
needs
to
punch
down
and
pop
up
and
staying
things,
then
I
don't
think
that
necessarily
maybe
it's
more,
maybe
it's
more
efficient
to
think
of
that
as
a
smaller
interface
I,
don't
know
if
that's
something
that
Casey
had
already
said,
but
maybe
I'm
thinking
of
it
differently.
I
I
think
that's
a
narrower
interface
and
and
and
and
not
hard.
It
doesn't
have
all
those
objects.
A
Yeah,
that's
where
I
was
going
initially,
but
yeah
I'm
still
not
sure.
D
A
Yeah
I
still
feel
like
the
the
hardest
part
to
get
started,
is
gonna,
be
adapting
our
existing
read
and
write
apis
and
zipper
to
fit
both
the
cache
and
the
this.
This
proxy
idea,
but
maybe
working
with
preetha
just
on
the
d3n
side
and
getting
that
working
with
the
existing
cash
back
end
would
be
a
good
start.
Then
we
could
add,
you
know
whatever
abstract
we
we
need
out
of.