Re: Ceph Rpm Packages for Fedora 18
Thanks Gary. On Wed, Feb 20, 2013 at 10:34 PM, Gary Lowell gary.low...@inktank.com wrote: Hi Kirin - The Ceph 0.56.3 (Bobtail) release includes Fedora18 rpms. You can find those at: http://www.ceph.com/rpm-bobtail/fc18/x86_64/ Cheers, Gary On Feb 19, 2013, at 7:01 PM, Kiran Patil wrote: Hello, Ceph Rpm Packages are up to Fedora 17. May I know when will Fedora 18 Rpm Packages release scheduled? Thanks, Kiran Patil. -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RGW, future directions
Hello, How about this CloudFS management system ? The CloudFS management system consists of two parts: a very simple web-based management daemon called cloudfsd, and scripts to perform various discrete functions. http://git.fedorahosted.org/git/?p=CloudFS.git;a=summary http://git.fedorahosted.org/git/?p=CloudFS.git;a=blob;f=scripts/README.ssl;h=3547f6b354d8b3455359ea019f6db9ce74862d2e;hb=cloudfsd I am not sure, whether it can be reused for ceph. Thanks, Kiran. On Tue, May 22, 2012 at 11:37 PM, Yehuda Sadeh yeh...@inktank.com 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. 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. 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. 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? Any comments are welcome! Thanks, Yehuda -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RGW, future directions
Sorry I missed to send this link. http://git.fedorahosted.org/git/?p=CloudFS.git;a=blob;f=doc/mgmt_manual.md;h=bfcbbe9769f8726ecd1aefcf19e1159074971110;hb=HEAD On Wed, May 23, 2012 at 3:47 PM, Kiran Patil kirantpa...@gmail.com wrote: Hello, How about this CloudFS management system ? The CloudFS management system consists of two parts: a very simple web-based management daemon called cloudfsd, and scripts to perform various discrete functions. http://git.fedorahosted.org/git/?p=CloudFS.git;a=summary http://git.fedorahosted.org/git/?p=CloudFS.git;a=blob;f=scripts/README.ssl;h=3547f6b354d8b3455359ea019f6db9ce74862d2e;hb=cloudfsd I am not sure, whether it can be reused for ceph. Thanks, Kiran. On Tue, May 22, 2012 at 11:37 PM, Yehuda Sadeh yeh...@inktank.com 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. 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. 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. 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? Any comments are welcome! Thanks, Yehuda -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dedupe and compression in ceph
Hello, May I know when would it be possible to use the underlying btrfs features such as dedupe(offline) and compression for ceph cosds ? Is it possible to access btrfs features in cosd seamlessly ? -- Kind Regards, Kiran T Patil -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
