| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This will allow for a DataSource to provide its own config
that will then be utilized as part of CloudConfig.
[to be used in OVF]
|
|
base64 encoding should be enough for the likely use case of this
Product Section property.
|
|
- add ubuntu-server.ovf that passes validation via:
xmllint --nonet --path open-ovf/mainline/schemas/ \
--noout --schema open-ovf/mainline/schemas/ovf-envelope.xsd \
doc/ovf/ubuntu-server.ovf
and via
ovftool --schemaValidate doc/ovf/ubuntu-server.ovf
where ovftool is 'VMware ovftool 2.0.1 (build-260188)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There is no default configured. Nothing is done by default.
|
|
|
|
|
|
LP: #668400
|
|
minor change to timestamps to all use gmtime()
|
|
|
|
|
|
This moves what was done as cloud-run-user-script.conf to 'cloud-final'
and makes that re-use the cloud-init-cfg code, but simply with a different
set of default configs.
Also, adds keys_to_console and final_message cloud-config modules
|
|
This moves what was done as cloud-run-user-script.conf to 'cloud-final'
and makes that re-use the cloud-init-cfg code, but simply with a different
set of default configs.
Also, adds keys_to_console and final_message cloud-config modules
LP: #653271
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
instead of hard-coding in cloud-init-cfg the module list that should be
read, read it from the second command line argument. Basically, instead
of reading 'cloud_config_modules', specify 'cloud_config' when
cloud-init-cfg is run.
change the upstart job to invoke cloud-init-cfg with:
exec cloud-init-cfg all cloud_config
rather than
exec cloud-init-cfg all
|
|
Now, in addition to running instance specific scripts (in runcmd or
user-data scripts), cloud-run-user-script will run other directories
also. All under /var/lib/cloud, and in the following order:
scripts/per-once [once ever]
scripts/per-boot [every boot]
scripts/per-instance [once per instance]
instance/scripts [once per instance]
At the moment, the marker is on the entire directory, so changes to that
directory. Changes to the contents of the directory will not be noticed.
|
|
add 'hostname' cloud-config option for setting hostname
make rsyslog and resizefs run at cloud-init time
|
|
|
|
|
|
|
|
LP: #653220
|
|
|
|
since user names and group names wont' be the same on all images,
allow configuration of what ownership to put on 'default_log_file'.
|
|
add caching of the parsed config, this will allow re-use in cloudinit
so that we don't have to load the default config more than once in
a program.
|
|
|
|
cloud-config-archive is a yaml formated document where the top
level should contain an array. Each entry in the array can be one of
- dict { 'filename' : 'value' , 'content' : 'value', 'type' : 'value' }
filename and type may not be present
- scalar(content)
if filename and type are not present, they are attempted to be guessed.
LP: #641504
|
|
|
|
- /var/lib/cloud is redesigned, and its layout now described in
doc/var-lib-cloud.txt.
The big plus point of this was to get instance specific data
into /var/lib/cloud/instances, so that data could easily be purged.
A symlink /var/lib/cloud/instance -> /var/lib/cloud/instances/<current_id>
is maintained.
- Also, now run scripts in /var/lib/cloud/scripts/
per-once
per-boot
per-instance
- bugs addressed:
- LP: #704509
|
|
|
|
|
|
This change just uses a different facility for coming up with the path.
But, by design I'm chosing to put 'previous-hostname' in
/var/lib/cloud/data/
rather than in
/var/lib/cloud/instance/data/
The idea is that if the user:
- started an instance
- modified /etc/hostname
- bundled instance (or create-image from it)
- started new instance
They would expect their modified /etc/hostname to persist. As such, the
previous-hostname file should be cross-instance data.
Bugs in this area include LP: #596993 and LP: #514492
|
|
|
|
- cloud_config and scripts now live in instance directory
- cachedir is now more correctly named 'seeddir'
|
|
|
