Ceph

h1. 1E - RADOS Gateway refactor into library internal APIs

h3. Live Pad

The live pad can be found here: [pad]

h3. Summit Snapshot

Coding tasks

# [Wido] Draft librgw API (informed by current rgw, and APIs of initial users that will utilize it... e.g. apache module interface, nginx plugin api, etc.)

# > Highest level API, where you just do GET and PUT

# [Yehuda?] Refactor rgw as need to match that interface

# [Gary] Repackage rgw bits into librgw (C++, C)

# > Lower level API for listing buckets, creating objects, etc, etc

# [Wido?] Python bindings for librgw

# Write rgwhttp (Python? Twisted Web server?)

# Write a MQ reader for Varnish (or any other caching reverse proxy)

Build / release tasks

# Package librgw

# Package rgwhttp (Own Git repository?)

# Package the MQ reader

Documentation tasks

# Document the API of librgw

# Document rgwhttp

# Write new documentation on how to set everything up

Deprecation tasks

# Remove RGW from the main repository

# Remove any old documentation

Other use cases:

# storing large objects with atomic replacement, collection/bucket indeces

# object expiration agents?  (instead of embedding in radosgw daemon)

# librgw could provide a migration path from Swift to native RADOS access without proxy server/gateway bottlenecks

OT: other S3/Swift API features we are missing:

# versioning

# object expiration (delete after, delete at)

# Swift temp URLs, #3454

# temporary security credentials

Comments

1. Why integrate with Varnish specifically? This doesn't seem very Ceph-related. It's basically an entirely different layer.

   For example, we have multiple layers of Varnish in our infrastructure in front of Apache/radosgw and we handle purges already via pre-existing mechanisms (multicast HTCP).

   I'm guessing most people have their own way of handling this (CDNs etc.). For some people this might just mean TTLs, others might care for instant purges.

-> Having a "hooks" system where radosgw invokes something e.g. on PUT/POST/DELETE operations could potentially solve this use case.

* -> We probably don't want this in librgw in the beginning, maybe in a later version. Could be handled by the HTTP server as well.

* perhaps a unix socket or fork/exec

2. Python isn't very good for performance and it's one of Swift's bottlenecks. This would seem a step backwards.

  -> It could be any language when librgw exists

3. Would it make sense to support WSGI middlewares in the Python webserver to provide an easier migration path from Swift?