| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Openstack has a unique derivative datasource
that is gaining usage. Previously the config
drive datasource provided part of this functionality
as well as the ec2 datasource, but since new
functionality is being added to openstack is
seems benefical to combine the used parts into
one datasource just made for handling openstack
deployments.
This patch factors out the common logic shared
between the config drive and the openstack
metadata datasource and places that in a shared
helper file and then creates a new openstack
datasource that readers from the openstack metadata
service and refactors the config drive datasource
to use this common logic.
|
|
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).
|
|
|
|
|
