lp:~smoser/cloud-init/landscape-client.lp857366

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:~cloud-init-dev/cloud-init/trunk at revision 496

Mike Milner (community): Approve on 2011-12-21

Andreas Hasenack: Pending requested 2011-12-20

Diff: 0 lines api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #857366: support configuring landscape-client in cloud-config format

Medium

Fix Released

Link a bug report

Related blueprints

497. By Scott Moser on 2011-12-21

fix bug where first entry in the list presented to mergeTogether was ignored

496. By Scott Moser on 2011-12-20

merge from trunk

495. By Scott Moser on 2011-12-20

support configuration of landscape-client via cloud-config (LP: #857366)

This adds the ability to configure landscape client code from
cloud-config. The fields available are those that were populated to
/etc/landscape/client.conf when I ran landscape-config on precise
('11.07.1.1-0ubuntu2')

494. By Scott Moser on 2011-12-20

add INSTANCE_ID to env of bootcmd, add cloud-init-per

the environment varible INSTANCE_ID is set when invoking boothooks from
multi-part input. However, previously that was not the case for things
run via bootcmd.

This adds cloud-init-per, which makes it easy for user in bootcmd or
boothook to do something per 'instance', 'always', or 'once'.

The functionality in cloud-init-per mostly duplicated what was in
cloud-init-run-module. That supported "modules", but it is unlikely
that it was used for anything other than "execute". So, cloud-init-per
now replaces cloud-init-run-module and provides legacy support for
the 'execute' path.

493. By Scott Moser on 2011-12-20

output public ssh host keys to console on boot (LP: #893400)

Currently cloud-init writes something like this to console output:
  ec2: #############################################################
  ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----
  ec2: 2048 78:ae:f3:91:04:6f:8d:ee:ef:e1:2d:72:83:6a:d0:82 root@h (RSA)
  ec2: 1024 d3:b6:32:64:22:d4:43:05:f9:25:b4:f3:65:4e:e2:51 root@h (DSA)
  ec2: -----END SSH HOST KEY FINGERPRINTS-----
  ec2: #############################################################

the key fingerprints are useful for humans to read, but not so useful
for machines, as you cannot populate a KnownHostsFile (~/.ssh/known_hosts)
from the data there.

This change adds output like:
  -----BEGIN SSH HOST KEY KEYS-----
  ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdH......STI= root@h
  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYRIQe6m......tWF3 root@h
  -----END SSH HOST KEY KEYS-----

Those lines can easily be grabbed and appended to a known_hosts file.

492. By Scott Moser on 2011-12-20

fix missing import for use of close_stdin

revision 490 missed some required imports.

491. By Scott Moser on 2011-12-20

revert default handling of /etc/hosts to 0.6.1 style (Ubuntu 11.04)

The default management of /etc/hosts in 0.6.2 (Ubuntu 11.10)
was problematic for a couple different uses, and represented a change
in what was present in previous releases.

This changes the default behavior back to the way it was in 11.04/0.6.1.

It makes 'manage_etc_hosts' in cloud-config more than just a boolean.
It can now have 3 values:

 * False (default): do not update /etc/hosts ever
 * "localhost": manage /etc/hosts' 127.0.1.1 entry (the way it was done
   in 11.10/0.6.2)
 * True (or "template"): manage /etc/hosts via template file

This addresses bugs
  * LP: #890501
  * LP: #871966

490. By Scott Moser on 2011-12-19

make stdin read from /dev/null for all cloud-init programs (LP: #903993)

the cloud-init programs are never intended to run interactively.
Some programs were being run via subprocess, and would notice that their
input was attached to a terminal (/dev/console). As a result, they
they would try to prompt the user for input (apt-add-repository)

This change simply re-opens standard input as /dev/null so any
subprocesses will not end up blocking on input.

489. By Scott Moser on 2011-12-19

update changelog for DataSourceEc2 changes

488. By Scott Moser on 2011-12-19

make DataSourceEc2 more resilliant to slow metadata service (LP: #894279)

This increases the timeout for a metadata request to something that should
be easily satisfiable (50 seconds). But hopefully does so while still keeping
the case of no-metadata service in mind.

Previously, there was a small timeout and many retries (30) would be done.
Now,
 - larger timeout (50 seconds) by default
 - retry until a given "max_wait" is reached (120 seconds default)

The end result is that if we're hitting the timeout, there will only end up
being a couple attempts made. But if the requests are coming back quickly
then we'll still make several attempts.

There is one EC2DataSource config change, now 'retries' is not used, but rather
'max_wait' to indicate generally how long it should try to find a metadata
service.