| Age | Commit message (Collapse) | Author |
|---|
|
call the command without capturing output, and provide RANDOM_SEED_FILE
to the environment that it is run in.
|
|
|
|
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.
|
|
This populates and maintains status.json and result.json with
json formated data about cloud-init's errors and datasource.
It is intended to be consumed by other programs that want to
wait until cloud-init is done, or know its success.
LP: #1284439
|
|
|
|
This extends 'random_seed' top level entry to include a 'command'
entry, that has the opportunity to then seed the random number generator.
Example config:
#cloud-config
random_seed:
command: ['dd', 'if=/dev/zero', 'of=/dev/random', 'bs=1M', 'count=10']
LP: #1286316
|
|
by default we call 'pollinate -q' which is nice and quiet.
if the user wants to be noisy, let them.
|
|
there was a bug that prevented seeding of /dev/urandom from metadata provided
by the datasource unless the user provided random_seed config.
This should, instead, be the default behavior.
|
|
|
|
if you have UNCOMMITTED=1 in environment then the tree will
contain uncommitted changes.
|
|
Similar test-hack as the SmartOS one.
Here we just pretend that we're running on x86_64 so as to avoid
re-writing the tests to expect otherwise on arm.
|
|
|
|
As with SmartOS change earlier, running dmidecode on arm will crash kvm.
So instead of doing that, just return UNKNOWN which will cause this
data source to not activate.
LP: #1285686
|
|
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
|
|
after freebsd merge, ubuntu shows addr:v.x.y.z instead of v.x.y.z for the
ipv4 address. This should fix that by just skipping the 'inet' (or inet6)
token if the next token starts with 'addr:'.
LP: #1285185
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
do not search 'latest', as that would be assuming the versioned
api would never break.
Also, instead of warning when we use something else, just debug.
|
|
|
|
The instance-id file contains the instance id
and a newline, to compare correctly make sure
we strip the newline before further usage.
|
|
|
|
|
|
|
|
This test case isn't really valid any more as we've changed
the way this works.
|
|
|
|
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.
|
|
The code in the previous commit was creating /var/lib/cloud/instance/
when it should not have. This is better handled now by using
/var/lib/cloud/instances/<instance-id>, and then letting the link get
created by cloud-init elsewhere.
|
|
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 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.
|
|
|
|
|
|
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's special datasource it seems beneficial to combine the used
parts into a new datasource just made for handling openstack deployments
that use the openstack metadata service (possibly in combination with the
ec2 metadata service).
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.
|
|
|
|
|
|
Waiting around for a metadata service in a given datasource means that if its
not there all the subsequent datasources have to wait, and boot is slowed down.
As it is right now, EC2 is the only one that has the right to wait. In the
past, we had to wait around for the EC2 metadata service. I really do not want
to extend that courtesy to other cloud platforms. A network based metadata
service should be up as soon as networking is up.
|
