lp://staging/~schuio/cloud-init/chef-client-opts

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

956. By Michael Schubert <email address hidden> on 2014-02-27

cc_chef: allow chef-client opts to be set via cfg

955. By Scott Moser on 2014-02-25

ConfigDrive: trim trailing newlines in previous-instance-id

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.

954. By Scott Moser on 2014-02-25

DataSourceOpenStack: debug, not warn on non-ideal version. do not use latest.

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.

953. By Scott Moser on 2014-02-24

test_smartos: remove bad test case

This test case isn't really valid any more as we've changed
the way this works.

952. By Scott Moser on 2014-02-18

NoCloud: fix broken seed from external image

951. By Scott Moser on 2014-02-18

CloudSigma: remove 'WARN' in not found case

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.

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.