| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
LP: #1115833
|
|
This change adds the ability to provide specific package versions to
Distro.install_packages and subsequently Distro.package_command. In order
to effectively use Distro.install_packages, one is now able to pass a
variety of formats in order to easily manage package requirements.
These are examples of what can be passed:
- "package"
- ["package1","package2"]
- ("package",)
- ("package", "version")
- [("package1",)("package2",)]
- [("package1", "version1"),("package2","version2")]
This change also adds the option to install a specific version for the
puppet configuration module. This is especially important here as
successful puppet deployments are highly reliant on specific puppet
versions.
|
|
Augmenting the package version support to be available when specifying
extra packages to be installed at boot via the 'packages:' yaml key. This
change also improves type checking and add a configuration example to the
docs.
|
|
Right now, all distros but ubuntu will fail to manage /etc/hosts.
This is due to the fact that the templates are named:
- hosts.ubuntu.tmpl
- hosts.redhat.tmpl
The config handler is specifically looking for a template with the
given distro name.
This change addresses this issue.
|
|
Quick chat with ctracy indicated that this is just as well run
PER_INSTANCE, and it is more consistent with other things that way.
|
|
This change adds the ability to provide specific package versions to
Distro.install_packages and subsequently Distro.package_command. In order
to effectively use Distro.install_packages, one is now able to pass a
variety of formats in order to easily manage package requirements. These
are examples of what can be passed:
- "package"
- ["package1","package2"]
- ("package",)
- ("package", "version")
- [("package1",)("package2",)]
- [("package1", "version1"),("package2","version2")]
This change also adds the option to install a specific version for the
puppet configuration module. This is especially important here as
successful puppet deployments are highly reliant on specific puppet
versions.
|
|
Managing resolv.conf can be quite handy when running in an environment
where you would like to control DNS resolution, despite being provided
DNS server information by DHCP. This module will allow one to define the
structure of their resolv.conf and write it PER_ONCE.
Right now this makes the most sense on RedHat, and therefore, has defined 'distros' as such.
Note that when a config drive is used, and dhcp is not used that this module
may not be applicable since in the RedHat based distros the config drive typically
contains a ubuntu style network configuration which contains nameservers that can
be used in /etc/resolv.conf, but for other types of datasources it is useful to
have a module which can be specifically configured to write out /etc/resolv.conf
|
|
When the old user: style entry is found, don't forget that
we need to use the distro settings that are provided but
override the name with the new name, this is now accomplished
by merging them together in the correct order (using the standard
cloud-init merging algo).
|
|
Often it is convenient to classify a distro as being part of an
operating system family. for instance, file templates may be
identical for both debian and ubuntu, but to support this under
the current templating code, one would need multiple templates for the
same code.
Similarly, configuration handlers often fall into the same bucket: the
configuraton is known to work/has been tested on a particular family
of operating systems. right now this is handled with a declaration
like:
distros = ['fedora', 'rhel']
This fix seeks to address both of these issues. it allows for the
simplification of the above line to:
osfamilies = ['redhat']
It also provides a mechanism for operating system family templates.
|
|
When the old user: style entry is found, don't forget that
we need to use the distro settings that are provided but
override the name with the new name, this is now accomplished
by merging them together in the correct order (using the standard
cloud-init merging algo).
|
|
Previously if a legacy user: XYZ entry was found, XYZ would not automatically
be promoted to the default user but would instead just be added on as a new
entry to the normalized user list. It appears the behavior that is wanted is
for the XYZ entry to be added on as the default user (thus overriding a distro
provided default user), which better matches how the code previous worked.
LP: #1100920
|
|
Forgot to pass cfg to this function, and thus this would have never
worked.
|
|
Managing resolv.conf can be quite handy when running in an environment
where you would like to control DNS resolution, despite being provided
DNS server information by DHCP. This module will allow one to define the
structure of their resolv.conf and write it PER_ONCE.
Right now this makes the most sense on RedHat, and therefore, has defined
'distros' as such.
|
|
previously, there was an attempt in the config drive source to limit
the source device to a "full block device" rather than a partition.
This was done by a simplistic approach of checking that the last
character of the name was not a number. That was filtering out
CD-rom devices (sr0).
Now, we have a bit more sophisticated approach to that same problem.
We filter out block devices that have a 'partition' entry in
/sys/class/block/DEVICE_NAME/partition .
LP: #1100545
|
|
Right now, all distros but ubuntu will fail to manage /etc/hosts. This
is due to the fact that the templates are named:
- hosts.ubuntu.tmpl
- hosts.redhat.tmpl
The config handler is specifically looking for a template with the
given distro name.
This change addresses this issue and is contingent upon support of
'osfamilies' as implemented in LP: #1100029
(lp:~craigtracey/cloud-init/osfamilies)
|
|
accidentally removed a line between two functions.
|
|
often it is convenient to classify a distro as being part of an
operating system family. for instance, file templates may be
identical for both debian and ubuntu, but to support this under
the current templating code, one would need multiple templates for the
same code.
similarly, configuration handlers often fall into the same bucket: the
configuraton is known to work/has been tested on a particular family
of operating systems. right now this is handled with a declaration
like:
distros = ['fedora', 'rhel']
this fix seeks to address both of these issues. it allows for the
simplification of the above line to:
osfamilies = ['redhat']
and provides a mechanism for operating system family templates.
|
|
Previously cloud-config to get a '/dev/sr0' entry written to /etc/fstab
would have had to have the full /dev/sr0. This change allows cloud-config
to reference it without the '/dev/' prefix. Like:
| mounts:
| - [ sr0, /media/sr0 ]
|
|
Changes in revision 753 broke cloud-init on ubuntu, as it has a different
dhclient directory than Fedora where the change was developed and tested.
This change does 2 things:
* searches multiple directories (including /var/lib/dhcp) for the lease
files.
* adds a fallback to the old code path of choosing the default route
as the virtual router if there were no virtual routers found in the
lease files.
LP: #1089989
|
|
This simiplifies the logic, by just making it independent of 'system'.
LP: #1096423
|
|
Instead of only not locking when system is present
the logic should handle the correct case when lock
password is set and system is not present.
LP: #1096423
|
|
LP: #1096417
|
|
|
|
In CloudStack's documentation, it is stated that meta/user-data can be
retrieved from CloudStack's Virtual Router [1].
However, cloud-init retrieves these information from default gateway. VR
and default gateway may be the same machine (i.e. have the same address)
in some cases, but that is not be always true (actually, in my case, it is
not).
This change searches the lease files in /var/lib/dhclient to pick out
the dhcp-server-identifier.
It admittedly does make this specific to dhclient.
--
[1] http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/user-data-and-meta-data.html).
LP: #1089989
|
|
|
|
Invoking 'initctl reload-configuration' is only required if inotify
does not work. overlayroot does not support inotify. So, we just
call initctl always, which wont hurt anything.
LP: #1080841
|
|
After parsing and merging datasource's config, the changes in were not making
it into the datasource's 'distro.
The end result was that the when a config module was called, it's 'cloud'
argument would be updated in 'cloud.distro', but not in
'cloud.datasource.distro'. This path was required for getting mirror settings
to take affect, because they include information from the datasource.
Ie:
cc_apt_configure had
mirror_info = cloud.datasource.get_package_mirror_info()
the datasource then used *its* copy of sys_cfg to call
self.distro.get_package_mirror_info
and *that* distro's sys_cfg had not been updated.
LP: #1090482
|
|
This adds 'omnibus' to the values supported for chef's "omnibus_url" config
option. It also:
* makes 'omnibus_url' configurable in cloud-config.
* adds a 'force_install' flag, to allow the install code to
act even if /usr/bin/chef-client is already present.
|
|
|
|
Thanks to Anatoliy Dobrosynets
|
|
The Init._read_base_cfg() was really a static function, this just moves
it to its own static function. Its not used anywhere else at the moment.
|
|
when /etc/ca-certificates.conf is read by update-ca-certificates
lines after a blank line get ignored. Here, ensure that
there are no blank lines, and no duplicate entries for cloud-init are
added.
LP: #1077020
|
|
resize_root: noblock
has been broken in the 0.7.0 series. Using it would disable resizing.
LP: #1080985
|
|
|
|
|
|
LP: #1079002
|
|
|
|
- Instead of always reading the previous hostname file even if it
did not exist lets only read it if it is a valid variable and is
actually a existent file instead of just attempting to read it
always.
- Also update the logging that is done when a previous file does not exist.
LP: #1078452
|
|
|
|
Instead of always reading the previous hostname file even if it
did not exist lets only read it if it is a valid variable and is
actually a existent file instead of just attempting to read it
always.
LP: #1078452
|
|
This check is a waste of a stat any time after the migrator module
had run. As it would take care of moving markers.
However, if the user runs:
sudo cloud-init modules --mode final
after an upgrade, they'd otherwise run any module that had a '-' in its
name again. To avoid that, we just return true in that case, and
inform the user how to run the migrator themselves.
|
|
the migrator was not renaming items in the "cloud" semaphore path.
Those were items that would run once only.
Now we just check both ipath('sem') and cpath('sem')
|
|
this adds 'power-state-change' config module that allows the user to
specify in cloud-config syntax that a system reboot or shutdown should occur
after cloud-init is done.
|
|
|
|
It seems like its possible that boto 2.5.2 and below have the lazy loading
metadata dictionary so as a precaution we will always take the hit of
unlazying the metadata dictionary by traversing it which in the non-lazy
dictionary case has no effect (its marginal). This also removes the need
to check the boto version and the dependency on setup tools just for this
case.
|
|
The sleep is added here simply to not completely spin cpu on waiting
for the parent pid to die.
the allowing of errno 3 is because I was getting this. I dont have
a perfect explanation, but I suspect that the 'open' was actually
getting this back from the /proc filesystem after the pid had died.
Possibly in the window between when the 'open' was done and the 'read()'
was done.
|
|
It seems like its possible that boto 2.5.2 and below have
the lazy loading metadata dictionary so as a precaution
we will always take the hit of unlazying the metadata dictionary
by traversing it which in the non-lazy dictionary case has
no effect (its marginal). This also removes the need to check
the boto version and the dependency on setup tools just for
this case.
|
|
|
