[ceph-calamari] distro packages for calamari

Tim Serong tserong at suse.com
Thu Oct 30 23:48:04 PDT 2014

Hi All,

Following up from our discussion in the Calamari session at CDS, here's
some notes on what I did to get openSUSE and SLES packages for Calamari.

* calamari-server and calamari-clients RPMs built on build.opensuse.org
at https://build.opensuse.org/project/monitor (SLES 12 packages are
currently only on our internal build server, but the source is identical
to what's on OBS).  If you go poking around calamari-server here, you'll
see a handful of additional patches.  Please ignore these; they're
mostly related to making a calamari-server-test subpackage, I just
haven't put them in git yet ;)

* Vagrant is not used for the build, so the dependencies don't all get
packed into a virtualenv, rather we rely on the dependencies also
existing as distro packages.  Some of these are already available on
openSUSE (and Fedora for that matter, and presumably other distros).
Some are not, or need updating (e.g.: diamond).  The dependencies that
weren't already packaged for the base openSUSE distros I also made RPMs
for (see above OBS project).

* Instead of installing to /opt/calamari, the various pieces are
installed in (pretty much) FHS paths:
  - global salt bits are in /srv/pillar, /srv/reactor, /srv/salt
    (because that's where salt installs things on SUSE).
    - local salt bits in /usr/share/calamari/salt
  - the frontend and calamari.wsgi are in /srv/www/calamari (this is
    correct by convention for SUSE, other distros might prefer /var/www
    or /usr/...)
  - calamari-ctl and cthulhu-manager in /usr/bin
  - alembic in /usr/lib/calamari/alembic
  - python (calamari_common, calamari_rest, calamari_web,cthulhu) in
    the site python directory (/usr/lib/python2.7/site-packages).

* supervisord is not used, because openSUSE and SLES 12 ship the
ever-increasingly-all-encompassingly-powerful systemd, so I added a
systemd unit file for cthulhu, and for carbon (the latter being in the
python-carbon package).  I assume this is appropriate for Fedora too,
but may or may not be for other distros/versions.

* There's no calamari-minions repo (the idea being if you've got distro
packages for everything, this becomes unnecessary).

The changes to the build are not huge, but the way I've got them at the
moment, it's just a replacement of /opt/calamari (and a couple other
things) with FHS paths, i.e. we wouldn't want to merge this to master
as-is because it'd break everything that wasn't a SUSE build.  Rather, I
suspect these paths need to be parameterized or sedded or something at
build time.  So that's one piece of work that needs to happen.

Here's the current changeset for reference:


Note the Requires and BuildRequires lines in the SUSE spec file in that
diff, these indicate the dependencies we have.

Next steps for supporting other distros would then, I think, be:

1) Parameterize target paths in the build somehow, so these can vary as
necessary per distro, also without breaking vagrant.

2) Make sure all the dependencies are packaged, or are otherwise somehow
easy to install for whatever distros we need to support.

3) Make packages available :)

Step 2 might be most irritating.

build.opensuse.org does support building packages for Fedora, Red Hat,
Debian and Ubuntu, so it might be interesting to enable this for the
systemsmanagement:calamari project and see what breaks.  Depending on
what's already available in the base distros, this may or may not be a
sensible approach (if, say, some distro is missing a lot of
dependencies, we'd end up having to package them too on OBS, which,
well, becomes a bit of a maintenance burden :-/ and would perhaps be
better dealt with by the upstream distro).

Finally, a note on calamari-clients.  Some time ago I added a
suse-tarball target to the Makefile, which runs build-real and tars
everything up so it'll extract under /srv/www/calamari.  So getting a
calamari-clients package is just a matter of running `make suse-tarball`
from the source tree, then shoving that tarball into a distro package
(see https://github.com/ceph/calamari-clients/pull/37/files).  The exact
same thing is probably suitable for other distros, except the
destination path might want to be /var/www/, or something else depending
on distro policy.


Tim Serong
Senior Clustering Engineer
tserong at suse.com

More information about the ceph-calamari mailing list