This appears to be an unmaintained fork of the original code, which
lives elsewhere [1]. Kill it.
[1] https://github.com/cloud-init/cloud-init
Change-Id: I1f57197f1f67aa6adce152b5e4acc63a72277c6a
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Add missing files and tweaks so that the automated
CI/flake8/pep8/docs/... and such work correctly.
Change-Id: I838b02bf0037569065b7c7914f4a68b92d7ebd6a
To make it so that cloud-init is installable in a virtualenv
where it can be tested in an isolated scenario we need to avoid
using and including datafiles (which won't be written into the
virtualenv) and also avoid using our initsys helper class which
also adds on its own files when we are being ran from a virtualenv.
a.) appease pylint on raring, as it doesn't like subprocess
pylint: 0.26.0-1ubuntu1
This is mentioned in comments at http://www.logilab.org/ticket/46273
b.) tests/unittests/test_util.py:
the mountinfo lines are longer than 80 chars.
Just disable long lines complaints for this file.
This brings with it other changes, and also makes an install
install all of the requisite init files. (ie, cloud-init needs the -local and
the non-local)
Let the package building solutions figure out exactly which
of these they wish to delete or wish to take, since setup.py
can not know it just has to install them all.
since not all distros fully support upstart that is in config here or even have upstart in general at all (for various reasons)
2. Found out that we really do need to specify these 2 packages due to the following
a. The cloudinit root needs to be a package (pretty obvious)
b. Not so obvious is the cloudinit.conf also needs to be a package so that its modules can be directly imported without
referring to the module name.
* debian.trunk/changelog: increase debian version to '1' to avoid lintian
error
* debian.trunk/control: bump standards version
* debian.trunk/rules: remove cloud-init-run-module symlink (been deprecated
for some time)
* tools/bddeb: read version from ChangeLog rather than setup.py
This replaces cloud-init-run-module (which was probably rarely or never used)
with 'cloud-init-per' which does basically the same thing, but doesn't
support "modules".
Stephen Finucane