►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everyone
and
thank
you
for
coming
to
this
presentation
on
the
rgw
subsystems,
with
focus
today
on
workflow
the
request
workflow
today
we're
gonna
build
upon
the
last
rgw
presentation
by
talking
about
some
of
the
features
and
sub
components
of
the
rgw
itself.
Instead
of
just
telling
you
what
it
basically
is
and
how
d
how
you
can
interact
with
it.
A
Very
simply,
this
presentation
is
meant
for
new
rgw
developers
and
we'll
kind
of
finish
off
a
foundation
for
developers
on
what
the
rgw
is
I'm
and
future
presentations,
which
I'll
talk
to
talk
about
at
the
end,
we'll
go
into
some
of
the
sub
components
that
we
touch
on
and
talk
about
them
in
depth.
I.
Ask
that
you
can
please
hold
your
questions
until
the
end
of
the
presentation
and
I
want
to
remind
everyone.
This
is
recorded
and
I'll
show
the
link
once
it's
ready
later
today,.
A
The
right
us
gateway
admin,
talks
to
the
OSD
using
libera
DOS
and
creates
users
and
credentials
for
the
requires
to
do
operations
on
the
rgw
with
once
the
clients
have
read
and
read
sorry,
write
and
read
to
the
rgw.
Those
objects
go
into
the
OSD
using
librettos,
with
the
CLS,
providing
rgw
richer
set
of
liberate
those
features.
And,
finally,
the
monitors
know
about
the
existence
of
the
gateways
and
the
OS
DS
and
the
entire
cluster
itself.
A
So
the
rgw
itself
has
numerous
subsystems,
and
this
the
this
is
not
an
exhaustive
list,
but
some
of
the
bigger
sub
components
and
parts
of
the
code
base
that
we
want
to
just
touch
on
today.
The
first
one
is
the
front
ends.
Rgw
has
two
front
ends
our
web
servers.
One
of
them
is
Civet
web
and
that's
a
sub
module
in
the
source
tree.
That's
a
fork
of
the
open-source
project
with
SEFs
own
patches
applied
to
it.
A
The
second
is
beast,
and
that
was
written
by
KC
Bodley,
the
rgw
tech
lead
and
that's
based
off
the
boost.
Seo
library,
the
rgw
has
a
common
framework
for
doing
many
different
types
of
authentication.
That
is
a
entirely
different
presentation
in
and
of
itself,
but
we're
going
to
touch
a
little
bit
more
on
that
later.
Today,
the
rgw
has
structures
in
place
or
the
operations
that
both
the
s3
and
swift
protocols
implement
an
s3
and
swift.
A
A
For
multi-site
SEF
monitors
used,
paxos
I
mean
all
clients
have
to
talk
to
the
paxos,
though
the
monitors
but
Paxos
doesn't
work
well
over
wide
area
networks.
So,
since
you
can't
have
one
soft
cluster
running
over
two
cities,
you
have
to
have
to
set
clusters
and
multi-site
replicates
the
data
back
and
forth.
Instead
of
just
being
one
store,
garbage
collection
runs
in
the
background
deleting
objects,
and
it
makes
our
deletes
look
fast
because
we
delete
the
head
objects
and
then
delete
the
rest.
In
the
background.
A
Life
cycle
is
another
set
of
rules
you
can
set
on
a
bucket
and
there's
two
types
of
lifecycle
rules.
There
is
expiration
where
you
said
a
lifecycle
rule
in
a
bucket
and
say
that
it
will
get
deleted
after
let's
say
X
amount
of
days,
then
there's
also
a
transition
where
you
set
a
rule
that
says
after
X
amount
of
days.
We
want
to
move
this
bucket
from
one
ratos
pool
in
another
and
the
rjw
implementation,
or
in
amazon
in
s3.
You
move
it
from
s3
to
glacier.
A
The
right
house,
GW
admin,
it
encompasses
the
the
admin
command,
which
is
a
tool
that
allows
you
to
interact
with
different
features
of
the
clusters
without
actually
going
through
the
rgw
and
then
also
there's
an
NFS
plugin
for
NFS
Ganesha.
That
allows
the
rgw
to
do
NFS
today,
we're
going
to
touch
on
a
lot
of
the
some
components
I
talked
about
before.
A
A
Yeah,
it
is
a
main
function
for
the
request
and
that's
what
triggers
or
where
you
go
into
the
auth
engine
from
and
also
where
you
get
the
OP
and
within
the
RW
op.
It
calls
things
in
our
GW
trade
house
and
then
within
our
GW
trade
house.
We
see
actual
calls
to
liberate
O's
to
get
us
started
on
the
to
give
us
more
in-depth
information
on
the
front
ends.
I'd
like
to
turn
it
over
to
Casey.
B
B
S3
and
swift
are
both
HTTP
based
you're
familiar
with
web
development.
You
probably
think
of
the
front
end
is
the
thing
that
sits
in
the
browser
as
the
client-side,
but
for
rgw
or
the
HTTP
server.
So
we
think
of
the
front
end
is
the
server
part
that
accepts
incoming
client
connections
and
knows
how
to
read
and
write
HTTP
requests
and
responses.
B
There's
a
newer
front-end
that
justin
nautilus
became
the
default
beast
and
that's
a
C++
one
based
on
some
boost.
Libraries
that
can
do
is
synchronize
networking
and
oh
yeah.
The
front
end
is
where
each
request
comes
in,
and
the
next
step
after
reading,
a
request
is
to
pass
it
into
the
process.
Request
function
go
back
to
Ali
on
that.
A
Yeah,
as
Casey
mentioned,
each
of
the
front
ends
call
into
process
requests
and
at
a
high
level
process
request
gets
a
handler
it
does.
The
ox'
does
the
odd
steps
it
then
executes
and
completes
the
OP,
and
what
I'm
gonna
do
is
I'm
actually
going
to
jump
into
it
and
give
a
quick
overview
of
the
function
itself.
A
A
A
A
And
in
process
authenticated,
this
is
where
permission
checking
happens
where
s3
or
Swift
check
for
bad
parameters
or
headers,
and
then
the
office
actually
executed
there,
then.
Finally,
on
284,
the
client
is
actually
completing
the
request,
and
so
this
function
more
or
less
encompasses
or
kicks
off
all
the
steps
for
the
lifecycle
of
a
request.
B
All
right,
so
the
common
earth
engines
are
the
local
ones
which
are
based
on
users
that
are
created
with
red,
O's
GW
admin
and
store
it
in
Ray
DOS.
So
when
you
create
a
user
that
generates
credentials
for
it,
and
the
s3
in
Swift,
clients
use
those
credentials
assign
the
requests,
though
the
local
engines
are
the
ones
that
are
of
checking
those
signatures
to
authenticate
users.
B
There
are
external
engines
like
Keystone,
which
is
used
in
OpenStack.
First
whiffed
we're
working
on
a
new
STS
engine,
which
is
a
security
token
service
which
does
more
flexible
and
AWS,
compatible,
authentication
and
there's
there's
an
LDAP
engine.
Also,
though,
the
author
engines
are
responsible
for
authenticating
requests
and
also
representing
the
identity
of
the
users
that
are
authenticated
as
a
class
called
identity,
applier
that
the
rest
of
the
request
flow
can
check,
respect
to
who
the
user
is
and
what
their
permissions
are.
A
For
the
OP
slide,
I'm.
B
So
process
requests
is
called
into
the
auth
engine
and
authenticated
a
user.
At
this
point,
and
so
process
request
is
figuring
out
which
which
app
to
execute
some
examples
of
apps.
Are
things
like
creating
a
pocket
listing
a
bucket
uploading,
an
object,
downloading,
an
object
and
all
kinds
of
other
things.
B
So
we
have
a
lot
of
app
base
classes
in
our
dwh
ncc
and
for
things
that
we
need
to
specialize
or
Swift
and
that's
three
protocols,
basically
parsing
special
headers
or
special
request
formats
and
formatting.
The
responses
for
those
and
that
special
stuff
happens
in
our
GW
arrests,
s3
or
arrests.
Swift.
B
B
B
Basically,
mapping
the
swift
and
s3
view
of
buckets
and
objects
do
the
ones
that
we
store
in
Rados,
though,
some
of
the
key
concepts
here
are
bucket
metadata,
which
is
about
which
buckets
exist
in
the
system.
What
their
attributes
are,
what
policy
they
have
attached,
there's
also
a
bucket
index
for
each
bucket
that
contains
the
list
of
all
the
objects
that
are
contained
in
it
and.
B
Buckets
can
get
really
large,
so
we
have
a
strategy
for
sharding
the
bucket
index
across
several
objects
so
that
it
can
be
spread
across
OS
DS,
and
we
have
a
dynamic
residing
feature
that
can
do
this.
At
runtime
and
ali
touched
on
the
CLS
modules,
which
we
can
load
into
the
OSD.
There
is
a
CLS
rgw
module
that
does
most
of
this
bucket
index
work
there.
There
donnas
transactions
and
their
semester,
logging
that
happens
inside
the
OSD,
so
that
all
happens
in
CLS
rgw
and
for
the
representation
of
objects
themselves.
B
By
default,
we
we
stripe,
objects
across
four
megabyte
rights
and,
as
Olli
mentioned,
the
garbage
collection
as
cleaning
up
these
tale
objects
after
their
the
hat
is
deleted.
So
a
lot
of
the
stuff
you
can
find
in
our
GW
ray
dose
at
H
and
CC
and
as
I
mentioned,
the
the
bucket
and
Dex
stuff
is
all
in
cos.
Our
GW.
A
C
C
B
B
C
D
Redose
I
think
that
we
imply
that
that
was
Rickard
the
case,
but
basically
readers
uses
the
monitors
to
buy
the
locations
of
objects
in
the
cluster
and
it
does
talk
to
them
to
the
monitors
to
send
proof,
counters
and
other
and
other
data.
Personally,
I
started
that
going
through
to
the
manager
Casey.
D
A
Since
future
talks
are
gonna
jump
into
some
of
these
subsystems
that
are
on
the
slide.
I
was
wondering,
if
there's
anything,
that
the
people
on
the
on
blue
jeans
right
now
would
like
to
be
specifically
like
any
subsystems,
you'd
really
like
us
to
touch
on
first
or
how
you'd,
like
the
format
for
one
of
the
presentations
on
with
these
subsystems,
to
go.
What
do
you
want
code
walkthroughs?
C
A
C
A
B
A
Well,
if
there
anyone
else
has
any
other
ideas
feel
free
to
shoot
me
an
email
and
with
that
I'd
like
to
thank
everyone
for
coming
to
this
presentation
and
Casey.
If
we're
presenting
some
of
these
slides
and
helping
me
out
with
the
PowerPoint
I,
look
forward
to
seeing
everyone
at
more
presentations
and
I
will
make
sure
to
post
the
presentation
today.
Thank
you.