On Tue, May 22, 2012 at 8:07 PM, Yehuda Sadeh <yehuda@xxxxxxxxxxx> wrote: > RGW is maturing. Beside looking at performance, which highly ties into > RADOS performance, we'd like to hear whether there are certain pain > points or future directions that you (you as in the ceph community) > would like to see us taking. > > There are a few directions that we were thinking about: > > 1. Extend Object Storage API > > Swift and S3 has some features that we don't currently support. We can > certainly extend our functionality, however, is there any demand for > more features? E.g., self destructing objects, web site, user logs, > etc. More compatibility with S3 and swift is good. > > 2. Better OpenStack interoperability > > Keystone support? Other? > > 3. New features > > Some examples: > > - multitenancy: api for domains and user management > - snapshots > - computation front end: upload object, then do some data > transformation/calculation. > - simple key-value api > > 4. CDMI > > Sage brought up the CDMI support question to ceph-devel, and I don't > remember him getting any response. Is there any intereset in CDMI? > > > 5. Native apache/nginx module or embedded web server > > We still need to prove that the web server is a bottleneck, or poses > scaling issues. Writing a correct native nginx module will require > turning rgw process model into event driven, which is not going to be > easy. > nginx module is nice thing. > 6. Improve garbage collection > > Currently rgw generates intent logs for garabage removal that require > running an external tool later, which is an administrative pain. We > can implement other solutions (OSD side garbage collection, > integrating cleanup process into the gateway, etc.) but we need to > understand the priority. crontab can handle this task for now, but in big workload, better if it's integrated, like scrub, and tuned via conf > > 7. libradosgw > > We have had this in mind for some time now. Creating a programming api > for rgw, not too different from librados and librbd. It'll hopefully > make code much cleaner. It will allow users to write different front > ends for the rgw backend, and it will make it easier for users to > write applications that interact with the backend, e.g., do processing > on objects that users uploaded, FUSE for rgw without S3 as an > intermediate, etc. > > 8. Administration tools improvement > > We can always do better there. > > 9. Other ideas? - I would like to see a feature that can make replication between clusters. For start 2 clusters. It's a very good feature, when you have two datacenters, and repliacation goes via hight speed link, but aplications at top of clusters does not need to handle this tasks, and data are consistent. - gracefull upgrade - reload cluster config without restart daemons - or maybe this exist right now ?? > > > Any comments are welcome! > > Thanks, > Yehuda > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- ----- Pozdrawiam Sławek "sZiBis" Skowron -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
