lp:~harlowja/cloud-init/shared-wait-metadata

Branch merges

Propose for merging

No branches dependent on this one.

Rejected for merging into lp:~cloud-init-dev/cloud-init/trunk

Server Team CI bot: Needs Fixing (continuous-integration) on 2016-07-22

cloud-init Commiters: Pending requested 2014-02-15

Diff: 231 lines (+64/-85)

3 files modified

cloudinit/sources/DataSourceEc2.py (+14/-46)
cloudinit/sources/DataSourceOpenStack.py (+13/-39)
cloudinit/util.py (+37/-0)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

951. By Joshua Harlow on 2014-02-15

Move shared waiting function to util

The ec2 and openstack datasources use a similar
piece of code for waiting for there metadata services
to become accessible (which varies depending on cloud,
service provider...) so its much nicer if we move that
duplicated/similar code to a standard utility method and
use that instead.

950. By Scott Moser on 2014-02-14

DataSourceGCE: fix 'is_resolvable', remove unnecessary WARN

949. By Scott Moser on 2014-02-14

DataSourceOpenStack: allow vendor-data to be a dict with 'cloud-init' inside

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.

948. By Scott Moser on 2014-02-14

smartos: fix bug in previous commit

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.

947. By Scott Moser on 2014-02-14

re-work vendor-data and smartos

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.

946. By Scott Moser on 2014-02-14

GCE: add some tests, some small fixes

945. By Joshua Harlow on 2014-02-13

Add a openstack specific datasource

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.

944. By Scott Moser on 2014-02-13

Add initial GCE datasource

There are some rough edges here and its missing some test, but
I want to get this pulled in.

943. By Scott Moser on 2014-02-13

cloudsigma: change default dsmode to 'net'

Previously this had 'local' as the default datasource mode, meaning
that user-data code such as boot hooks and such would not be guaranteed to have
network access. That would be out of sync with the expectation on other
platforms where the default is 'network up'.

The user can still specify 'dsmode' as local if necessary and the
local datasource will claim itself found.

942. By Nathan House on 2014-02-12

initial Gentoo and Arch linux support