cloud-config/cloud-init should support launch-index

[Scott Moser]

$ ec2metadata --ami-launch-index
0

In EC2 and nova if you launch multiple instances in a single reservation, each has the same user-data, but the metadata service identifies the "launch index" as an integer.

This can be utilized to have instances behave differently, turning one instance into a web server, one into a db server ...

One idea on how to support this in cloud-init would be to add a header field to muliti-part input (both mime and cloud-archive) that indicates that this part only applies to a given launch-index.

Example cloud-archive format:
- type: text/upstart-job
  filename: my-upstart.conf
  launch-index: 0
  content: |
   # upstart job here
- type: text/upstart-job
  filename: my-index2-upstart-job.conf
  launch-index: 1
  content:
   # upstart job here for launch-index 2

Related bugs:
 * bug 1042020: launch index should be in openstack metadata
    merge proposal merged https://review.openstack.org/#/c/11997/

[Joshua Harlow (harlowja)]

Seems to make sense, the above example might be one way to tag configs for certain launch-indexes.

I wonder if we can restrict this change to just the user-data writing 'processor' and say, write to a launch-index folder (a subfolder of the instance-id folder?) which then can be selected for the 'current' index? Does that make sense? This way if you wanted to see the config/mime data that will be activated for a index u can go look at one folder, and later running would just be symlinked into that folder (instead of the current instance-id folder), say configs that have no launch-index would be duplicated, but configs that have specific launch-indexes would only be written into there appropriate folder, then the modules down the line would not even know they were running in a given index (although this should be provided to them, ideally via a datasource function).

It could also seem possible that you would only want to run a given set of 'config' modules for a given launch-index? Some cases u want to run something that will configure your db (but only on launch-index X).

This could mean changes in cloud.cfg,

Instead of the previous:

--
cloud_config_modules:
 - m1
 - m2
...

There could be:

---
cloud_config_modules:
  - index: all
    module: m1
  - index: [1, 2, 3]
    module: m2
...

[Scott Moser (smoser)]

I think I"m ok with what you're suggesting, but the cloud_config_modules section is confusing specifically. I'd like to do this at a level above that, at the cloud-config-archive or 'part' level.

I do see the value of a 'index: all' (which would be the default) and supporting 'index: [1,2,3]' also. The default, when not present is 'index: all'. That way the backwards compatible behavior is identical.

I also am fine if we expose this to the cloud-init consumer via having /var/lib/cloud/instance/user-data.i contain only the parts that were relevant to that instance. I'd like to have 'user-data' continue to have exactly what was found in 'user-data' bit for bit. Note, the '.i' extension is the traditional extension for files already processed through cpp (ie, it has been pre-processed).

[Joshua Harlow (harlowja)]

Ok, maybe for now we just see if we can get the userdata processor class to split this up, and see if we can make it transparent to everyone down the line (the config modules...) and leave out the 'cloud.cfg' changes for now, those seem useful but maybe someday in the future?

[Scott Moser (smoser)]

this is fixed in trunk at revno 644. see example at
doc/examples/cloud-config-launch-index.txt

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2272