diff options
author | Scott Moser <smoser@ubuntu.com> | 2014-02-14 00:15:08 -0500 |
---|---|---|
committer | Scott Moser <smoser@ubuntu.com> | 2014-02-14 00:15:08 -0500 |
commit | 12672e77a2881f9a87d2dcb4217e5e56b8b3dfd6 (patch) | |
tree | 311d2acd0e220ffbf316c7d0d75380f160a67518 /config | |
parent | 053667688d7c2ad51e569c62e00dac1942e46f62 (diff) | |
parent | 1bf99b6fe9d11a9e3b1d452940d21779347ea461 (diff) | |
download | vyos-cloud-init-12672e77a2881f9a87d2dcb4217e5e56b8b3dfd6.tar.gz vyos-cloud-init-12672e77a2881f9a87d2dcb4217e5e56b8b3dfd6.zip |
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.
Diffstat (limited to 'config')
0 files changed, 0 insertions, 0 deletions