| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows the user to easily run stuff even after cloud-init-final
has finished. The initial reason for it is to be able to run
/sbin/poweroff and not have cloud-init complain loudly that it is
being killed.
LP: #1064665
|
|
|
|
Fix how the comparison of a fqdn and its aliases was done
via sorting instead of existence checking which is the better
way to check if a alias already exists as well as cleanup
the new files pep8/pylint issues.
LP: #1078097
|
|
Previous commit set up an object for checking "None" in the stages class.
Here, change that to be None. The benefit of the DataSourceNone was so that
the stages was generally functional even with that "None" object.
The negative affect of that is that you could go down the error path much
longer when using it. If we use None type, then self.datasource.<something>
will fail immediately and loudly.
|
|
This just replaces the portions of stages.py that were checking or
setting self.datasource to a DataSourceNone to use a static/global
datasource. And then, check for None is done against that.
|
|
This does a couple things:
* separates out the 'normalize_public_keys' from the DataSource's get_public_ssh_keys
* uses that from config-drive datasource
* supports config drive v1 or v2 public-keys
* adds a test.
LP: #1077700
|
|
|
|
'public_keys'
|
|
|
|
|
|
other datasources populate 'public-keys' rather than 'public_keys'
and there is a more complete handler in the base DataSource.
So, to take advantage of that, have DataSourceConfigDrive copy
public_keys to public-keys, and remove the 'get_public_ssh_keys'
from the DataSourcEConfigDrive.
LP: #1077700
|
|
These changes were pulled out of the previous merge (cc_yum_add_repo)
as they were unrelated there. Re-applying them here.
|
|
Add in a configuration module that can write out the yum.repo format for
those that want to hook into different repos for installing.
|
|
|
|
|
