| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Config modules are able to declare distros that they were verified
to run on by setting 'distros' as a list in the config module.
Previously, if a module was configured to run and the running distro was not
listed as supported, it would run anyway, and a warning would be written.
Now, we change the behavior to skip those modules.
The distro (or user) can specify that a given list of modules should run anyway
by declaring the 'unverified_modules' config variable.
run_once modules will be run without this filter (ie, expecting that the user
explicitly wanted to run it).
|
|
|
|
LP: #1277746
|
|
|
|
|
|
get_url_settings should return a pair of max wait and timeout and not
false, fix this bug by checking the max_wait <= 0 in the calling function
and returning correctly from there instead.
|
|
- failing build due to missing Requires (changed to requirements.txt)
- RH: require sudo >= 1.7.2p2-3 (with sudoers.d/)
|
|
I'm not really sure what the function of tools/sudo was, and it was definitely
not required for fixing the rpm build.
|
|
If a datasource was found other than in /var/lib/waagent, and /var/lib/waagent
contained all the files necessary for 'wait_for_files' (most likely
'SharedConfig.xml'), then cloud-init would continue on before looking properly.
To address this, if the ovf-env.xml came from somewhere other than
/var/lib/waagent, and it differs from the file in /var/lib/waagent, then
we clean up some files that we expect to be provided by 'wait_for_files'.
Also some minor changes to the tests here.
LP: #1269626
|
|
|
|
|
|
|
|
|
|
get_url_settings should return a pair of
max wait and timeout and not false, fix this
bug by checking the max_wait <= 0 in the calling
function and returning correctly from there
instead.
|
|
|
|
|
|
|
|
Here we add the ability to read vendor-data from a file named
vendor-data at the same location as the user-data and meta-data files.
At the moment, vendor-data is not read at all from 'seedfrom'.
|
|
|
|
|
|
Due to bug in function "cloudinit.util.is_ipv4" an IPv4 address with zero (0)
at any component wasn't evaluated as IPv4 address.
E.g.: having local datasource with 192.168.0.1 in meta-data/local-hostname. The
correct behaviour would be to generate ip-192-168-0-1 hostname. With this bug,
the hostname (with IPv4) was considered as FQDN (no IPv4 inside) and just first
component (supposed to be hostname there) was taken. It generated hostname
"192".
Fixes for SmartOS datasource
1. fixed conflation of user-data and cloud-init user-data. Cloud-init
user-data is now namespaced as 'cloud-init:user-data'.
2. user-scripts (not user-data) are now fetched from the meta-data service
each boot and executed as in the scripts directory
3. datacenter name is now namespaced as sdc:datacenter
4. user-scripts will now have '#!/bin/bash' magically prepended
if the 'file' thinks its plain text and it does not start with '#!'
read_file_or_url: raise UrlError with 404 on ENOENT
This makes it easier to call read_file_or_url and handle file or url
errors. Now read_file_or_url will raise a UrlError in either case
on errors.
|
|
|
|
Here we add the ability to read vendor-data from a file named
vendor-data at the same location as the user-data and meta-data files.
At the moment, vendor-data is not read at all from 'seedfrom'.
|
|
|
|
|
|
|
|
This makes it easier to call read_file_or_url and handle file or url
errors. Now read_file_or_url will raise a UrlError in either case
on errors.
|
|
|
|
- There appeared to be a few logexc calls
that did not pass the logger in, fix those
locations where this occured.
- When a group member adding fails, log the
error and try the next member instead of
failing adding any more members
|
|
1. fixed conflation of user-data and cloud-init user-data. Cloud-init
user-data is now namespaced as 'cloud-init:user-data'.
2. user-scripts (not user-data) are now fetched from the meta-data service
each boot and executed as in the scripts directory
3. datacenter name is now namespaced as sdc:datacenter
4. user-scripts will now have '#!/bin/bash' magically prepended
if the 'file' thinks its plain text and it does not start with '#!'
LP: #1272115
|
|
if write_boot_content is given somethign that starts with #!,
then there isn't a reason to invoke 'file' to tell us that it
starts with shebang.
This way, we only run file in 2 cases:
a.) binary content (don't really know if that is supported or not)
b.) magic "user meant to run this with /bin/bash but couldn't be bothered to
type that"
|
|
|
|
- Remove direct usage of open() and use the
corresponding helpers instead.
- Fix the non-existence of the copyfile routine
and just use the ones that do exist in the
utils module to do the file backup.
- Use class level constants for the various file
names read, this matches the same usage in the
other distro types.
|
|
|
|
|
|
This fixes up many long lines to be < 80 chars and some other
pylint issues. pylint 1.1 (in trusty) is now complaining about
the lazy logging, so I'll clean that up when I touch things.
|
|
new pylint in trusty complains about '_' variables if we don't do this.
This seems to be ok in older versions of pylint also.
|
|
|
|
tools/run-pep8 wasn't checking all python files.
tools/run-pylint wasnt checking bin/cloud-init
fixed resultant pep8 issues after finding them.
|
|
1. fixed conflation of user-data and cloud-init user-data. Cloud-init
user-data is now namespaced as 'cloud-init:user-data'.
2. user-scripts are now fetched from the meta-data service each boot and
executed as in the scripts directory
3. datacenter name is now namespaced as sdc:datacenter
4. user-scripts should be shebanged if there is no file magic
|
|
previously, we were calling with the exception that was caught rather
than the UrlException, which meant the exception callback couldn't
be assured there would be a status_code.
|
|
|
|
When a 404 http code comes back from the fetching of ec2
data, instead of retrying immediately stop the fetching process
and in the userdata fetching function handle this case as a
special case of no userdata being fetched (an empty string
in this case).
|
|
|
|
When a 404 http code comes back from the fetching of ec2
data, instead of retrying immediatly stop the fetching process
and in the userdata fetching function handle this case as a
special case of no userdata being fetched (an empty string
in this case).
|
|
This fixes a test case that failed because PATH was unset in the os.environ.
|
|
|
|
This gets initial support for freebsd.
|
