← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

 

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 <smoser@xxxxxxxxxx>  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