| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
|
|
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 was checking that the lenghth of the mount line from /proc/mounts
was 6, not the number of tokens.
|
|
|
|
|
|
This change removes the filtering of partitions from potential ConfigDrive
sources, if the LABEL of the partition is set to "config-2".
This is useful for a bare metal device. It may not have a separate device for
ConfigDrive, but instead have a ConfigDrive available on a partition.
|
|
The ubuntu/debian networking file parsing function really is more generic
than just a rhel utility function and can be used by others that want to
use this functionality for there own purposes (say in writing down a
freebsd network format instead) so moving this to its own module to
encourage its usage outside of rhel.
|
|
|
|
If mount_info says that the root filesystem is on /dev/root and
/dev/root does not exist, then we'll try to glean that information
from the linux kernel cmdline.
This situation occurs at least when you boot without an initramfs
for the current ppc64el cloud images:
qemu-system-ppc64 ... -kernel my.kernel -append 'root=/dev/sda'
When doing that, /proc/1/mountinfo will say '/dev/root' for '/'.
|
|
|
|
|
|
The ubuntu/debian networking file parsing function
really is more generic than just a rhel utility function
and can be used by others that want to use this functionality
for there own purposes (say in writing down a freebsd network
format instead) so moving this to its own module to encourage
its usage outside of rhel.
|
|
the Requires would get that string rendered into the package's
Depends/Requires (rather than BuildDepends/BuildRequires).
We should have BuildDepends/BuildRequires too, but since
trunk's package builds do not run 'make test', this isn't a big deal.
This also adds 'test-requires' for httpretty.
|
|
We had a requirement on boto only to use
boto.utils.get_instance_metadata(). That had actually caused some pain in
the past. This removes a Requires and also one that wasn't python3.
|
|
|
|
|
|
|
|
This was previously broken anyway. It doesn't seem like there
was an easy way to actually support it, so for now I'm removing
it entirely. growpart works well enough.
|
|
|
|
SECONDS is a special variable in bash, it gets set to the time the
shell has been alive. This would cause us to fail randomly (if the
process happened to take more than 1 second, then SECONDS would
be defined).
|
|
|
|
this simplifies consume_vendordata a bit, changes consume_vendordata to
be by default "PER_INSTANCE" (like userdata).
The other thing we do here is move the exlusion to be handled when walking the
data. The benefit of doing it then is that we can exclude part-handlers.
Without the ability to exlude part handlers, exclusion is basically useless
(since part-handlers could accomplish anything they wanted).
|
|
remove apply_filter from get_vendordata. I can't think of a good
reason to filter vendor-data per instance-id.
remove has_vendordata and consume_vendordata.
has vendordata is always "true", whether or not there is something
to operate is determined by:
if ds.vendordata_raw()
consume_vendordata is based on config entirely.
|
|
|
|
this makes runparts take exe_prefix and do string to list conversion
inside. that means we don't have to do it in cc_scripts_vendor.
Also, get_nested_option_as_list was essentially get_cfg_by_path anyway.
|
|
I don't see a real need for these. The intent of the 'per-boot' or
'per-instance' or 'per-once' config modules is to handle running
scripts that were already inserted into the instance.
If the vendor is doing that, then there is value in vendor-data.
Ie, they'd already modified the image, they might as well have just
put the stuff in that they wanted.
|
