-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 15/09/13 20:04, Bastian Blank wrote: > 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.
Ceph itself uses a key based kerberos style authentication system called cephx; the ceph_rest_api library uses the keys/config in /etc/ceph but provides no additional auth for HTTP API access; neither does the wrapper ceph-rest-api which is why right now there is no init script or upstart configuration for this feature. I make no general observations about the python code in ceph other than it's worked well for me for the last 18 months. > >>> 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. Technically its just two - gdisk and parted; I don't have any strong objection to upstream using two different tools if it makes massaging block devices easier for them. >>> 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. I'd like to try and play nice with other methods of distribution especially if one of those has been used extensively by Debian users to-date; makes life easier for potential users of these packages. >>> 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. OK; I know they are just a simple wrap over the core libs so that makes sense. >> 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. Meh - well it works for me; the -java is arch independent whereas the - -jni is not; saves duping the jar file in binary packages. If the -jni every gets multi-arched then this approach is required anyway. >> 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. I don't think the ceph packages are split for no apparent reason; I believe that by adopting the current structure which works with the most popular deployment tooling for ceph we work with upstream, rather than going against the grain. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJSNhlBAAoJEL/srsug59jDgQgQAM91nm57XBaWGQoxJ6mC7hy3 n0hsT9ehI+FJDL2nC9jr1vSBCMgQKgfkt4LHrBXUt4t/Dz6YVu1vwZbmrhfP36Bi O1WcZ+StIJZaBxHYq37XheoLqShR39VSPfGmp7dK5u0RBrcqj1PatVfF/oYrLSxL KSkqmccaOeAvbE0G4gGuceEuLnR6ZI1kgeJkFCE0daEtJdDe89ojj3PBRz6H4Ya0 zRSP3Es4YcHgEr6vlFV0+jDNrsuq72g/1kn+ouW0jLQQ+a9+12+v4kkVBNL4fUBj d9+2wwOEuiFOK1/tOGQjwc5XdOtPe+P6oHQ1uWoZzYOYOCw45+LDO6IIMgrr8+Xa QtolHNKPJtEr24myCowOkQ9tmbrx7YRzs/y7EMAo6faYI7ZPDc6gwRZESUtiqAuJ +HgyEGyqUjuJGOjQ0PIhB1KteJdJNoFFeAUAvbDh1UaEgMLdrRw+ZyFoC0NkeGjX 2xoHPIInN8v/qeOc1vGkwzCXg9SFe6VkVi338SU8M4k/nEGwPxr6TCgKs0bK+P9x lbdK17HPr5ZtzmoMyVT83WPTyIad7IfyeLOU2N0EX3zbWaBwp1NplZhKRx+qeAGP CYL5UdN0YQCXGiWbS4FFJrl2q603uuvq1FqiObGnMPZdjliBUnhqUXeBMgxuUNPB cj7DnhsMhZO2xBA91WqV =Mp6n -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
