This bug was fixed in the package cloud-init - 0.7.9-0ubuntu1~16.04.2 --------------- cloud-init (0.7.9-0ubuntu1~16.04.2) xenial-proposed; urgency=medium
* debian/update-grub-legacy-ec2: fix shell syntax error. (LP: #1662221) cloud-init (0.7.9-0ubuntu1~16.04.1) xenial-proposed; urgency=medium * debian/copyright: update License field to include Apache. * debian/update-grub-legacy-ec2: fix to include kernels whose config has CONFIG_XEN=y (LP: #1379080). * debian/patches/azure-use-walinux-agent.patch: continue relying on walinux agent in stable release. * New upstream release. - doc: adjust headers in tests documentation for consistency. - pep8: fix issue found in zesty build with pycodestyle. - integration test: initial commit of integration test framework [Wesley Wiedenmeier] - LICENSE: Allow dual licensing GPL-3 or Apache 2.0 [Jon Grimm] - Fix config order of precedence, putting kernel command line over system. [Wesley Wiedenmeier] (LP: #1582323) - pep8: whitespace fix [Scott Moser] - Update the list of valid ssh keys. [Michael Felt] - network: add ENI unit test for statically rendered routes. - set_hostname: avoid erroneously appending domain to fqdn [Lars Kellogg-Stedman] (LP: #1647910) - doc: change 'nobootwait' to 'nofail' in docs [Anhad Jai Singh] - Replace an expired bit.ly link in code comment. [Joshua Harlow] - user-groups: fix bug when groups was provided as string and had spaces [Scott Moser] (LP: #1354694) - when adding a user, strip whitespace from group list [Lars Kellogg-Stedman] (LP: #1354694) - fix decoding of utf-8 chars in yaml test - Replace usage of sys_netdev_info with read_sys_net [Joshua Harlow] (LP: #1625766) - fix problems found in python2.6 test. [Joshua Harlow] - Just use file logging by default [Joshua Harlow] (LP: #1643990) - Improve formatting for ProcessExecutionError [Wesley Wiedenmeier] - flake8: fix trailing white space - Doc: various documentation fixes [Sean Bright] - cloudinit/config/cc_rh_subscription.py: Remove repos before adding [Brent Baude] - packages/redhat: fix rpm spec file. - main: set TZ in environment if not already set. [Ryan Harper] -- Scott Moser <smo...@ubuntu.com> Mon, 06 Feb 2017 16:18:28 -0500 ** Changed in: cloud-init (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1582323 Title: Commissioning fails when competing cloud metadata resides on disk Status in cloud-init: Fix Released Status in MAAS: Fix Committed Status in MAAS 2.1 series: Fix Released Status in MAAS trunk series: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Bug description: === Begin SRU Information === [Impact] The issue originally reported was that when MAAS attempted to enlist a system by booting it with a remote iscsi disk with intent to have cloud-init utilize the MAAS metadata service, cloud-init found some metadata from a previous use of the system on the local disk. cloud-init then went on to use that data and did not respond to maas. The impact in this case was that cloud-init failed to enlist. The same problem could occur in any other case where there was data on the local disk that provided a datasource for cloud-init. The fix provided was for the scenario provided was for MAAS to provide configuration on the maas provided kernel command line that tells cloud-init it should read only attempt to use the MAAS datasource. Specifically, as mentioned in comment 7, this looked like: root=iscsi:.... cc:{'datasource_list': ['MAAS']}end_cc \ cloud-config-url=http://maas/path/to/config ... cloud-init then reads that information on boot and it overrides the settings found inside the iscsi root device. [Test Case] A test case lives in unit tests now that ensures kernel config overrides system config. To further test this we could a.) cause this situation by 1.) installing a node in maas 2.) putting config drive or nocloud data onto one of the partitions 3.) returning the system to maas 4.) attempt re-deploy. b.) use a cloud image, kernel and initramfs and web server 1.) download image, update cloud-init to -proposed. 2.) set up a web service to serve files like MAAS described at https://maas.ubuntu.com/docs/development/metadata.html 3.) boot image with kernel command line including the cc: and cloud-config-url referencing that web service. 4.) have provided a config drive or nocloud seed disk to the vm. The 'b' test above is easier to reproduce in that it does not rely on MAAS. [Regression Potential] Regression potential is low, in that this feature worked for some time in previous releases. A bad reading of the code made me (smoser) change the code intending to fix the problem, but in fact regressed it. So this change is actually reverting a previous change in behavior. This was first broken in 16.04 in 0.7.7~bzr1245-0ubuntu1~16.04.1 . [Other Info] The upstream commit that fixed this behavior (including the added tests) is 0b0f254a [1] -- [1] https://git.launchpad.net/cloud-init/commit/?id=0b0f254a6935a1b1fff128fa177152dd519e1a3d === End SRU Information === A customer reused hardware that had previously deployed a RHEL Overcloud-controller which places metadata on the disk as a legitimate source, that cloud-init looks at by default. When the newly enlisted node appeared it had the name of "overcloud-controller-0" vs. maas- enlist, pulled from the disk metadata which had overridden MAAS' metadata. Commissioning continually failed on all of the nodes until the disk metadata was manually removed (KVM boot Ubuntu ISO, rm -f data or dd zeros to disk). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1582323/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp