| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
look in more places.
|
|
|
|
|
|
|
|
After user data handling splits apart all the different
content types into there various mime messages it is
nice to be able to have each message specify how it should
be merged (mainly for cloud-config or cloud-archive) into
the single cloud config that is eventually used. This
starts to add a plugable merging framework and the
needed components to activate said headers and merging.
|
|
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.
|
