| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
This fixes a test case that failed because PATH was unset in the os.environ.
|
|
|
|
This gets initial support for freebsd.
|
|
|
|
|
|
|
|
|
|
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.
|
|
This just does python rewrites of these tools that were shell or sed or
grep. Clearly the user of cloud-init has python, but it turns out that
getting sane versions of sed or grep on different unixes is less than
simple.
|
|
|
|
This splits up 'Requires' into requirements.txt and test-requirements.txt
to differenciate the build dependencies and runtime dependencies.
one sticky thing still exists in that the packages/bddeb doesn't:
- list any Build-Depends
- address versions in the requirements.txt
|
|
|
|
|
|
|
|
|
|
|
|
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 adds the ability for a datasource to provide "vendordata".
The difference here is that vendordata is from the vendor (cloud provider)
where user-data is from the user. By enabling this channel, the vendor
can have input on how the instance is set up without modifying or needing
to understand the user-data.
vendordata is generally consumed exactly like user-data, but the user
has the ability to disable its consumption.
The only datasource supporting this at the moment is SmartOS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
