| Age | Commit message (Collapse) | Author |
|---|
|
sysvinit_freebsd argument. Specifying sysvinit will install the RH
scripts, which is wrong.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
smoser pastebins).
|
|
fallback to universally acceptable one.
|
|
tools/run-pep8 wasn't checking all python files.
tools/run-pylint wasnt checking bin/cloud-init
fixed resultant pep8 issues after finding them.
|
|
|
|
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.
|
|
|
|
|
|
|
|
to a variable of the name 'init_system' instead due to the param name being
'init-system'.
|
|
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)
|
|
type
which then later affects the installation of certain config files, which then
can be extracted during package creation as needed.
|
|
packaging solutions handle these
2. Get the cloud-init specfile working for the init.d case (with the right postun and post and install sections)
a. It works!!!
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
requirements to work
|
|
sometime (in a distro specific build?)
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
|
|
refactoring stuff and setup.py for both of those.
|
|
Just to avoid an entry in top level directory, get rid of profile.d there
and instead move Z99-cloud-locale-test.sh -> tools/Z99-cloud-locale-test.sh
|
|
|
|
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".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
At this point, this is appears much like a cripped 'ec2metdata' tool.
However, it does provide a tool interface to some fields independent
of their DataSource.
|
|
This will allow this code to be called more easily elsewhere.
I'm considering having the "all the way up" message contain fingerprints
so that they're more or less guaranteed to get to the console where
the user could see them.
|
|
|
|
This set of changes makes '/etc/cloud/cloud.cfg' support "#include"
and "#opt_include". The idea is to then provide a base configuration
and allow distro or local changes that would override that.
|
|
|
|
This was causing failure in debian packaging.
|
|
|
|
The new classes 'DataSourceNoCloud' and 'DataSourceNoCloudNet'
implement a way to get data from the filesystem, or (very minimal)
data from the kernel command line. This allows the user to seed data to
these sources.
There are now 2 "cloud-init" jobs, cloud-init-local that runs on
mounted MOUNTPOINT=/
and 'cloud-init' that runs on
start on (mounted MOUNTPOINT=/ and net-device-up IFACE=eth0 and
stopped cloud-init-local )
The idea is that cloud-init-local can actually function without network.
The last thing in this commit is "uncloud-init".
This tool can be invoked as 'init=/usr/lib/cloud-init/uncloud-init'
It will "uncloudify" things in the image, generally making it easier
to use for a simpler environment, and then it will exec /sbin/init.
|
|
|
|
|
