On Sun, Sep 15, 2013 at 06:23:23PM +0100, James Page wrote: > On 15/09/13 12:03, Bastian Blank wrote: > > There is a python script ceph-rest-api. Where is this used? Why > > does it warrant a dependency on 20 other packages? > Dumpling (0.67.x) is the first release with basic support for a REST > api for administering a ceph cluster - this binary supports this > feature - but more of a demo of how to use than anything really usable > (dev mode only). However I do agree that it looks like it should be > in ceph.
How does the authentication work? The whole Python code in Ceph looks pretty bad for me. > > Because ceph-disk (another incompletely documented indirection) > > uses it. The important parts (ceph-mon, ceph-osd) works fine > > without it. > ceph-disk is a key part of the deployment infrastructure for ceph so > these are important dependencies for anyone deploying ceph at scale > using upstream Chef recipes or ceph-deploy. Well. Then it would be one, not three diffrent implementations of fdisk. > > Not a concern for Debian. It was never in a stable release. > I think it is a concern for Debian; the principle source of Ceph > packages for Debian to-date has been from upstream, so ensuring smooth > transitions to/from Debian/upstream is important IMHO. Nope. Other sources are no concern. > > At least the dependencies for librados2 and librdb1 needs to be > > stricter. The dependency on libcephfs1 is missing. > Agreed - python-ceph only just grew bindings for cephfs so that's just > an oversight. Good spot. >= on equiv binary package version should do > the job for the librbd/rados depends. Nope. They need to be ==. The (bad written) Python wrappers uses ctypes, which does not implement a full ELF-loader. > Laszlo - re -java/-jni split - this is in compliance with the Java > packaging policy: > http://www.debian.org/doc/packaging-manuals/java-policy/x114.html You forgot the "should". Plus this is not part of the Debian policy. > I really think we need to stick with the packaging structure and > naming that is already in place as much as possible; All of the > existing deployment tooling (chef, juju, ceph-deploy) is written based > on this structure on Debian based systems; diverging is just going to > create work in other areas and potentially alienate the Debian > packaging as its different to the packaging that the Ceph community > has been using for the last two years... at least! I'm talked to the ftp-masters. They usualy don't like if a package is split too much for no apparent reason. It is nice if they are compatible, but for Debian all problems have to be taken into account. Bastian -- Pain is a thing of the mind. The mind can be controlled. -- Spock, "Operation -- Annihilate!" stardate 3287.2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
