| Age | Commit message (Collapse) | Author |
|---|
|
If something is broken as in a built in config, or code
just broken, then logging warning during search for metadata
is ok.
|
|
make pyflakes now passes.
|
|
|
|
|
|
|
|
|
|
Instead of using this log (which really isn't a failure) we should
instead of just return the looked up locations and then if there really
is an error the caller can handle the usage of the looked up locations
as they choose fit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This just removes comments '# pylint:' things and other code
remnents of pylint.
|
|
Fixed all complaints from running "make pep8". Also version locked
pep8 in test-requirements.txt to ensure that pep8 requirements don't
change without an explicit commit.
|
|
This seems cleaner, to avoid duplicate '/' being added.
|
|
LP: #1316597
|
|
On systems with a ttyS1 and nothing attached, the read attempts
that the cloud sigma datasource would do would block.
Also, Add timeouts for reading/writting from/to the serial console
LP: #1316475
|
|
* do not run dmidecode on arm.
* line length
* comment that 60 second time out is expected
|
|
|
|
|
|
Instead of just trying to see if userdata decodes as the indication that
it should be encoded, the user must explicitly set this.
The "just try it" will fail in the case where the user had other use
of user-data and wanted a blob of data to go through unrecognized by
cloud-init.
In cases where there can be mistake in automatic behavior,
and some users may be relaying on old behavior, its best to just require
explicit use.
|
|
|
|
This was broken in the VendorData add.
LP: #1295223
|
|
|
|
|
|
|
|
per instance. Under a variety of circumstances, the ephemeral device may
be presented as a default device. This patch detects when that situation
happens and triggers CC modules disk-setup and mounts to run again.
Details of changes for cloudinit/sources/DataSourceAzure.py:
- auto-detect the location of ephemeral0
- check each boot if ephemeral0 is new
- done via NTFS w/ label of "Temporary Storage" w/ no files on it
- if device is mounted, datasource will unmount it
- if is new, change mounts and disk-setup to always for that boot only
|
|
This adds the ability to read a 'base64_fields' entry in the metadata,
and if cloud-init-userdata is listed in that, then content will be
base64 decoded first.
|
|
See LP1243287 for more information
|
|
|
|
See LP: #1243287 for more information, but the easiest thing to do
here is just not run smartos on arm.
LP: #1243287
|
|
When cloud-init writes previous-instance-id, it does so with a
trailing '\n'. This isn't ideal, as other readers also have to know
that this will have a trailing '\n' on it, but here we just trim that off.
|
|
|
|
The instance-id file contains the instance id
and a newline, to compare correctly make sure
we strip the newline before further usage.
|
|
This allows users of CloudSigma's VM to encode their user data with base64.
In order to do that thet have to add the ``cloudinit-user-data`` field to
the ``base64_fields``. The latter is a comma-separated field with
all the meta fields whit base64 encoded values.
|
|
|
|
The CloudSigma datasource would attempt to read /dev/ttyS1
and if not found would warn (which gets logged to stdout by default).
Better to just debug.
|
|
|
|
There might be multiple things to put inside a vendor-data.
So, if it is a dict and that dict has 'cloud-init', assume that the whole
thing was not meant for cloud-init, and set vendordata_raw to the specific
item.
|
|
datasource for SmartOS runs. This patch creates the instance's directory.
|
|
This reduces how much cloud-init is explicitly involved in what "vendor-data"
could accomplish. The goal of vendor-data was to provide the vendor with a
channel to run arbitrary code that accomodate for their specific platform.
Much of those accomodations are currently being done in cloud-init.
However, this now moves some of those things to default "vendor-data", instead
of cloud-init proper.
Basically, now we have an 'sdc:vendor-data' key in the metadata.
If that does not exist, then cloud-init will use the default.
The default, provides a boothook. That boothook writes a file into
/var/lib/cloud/per-boot/ . That file will be both written on every boot
and then executed at rc.local time frame (by 'scripts-per-boot').
It will then execute /var/lib/cloud/instance/data/user-script
and /var/lib/cloud/instance/data/operator-script if they exist.
So, the things that cloud-init is now doing outside of the default vendor-data
that I would rather be done in vendor-data is:
* managing the population of instance/data/user-script and
instance/data/operator-script. These could very easily be done
from the boothook, but doing them in cloud-init removes the necessity
for having a 'mdata-get' command in the image (or some other way for
the boothook script to query the datasource).
* managing the LEGACY things.
|
|
|
|
this changes url_map to a list and adds 'required' information.
* If we've not already found an entry, and this is required,
then debug log (ie, this is just not GCE).
* if we already found an entry and this is required: warn
split the keys fixing out of the loop.
|
|
default #cloud-config that writes per-boot script that fetches subsequent
sdc:operator-scripts and executes it.
|
|
|
|
|
|
|
