On Sun, Sep 15, 2013 at 1:03 PM, Bastian Blank <wa...@debian.org> wrote:
> There is a python script ceph-rest-api. Where is this used? Why does > it warrant a dependency on 20 other packages? > This is the as yet sparsely documented admin REST WSGI app (which can also run as a standalone server), which was a new feature in the 0.67 "dumpling" release. This should not be confused with the RADOSGW REST stuff. I have not looked at the source of the script yet, but have had a play with it. I suspect it depends on things like Jinja2 because it renders HTML tables for self-documenting purposes if you simply open the API with a web browser. This seems like a bit of an overkill for using a template engine like Jinja2, but oh well. If you make an API request using a "non-browser" client (e.g. wget or XmlHttpRequest), it returns JSON for the most part. I suspect this could be made a separate package, since it is not essential to running an OSD, MDS or mon. > > - Why ceph-mds? > > Ceph has three independent blocks. Metadata servers (-mds) are one of > > them. Please see the overview[1]. > > Yeah. But why does it need a different package? What does this extra > package bring for the user? > > Ceph MDS are not needed on every OSD, and are in fact only needed if using CephFS. If you're only using RBD pools and RADOSGW, then a MDS is completely unnecessary. Similarly, a mon is not needed on every Ceph node either. A typical setup consists of two or more OSDs (likely many more), three or more (preferably an odd number) monitors - either on selected OSD nodes, or separate servers, and one or more MDS nodes - but only if using CephFS. I only know of one or two people who've actually tried CephFS, and according to the developers, it should not be considered quite production-ready yet. Bear in mind however that OSDs, mons, and MDSs all use the same /etc/ceph/ceph.conf config file, making it potentially hard to split them into separate packages.
