[Yahoo-eng-team] [Bug 1674685] [NEW] hostname ddns update is not done on azure with built-in agent path.

[Scott Moser]

Public bug reported:

Brent Baude and Paul Meyer realized that on Azure, that when the
'agent_command' is set to __builtin__ (the current default in trunk)
that cloud-init does not bounce the network device in order to do a ddns
update of the systems' hostname.

** Affects: cloud-init
 Importance: Medium
 Assignee: Brent Baude (bbaude)
 Status: Fix Committed

** Affects: cloud-init (Ubuntu)
 Importance: Medium
 Status: Confirmed

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
 Assignee: (unassigned) => Brent Baude (bbaude)

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Merge proposal linked:
   https://code.launchpad.net/~bbaude/cloud-init/+git/cloud-init/+merge/320411

** Changed in: cloud-init
   Status: Confirmed => Fix Committed

-- 
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/1674685

Title:
  hostname ddns update is not done on azure with built-in agent path.

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  Brent Baude and Paul Meyer realized that on Azure, that when the
  'agent_command' is set to __builtin__ (the current default in trunk)
  that cloud-init does not bounce the network device in order to do a
  ddns update of the systems' hostname.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1674685/+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

[Yahoo-eng-team] [Bug 1673853] [NEW] do not write ifcfg-lo when rendering syscfg

[Scott Moser]

Public bug reported:

As discussed some in merge proposal at [1].
The sysconfig renderer could use some work.

a.) seems like we should not be rendering ifcfg-lo at least in the case that it 
already exists.
b.) we should be able to now replace _write_network with something that uses 
eni.convert_eni_data
like http://paste.ubuntu.com/24196078/
--
[1] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/319943

** Affects: cloud-init
 Importance: Medium
 Status: Confirmed

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/1673853

Title:
  do not write ifcfg-lo when rendering syscfg

Status in cloud-init:
  Confirmed

Bug description:
  As discussed some in merge proposal at [1].
  The sysconfig renderer could use some work.

  a.) seems like we should not be rendering ifcfg-lo at least in the case that 
it already exists.
  b.) we should be able to now replace _write_network with something that uses 
eni.convert_eni_data
  like http://paste.ubuntu.com/24196078/
  --
  [1] 
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/319943

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1673853/+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

[Yahoo-eng-team] [Bug 1671274] Re: network interface doesn't come up after installation in VM

[Scott Moser]

The last screenshot (ipaddrdelifup.png) we think shows what went wrong.
Jason had an rtl device attached to this kvm vm.  It doesn't seem to like 
setting the MTU to 9000.
Possibly that is a bug in the driver, or possibly it is a limitation of the 
(emulated or real) hardware.

2 fixes:
 a.) do not use mtu 9000
 b.) use virtio devices

** No longer affects: cloud-init

** No longer affects: maas

** No longer affects: systemd (Ubuntu)

** Changed in: curtin
   Status: New => Invalid

-- 
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/1671274

Title:
  network interface doesn't come up after installation in VM

Status in curtin:
  Invalid

Bug description:
  I'm installing into a VM. It commissions fine, and deploy works up to
  the point where it reboots after curtin finishes, but when it comes
  back up after reboot, the network interface is not brought up.  This
  means it never finishes deployment.

  Looking at syslog, there is a Failed to start Raise network interfaces
  error. You can see it in the attached screenshot.

  This VM worked fine up until a couple of months ago.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1671274/+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

[Yahoo-eng-team] [Bug 1669875] Re: identify openstack vmware platform

[Scott Moser]

** Also affects: nova
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1669875

Title:
  identify openstack vmware platform

Status in cloud-init:
  Confirmed
Status in OpenStack Compute (nova):
  New

Bug description:
  We need a way to identify locally that we are running on openstack
  when inside a guest of VmWare.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1669875/+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

[Yahoo-eng-team] [Bug 1669949] Re: report mode can exit 1 which will disable cloud-init

[Scott Moser]

** Changed in: cloud-init
   Status: Confirmed => Fix Committed

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => 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/1669949

Title:
  report mode can exit 1 which will disable cloud-init

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  Report mode could exit with 1 (disable) and the caller (cloud-init-
  generator) would then disable cloud-init.

  Thats not very "report only".

  The change needed is to just make report always exit with 0 (enable).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1669949/+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

[Yahoo-eng-team] [Bug 1669949] [NEW] report mode can exit 1 which will disable cloud-init

[Scott Moser]

Public bug reported:

Report mode could exit with 1 (disable) and the caller (cloud-init-
generator) would then disable cloud-init.

Thats not very "report only".

The change needed is to just make report always exit with 0 (enable).

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
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/1669949

Title:
  report mode can exit 1 which will disable cloud-init

Status in cloud-init:
  New

Bug description:
  Report mode could exit with 1 (disable) and the caller (cloud-init-
  generator) would then disable cloud-init.

  Thats not very "report only".

  The change needed is to just make report always exit with 0 (enable).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1669949/+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

[Yahoo-eng-team] [Bug 1669860] Re: cloud-init attempts to rename bonds

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/1669860

Title:
  cloud-init attempts to rename bonds

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  1. Zesty amd64
  2. cloud-init 0.7.9-47-gc81ea53-0ubuntu1

  3. cloud-init boots with a bond network config and does not attempt to
  rename bond0

  4. cloud-init init (net mode) fails when it attempts to rename a bond
  interface

  
  Running with the following network config (2 nics)
  config:
  -   mac_address: bc:76:4e:06:96:b3
  name: interface0
  type: physical
  -   mac_address: bc:76:4e:04:88:41
  name: interface1
  type: physical
  -   bond_interfaces:
  - interface0
  - interface1
  name: bond0
  params:
  bond_miimon: 100
  bond_mode: 802.3ad
  bond_xmit_hash_policy: layer3+4
  type: bond
  -   name: bond0.108
  subnets:
  -   address: 65.61.151.38
  netmask: 255.255.255.252
  routes:
  -   gateway: 65.61.151.37
  netmask: 0.0.0.0
  network: 0.0.0.0
  type: static
  -   address: 2001:4800:78ff:1b:be76:4eff:fe06:96b3
  netmask: ':::::'
  routes:
  -   gateway: 2001:4800:78ff:1b::1
  netmask: '::'
  network: '::'
  type: static
  type: vlan
  vlan_id: '108'
  vlan_link: bond0
  -   name: bond0.208
  subnets:
  -   address: 10.184.225.122
  netmask: 255.255.255.252
  routes:
  -   gateway: 10.184.225.121
  netmask: 255.240.0.0
  network: 10.176.0.0
  -   gateway: 10.184.225.121
  netmask: 255.240.0.0
  network: 10.208.0.0
  type: static
  type: vlan
  vlan_id: '208'
  vlan_link: bond0
  -   address: 72.3.128.240
  type: nameserver
  -   address: 72.3.128.241
  type: nameserver

  
  During cloud-init init --local; the network configuration is rendered and 
brought up
  bond0 is a virtual interface which uses the MAC from one of the slaves.

  In cloud-init init (net) mode, we check if the interfaces are named properly;
  When cloud-init collects the current_rename_info, it reads the MAC address of
  each device listed in /sys/class/net;  this includes *virtual* devices, like 
bonds/bridges
  Then it looks up an interface name by MAC, however the bond and one of the 
interfaces
  have the same value which results in cloud-init attempting to rename bond0

  The solution is to not collect MACs of virtual interfaces for rename-purpose 
since
  virtual devices do not ever get renamed; their name is defined by the config.

  diff --git a/cloudinit/net/__init__.py b/cloudinit/net/__init__.py
  index ea649cc..e2a50ad 100755
  --- a/cloudinit/net/__init__.py
  +++ b/cloudinit/net/__init__.py
  @@ -14,6 +14,7 @@ from cloudinit import util
   
   LOG = logging.getLogger(__name__)
   SYS_CLASS_NET = "/sys/class/net/"
  +SYS_DEV_VIRT_NET = "/sys/devices/virtual/net/"
   DEFAULT_PRIMARY_INTERFACE = 'eth0'
   
   
  @@ -205,7 +206,11 @@ def _get_current_rename_info(check_downable=True):
   """Collect information necessary for rename_interfaces."""
   names = get_devicelist()
   bymac = {}
  +virtual = os.listdir(SYS_DEV_VIRT_NET)
   for n in names:
  +# do not attempt to rename virtual interfaces
  +if n in virtual:
  +continue
   bymac[get_interface_mac(n)] = {
   'name': n, 'up': is_up(n), 'downable': None}
   

  Log file of a failure:
  http://paste.ubuntu.com/24084999/

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1669860/+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

[Yahoo-eng-team] [Bug 1669875] [NEW] identify openstack vmware platform

[Scott Moser]

Public bug reported:

We need a way to identify locally that we are running on openstack when
inside a guest of VmWare.

** Affects: cloud-init
 Importance: Medium
 Status: Confirmed


** Tags: dsid

-- 
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/1669875

Title:
  identify openstack vmware platform

Status in cloud-init:
  Confirmed

Bug description:
  We need a way to identify locally that we are running on openstack
  when inside a guest of VmWare.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1669875/+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

[Yahoo-eng-team] [Bug 1657130] Re: get_data in DataSourceOpenStack.py can time out if metadata service is slow

[Scott Moser]

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: New => Fix Released

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: Fix Released => Fix Committed

-- 
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/1657130

Title:
  get_data in DataSourceOpenStack.py can time out if metadata service is
  slow

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  cloud-init sometimes times out and fails to fetch metadata in the
  OpenStack environment when the Controller node is under high workload.

  The default timeout value is 5 seconds and it may be too small in some
  cases where the Controller node is too busy to respond to the metadata
  request  from the instance in time.

  There is a 'timeout' configuration setting, as in...

datasource:
  OpenStack:
timeout: 30

  ...but this value is not used by the get_data method in
  cloudinit/sources/DataSourceOpenStack.py, because get_data is called
  from cloudinit/sources/__init__.py with no keyword arguments:

  LOG.debug("Seeing if we can get any data from %s", cls)
  s = cls(sys_cfg, distro, paths)
  if s.get_data():
  myrep.message = "found %s data from %s" % (mode, name)
  return (s, type_utils.obj_name(cls))

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1657130/+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

[Yahoo-eng-team] [Bug 1661797] Re: identify lxd-nova platform to enable Openstack datasource

[Scott Moser]

Marking fix-released in nova-lxd  in zesty.

** Description changed:

  nova-lxd uses the Openstack Network metadata service.
  
  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.
  
  We need to be able to positively identify that the container we are running
  inside should have access to an openstack metadata service so we can
  safely assume it will be there.
  
  How can we positively identify that a container is running in nova-lxd?
  Is there anything in the environment (possibly pid 1 environ?) that we
  can look at?
  
  One way I could see doing t his would be for lxd-nova to put
     CLOUD_PLATFORM='openstack-nova'
  inside the pid 1 environment.  then cloud-init can look at /proc/1/environ
  and pick that out.
  
  Open to other ideas, and would love it if there was something we could
  do.
  
  Related bugs
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
-  bug 1663304: identify openstack kvm platform on arm64
+  bug 1663304: identify openstack kvm platform on arm64
+  bug 1668313: [SRU] mitaka point release

** Changed in: nova-lxd (Ubuntu Zesty)
   Status: Confirmed => Fix Released

** Changed in: nova-lxd (Ubuntu Yakkety)
   Status: Confirmed => In Progress

** Changed in: nova-lxd (Ubuntu Xenial)
   Status: Confirmed => In Progress

-- 
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/1661797

Title:
  identify lxd-nova platform to enable Openstack datasource

Status in cloud-init:
  Fix Committed
Status in nova-lxd:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in nova-lxd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in nova-lxd source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Confirmed
Status in nova-lxd source package in Yakkety:
  In Progress
Status in cloud-init source package in Zesty:
  Fix Released
Status in nova-lxd source package in Zesty:
  Fix Released

Bug description:
  nova-lxd uses the Openstack Network metadata service.

  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.

  We need to be able to positively identify that the container we are running
  inside should have access to an openstack metadata service so we can
  safely assume it will be there.

  How can we positively identify that a container is running in nova-lxd?
  Is there anything in the environment (possibly pid 1 environ?) that we
  can look at?

  One way I could see doing t his would be for lxd-nova to put
     CLOUD_PLATFORM='openstack-nova'
  inside the pid 1 environment.  then cloud-init can look at /proc/1/environ
  and pick that out.

  Open to other ideas, and would love it if there was something we could
  do.

  Related bugs
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
   bug 1663304: identify openstack kvm platform on arm64
   bug 1668313: [SRU] mitaka point release

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1661797/+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

[Yahoo-eng-team] [Bug 1657940] Re: eni rendering dhcp6 writes aliases fails to bring up dhcp6

[Scott Moser]

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Incomplete => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

-- 
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/1657940

Title:
  eni rendering dhcp6 writes aliases fails to bring up dhcp6

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  Currently, a config like this:
  | version: 1
  | config:
  |- 'type': 'physical'
  |  'name': 'iface0'
  |  'subnets':
  |- {'type': 'dhcp4'}
  |- {'type': 'dhcp6'}

  Will render:
  | auto lo
  | iface lo inet loopback
  | 
  | auto iface0
  | iface iface0 inet dhcp
  | post-up ifup iface0:1
  | 
  | 
  | auto iface0:1
  | iface iface0:1 inet6 dhcp

  Below is an example test case that shows the output.
  Heres the problem:
  $ sudo sh -c 'ifdown eth0; ifup eth0'
  $ sudo sh -c 'ifdown eth0; ifup eth0'
  Killed old client process
  Internet Systems Consortium DHCP Client 4.3.3
  Copyright 2004-2015 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   Socket/fallback
  DHCPRELEASE on eth0 to 172.31.16.1 port 67 (xid=0x32b625f1)
  Internet Systems Consortium DHCP Client 4.3.3
  Copyright 2004-2015 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   Socket/fallback
  DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0xa4d5f301)
  DHCPREQUEST of 172.31.29.161 on eth0 to 255.255.255.255 port 67 
(xid=0x1f3d5a4)
  DHCPOFFER of 172.31.29.161 from 172.31.16.1
  DHCPACK of 172.31.29.161 from 172.31.16.1
  bound to 172.31.29.161 -- renewal in 1801 seconds.

  Failed to bring up eth0:1.
  Failed to bring up eth0.

  $ sudo ifup -v eth0:1
  Parsing file /etc/network/interfaces.d/50-cloud-init.cfg
  Parsing file /etc/network/interfaces.d/60-ipv6.cfg
  Configuring interface eth0:1=eth0:1 (inet6)
  /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
  run-parts: executing /etc/network/if-pre-up.d/ethtool
  run-parts: executing /etc/network/if-pre-up.d/ifenslave
  + [ inet6 = meta ]
  + IF_BOND_SLAVES=
  + [  ]
  + [  ]
  + [ -z  ]
  + exit
  run-parts: executing /etc/network/if-pre-up.d/vlan
  /sbin/modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure.
  /sbin/sysctl -q -e -w net.ipv6.conf.eth0:1.accept_ra=1

  /bin/ip link set dev eth0:1  up
  /lib/ifupdown/wait-for-ll6.sh
  /sbin/dhclient -1 -6 -pf /run/dhclient6.eth0:1.pid -lf 
/var/lib/dhcp/dhclient6.eth0:1.leases -I -df 
/var/lib/dhcp/dhclient.eth0:1.leases eth0:1

  
  --- a/tests/unittests/test_net.py
  +++ b/tests/unittests/test_net.py
  @@ -813,6 +813,27 @@ class TestEniRoundTrip(TestCase):
   self.assertEqual(
   expected, [line for line in found if line])
   
  +def test_dhcp4_and_dhcp6(self):
  +conf = yaml.load(textwrap.dedent("""\
  +version: 1
  +config:
  +   - 'type': 'physical'
  + 'name': 'iface0'
  + 'subnets': 
  +   - {'type': 'dhcp4'}
  +   - {'type': 'dhcp6'}
  +   """))
  +
  +#conf = [
  +#{'type': 'physical', 'name': 'iface0',
  +# 'subnets': [
  +# {'type': 'dhcp4'},
  +# {'type': 'dhcp6'},
  +# ]},
  +#]
  +files = self._render_and_read(network_config=conf)
  +raise Exception(files['/etc/network/interfaces'])
  +

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1657940/+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

[Yahoo-eng-team] [Bug 1660385] Re: Alert user of Ec2 Datasource on lookalike cloud

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

-- 
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/1660385

Title:
  Alert user of Ec2 Datasource on lookalike cloud

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  Many cloud providers mimic the EC2 Metadata service [1] in order to
  provide a level of EC2 compatibility for images.  This is quite useful and
  allows image portability.

  Because this is a network based metadata service, cloud-init
  opportunistically poll an IPv4 link local address (http://169.254.169.254)
  to determine if there is metadata available.  That can have negative side
  affects such as timeouts.

  AWS has recently begun providing a way for instances to determine if they
  are running on EC2 [2].

  Cloud-init will change its behavior to attempt to find the EC2 metadata
  service only if it has determined itself to be running on EC2 or another
  known cloud provider which provides an EC2 metadata service.

  For more information, please see:
https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039697.html

  
  --
  [1] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
  [2] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1660385/+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

[Yahoo-eng-team] [Bug 1667735] Re: cloud-init doesn't retry metadata lookups and hangs forever if metadata is down

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: Fix Released => Confirmed

-- 
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/1667735

Title:
  cloud-init doesn't retry metadata lookups and hangs forever if
  metadata is down

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Precise:
  Confirmed
Status in cloud-init source package in Trusty:
  Confirmed

Bug description:
  If a host SmartOS server is rebooted and the metadata service is not
  available, a KVM VM instance that use cloud-init (via the SmartOS
  datasource) will fail to start.

  If the metadata agent on the host server is not available the python
  code for cloud-init gets blocked forever waiting for data it will
  never receive. This causes the boot process for an instance to hang on
  cloud-init.

  This is problematic if there happens to be some reason the metadata
  agent is not available for any reason while a SmartOS KVM VM that
  relies on cloud-init is booting.

  From the engineer that worked on this (not the svadm command is run on
  the host SmartOS server):

  You can reproduce this by disabling the metadata service SmartOS host:

  svcadm disable metadata

  and then boot a KVM VM running an Ubuntu Certified Cloud image such
  as:

  c864f104-624c-43d2-835e-b49a39709b6b (ubuntu-certified-14.04
  20150225.2)

  when you do this, the VM's boot process will hang at cloud-init. If
  you then start the metadata service, cloud-init will not recover.

  On of our engineers who looked at this was able to cause forward
  progress by applying this patch:

  --- 
/usr/lib/python2.7/dist-packages/cloudinit/sources/DataSourceSmartOS.py.ori 
  2017-02-23 01:28:28.405885775 +
  +++ /usr/lib/python2.7/dist-packages/cloudinit/sources/DataSourceSmartOS.py   
2017-02-23 01:35:51.281885775 +
  @@ -286,7 +286,7 @@
   if not seed_device:
   raise AttributeError("seed_device value is not set")

  -ser = serial.Serial(seed_device, timeout=seed_timeout)
  +ser = serial.Serial(seed_device, timeout=10)
   if not ser.isOpen():
   raise SystemError("Unable to open %s" % seed_device)

  which causes the following strace output:

  [pid  2119] open("/dev/ttyS1", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5
  [pid  2119] ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or 
TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
  [pid  2119] write(5, "GET user-script\n", 16) = 16
  [pid  2119] select(6, [5], [], [], {10, 0}) = 0 (Timeout)
  [pid  2119] close(5)= 0
  [pid  2119] open("/dev/ttyS1", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5
  [pid  2119] ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or 
TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
  [pid  2119] write(5, "GET iptables_disable\n", 21) = 21
  [pid  2119] select(6, [5], [], [], {10, 0}) = 0 (Timeout)
  [pid  2119] close(5)= 0

  instead of:

  [pid  1977] open("/dev/ttyS1", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5
  [pid  1977] ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or 
TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
  [pid  1977] write(5, "GET base64_keys\n", 16) = 16
  [pid  1977] select(6, [5], [], [], NULL

  which you get without the patch (notice the NULL for the timeout
  parameter). The code that gets blocked in this version of cloud-init
  is:

  ser.write("GET %s\n" % noun.rstrip())
  status = str(ser.readline()).rstrip()

  in cloudinit/sources/DataSourceSmartOS.py. The ser.readline()
  documentation says

  (https://pyserial.readthedocs.io/en/latest/shortintro.html#readline):

  Be careful when using readline(). Do specify a timeout when opening
  the serial port otherwise it could block forever if no newline
  character is received. Also note that readlines() only works with a
  timeout. readlines() depends on having a timeout and interprets that
  as EOF (end of file). It raises an exception if the port is not opened
  correctly.

  which is exactly the situation we've hit here.

  It might be better to have a timeout but when the timeout is hit, the
  GET should be retried if there's no answer rather than moving on to
  the next key. A negative answer (NOTFOUND for example) should not be
  retried, only when there's no answer (because metadata is
  unavailable).

  Once this is resolved, it should be possible to start a VM with cloud-
  init and metadata disabled, and then enable metadata some time later
  and have the boot process complete at that time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1667735/+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

[Yahoo-eng-team] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

[Scott Moser]

** No longer affects: cloud-init

** No longer affects: cloud-init (Ubuntu)

** No longer affects: cloud-init (Ubuntu Xenial)

** No longer affects: cloud-init (Ubuntu Yakkety)

-- 
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/1636912

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Yakkety:
  Fix Released

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list
  ii  cloud-init
0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all  Init 
scripts for cloud instances

  SRU INFORMATION FOR systemd
  ===
  Fix: For xenial it is sufficient to drop systemd-networkd's 
After=dbus.service (https://github.com/systemd/systemd/commit/5f004d1e32) and 
(for xenial only) drop the useless org.freedesktop.network1.busname unit (which 
is always "condition failed" as there is no kdbus, but it moves 
systemd-network.service after sockets.target which is too late for cloud-init).

  Regression potential: Low. networkd is not widely being used outside of 

[Yahoo-eng-team] [Bug 1661693] Re: identify brightbox platform to enable Ec2 datasource

[Scott Moser]

** Changed in: cloud-init
   Status: Confirmed => Fix Committed

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

-- 
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/1661693

Title:
  identify brightbox platform to enable Ec2 datasource

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  Brightbox provides an EC2 Metadata service lookalike, and that is how 
cloud-init
  gets metadata on their platform.

  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.

  We need to be able to positively identify that the host platform is
  brightbox so we can safely assume there will be a metadata service there.

  The easiest thing is for Brightbox to put something in dmi tables that 
identify
  their platform.  See bug 1660385 for more information and for how Amazon does
  this.

  Related bugs
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
   bug 1663304: identify openstack kvm platform on arm64
   bug 1663315: identify openstack kvm platform on ppc64

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1661693/+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

[Yahoo-eng-team] [Bug 1667878] [NEW] fstab entries with x-systemd.requires=cloud-init.service mean cloud-init will always run.

[Scott Moser]

Public bug reported:

when cloud-init writes mount entries into /etc/fstab, it adds:
 x-systemd.requires=cloud-init.service

This is because a subsequent boot of cloud-init may need to remove that
entry (a new instance for example).

cloud-init has a feature where it can be disabled by:
  sudo touch /etc/cloud/cloud-init.disabled

The generator for cloud-init then says that the cloud-init.target does
not need to run.

However, due to the (possibly stale) x-systemd.requires=cloud-
init.service entries, cloud-init will still run.

I think what I'd like is a:
  x-systemd.after=cloud-init.service

** Affects: cloud-init
 Importance: Medium
 Status: Confirmed

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/1667878

Title:
  fstab entries with x-systemd.requires=cloud-init.service mean cloud-
  init will always run.

Status in cloud-init:
  Confirmed

Bug description:
  when cloud-init writes mount entries into /etc/fstab, it adds:
   x-systemd.requires=cloud-init.service

  This is because a subsequent boot of cloud-init may need to remove
  that entry (a new instance for example).

  cloud-init has a feature where it can be disabled by:
sudo touch /etc/cloud/cloud-init.disabled

  The generator for cloud-init then says that the cloud-init.target does
  not need to run.

  However, due to the (possibly stale) x-systemd.requires=cloud-
  init.service entries, cloud-init will still run.

  I think what I'd like is a:
x-systemd.after=cloud-init.service

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1667878/+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

[Yahoo-eng-team] [Bug 1667831] Re: cloud-init dependency for open-vm-tools service

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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/1667831

Title:
  cloud-init dependency for open-vm-tools service

Status in cloud-init:
  New
Status in cloud-init package in Ubuntu:
  New

Bug description:
  Had a private chat conversation with Scott Moser (@smoser). As per his
  instructions, logging this bug. We need to add 'cloud-init' dependency
  for 'open-vm-tools' service.

  This is how 'Guest Customization' works for the 'VMware' managed
  guests.

  1. open-vm-tools service comes up and populates a 'customization' 
configuration file.
  2. cloud-init service starts and waits for the 'customization config' file, 
reads it and applies the customization.

  (1) should start before (2). Else, (2) will just block itself and not
  find the config file. Everything was working fine. But due to recent
  'systemd' changes done to 'cloud-init', 'cloud-init' service starts
  early in the boot process before 'open-vm-tools' service. Due to this,
  no customization actually happens.

  Need to add the 'cloud-init' dependency for 'open-vm-tools' service so
  that (1) always happens before (2).

  Logging a bug.

  Thanks
  Sankar.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1667831/+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

[Yahoo-eng-team] [Bug 1667777] [NEW] identify ovf datasource

[Scott Moser]

Public bug reported:

Currently there is no positive identification for ovf datasource in ds-identify.
The ovf specification for iso transport only says that there will be a cdrom 
attached in iso9660 format, and that it would have an 'ovf-env.xml' file.

At this point, ds-identify does not do any mounting of devices, so
mounting and looking for the file is not something I'd like to do if we
can avoid it at all.

For further reference:
  https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039697.html

** Affects: cloud-init
 Importance: Medium
 Status: Confirmed

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/166

Title:
  identify ovf datasource

Status in cloud-init:
  Confirmed

Bug description:
  Currently there is no positive identification for ovf datasource in 
ds-identify.
  The ovf specification for iso transport only says that there will be a cdrom 
attached in iso9660 format, and that it would have an 'ovf-env.xml' file.

  At this point, ds-identify does not do any mounting of devices, so
  mounting and looking for the file is not something I'd like to do if
  we can avoid it at all.

  For further reference:
https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039697.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/166/+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

[Yahoo-eng-team] [Bug 1667735] Re: cloud-init doesn't retry metadata lookups and hangs forever if metadata is down

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: cloud-init (Ubuntu Precise)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Trusty)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Precise)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Trusty)
   Importance: Undecided => Medium

-- 
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/1667735

Title:
  cloud-init doesn't retry metadata lookups and hangs forever if
  metadata is down

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Precise:
  Confirmed
Status in cloud-init source package in Trusty:
  Confirmed

Bug description:
  If a host SmartOS server is rebooted and the metadata service is not
  available, a KVM VM instance that use cloud-init (via the SmartOS
  datasource) will fail to start.

  If the metadata agent on the host server is not available the python
  code for cloud-init gets blocked forever waiting for data it will
  never receive. This causes the boot process for an instance to hang on
  cloud-init.

  This is problematic if there happens to be some reason the metadata
  agent is not available for any reason while a SmartOS KVM VM that
  relies on cloud-init is booting.

  From the engineer that worked on this (not the svadm command is run on
  the host SmartOS server):

  You can reproduce this by disabling the metadata service SmartOS host:

  svcadm disable metadata

  and then boot a KVM VM running an Ubuntu Certified Cloud image such
  as:

  c864f104-624c-43d2-835e-b49a39709b6b (ubuntu-certified-14.04
  20150225.2)

  when you do this, the VM's boot process will hang at cloud-init. If
  you then start the metadata service, cloud-init will not recover.

  On of our engineers who looked at this was able to cause forward
  progress by applying this patch:

  --- 
/usr/lib/python2.7/dist-packages/cloudinit/sources/DataSourceSmartOS.py.ori 
  2017-02-23 01:28:28.405885775 +
  +++ /usr/lib/python2.7/dist-packages/cloudinit/sources/DataSourceSmartOS.py   
2017-02-23 01:35:51.281885775 +
  @@ -286,7 +286,7 @@
   if not seed_device:
   raise AttributeError("seed_device value is not set")

  -ser = serial.Serial(seed_device, timeout=seed_timeout)
  +ser = serial.Serial(seed_device, timeout=10)
   if not ser.isOpen():
   raise SystemError("Unable to open %s" % seed_device)

  which causes the following strace output:

  [pid  2119] open("/dev/ttyS1", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5
  [pid  2119] ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or 
TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
  [pid  2119] write(5, "GET user-script\n", 16) = 16
  [pid  2119] select(6, [5], [], [], {10, 0}) = 0 (Timeout)
  [pid  2119] close(5)= 0
  [pid  2119] open("/dev/ttyS1", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5
  [pid  2119] ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or 
TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
  [pid  2119] write(5, "GET iptables_disable\n", 21) = 21
  [pid  2119] select(6, [5], [], [], {10, 0}) = 0 (Timeout)
  [pid  2119] close(5)= 0

  instead of:

  [pid  1977] open("/dev/ttyS1", O_RDWR|O_NOCTTY|O_NONBLOCK) = 5
  [pid  1977] ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or 
TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
  [pid  1977] write(5, "GET base64_keys\n", 16) = 16
  [pid  1977] select(6, [5], [], [], NULL

  which you get without the patch (notice the NULL for the timeout
  parameter). The code that gets blocked in this version of cloud-init
  is:

  ser.write("GET %s\n" % noun.rstrip())
  status = str(ser.readline()).rstrip()

  in cloudinit/sources/DataSourceSmartOS.py. The ser.readline()
  documentation says

  (https://pyserial.readthedocs.io/en/latest/shortintro.html#readline):

  Be careful when using readline(). Do specify a timeout when opening
  the serial port otherwise it could block forever if no newline
  character is received. Also note that readlines() only works with a
  timeout. readlines() depends on having a timeout and interprets that
  as EOF (end of file). It raises an exception if the port is not opened
  correctly.

  which is exactly the situation we've hit here.

[Yahoo-eng-team] [Bug 1661797] Re: identify lxd-nova platform to enable Openstack datasource

[Scott Moser]

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: nova-lxd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Zesty)
   Importance: High
   Status: Fix Released

** Also affects: nova-lxd (Ubuntu Zesty)
   Importance: Medium
   Status: Confirmed

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: nova-lxd (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: nova-lxd (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: nova-lxd (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: nova-lxd (Ubuntu Yakkety)
   Importance: Undecided => High

** Changed in: nova-lxd (Ubuntu Yakkety)
   Status: New => Confirmed

-- 
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/1661797

Title:
  identify lxd-nova platform to enable Openstack datasource

Status in cloud-init:
  Fix Committed
Status in nova-lxd:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in nova-lxd package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed
Status in nova-lxd source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed
Status in nova-lxd source package in Yakkety:
  Confirmed
Status in cloud-init source package in Zesty:
  Fix Released
Status in nova-lxd source package in Zesty:
  Confirmed

Bug description:
  nova-lxd uses the Openstack Network metadata service.

  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.

  We need to be able to positively identify that the container we are running
  inside should have access to an openstack metadata service so we can
  safely assume it will be there.

  How can we positively identify that a container is running in nova-lxd?
  Is there anything in the environment (possibly pid 1 environ?) that we
  can look at?

  One way I could see doing t his would be for lxd-nova to put
     CLOUD_PLATFORM='openstack-nova'
  inside the pid 1 environment.  then cloud-init can look at /proc/1/environ
  and pick that out.

  Open to other ideas, and would love it if there was something we could
  do.

  Related bugs
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
   bug 1663304: identify openstack kvm platform on arm64

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1661797/+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

[Yahoo-eng-team] [Bug 1663735] Re: ds-identify finding by fslabel does not work right

[Scott Moser]

** Summary changed:

- ds-identify finding by fslable does not work right
+ ds-identify finding by fslabel does not work right

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: Confirmed => Fix Committed

** Changed in: cloud-init
   Importance: Medium => High

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

-- 
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/1663735

Title:
  ds-identify finding by fslabel does not work right

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  in vmtest for curtin, we fail to boot the installed system because
  has_fs_with_label does not work right.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1663735/+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

[Yahoo-eng-team] [Bug 1663735] [NEW] ds-identify finding by fslable does not work right

[Scott Moser]

Public bug reported:

in vmtest for curtin, we fail to boot the installed system because
has_fs_with_label does not work right.

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
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/1663735

Title:
  ds-identify finding by fslable does not work right

Status in cloud-init:
  New

Bug description:
  in vmtest for curtin, we fail to boot the installed system because
  has_fs_with_label does not work right.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1663735/+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

[Yahoo-eng-team] [Bug 1661797] Re: identify lxd-nova platform to enable Openstack datasource

[Scott Moser]

** Changed in: cloud-init
   Status: Confirmed => Fix Committed

** Also affects: nova-lxd (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: nova-lxd (Ubuntu)
   Status: New => Confirmed

** Changed in: nova-lxd (Ubuntu)
   Importance: Undecided => Medium

-- 
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/1661797

Title:
  identify lxd-nova platform to enable Openstack datasource

Status in cloud-init:
  Fix Committed
Status in nova-lxd:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in nova-lxd package in Ubuntu:
  Confirmed

Bug description:
  nova-lxd uses the Openstack Network metadata service.

  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.

  We need to be able to positively identify that the container we are running
  inside should have access to an openstack metadata service so we can
  safely assume it will be there.

  How can we positively identify that a container is running in nova-lxd?
  Is there anything in the environment (possibly pid 1 environ?) that we
  can look at?

  One way I could see doing t his would be for lxd-nova to put
     CLOUD_PLATFORM='openstack-nova'
  inside the pid 1 environment.  then cloud-init can look at /proc/1/environ
  and pick that out.

  Open to other ideas, and would love it if there was something we could
  do.

  Related bugs
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
   bug 1663304: identify openstack kvm platform on arm64

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1661797/+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

[Yahoo-eng-team] [Bug 1663315] [NEW] identify openstack kvm platform on ppc64

[Scott Moser]

Public bug reported:

On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
information. OpenStack using kvm on ppc64el or ppc64, does not identify itself
to the guest in any way.

The result is that cloud-init cannot identify it is running on
openstack.

We need two things
 a.) change openstack to provide that information through libvirt on ppc64
 in some way.
 b.) possibly changes in qemu to pass information through that the guest
 can see.  Some options here might include putting information in
 the device tree or possibly on the attached disk (model of the disk could 
be 'OpenStack disk ').

Related bugs:
 bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
 bug 1661797: identify lxd-nova platform to enable Openstack datasource
 bug 1661693: identify brightbox platform to enable Ec2 datasource
 bug 1663304: identify openstack kvm platform on arm64
 bug 1662345: [qemu] smbios parameter settings not visible in guest

** Affects: cloud-init
 Importance: Medium
 Status: Confirmed

** Affects: nova
 Importance: Undecided
 Status: New

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1663315

Title:
   identify openstack kvm platform on ppc64

Status in cloud-init:
  Confirmed
Status in OpenStack Compute (nova):
  New

Bug description:
  On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
  information. OpenStack using kvm on ppc64el or ppc64, does not identify itself
  to the guest in any way.

  The result is that cloud-init cannot identify it is running on
  openstack.

  We need two things
   a.) change openstack to provide that information through libvirt on ppc64
   in some way.
   b.) possibly changes in qemu to pass information through that the guest
   can see.  Some options here might include putting information in
   the device tree or possibly on the attached disk (model of the disk 
could be 'OpenStack disk ').

  Related bugs:
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
   bug 1663304: identify openstack kvm platform on arm64
   bug 1662345: [qemu] smbios parameter settings not visible in guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1663315/+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

[Yahoo-eng-team] [Bug 1663304] Re: identify openstack kvm platform on arm64

[Scott Moser]

** Also affects: nova
   Importance: Undecided
   Status: New

** Changed in: nova
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1663304

Title:
  identify openstack kvm platform on arm64

Status in cloud-init:
  Confirmed
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
  information.  OpenStack using kvm on arm64, does not identify itself to the
  guest in any way.

  The result is that OpenStack nodes will not attempt to reach the metadata
  service and will be unusable.

  We need two things
   a.) change openstack to provide that information through libvirt on arm.
   b.) fix qemu bug 1662345 that prevents the information from getting to the 
guest.

  Related bugs:
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
   bug 1663304: identify openstack kvm platform on arm64
   bug 1662345: [qemu] smbios parameter settings not visible in guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1663304/+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

[Yahoo-eng-team] [Bug 1663304] [NEW] identify openstack kvm platform on arm64

[Scott Moser]

Public bug reported:

On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
information.  OpenStack using kvm on arm64, does not identify itself to the
guest in any way.

The result is that OpenStack nodes will not attempt to reach the metadata
service and will be unusable.

We need two things
 a.) change openstack to provide that information through libvirt on arm.
 b.) fix qemu bug 1662345 that prevents the information from getting to the 
guest.

Related bugs:
 bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
 bug 1661797: identify lxd-nova platform to enable Openstack datasource
 bug 1661693: identify brightbox platform to enable Ec2 datasource
 bug 1663304: identify openstack kvm platform on arm64
 bug 1662345: [qemu] smbios parameter settings not visible in guest

** Affects: cloud-init
 Importance: Medium
 Status: Confirmed

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Description changed:

  On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
  information.  OpenStack using kvm on arm64, does not identify itself to the
  guest in any way.
  
+ The result is that OpenStack nodes will not attempt to reach the metadata
+ service and will be unusable.
+ 
  We need two things
-  a.) change openstack to provide that information through libvirt on arm.
-  b.) fix qemu bug 1662345 that prevents the information from getting to the 
guest.
+  a.) change openstack to provide that information through libvirt on arm.
+  b.) fix qemu bug 1662345 that prevents the information from getting to the 
guest.
  
  Related bugs:
-  bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
-  bug 1661797: identify lxd-nova platform to enable Openstack datasource
-  bug 1661693: identify brightbox platform to enable Ec2 datasource
-  bug XXX: identify openstack kvm platform on arm64
-  bug 1662345: [qemu] smbios parameter settings not visible in guest
+  bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
+  bug 1661797: identify lxd-nova platform to enable Openstack datasource
+  bug 1661693: identify brightbox platform to enable Ec2 datasource
+  bug XXX: identify openstack kvm platform on arm64
+  bug 1662345: [qemu] smbios parameter settings not visible in guest

** Description changed:

  On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
  information.  OpenStack using kvm on arm64, does not identify itself to the
  guest in any way.
  
  The result is that OpenStack nodes will not attempt to reach the metadata
  service and will be unusable.
  
  We need two things
   a.) change openstack to provide that information through libvirt on arm.
   b.) fix qemu bug 1662345 that prevents the information from getting to the 
guest.
  
  Related bugs:
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
-  bug XXX: identify openstack kvm platform on arm64
+  bug 1663304: identify openstack kvm platform on arm64
   bug 1662345: [qemu] smbios parameter settings not visible in guest

-- 
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/1663304

Title:
  identify openstack kvm platform on arm64

Status in cloud-init:
  Confirmed

Bug description:
  On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
  information.  OpenStack using kvm on arm64, does not identify itself to the
  guest in any way.

  The result is that OpenStack nodes will not attempt to reach the metadata
  service and will be unusable.

  We need two things
   a.) change openstack to provide that information through libvirt on arm.
   b.) fix qemu bug 1662345 that prevents the information from getting to the 
guest.

  Related bugs:
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource
   bug 1661693: identify brightbox platform to enable Ec2 datasource
   bug 1663304: identify openstack kvm platform on arm64
   bug 1662345: [qemu] smbios parameter settings not visible in guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1663304/+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

[Yahoo-eng-team] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

[Scott Moser]

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

-- 
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 Committed
Status in cloud-init source package in Yakkety:
  Confirmed

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

[Yahoo-eng-team] [Bug 1647910] Re: hostname is set incorrectly if localhostname is fully qualified

[Scott Moser]

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

-- 
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/1647910

Title:
  hostname is set incorrectly if localhostname is fully qualified

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Committed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  If no data source is available and the local hostname is set to
  "localhost.localdomain", and /etc/hosts looks like:

127.0.0.1   localhost localhost.localdomain localhost4
  localhost4.localdomain4

  Then in sources/__init__.py in get_hostname:

  - util.get_hostname() will return 'localhost.localdomain'
  - util.get_fqdn_from_hosts(hostname) will return 'localhost'
  - 'toks' will be set to [ 'localhost.localdomain', 'localdomain'

  And ultimately the system hostname will be set to
  'localhost.localdomain.localdomain', which isn't useful to anybody.

  Also reported in:

  https://bugzilla.redhat.com/show_bug.cgi?id=1389048

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1647910/+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

[Yahoo-eng-team] [Bug 1661797] Re: identify lxd-nova platform to enable Openstack datasource

[Scott Moser]

** Also affects: nova-lxd
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: nova-lxd
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => High

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => High

** Description changed:

  nova-lxd uses the Openstack Network metadata service.
  
  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.
  
- We need to be able to positively identify that the container we are running 
+ We need to be able to positively identify that the container we are running
  inside should have access to an openstack metadata service so we can
  safely assume it will be there.
  
  How can we positively identify that a container is running in nova-lxd?
  Is there anything in the environment (possibly pid 1 environ?) that we
  can look at?
  
- One way I could see doing t his would be for lxd-nova to put 
-CLOUD_PLATFORM='openstack-nova'
+ One way I could see doing t his would be for lxd-nova to put
+    CLOUD_PLATFORM='openstack-nova'
  inside the pid 1 environment.  then cloud-init can look at /proc/1/environ
  and pick that out.
  
  Open to other ideas, and would love it if there was something we could
  do.
  
  Related bugs
-  bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
+  bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
+  bug 1661797: identify lxd-nova platform to enable Openstack datasource 
+  bug 1661693: identify brightbox platform to enable Ec2 datasource

-- 
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/1661797

Title:
  identify lxd-nova platform to enable Openstack datasource

Status in cloud-init:
  Confirmed
Status in nova-lxd:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  nova-lxd uses the Openstack Network metadata service.

  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.

  We need to be able to positively identify that the container we are running
  inside should have access to an openstack metadata service so we can
  safely assume it will be there.

  How can we positively identify that a container is running in nova-lxd?
  Is there anything in the environment (possibly pid 1 environ?) that we
  can look at?

  One way I could see doing t his would be for lxd-nova to put
     CLOUD_PLATFORM='openstack-nova'
  inside the pid 1 environment.  then cloud-init can look at /proc/1/environ
  and pick that out.

  Open to other ideas, and would love it if there was something we could
  do.

  Related bugs
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1661797: identify lxd-nova platform to enable Openstack datasource 
   bug 1661693: identify brightbox platform to enable Ec2 datasource

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1661797/+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

[Yahoo-eng-team] [Bug 1661797] [NEW] identify lxd-nova platform to enable Openstack datasource

[Scott Moser]

Public bug reported:

nova-lxd uses the Openstack Network metadata service.

In an effort to avoid polling metadata services in cloud-init we will disable
attempts to reach the MD without positive identification of the cloud.

We need to be able to positively identify that the container we are running 
inside should have access to an openstack metadata service so we can
safely assume it will be there.

How can we positively identify that a container is running in nova-lxd?
Is there anything in the environment (possibly pid 1 environ?) that we
can look at?

One way I could see doing t his would be for lxd-nova to put 
   CLOUD_PLATFORM='openstack-nova'
inside the pid 1 environment.  then cloud-init can look at /proc/1/environ
and pick that out.

Open to other ideas, and would love it if there was something we could
do.

Related bugs
 bug 1660385: Alert user of Ec2 Datasource on lookalike cloud

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
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/1661797

Title:
  identify lxd-nova platform to enable Openstack datasource

Status in cloud-init:
  New

Bug description:
  nova-lxd uses the Openstack Network metadata service.

  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.

  We need to be able to positively identify that the container we are running 
  inside should have access to an openstack metadata service so we can
  safely assume it will be there.

  How can we positively identify that a container is running in nova-lxd?
  Is there anything in the environment (possibly pid 1 environ?) that we
  can look at?

  One way I could see doing t his would be for lxd-nova to put 
 CLOUD_PLATFORM='openstack-nova'
  inside the pid 1 environment.  then cloud-init can look at /proc/1/environ
  and pick that out.

  Open to other ideas, and would love it if there was something we could
  do.

  Related bugs
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1661797/+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

[Yahoo-eng-team] [Bug 1661693] [NEW] identify brightbox platform to enable Ec2 datasource

[Scott Moser]

Public bug reported:

Brightbox provides an EC2 Metadata service lookalike, and that is how cloud-init
gets metadata on their platform.

In an effort to avoid polling metadata services in cloud-init we will disable
attempts to reach the MD without positive identification of the cloud.

We need to be able to positively identify that the host platform is
brightbox so we can safely assume there will be a metadata service there.

The easiest thing is for Brightbox to put something in dmi tables that identify
their platform.  See bug 1660385 for more information and for how Amazon does
this.

Related bugs
 bug 1660385: Alert user of Ec2 Datasource on lookalike cloud

** Affects: cloud-init
 Importance: Medium
 Status: Confirmed

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/1661693

Title:
  identify brightbox platform to enable Ec2 datasource

Status in cloud-init:
  Confirmed

Bug description:
  Brightbox provides an EC2 Metadata service lookalike, and that is how 
cloud-init
  gets metadata on their platform.

  In an effort to avoid polling metadata services in cloud-init we will disable
  attempts to reach the MD without positive identification of the cloud.

  We need to be able to positively identify that the host platform is
  brightbox so we can safely assume there will be a metadata service there.

  The easiest thing is for Brightbox to put something in dmi tables that 
identify
  their platform.  See bug 1660385 for more information and for how Amazon does
  this.

  Related bugs
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1661693/+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

[Yahoo-eng-team] [Bug 1660385] [NEW] Alert user of Ec2 Datasource on lookalike cloud

[Scott Moser]

Public bug reported:

Many cloud providers mimic the EC2 Metadata service [1] in order to provide
a level of EC2 compatibility for images.  This is quite useful and allows
image portability.

Because this is a network based metadata service, cloud-init opportunistically
poll an IPv4 link local address (http://169.254.169.254) to determine if there
is metadata available.  That can have negative side affects such as timeouts.

AWS has recently begun providing a way for instances to determine if they
are running on EC2 [2].

Cloud-init will change its behavior to only attempt to find the EC2 metadata
service only if it has determined itself to be running on EC2 or another
known cloud provider which provides an EC2 metadata service.

--
[1] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
[2] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html

** Affects: cloud-init
 Importance: Medium
 Assignee: Scott Moser (smoser)
 Status: In Progress

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: Confirmed => In Progress

** Changed in: cloud-init
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
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/1660385

Title:
  Alert user of Ec2 Datasource on lookalike cloud

Status in cloud-init:
  In Progress

Bug description:
  Many cloud providers mimic the EC2 Metadata service [1] in order to provide
  a level of EC2 compatibility for images.  This is quite useful and allows
  image portability.

  Because this is a network based metadata service, cloud-init opportunistically
  poll an IPv4 link local address (http://169.254.169.254) to determine if there
  is metadata available.  That can have negative side affects such as timeouts.

  AWS has recently begun providing a way for instances to determine if they
  are running on EC2 [2].

  Cloud-init will change its behavior to only attempt to find the EC2 metadata
  service only if it has determined itself to be running on EC2 or another
  known cloud provider which provides an EC2 metadata service.

  --
  [1] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
  [2] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1660385/+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

[Yahoo-eng-team] [Bug 1657940] Re: eni rendering dhcp6 writes aliases fails to bring up dhcp6

[Scott Moser]

** Changed in: cloud-init
   Status: In Progress => Fix Committed

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Committed

** Changed in: cloud-init (Ubuntu)
   Status: Fix Committed => Confirmed

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

-- 
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/1657940

Title:
  eni rendering dhcp6 writes aliases fails to bring up dhcp6

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  Currently, a config like this:
  | version: 1
  | config:
  |- 'type': 'physical'
  |  'name': 'iface0'
  |  'subnets':
  |- {'type': 'dhcp4'}
  |- {'type': 'dhcp6'}

  Will render:
  | auto lo
  | iface lo inet loopback
  | 
  | auto iface0
  | iface iface0 inet dhcp
  | post-up ifup iface0:1
  | 
  | 
  | auto iface0:1
  | iface iface0:1 inet6 dhcp

  Below is an example test case that shows the output.
  Heres the problem:
  $ sudo sh -c 'ifdown eth0; ifup eth0'
  $ sudo sh -c 'ifdown eth0; ifup eth0'
  Killed old client process
  Internet Systems Consortium DHCP Client 4.3.3
  Copyright 2004-2015 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   Socket/fallback
  DHCPRELEASE on eth0 to 172.31.16.1 port 67 (xid=0x32b625f1)
  Internet Systems Consortium DHCP Client 4.3.3
  Copyright 2004-2015 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   Socket/fallback
  DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0xa4d5f301)
  DHCPREQUEST of 172.31.29.161 on eth0 to 255.255.255.255 port 67 
(xid=0x1f3d5a4)
  DHCPOFFER of 172.31.29.161 from 172.31.16.1
  DHCPACK of 172.31.29.161 from 172.31.16.1
  bound to 172.31.29.161 -- renewal in 1801 seconds.

  Failed to bring up eth0:1.
  Failed to bring up eth0.

  $ sudo ifup -v eth0:1
  Parsing file /etc/network/interfaces.d/50-cloud-init.cfg
  Parsing file /etc/network/interfaces.d/60-ipv6.cfg
  Configuring interface eth0:1=eth0:1 (inet6)
  /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
  run-parts: executing /etc/network/if-pre-up.d/ethtool
  run-parts: executing /etc/network/if-pre-up.d/ifenslave
  + [ inet6 = meta ]
  + IF_BOND_SLAVES=
  + [  ]
  + [  ]
  + [ -z  ]
  + exit
  run-parts: executing /etc/network/if-pre-up.d/vlan
  /sbin/modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure.
  /sbin/sysctl -q -e -w net.ipv6.conf.eth0:1.accept_ra=1

  /bin/ip link set dev eth0:1  up
  /lib/ifupdown/wait-for-ll6.sh
  /sbin/dhclient -1 -6 -pf /run/dhclient6.eth0:1.pid -lf 
/var/lib/dhcp/dhclient6.eth0:1.leases -I -df 
/var/lib/dhcp/dhclient.eth0:1.leases eth0:1

  
  --- a/tests/unittests/test_net.py
  +++ b/tests/unittests/test_net.py
  @@ -813,6 +813,27 @@ class TestEniRoundTrip(TestCase):
   self.assertEqual(
   expected, [line for line in found if line])
   
  +def test_dhcp4_and_dhcp6(self):
  +conf = yaml.load(textwrap.dedent("""\
  +version: 1
  +config:
  +   - 'type': 'physical'
  + 'name': 'iface0'
  + 'subnets': 
  +   - {'type': 'dhcp4'}
  +   - {'type': 'dhcp6'}
  +   """))
  +
  +#conf = [
  +#{'type': 'physical', 'name': 'iface0',
  +# 'subnets': [
  +# {'type': 'dhcp4'},
  +# {'type': 'dhcp6'},
  +# ]},
  +#]
  +files = self._render_and_read(network_config=conf)
  +raise Exception(files['/etc/network/interfaces'])
  +

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1657940/+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

[Yahoo-eng-team] [Bug 1657940] [NEW] eni rendering dhcp6 writes aliases fails to bring up dhcp6

[Scott Moser]

Public bug reported:

Currently, a config like this:
| version: 1
| config:
|- 'type': 'physical'
|  'name': 'iface0'
|  'subnets':
|- {'type': 'dhcp4'}
|- {'type': 'dhcp6'}

Will render:
| auto lo
| iface lo inet loopback
| 
| auto iface0
| iface iface0 inet dhcp
| post-up ifup iface0:1
| 
| 
| auto iface0:1
| iface iface0:1 inet6 dhcp

Below is an example test case that shows the output.
Heres the problem:
$ sudo sh -c 'ifdown eth0; ifup eth0'
$ sudo sh -c 'ifdown eth0; ifup eth0'
Killed old client process
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/06:b3:0a:3a:2d:e3
Sending on   LPF/eth0/06:b3:0a:3a:2d:e3
Sending on   Socket/fallback
DHCPRELEASE on eth0 to 172.31.16.1 port 67 (xid=0x32b625f1)
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/06:b3:0a:3a:2d:e3
Sending on   LPF/eth0/06:b3:0a:3a:2d:e3
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0xa4d5f301)
DHCPREQUEST of 172.31.29.161 on eth0 to 255.255.255.255 port 67 (xid=0x1f3d5a4)
DHCPOFFER of 172.31.29.161 from 172.31.16.1
DHCPACK of 172.31.29.161 from 172.31.16.1
bound to 172.31.29.161 -- renewal in 1801 seconds.

Failed to bring up eth0:1.
Failed to bring up eth0.

$ sudo ifup -v eth0:1
Parsing file /etc/network/interfaces.d/50-cloud-init.cfg
Parsing file /etc/network/interfaces.d/60-ipv6.cfg
Configuring interface eth0:1=eth0:1 (inet6)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/ifenslave
+ [ inet6 = meta ]
+ IF_BOND_SLAVES=
+ [  ]
+ [  ]
+ [ -z  ]
+ exit
run-parts: executing /etc/network/if-pre-up.d/vlan
/sbin/modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure.
/sbin/sysctl -q -e -w net.ipv6.conf.eth0:1.accept_ra=1

/bin/ip link set dev eth0:1  up
/lib/ifupdown/wait-for-ll6.sh
/sbin/dhclient -1 -6 -pf /run/dhclient6.eth0:1.pid -lf 
/var/lib/dhcp/dhclient6.eth0:1.leases -I -df 
/var/lib/dhcp/dhclient.eth0:1.leases eth0:1


--- a/tests/unittests/test_net.py
+++ b/tests/unittests/test_net.py
@@ -813,6 +813,27 @@ class TestEniRoundTrip(TestCase):
 self.assertEqual(
 expected, [line for line in found if line])
 
+def test_dhcp4_and_dhcp6(self):
+conf = yaml.load(textwrap.dedent("""\
+version: 1
+config:
+   - 'type': 'physical'
+ 'name': 'iface0'
+ 'subnets': 
+   - {'type': 'dhcp4'}
+   - {'type': 'dhcp6'}
+   """))
+
+#conf = [
+#{'type': 'physical', 'name': 'iface0',
+# 'subnets': [
+# {'type': 'dhcp4'},
+# {'type': 'dhcp6'},
+# ]},
+#]
+files = self._render_and_read(network_config=conf)
+raise Exception(files['/etc/network/interfaces'])
+

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
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/1657940

Title:
  eni rendering dhcp6 writes aliases fails to bring up dhcp6

Status in cloud-init:
  New

Bug description:
  Currently, a config like this:
  | version: 1
  | config:
  |- 'type': 'physical'
  |  'name': 'iface0'
  |  'subnets':
  |- {'type': 'dhcp4'}
  |- {'type': 'dhcp6'}

  Will render:
  | auto lo
  | iface lo inet loopback
  | 
  | auto iface0
  | iface iface0 inet dhcp
  | post-up ifup iface0:1
  | 
  | 
  | auto iface0:1
  | iface iface0:1 inet6 dhcp

  Below is an example test case that shows the output.
  Heres the problem:
  $ sudo sh -c 'ifdown eth0; ifup eth0'
  $ sudo sh -c 'ifdown eth0; ifup eth0'
  Killed old client process
  Internet Systems Consortium DHCP Client 4.3.3
  Copyright 2004-2015 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   Socket/fallback
  DHCPRELEASE on eth0 to 172.31.16.1 port 67 (xid=0x32b625f1)
  Internet Systems Consortium DHCP Client 4.3.3
  Copyright 2004-2015 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   LPF/eth0/06:b3:0a:3a:2d:e3
  Sending on   Socket/fallback
  DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0xa4d5f301)
  DHCPREQUEST of 172.31.29.161 on eth0 to 255.255.255.255 port 67 
(xid=0x1f3d5a4)
  DHCPOFFER of 172.31.29.161 from 172.31.16.1
  

[Yahoo-eng-team] [Bug 1639030] Re: Configure networking based on EC2 metadata source

[Scott Moser]

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/1639030

Title:
  Configure networking based on EC2 metadata source

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  New

Bug description:
  EC2 metadata[1] presents information regarding network devices (mac,
  name, etc) that would be useful to consume.  Chiefly we could match
  the network device names surfaced in the EC2 UIs (eth0, eth2...)
  rather than using our own enumeration at boot.

  A method to detemermine if we are on an instance in EC2 as been
  published[2] as part of their documentation so we can now do this in
  the EC2 datasource without impacting clouds that have copied that
  datasource.

  The work done for DO datasource[3] would be applicable here as a
  model.

  [1] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
  [2] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html
  [3] 
https://git.launchpad.net/cloud-init/commit/?id=9f83bb8e80806d3dd79ba426474dc3c696e19a41

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1639030/+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

[Yahoo-eng-team] [Bug 1645644] Re: ntp not using expected servers

[Scott Moser]

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** No longer affects: maas (Ubuntu)

-- 
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/1645644

Title:
  ntp not using expected servers

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  In Progress

Bug description:
  cloud-init: 0.7.8-49-g9e904bb-0ubuntu1~16.04.1

  Expected NTP server address is written in /etc/ntp.conf by cloud-init through 
vendor-data. However, `ntpq -p` shows the default ntp pools, not my local NTP 
server written in /etc/ntp.conf.
  It looks like cloud-init needs to write /etc/ntp.conf before installing ntp 
package, or restart ntp after writing /etc/ntp.conf.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1645644/+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

[Yahoo-eng-team] [Bug 1611074] Re: Reformatting of ephemeral drive fails on resize of Azure VM

[Scott Moser]

This is fixed in 0.7.9.

** Changed in: cloud-init
   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/1611074

Title:
  Reformatting of ephemeral drive fails on resize of Azure VM

Status in cloud-init:
  Fix Released
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 Template ===
  [Impact]
  In some cases, cloud-init writes entries to /etc/fstab, and on azure it will
  even format a disk for mounting and then write the entry for that 'ephemeral'
  disk there.

  A supported operation on Azure is to "resize" the system.  When you do this
  the system is shut down, resized (given larger/faster disks and more CPU) and
  then brought back up.  In that process, the "ephemeral" disk re-initialized
  to its original NTFS format.  The designed goal is for cloud-init to recognize
  this situation and re-format the disk to ext4.

  The problem is that the mount of that disk happens before cloud-init can
  reformat.  Thats because the entry in fstab has 'auto' and is automatically
  mounted.  The end result is that after resize operation the user will be left
  with the ephemeral disk mounted at /mnt and having a ntfs filesystem rather
  than ext4.

  [Test Case]
  The text in comment 3 describes how to recreate by the original reporter.
  Another way to do this is to just re-format the ephemeral disk as
  ntfs and then reboot.  The result *should* be that after reboot it
  comes back up and has an ext4 filesystem on it.

  1.) boot system on azure
    (for this, i use https://gist.github.com/smoser/5806147, but you can
     use web ui or any other way).
     Save output of
   journalctl --no-pager > journalctl.orig
   systemctl status --no-pager > systemctl-status.orig
   systemctl --no-pager > systemctl.orig

  2.) unmount the ephemeral disk
     $ umount /mnt

  3.) repartition it so that mkfs.ntfs does less and is faster
     This is not strictly necessary, but mkfs.ntfs can take upwards of
     20 minutes.  shrinking /dev/sdb2 to be 200M means it will finish
     in < 1 minute.

     $ disk=/dev/disk/cloud/azure_resource
     $ part=/dev/disk/cloud/azure_resource-part1
     $ echo "2048,$((2*1024*100)),7" | sudo sfdisk "$disk"
     $ time mkfs.ntfs --quick "$part"

  4.) reboot
  5.) expect that /proc/mounts has /dev/disk/cloud/azure_resource-part1 as ext4
  and that fstab has x-systemd.requires in it.

  $ awk '$2 == "/mnt" { print $0 }' /proc/mounts
  /dev/sdb1 /mnt ext4 rw,relatime,data=ordered 0 0

  $ awk '$2 == "/mnt" { print $0 }' /etc/fstab
  /dev/sdb1 /mnt auto 
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig 0 2

  6.) collect journal and systemctl information as described in step 1 above.
  Compare output, specifically looking for case insensitve "breaks"

  [Regression Potential]
  Regression is unlikely.  Likely failure case is just that the problem is not
  correctly fixed, and the user ends up with either an NTFS formated disk that
  is mounted at /mnt or there is nothing mounted at /mnt.

  === End SRU Template ===

  After resizing a 16.04 VM on Azure, the VM is presented with a new
  ephemeral drive (of a different size), which initially is NTFS
  formatted. Cloud-init tries to format the appropriate partition ext4,
  but fails because it is mounted. Cloud-init has unmount logic for
  exactly this case in the get_data call on the Azure data source, but
  this is never called because fresh cache is found.

  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] handlers.py[DEBUG]: start: 
init-network/check-cache: attempting to read from cache [trust]
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Reading from 
/var/lib/cloud/instance/obj.pkl (quiet=False)
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Read 5950 bytes 
from /var/lib/cloud/instance/obj.pkl
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] stages.py[DEBUG]: restored from 
cache: DataSourceAzureNet [seed=/dev/sr0]
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] handlers.py[DEBUG]: finish: 
init-network/check-cache: SUCCESS: restored from cache: DataSourceAzureNet 
[seed=/dev/sr0]
  ...
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] cc_disk_setup.py[DEBUG]: Creating 
file system None on /dev/sdb1
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] cc_disk_setup.py[DEBUG]:  
Using cmd: /sbin/mkfs.ext4 /dev/sdb1
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Running command 
['/sbin/mkfs.ext4', '/dev/sdb1'] with allowed return codes [0] (shell=False, 
capture=True)
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Creating fs for 
/dev/disk/cloud/azure_resource took 0.052 seconds
  Jun 27 19:07:48 azubuntu1604arm 

[Yahoo-eng-team] [Bug 1351960] Re: cloud-init.log inconsistent date format

[Scott Moser]

** Changed in: cloud-init
   Status: Confirmed => Fix Released

** Changed in: cloud-init
Milestone: 0.7.9 => None

-- 
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/1351960

Title:
  cloud-init.log inconsistent date format

Status in cloud-init:
  Fix Released

Bug description:
  The first field of the /var/log/cloud-init.log file alternates between
  ISO and local date formats.  In the attached example, the change
  happens at:

2014-08-03 01:45:53,472 - util.py[DEBUG]: Read 12 bytes from 
/proc/uptime
2014-08-03 01:45:53,472 - util.py[DEBUG]: cloud-init mode 'init' took 
12.704 seconds (12.71)
Aug  3 01:45:56 test209 [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.5 
running 'modules:config' at Sun, 03 Aug 2014 01:45:56 +. Up 94.33 seconds.
Aug  3 01:45:56 test209 [CLOUDINIT] importer.py[DEBUG]: Looking for 
modules ['cc_emit_upstart', 'cloudinit.config.cc_emit_upstart'] that have 
attributes ['handle']

  Expected behavior is consistency in the date format.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1351960/+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

[Yahoo-eng-team] [Bug 1623868] Re: cloud-final.service does not run due to dependency cycle

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => 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/1623868

Title:
  cloud-final.service does not run due to dependency cycle

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
   Begin SRU Template 
  [Impact]
  As part of the change in bug 1576692, we made cloud-final.target
  run After multi-user.target.  That created a dependency loop between
  cloud-init.target and multi-user.target and cloud-final.target.

  Most of the time systemd would break that loop by dropping
  cloud-init.target.  But sometimes, it would break the loop by dropping
  cloud-final.target, which would mean that user scripts do not run
  and generally cloud-init doesn't finish.

  [Test Case]
  ## Failure in a xenial image can only be reproduced by
  ## patching an image up to the previous xenial-proposed upload
  ## (0.7.7-31-g65ace7b-0ubuntu1~16.04.1), then cleaning it
  ## and then restarting.  We will focus on verifying there is not
  ## a problem.

  ## Launch an instance and patch it up to xenial-proposed
  $ release=xenial
  $ name=x1
  $ lxc launch ubuntu-daily:$release $name

  # wait for it to boot
  $ while ! lxc exec $name -- [ -e /run/cloud-init/result.json ]; do sleep 1; 
done

  ## Now update container, clean and reboot to show first boot
  $ lxc exec $name -- sh -c '
  p=/etc/apt/sources.list.d/proposed.list
  echo deb http://archive.ubuntu.com/ubuntu xenial-proposed main > "$p" &&
  apt-get update -q && apt-get -qy install cloud-init'
  $ lxc exec $name -- sh -c '
  cd /var/lib/cloud && for d in *; do [ "$d" = "seed" ] || rm -Rf "$d"; done
  rm -Rf /var/log/cloud-init*'

  ## This is like first boot now.
  $ lxc exec $name reboot
  $ while ! lxc exec $name -- [ -e /run/cloud-init/result.json ]; do sleep 1; 
done

  ## The services should show active
  $ lxc exec $name -- journalctl | grep Break || echo Good, no breaks
  $ lxc exec $name -- systemctl --no-pager status cloud-final.service
  $ lxc exec $name -- systemctl --no-pager status cloud-init.target

  [Regression Potential]
  Playing with boot order can cause problems.  Regression would be around
  some targets not running.   On a booted system this would show itself inx
    journalctl | grep -i Break
  or
    journalctl | grep -i ordering

   End SRU Template 

  With current yakkety cloud images (at least in Scalingstack), I often
  run into this dependency cycle at boot:

  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Found ordering cycle on 
cloud-init.target/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Found dependency on 
cloud-final.service/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Found dependency on 
multi-user.target/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Found dependency on 
cloud-init.target/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-init.target: Breaking ordering cycle 
by deleting job cloud-final.service/start
  Sep 15 09:28:51 ubuntu systemd[1]: cloud-final.service: Job 
cloud-final.service/start deleted to break ordering cycle starting with 
cloud-init.target/start

  ● cloud-final.service - Execute cloud user/final scripts
     Loaded: loaded (/lib/systemd/system/cloud-final.service; enabled; vendor 
preset: enabled)
     Active: inactive (dead)

  Thus /var/lib/cloud/instance/boot-finished never gets written and thus
  waiting for an instance to init just times out.

  This is with the most recent https://launchpad.net/ubuntu/+source
  /cloud-init/0.7.7-31-g65ace7b-0ubuntu1

  Related bugs:
   * bug 1576692: fully support package installation in systemd

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1623868/+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

[Yahoo-eng-team] [Bug 1354694] Re: useradd crashes if group list contains whitespace on Fedora

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1354694

Title:
  useradd crashes if group list contains whitespace on Fedora

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  A specific usage of user data to cloud-init will fail to add a user.

  This cloud-config:
#cloud-config
users:
  - default
  - name: foobar
gecos: "My User"
groups: sudo, adm

  Will fail with information in the cloud-init log showing:
  2016-12-19 21:39:32,713 - util.py[WARNING]: Failed to create group  adm
  2016-12-19 21:39:32,713 - util.py[DEBUG]: Failed to create group  adm
  Traceback (most recent call last):
  ...
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['groupadd', ' adm']
  Exit code: 3
  Reason: -
  Stdout: ''
  Stderr: "groupadd: ' adm' is not a valid group name\n"

  While changing the last line to the following would work:
groups: [sudo, adm]

  [Test Case]
  $ cat > user-data <"EOF"
  #cloud-config
  users:
- default
- name: foobar
  gecos: "My User"
  groups: sudo, adm
- name: wark
  groups: [sudo, adm]

  $ release=yakkety
  $ name="$release-1354694"

  $ lxc launch "ubuntu-daily:$release" "$name" \
   "--config=user.user-data=$(cat user-data)"

  $ sleep 10

  ## Check foobar is in expected groups
  $ lxc exec $name -- groups foobar
  foobar : foobar adm sudo

  $ lxc exec $name -- groups wark
  wark : wark adm sudo

  $ lxc exec $name -- grep WARN /var/log/cloud-init.log || echo "no warn"
  no warn

  [Regression Potential]
  There are 3 changes in this commit
  a.) if 'groups' entry is a string, split on "," and strip pieces
  The most likely path to failure here is if previously a non-string
  (possibly bytes) was being passed in and now will be ignored.
  That seems unlikely and clearly wrong input.

  b.) fix and unit tests to explicitly set system=False or no_create_home=True.
  Previously those paths did not test the value of the entry, only the
  presense of the entry.
  This meant that these 2 configs were the same:
users: {name: bob, system: True}
  and
users: {name: bob, system: False}

  That bug is fixed here so that 'system: False' is just explicitly
  disabling the '--system' flag to adduser.

  c.) debug message cleanup:

 LOG.debug("created group %s for user %s", name, group)
 LOG.debug("created group '%s' for user '%s'", group, name)

  [Other Info]
  Upstream commit at

https://git.launchpad.net/cloud-init/commit/?id=ca3ae67211d907b4cfdcd685c0ae4f9530cb7da1

  === End SRU Template ===

  
  See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1354694/+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

[Yahoo-eng-team] [Bug 1460715] Re: MBR disk setup fails because sfdisk no longer accepts M as a valid unit

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1460715

Title:
  MBR disk setup fails because sfdisk no longer accepts M as a valid
  unit

Status in cloud-init:
  Fix Released
Status in Ubuntu Image:
  Invalid
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:
  In Progress

Bug description:
  === Begin SRU Template ===
  [Impact]
  Cloud-init has function to partition disks on devices.
  Creating partitions on a disk no longer works with sfdisk as recent versions 
of
  sfdisk no accept the unit 'M' as input, this function is broken.

  [Test Case]
  1. Launch an instance with provided user-data

     On Azure, this will work:
   #cloud-config
   disk_setup:
     ephemeral0:
     table_type: mbr
     layout: [66, [33, 82]]
     overwrite: True
   fs_setup:
     - device: ephemeral0.1
   filesystem: ext4
     - device: ephemeral0.2
   filesystem: swap
   mounts:
     - ["ephemeral0.1", "/mnt2"]
     - ["ephemeral0.2", "none", "swap", "sw", "0", "0"]

     On a typical kvm openstack use:
   #cloud-config
   disk_setup:
     /dev/vdb:
     table_type: mbr
     layout: [66, [33, 82]]
     overwrite: True
   fs_setup:
     - device: /dev/vdb1
   filesystem: ext4
     - device: /dev/vdb2
   filesystem: swap
   mounts:
     - ["/dev/vdb1", "/mnt2"]
     - ["/dev/vdb2", "none", "swap", "sw", "0", "0"]

  2. Add proposed, update, and reboot as fresh instance.

     # enable proposed
     echo deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-proposed main 
| sudo tee /etc/apt/sources.list.d/proposed.list
     sudo apt-get -qy update && sudo apt-get -qy install cloud-init https://bugs.launchpad.net/cloud-init/+bug/1460715/+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

[Yahoo-eng-team] [Bug 1354694] Re: useradd crashes if group list contains whitespace on Fedora

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1354694

Title:
  useradd crashes if group list contains whitespace on Fedora

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  A specific usage of user data to cloud-init will fail to add a user.

  This cloud-config:
#cloud-config
users:
  - default
  - name: foobar
gecos: "My User"
groups: sudo, adm

  Will fail with information in the cloud-init log showing:
  2016-12-19 21:39:32,713 - util.py[WARNING]: Failed to create group  adm
  2016-12-19 21:39:32,713 - util.py[DEBUG]: Failed to create group  adm
  Traceback (most recent call last):
  ...
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['groupadd', ' adm']
  Exit code: 3
  Reason: -
  Stdout: ''
  Stderr: "groupadd: ' adm' is not a valid group name\n"

  While changing the last line to the following would work:
groups: [sudo, adm]

  [Test Case]
  $ cat > user-data <"EOF"
  #cloud-config
  users:
- default
- name: foobar
  gecos: "My User"
  groups: sudo, adm
- name: wark
  groups: [sudo, adm]

  $ release=yakkety
  $ name="$release-1354694"

  $ lxc launch "ubuntu-daily:$release" "$name" \
   "--config=user.user-data=$(cat user-data)"

  $ sleep 10

  ## Check foobar is in expected groups
  $ lxc exec $name -- groups foobar
  foobar : foobar adm sudo

  $ lxc exec $name -- groups wark
  wark : wark adm sudo

  $ lxc exec $name -- grep WARN /var/log/cloud-init.log || echo "no warn"
  no warn

  [Regression Potential]
  There are 3 changes in this commit
  a.) if 'groups' entry is a string, split on "," and strip pieces
  The most likely path to failure here is if previously a non-string
  (possibly bytes) was being passed in and now will be ignored.
  That seems unlikely and clearly wrong input.

  b.) fix and unit tests to explicitly set system=False or no_create_home=True.
  Previously those paths did not test the value of the entry, only the
  presense of the entry.
  This meant that these 2 configs were the same:
users: {name: bob, system: True}
  and
users: {name: bob, system: False}

  That bug is fixed here so that 'system: False' is just explicitly
  disabling the '--system' flag to adduser.

  c.) debug message cleanup:

 LOG.debug("created group %s for user %s", name, group)
 LOG.debug("created group '%s' for user '%s'", group, name)

  [Other Info]
  Upstream commit at

https://git.launchpad.net/cloud-init/commit/?id=ca3ae67211d907b4cfdcd685c0ae4f9530cb7da1

  === End SRU Template ===

  
  See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1354694/+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

[Yahoo-eng-team] [Bug 1354694] Re: useradd crashes if group list contains whitespace on Fedora

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   Status: Fix Released => Fix Committed

-- 
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/1354694

Title:
  useradd crashes if group list contains whitespace on Fedora

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  A specific usage of user data to cloud-init will fail to add a user.

  This cloud-config:
#cloud-config
users:
  - default
  - name: foobar
gecos: "My User"
groups: sudo, adm

  Will fail with information in the cloud-init log showing:
  2016-12-19 21:39:32,713 - util.py[WARNING]: Failed to create group  adm
  2016-12-19 21:39:32,713 - util.py[DEBUG]: Failed to create group  adm
  Traceback (most recent call last):
  ...
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['groupadd', ' adm']
  Exit code: 3
  Reason: -
  Stdout: ''
  Stderr: "groupadd: ' adm' is not a valid group name\n"

  While changing the last line to the following would work:
groups: [sudo, adm]

  [Test Case]
  $ cat > user-data <"EOF"
  #cloud-config
  users:
- default
- name: foobar
  gecos: "My User"
  groups: sudo, adm
- name: wark
  groups: [sudo, adm]

  $ release=yakkety
  $ name="$release-1354694"

  $ lxc launch "ubuntu-daily:$release" "$name" \
   "--config=user.user-data=$(cat user-data)"

  $ sleep 10

  ## Check foobar is in expected groups
  $ lxc exec $name -- groups foobar
  foobar : foobar adm sudo

  $ lxc exec $name -- groups wark
  wark : wark adm sudo

  $ lxc exec $name -- grep WARN /var/log/cloud-init.log || echo "no warn"
  no warn

  [Regression Potential]
  There are 3 changes in this commit
  a.) if 'groups' entry is a string, split on "," and strip pieces
  The most likely path to failure here is if previously a non-string
  (possibly bytes) was being passed in and now will be ignored.
  That seems unlikely and clearly wrong input.

  b.) fix and unit tests to explicitly set system=False or no_create_home=True.
  Previously those paths did not test the value of the entry, only the
  presense of the entry.
  This meant that these 2 configs were the same:
users: {name: bob, system: True}
  and
users: {name: bob, system: False}

  That bug is fixed here so that 'system: False' is just explicitly
  disabling the '--system' flag to adduser.

  c.) debug message cleanup:

 LOG.debug("created group %s for user %s", name, group)
 LOG.debug("created group '%s' for user '%s'", group, name)

  [Other Info]
  Upstream commit at

https://git.launchpad.net/cloud-init/commit/?id=ca3ae67211d907b4cfdcd685c0ae4f9530cb7da1

  === End SRU Template ===

  
  See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1354694/+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

[Yahoo-eng-team] [Bug 1538522] Re: Calls "service walinuxagent start" in Azure data source

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1538522

Title:
  Calls "service walinuxagent start" in Azure data source

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  Hi

  cloud-init calls "service walinuxagent start" in the Azure data source
  during "init" phase.

  Currently walinuxagent.service in Ubuntu 15.10 specifies:
  | After=cloud-final.service
  This asks systemd to start if much later, after the "final" phase.

  New enough systemd version as available in Ubuntu 15.10 and Debian
  Stretch will just ignore the relation, as it is a deadlock and start
  the service in this place. Older version as in Debian Jessie will
  block the whole boot.

  Is there a reason to explicitely start walinuxagent instead of relying
  on order in systemd?

  Bastian

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1538522/+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

[Yahoo-eng-team] [Bug 1621615] Re: network not configured when ipv6 netbooted into cloud-init

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1621615

Title:
  network not configured when ipv6 netbooted into cloud-init

Status in cloud-init:
  Fix Released
Status in MAAS:
  In Progress
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-initramfs-tools source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released
Status in cloud-initramfs-tools source package in Yakkety:
  Fix Released

Bug description:
  https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of
  how IPv6 netboot with iscsi root disk doesn't work, blocking IPv6-only
  MAAS.

  After I hand-walked busybox through getting an IPv6 address,
  everything worked just fine until cloud-init couldn't fetch the
  instance data, because it insisted on bringing up the interface in
  IPv4, and there is no IPv4 DHCP on that vlan.

  Please work with initramfs and friends on getting IPv6 netboot to
  actually configure the interface.  This may be as simple as teaching
  it about "inet6 dhcp" interfaces, and bolting the pieces together.
  Note that "use radvd" is not really an option for our use case.

  Related bugs:
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)
   * bug 1639930: initramfs network configuration ignored if only ip6= on 
kernel command line 

  [Impact]

  It is not possible to enlist, commmission, or deploy with MAAS in an
  IPv6-only environment. Anyone wanting to netboot with a network root
  filesystem in an IPv6-only environment is affected.

  This upload addresses this by accepting, using, and forwarding any
  IPV6* variables from the initramfs boot.  (See
  https://launchpad.net/bugs/1621507)

  [Test Case]

  See Bug 1229458. Configure radvd, dhcpd, and tftpd for your IPv6-only
  netbooting world. Pass the boot process an IPv6 address to fetch
  instance-data from, and see it fail to configure the network.

  [Regression Potential]

  1) If the booting host is in a dual-boot environment, and the
  instance-dat URL uses a hostname that has both A and  RRsets, the
  booting host may try to talk IPv6 to get instance data.  If the
  instance-data providing host is only allowing that to happen over
  IPv4, it will fail. (It also represents a configuraiton issue on the
  providing host...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1621615/+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

[Yahoo-eng-team] [Bug 1626243] Re: Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1626243

Title:
  Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive

Status in cloud-init:
  Fix Released
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
Status in cloud-init source package in Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  There is a race condition that occurs when cloud-init tries to partition a
  block device (/dev/sdb) and then put a filesystem on a partition on it.  It is
  possible that cloud-init tries to run mkfs on /dev/sdb1 after partitioning the
  device /dev/sdb but before the partition device node '/dev/sdb1' exists.

  When this race condition occurs, cloud-init will fail to make the "ephemeral"
  device available to the user on Azure.

  [Test Case]
  A reliable reproduce test case is hard to come by here.  The failure case
  is believed to be well understood.

  [Regression Potential]
  There should be very little chance for regression, as essentially all the 
change
  does is change:

  1.   sgdisk -n 1:0:0 /dev/sdb
  2.   mkfs.ext4 /dev/sdb1

  to

  1.   sgdisk -n 1:0:0 /dev/sdb
  1a   udevadm settle
  1b   blockdev --rereadpt
  1c   udevadm settle
  2.   mkfs.ext4 /dev/sdb1

  The steps '1b' and '1c' above are not necessary, but were present already in
  the method.  They serve here as additional wait.

  [Other Info]
  The change that fixes this is viewable at [1].  For context, viewin all of
  cc_disk_setup.py [2].  Basically we just add a call to read_parttbl [3] to
  exec_mkpart_gpt after invoking a sgdisk command that partitions a disk.
  read_partbl basically does a udevadm settle which fixes the race condition 
that
  was seen.

  [1] 
https://git.launchpad.net/cloud-init/commit/?id=29348af1c889931e8973f8fc8cb090c063316f7a
  [2] 
https://git.launchpad.net/cloud-init/tree/cloudinit/config/cc_disk_setup.py?id=29348af1c889931e8973f8fc8cb090c063316f7a
  [3] 
https://git.launchpad.net/cloud-init/tree/cloudinit/config/cc_disk_setup.py?id=29348af1c889931e8973f8fc8cb090c063316f7a#n674

  === End SRU Template ===

  The symptom is similar to bug 1611074 but the cause is different. In
  this case it seems there is an error accessing /dev/sdb1 when lsblk is
  run, possibly because sgdisk isn't done creating the partition. The
  specific error message is "/dev/sdb1: not a block device." A simple
  wait and retry here may resolve the issue.

  util.py[DEBUG]: Running command ['/sbin/sgdisk', '-p', '/dev/sdb'] with 
allowed return codes [0] (shell=False, capture=True)
  cc_disk_setup.py[DEBUG]: Device partitioning layout matches
  util.py[DEBUG]: Creating partition on /dev/disk/cloud/azure_resource took 
0.056 seconds
  cc_disk_setup.py[DEBUG]: setting up filesystems: [{'filesystem': 'ext4', 
'device': 'ephemeral0.1', 'replace_fs': 'ntfs'}]
  cc_disk_setup.py[DEBUG]: ephemeral0.1 is mapped to 
disk=/dev/disk/cloud/azure_resource part=1
  cc_disk_setup.py[DEBUG]: Creating new filesystem.
  cc_disk_setup.py[DEBUG]: Checking /dev/sdb against default devices
  cc_disk_setup.py[DEBUG]: Manual request of partition 1 for /dev/sdb1
  cc_disk_setup.py[DEBUG]: Checking device /dev/sdb1
  util.py[DEBUG]: Running command ['/sbin/blkid', '-c', '/dev/null', 
'/dev/sdb1'] with allowed return codes [0, 2] (shell=False, capture=True)
  cc_disk_setup.py[DEBUG]: Device /dev/sdb1 has None None
  cc_disk_setup.py[DEBUG]: Device /dev/sdb1 is cleared for formating
  cc_disk_setup.py[DEBUG]: File system None will be created on /dev/sdb1
  util.py[DEBUG]: Running command ['/bin/lsblk', '--pairs', '--output', 
'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', '--nodeps'] with allowed return codes 
[0] (shell=False, capture=True)
  util.py[DEBUG]: Creating fs for /dev/disk/cloud/azure_resource took 0.008 
seconds
  util.py[WARNING]: Failed during filesystem operation#012Failed during disk 
check for /dev/sdb1#012Unexpected error while running command.#012Command: 
['/bin/lsblk', '--pairs', '--output', 'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', 
'--nodeps']#012Exit code: 32#012Reason: -#012Stdout: ''#012Stderr: 'lsblk: 
/dev/sdb1: not a block device\n'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1626243/+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

[Yahoo-eng-team] [Bug 1642062] Re: cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud rather than /var/lib

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1642062

Title:
  cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud
  rather than /var/lib

Status in cloud-init:
  Fix Released
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:
  New

Bug description:
  cloud-init-local.service writes to /var/lib/cloud/ and is more correct
  to have that listed here than /var/lib.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1642062/+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

[Yahoo-eng-team] [Bug 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1629797

Title:
  resolve service in nsswitch.conf adds 25 seconds to failed lookups
  before systemd-resolved is up

Status in cloud-init:
  Fix Released
Status in D-Bus:
  Unknown
Status in cloud-init package in Ubuntu:
  Fix Released
Status in dbus package in Ubuntu:
  Won't Fix
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact] 
  In cases where cloud-init used dns during early boot and system was
  configured in nsswitch.conf to use systemd-resolvd, the system would
  timeout on dns attempts making system boot terribly slow.

  [Test Case]
  Boot a system on GCE.
  check for WARN in /var/log/messages
  check that time to boot is reasonable (<30 seconds).  In failure case the
  times would be minutes.

  [Regression Potential]
  Changing order in boot can be dangerous.  There is real chance for 
  regression here, but it should be fairly small as xenial does not include
  systemd-resolved usage.  This was first noticed on yakkety where it did.

  [Other Info]
  It seems useful to SRU this in the event that systemd-resolvd is used
  on 16.04 or the case where user upgrades components (admittedly small use
  case).

  === End SRU Template ===


  
  During boot, cloud-init does DNS resolution checks to if particular metadata 
services are available (in order to determine which cloud it is running on).  
These checks happen before systemd-resolved is up[0] and if they resolve 
unsuccessfully they take 25 seconds to complete.

  This has substantial impact on boot time in all contexts, because
  cloud-init attempts to resolve three known-invalid addresses ("does-
  not-exist.example.com.", "example.invalid." and a random string) to
  enable it to detect when it's running in an environment where a DNS
  server will always return some sort of redirect.  As such, we're
  talking a minimum impact of 75 seconds in all environments.  This
  increases when cloud-init is configured to check for multiple
  environments.

  This means that yakkety is consistently taking 2-3 minutes to boot on
  EC2 and GCE, compared to the ~30 seconds of the first boot and ~10
  seconds thereafter in xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1629797/+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

[Yahoo-eng-team] [Bug 1639930] Re: initramfs network configuration ignored if only ip6= on kernel command line

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1639930

Title:
  initramfs network configuration ignored if only ip6= on kernel command
  line

Status in cloud-init:
  Fix Released
Status in MAAS:
  New
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:
  In Progress

Bug description:
  === Begin SRU Template ===
  [Impact]
  On a system booted with both ip6= and ip= on the kernel command line
  cloud-init will raise an exception and fail to process user-data and
  have its normal affect on boot.

  That is because cloud-init previously raised an exception when more
  than one file in /run/net*.conf declared the same DEVICE.  Changes to
  isc-dhcp and initramfs-tools have changed their behavior and cloud-init
  has to adjust to allow DEVICE6= and DEVICE= in separate files.

  [Test Case]
  Boot a system on a network with both ipv4 and ipv6 dhcp servers,
  and pass kernel command line with:
    ip=dhcp ip6=dhcp

  [Regression Potential]
  Regression seems unlikely as this is relaxing a check.  Where previously
  an exception would have been raised, cloud-init will now go on.

  So it seems most likely, something that didn't work before (due to raised
  exception) would now still not work, but with failures.  That is not
  expected, but that would likely be where regressions were found.

  === End SRU Template ===

  In changes made under bug 1621615 (specifically a1cdebdea), we now
  expect that there may be a 'ip6=' argument on the kernel command line.
  The changes made did not test the case where there is 'ip6=' and no
  'ip='.

  The code currently will return with no network configuration found if
  there is only ip6=...

  Related bugs:
   * bug 1621615: network not configured when ipv6 netbooted into cloud-init
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1639930/+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

[Yahoo-eng-team] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

[Scott Moser]

** Also affects: cloud-init
   Importance: Undecided
   Status: New

-- 
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/1636912

Title:
  systemd-networkd runs too late for cloud-init.service (net)

Status in cloud-init:
  New
Status in systemd:
  Fix Released
Status in cloud-init package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  New
Status in systemd source package in Yakkety:
  Fix Released

Bug description:
  Ubuntu Core 16 images using cloud-init fail to function when the
  DataSource is over the network (Like OpenStack) as networking is not
  yet available when cloud-init.service runs.

  cloud-init service unit deps look like this:

  [Unit]
  Description=Initial cloud-init job (metadata service crawler)
  DefaultDependencies=no
  Wants=cloud-init-local.service
  Wants=local-fs.target
  Wants=sshd-keygen.service
  Wants=sshd.service
  After=cloud-init-local.service
  After=networking.service
  Requires=networking.service
  Before=basic.target
  Before=dbus.socket
  Before=network-online.target
  Before=sshd-keygen.service
  Before=sshd.service
  Before=systemd-user-sessions.service
  Conflicts=shutdown.target

  Here's networkd unit deps:

  [Unit]
  Description=Network Service
  Documentation=man:systemd-networkd.service(8)
  ConditionCapability=CAP_NET_ADMIN
  DefaultDependencies=no
  # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
  # dropped once tuntap is moved to netlink
  After=systemd-udevd.service dbus.service network-pre.target 
systemd-sysusers.service systemd-sysctl.service
  Before=network.target multi-user.target shutdown.target
  Conflicts=shutdown.target
  Wants=network.target

  # On kdbus systems we pull in the busname explicitly, because it
  # carries policy that allows the daemon to acquire its name.
  Wants=org.freedesktop.network1.busname
  After=org.freedesktop.network1.busname

  And a critical-chain output:

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd
  Failed to get ID: Unit name systemd-networkd is not valid.
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service
  The time after the unit is active or started is printed after the "@" 
character.
  The time the unit takes to start is printed after the "+" character.

  systemd-networkd.service +440ms
  └─dbus.service @11.461s
    └─basic.target @11.403s
  └─sockets.target @11.401s
    └─dbus.socket @11.398s
  └─cloud-init.service @10.127s +1.266s
    └─networking.service @9.305s +799ms
  └─network-pre.target @9.295s
    └─cloud-init-local.service @3.822s +5.469s
  └─local-fs.target @3.813s
    └─run-cgmanager-fs.mount @12.687s
  └─local-fs-pre.target @1.393s
    └─systemd-tmpfiles-setup-dev.service @1.116s +195ms
  └─kmod-static-nodes.service @887ms +193ms
    └─system.slice @783ms
  └─-.slice @721ms

  cloud-init would need networkd to run at or before
  'networking.service' so it can raise networking to then find and use
  network-based datasources.

  # grep systemd /usr/share/snappy/dpkg.list
  ii  libnss-resolve:amd64  229-4ubuntu11   
 amd64nss module to resolve names via systemd-resolved
  ii  libpam-systemd:amd64  229-4ubuntu11   
 amd64system and service manager - PAM module
  ii  libsystemd0:amd64 229-4ubuntu11   
 amd64systemd utility library
  ii  systemd   229-4ubuntu11   
 amd64system and service manager
  ii  systemd-sysv  229-4ubuntu11   
 amd64system and service manager - SysV links

  # grep cloud-init /usr/share/snappy/dpkg.list
  ii  cloud-init
0.7.8-201610260005-gf7a5756-0ubuntu1~trunk~ubuntu16.04.1 all  Init 
scripts for cloud instances

  SRU INFORMATION FOR systemd
  ===
  Fix: For xenial it is sufficient to drop systemd-networkd's 
After=dbus.service (https://github.com/systemd/systemd/commit/5f004d1e32) and 
(for xenial only) drop the useless org.freedesktop.network1.busname unit (which 
is always "condition failed" as there is no kdbus, but it moves 
systemd-network.service after sockets.target which is too late for 

[Yahoo-eng-team] [Bug 1628337] Re: cloud-init tries to install NTP before even configuring the archives

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1628337

Title:
  cloud-init tries to install NTP before even configuring the archives

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  == Begin SRU Template ==
  [Impact]
  When told to configure ntp, and the ntp package is not installed
  in an image, cloud-init will attempt to install the package.

  The problem here is that it currently tries to install the package before
  it configures apt.  As a result, no apt proxy or mirror configuration is
  setup, and the stock image apt config is used.

  [Test Case]
  ## Failure can be shown like this:
  $ cat > user-data  "$p" &&
  apt-get update -q && apt-get -qy install cloud-init'
  $ lxc exec $name -- sh -c '
  cd /var/lib/cloud && for d in *; do [ "$d" = "seed" ] || rm -Rf "$d"; done
  rm -Rf /var/log/cloud-init*'

  $ lxc file pull $name/var/log/cloud-init-output.log - | egrep "^[EW]:" ||
echo "FIX WORKED."

  [Regression Potential]
  The 'ntp' function is fairly new, and is only used if a user specifies
  an ntp configuration as shown above.  Regression chance is low then
  and should be restricted to scenarios where users are providing
  the ntp configuration.
  == End SRU Template ==

  cloud-init tries to install NTP package before it actually configures
  /etc/apt/sources.list.

  In a closed MAAS environment where MAAS is limited to access to
  us.archive.ubuntu.com , cloud-init is trying to access to
  archive.ubuntu.com.

  In commissioning, however, cloud-init is doing this:

  1. cloud-init gets metadata from MAAS
  2. cloud-init tries to install NTP from archive.ubuntu.com
  3. cloud-init configures /etc/apt/sources.list with us.archive.ubuntu.com
  4. cloud-init installs other packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1628337/+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

[Yahoo-eng-team] [Bug 1635350] Re: unit tests fail as non-root on maas deployed system

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1635350

Title:
  unit tests fail as non-root on maas deployed system

Status in cloud-init:
  Fix Released
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 Template ===
  [Impact]
  Running cloud-init's unit test cases on a system deployed by MAAS would
  fail.  The reason is that the non-root user would not be able to read
  files with MAAS node credentials in /etc/cloud/cloud.cfg.d

  We want this change SRU so that an attempt to build and run tests on a
  system deployed by maas will work rather than fail due to unit test failure.

  [Test Case]
  Run unit tests on a system deployed by maas, or even just with:
    f=/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg
    sh -c 'mkdir -p "${1%/*}" && touch "$1" && chmod ugo-r "$1"' -- "$f"
    tox -e py3

  [Regression Potential]
  This was just to fix a build break or unit tests being run.
  Changes are only to unit tests.
  === End SRU Template ===

  Observed Behavior:

  On a system deployed by MAAS I checked out master and then tried to 
immediately build it:
  > git clone https://git.launchpad.net/cloud-init
  > cd cloud-init
  > ./packages/bddeb

  I get a number of errors around permission issues around this file:
  PermissionError: [Errno 13] Permission denied: 
\'/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg\'

  See: https://paste.ubuntu.com/23354559/
   or formatted better: http://paste.ubuntu.com/23374383/

  If I run as root however, it build as expected.

  Expected Behavior:
  Running bddeb works as a non-root user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1635350/+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

[Yahoo-eng-team] [Bug 1648380] Re: cloud-init fails to find CloudSigma datasource with cloud-init 0.7.8-1-g3705bb5-0ubuntu1

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: New => 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/1648380

Title:
  cloud-init fails to find CloudSigma datasource with cloud-init
  0.7.8-1-g3705bb5-0ubuntu1

Status in cloud-init:
  Fix Released
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:
  Confirmed

Bug description:
  [SRU justification]
  Without this fix, images built with cloud-init 0.7.8-1-g3705bb5-0ubuntu1  and 
later will not correctly boot and become unreachable

  [Impact]
  Some cloud images built with this version of cloud-init may become unusable

  [Fix]
  Reinstate the second element of the datasources list as a tuple instead of a 
string.

  [Test Case]
  This test must be done on CloudSigma to complete correctly :

  Build cloud image with only the CloudSigma datasource using cloud-init 
version 0.7.8-1-g3705bb5-0ubuntu1 or later
  Launch an instance with this image
  The instance will boot but will not be accessible through ssh

  With this fix,the instance will complete its boot sequence and be
  accessible through ssh

  [Regression]
  None expected, the second element was a tuple in previous versions of the 
CloudSigma datasource

  [Description of the problem]
  The issue materialized itself on cloud instances launched with such images 
that became unreachable through SSH with the following message:

  "Connection closed by {IP} port 22"

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1648380/+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

[Yahoo-eng-team] [Bug 1642679] Re: The OpenStack network_config.json implementation fails on Hyper-V compute nodes

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1642679

Title:
  The OpenStack network_config.json implementation fails on Hyper-V
  compute nodes

Status in cloud-init:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
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:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  When a config drive provides network_data.json on Azure OpenStack,
  cloud-init will fail to configure networking.

  Console log and /var/log/cloud-init.log will show:
   ValueError: Unknown network_data link type: hyperv

  This woudl also occur when the type of the network device as declared
  to cloud-init was 'hw_veb', 'hyperv', or 'vhostuser'.

  [Test Case]
  Launch an instance with config drive on hyperv cloud.

  [Regression Potential]
  Low to none.   cloud-init is relaxing requirements and will accept things
  now that it previously complained were invalid.
  === End SRU Template ===

  We have discovered an issue when booting Xenial instances on OpenStack
  environments (Liberty or newer) and Hyper-V compute nodes using config
  drive as metadata source.

  When applying the network_config.json, cloud-init fails with this error:
  http://paste.openstack.org/show/RvHZJqn48JBb0TO9QznL/

  The fix would be to add 'hyperv' as a link type here:
  /usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py, line 
587

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1642679/+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

[Yahoo-eng-team] [Bug 1643990] Re: cloud-init-local.service messages not written to /var/log/cloud-init.log in systemd

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1643990

Title:
  cloud-init-local.service messages not written to /var/log/cloud-
  init.log in systemd

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Triaged
Status in cloud-init source package in Yakkety:
  In Progress

Bug description:
  === Begin SRU Template ===
  [Impact] 
  Cloud-init's logging is inconsistent due to availability of syslog during
  boot.

  Cloud-init logs to /var/log/cloud-init.log by default.  It does this in
  a way that was originally designed to prefer to use syslog if it was
  available, and then fall back to writing directly to that file.

  Over time this has been shown to be problematic.
  a.) it relied on syslog during boot, and on some distros it wasn't
  present.
  b.) sometimes it would not be available during cloud-init-local.service
  and then would be during cloud-init.service.  The result was that
  the log would have two different time stamp formats (one written
  by rsyslog and one by python logging).
  c.) if rsyslog was used, micro seconds were not included in the log.
  d.) since the move to systemd, there has even been times when cloud-init's
  attempt to determine if syslog was available would false-positive.
  that would result logging not being written to the file at all.

  Over all, the complexity was just not found to worth the benefit.

  [Test Case]
* Launch an instance.
* Look at /var/log/cloud-init.log.
  on start, the cloud-int process logs a message like
'Cloud-init v 0.7.8 running'
  Look at those messages specifically.  In the example here (lxd), neither
  cloud-init.service or cloud-init-local.service successfully logged at all.

  # grep Cloud-init /var/log/cloud-init.log 
  Dec  2 18:06:56 y2 [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8 
running 'modules:config' at Fri, 02 Dec 2016 18:06:56 +. Up 5.0 seconds.
  Dec  2 18:06:58 y2 [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8 
running 'modules:final' at Fri, 02 Dec 2016 18:06:58 +. Up 7.0 seconds.
  Dec  2 18:06:58 y2 [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8 
finished at Fri, 02 Dec 2016 18:06:58 +. Datasource DataSourceNoCloud 
[seed=/var/lib/cloud/seed/nocloud-net][dsmode=net].  Up 7.0 seconds

* update to proposed, cleanup reboot
  # enable propose and update
  # cleanup

  sudo rm -Rf /var/log/cloud-init* /var/lib/cloud/
  sudo reboot
  
* login again and look.

  This time, all messages will have the format:
 2016-12-02 17:58:43,175 - util.py[DEBUG]: Cloud-init v. 0.7.8 running 
'init-local' at Fri, 02 Dec 2016 17:58:43 +. Up 13.73 seconds.

  And you will have one for each 'init-local', 'init', 'modules:config' and
  modules:final.

  [Regression Potential] 
  Users relying on cloud-init writing entries to syslog will lose that.

  [Other Info]

  === End SRU Template ===

  
  output of cloud-init-local.service can get lost in systemd.
  The result is that there is no output in /var/log/cloud-init.log from 
cloud-init-local.service.

  There is some information in 
https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729
  about how this occurrs and how it used to work.
  copying part of that here:

  Cloud-init's logging basically employed a "try syslog and fallback to direct 
log to file".
  The proposed "just log to a file" is definitely dramatically simpler and 
advantageous in some cases.

  The way the "try syslog and fallback" works (or worked) on Ubuntu up
  until systemd was:

  a.) cloud-init init --local
  1. read logging config,
  2. attempt to log to syslog ([ *log_base, *log_syslog ])
  3. that fail, so it log to file directly

  b.) cloud-init init
     1.) rsyslog would have /dev/log up functional at this point
     2.) cloud-init logging config read and ends up logging to syslog

  Systemd changed some things in teh way /dev/log was handled, and the
  above no longer worked well.

  Additionally, cloud-init installs a file
  /etc/rsyslog.d/21-cloudinit.conf which tells rsyslog to redirect
  messages generated by cloud-init to /var/log/cloud-init.log

  The value of doing this in this way was that we use syslog, so if the
  user had configured the system to log remotely, cloud-init's logs
  would go to that remote system as they desired.

  If we directly log to a file, then cloud-init's log messages will not
  without further configuration go to syslog.

  One other thing to be aware of is that cloud-init can itself configure
  rsyslog through cloudinit/config/cc_rsyslog.py . So, the user could
  provide in user-data some rsyslog 

[Yahoo-eng-team] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

[Scott Moser]

This is fixed in cloud-init 0.7.9

** Changed in: cloud-init
   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 Committed
Status in MAAS trunk series:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed

Bug description:
  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

[Yahoo-eng-team] [Bug 1625766] Re: Fallback networking doesn't handle IOError when reading sys/net//carrier

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1625766

Title:
  Fallback networking doesn't handle IOError when reading
  sys/net//carrier

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  Sometimes reading from /sys/class/net//carrier returns an error
  and is unhangled causing fallback networking to not bring anything up.

  
  [Original Description]

  I am running Arch on a KVM vps provider. I installed using this
  template: Arch Linux 2016.03 64-bit (template). Everything was working
  fine until I decided to upgrade. I did pacman -Syu and everything
  upgraded without error until it restarted.

  I had to manually install certain python packages. But, I kept getting
  more errors so I joined IRC.

  Here's the log: https://irclogs.ubuntu.com/2016/09/20/%23cloud-
  init.html

  Was told to post it Here to sum up everything

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1625766/+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

[Yahoo-eng-team] [Bug 1644043] Re: Read Kernel Config tests missing MAC Address

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   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/1644043

Title:
  Read Kernel Config tests missing MAC Address

Status in cloud-init:
  Fix Released
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:
  In Progress

Bug description:
  http://pad.lv/1644043
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1644043
  
  === Begin SRU Template ===
  [Impact] 
  Unit tests would fail, causing build failure.

  [Test Case]
  Run cloud-init tests a system with a network device named 'eth0'
  Building cloud-init runs the unit tests, so even just building on
  such a system is sufficient.

  lxc provides such an environment.

  Generally, the build worked, so unit tests passed.

  [Regression Potential] 
  None: unit test changes only.

  === End SRU Template ===

  
  Unittests are broken [1] preventing cloud-init from building currently. The 
issue is the kernel config tests are looking for a MAC address that is not 
there.

  [1] https://jenkins.ubuntu.com/server/job/cloud-init-integration-
  lts/35/console

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1644043/+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

[Yahoo-eng-team] [Bug 1647708] Re: Ephemeral disk on xenial is not mounted at boot

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Importance: Undecided => High

** Changed in: cloud-init
   Status: New => 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/1647708

Title:
  Ephemeral disk on xenial is not mounted at boot

Status in cloud-init:
  Fix Released
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:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  An ephemeral disk will not correctly be mounted on /mnt.
  This affects Azure and other instances where an ephemeral device is
  mounted by default on /mnt.  It is recreated in Azure and on OpenStack.

  This can be mitigated by either:
   1.) mount -a
   2.) reboot

  [Test Case]
  In a correctly functioning image on OpenStack or Azure, you should be
  able to:

  1.) Launch an instance
  2.) ssh into instance and look around
 $ awk '$2 == "/mnt" { print $0 }' /etc/fstab
 /dev/vdb /mnt  auto  
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig  0  2
 $ awk '$2 == "/mnt" { print $0 }' /proc/mounts
  /dev/vdb /mnt vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
 0 0

 $ df -h /mnt
 Filesystem  Size  Used Avail Use% Mounted on
 /dev/vdb 40G   32K   40G   1% /mnt

  To check that this is functional with -proposed, after you've seen it
  failed

  3.) enable -proposed and apt-get install cloud-init
  4.) clean up and reboot as if fresh:
  sudo rm -Rf /var/lib/cloud /var/log/cloud-init
  sudo sed -i '/cloudconfig/d' /etc/fstab
  sudo reboot

  [Regression Potential]
  This is a regression caused by bug 1611074, so in addition to the above
  test case, we should go through the test cases shown there to see that
  those also work.
  === End SRU Template ===


  When I boot the latest xenial Azure image (containing cloud-init
  0.7.8-49-g9e904bb-0ubuntu1~16.04.1), the ephemeral disk does not end
  up mounted (though it is formatted appropriately).  Restarting the
  mnt.mount service does mount it, which suggests there is an issue in
  the ordering of the services at boot.

  $ mount | grep mnt
  $ sudo systemctl status mnt.mount
  ● mnt.mount - /mnt
     Loaded: loaded (/etc/fstab; bad; vendor preset: enabled)
     Active: inactive (dead)
  Where: /mnt
   What: /dev/disk/cloud/azure_resource-part1
   Docs: man:fstab(5)
     man:systemd-fstab-generator(8)
  $ sudo journalctl -u mnt.mount
  -- No entries --
  $ cat /etc/fstab
  # CLOUD_IMG: This file was created/modified by the Cloud Image build process
  UUID=6a8554fa-8e1d-4916-ba03-4ca3837feb34 /ext4   
defaults,discard0 0
  /dev/disk/cloud/azure_resource-part1  /mntauto
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig   
0   2
  $ sudo systemctl restart mnt.mount
  $ mount | grep mnt
  /dev/sdb1 on /mnt type ext4 (rw,relatime,data=ordered)
  $ ls /mnt/
  lost+found
  $ sudo systemctl status mnt.mount
  ● mnt.mount - /mnt
     Loaded: loaded (/etc/fstab; bad; vendor preset: enabled)
     Active: active (mounted) since Tue 2016-12-06 12:49:06 UTC; 6s ago
  Where: /mnt
   What: /dev/sdb1
   Docs: man:fstab(5)
     man:systemd-fstab-generator(8)
    Process: 1916 ExecMount=/bin/mount /dev/disk/cloud/azure_resource-part1 
/mnt -o defaults,x-systemd.requires=cloud-init.service,comment=cloudconfig 
(code=exited, status=0/SUCCESS)
  Tasks: 0
     Memory: 88.0K
    CPU: 15ms

  Dec 06 12:49:06 xenial-161206-1345 systemd[1]: Mounting /mnt...
  Dec 06 12:49:06 xenial-161206-1345 systemd[1]: Mounted /mnt.

  Related bugs:
   * bug 1611074: Reformatting of ephemeral drive fails on resize of Azure VM
   * bug 1642383: Unable to configure swap space on ephemeral disk in Azure

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1647708/+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

[Yahoo-eng-team] [Bug 1647910] Re: hostname is set incorrectly if localhostname is fully qualified

[Scott Moser]

This is fixed in cloud-init 0.7.9.

** Changed in: cloud-init
   Status: New => 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/1647910

Title:
  hostname is set incorrectly if localhostname is fully qualified

Status in cloud-init:
  Fix Released

Bug description:
  If no data source is available and the local hostname is set to
  "localhost.localdomain", and /etc/hosts looks like:

127.0.0.1   localhost localhost.localdomain localhost4
  localhost4.localdomain4

  Then in sources/__init__.py in get_hostname:

  - util.get_hostname() will return 'localhost.localdomain'
  - util.get_fqdn_from_hosts(hostname) will return 'localhost'
  - 'toks' will be set to [ 'localhost.localdomain', 'localdomain'

  And ultimately the system hostname will be set to
  'localhost.localdomain.localdomain', which isn't useful to anybody.

  Also reported in:

  https://bugzilla.redhat.com/show_bug.cgi?id=1389048

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1647910/+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

[Yahoo-eng-team] [Bug 1652329] [NEW] sort out pyflakes flake8 pycodestyle pep8

[Scott Moser]

Public bug reported:

I was again bit by this... tox works fine (running flake8)
but built of zesty failed.

In cloud-init, the Makefile that is run during build runs (currently)
pep8 and pyflakes (either pyflakes2 or pyflakes3).

I think what we ultimately want is to run flake8 and let it run pyflakes
and pep8.

However, given dependencies and versions in different distro releases,
this is a bit of a pain.

One path to this is just to not run any code checking in the distro
build, assuming that it is already run in trunk.  I think that seems
like a sane argument actually.

One thing to note, is that pep8 is now called pycodestyle.

Out of this, I'd like to have:
 a.) a tox target that tracks upstream pypi versions (but doesn't fail c-i), 
and somethign that runs this fairly often to at least see how bad we are 
getting.
 b.) a tox target that has pinned versions of checking tools, and runs checks 
both for python2 and python3.

** Affects: cloud-init
 Importance: Undecided
 Status: New

** Affects: curtin
 Importance: Undecided
 Status: New

** Also affects: curtin
   Importance: Undecided
   Status: New

-- 
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/1652329

Title:
  sort out pyflakes flake8 pycodestyle pep8

Status in cloud-init:
  New
Status in curtin:
  New

Bug description:
  I was again bit by this... tox works fine (running flake8)
  but built of zesty failed.

  In cloud-init, the Makefile that is run during build runs (currently)
  pep8 and pyflakes (either pyflakes2 or pyflakes3).

  I think what we ultimately want is to run flake8 and let it run
  pyflakes and pep8.

  However, given dependencies and versions in different distro releases,
  this is a bit of a pain.

  One path to this is just to not run any code checking in the distro
  build, assuming that it is already run in trunk.  I think that seems
  like a sane argument actually.

  One thing to note, is that pep8 is now called pycodestyle.

  Out of this, I'd like to have:
   a.) a tox target that tracks upstream pypi versions (but doesn't fail c-i), 
and somethign that runs this fairly often to at least see how bad we are 
getting.
   b.) a tox target that has pinned versions of checking tools, and runs checks 
both for python2 and python3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1652329/+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

[Yahoo-eng-team] [Bug 1374115] Re: Allow cloud-config to modify partitioning and mount point of temporary resource disk in Azure

[Scott Moser]

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

-- 
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/1374115

Title:
  Allow cloud-config to modify partitioning and mount point of temporary
  resource disk in Azure

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  Users would like to use a local cloud-config to modify how the
  resource/ephemeral disk is partitioned and where it is mounted on
  Azure VMs.  Currently it seems this is only customizable via a
  configuration sent via CustomData (user data).

  If I understand correctly, the Azure data source overrides the local
  cloud config for how this disk is set up.  Users would like to be able
  to use a local cloud-config to override what's defined in the data
  source.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1374115/+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

[Yahoo-eng-team] [Bug 1354694] Re: useradd crashes if group list contains whitespace on Fedora

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: Fix Released => Confirmed

** Changed in: cloud-init
   Status: Fix Committed => Confirmed

-- 
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/1354694

Title:
  useradd crashes if group list contains whitespace on Fedora

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1354694/+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

[Yahoo-eng-team] [Bug 1354694] Re: useradd crashes if group list contains whitespace on Fedora

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Low

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Low

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Low

-- 
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/1354694

Title:
  useradd crashes if group list contains whitespace on Fedora

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1354694/+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

[Yahoo-eng-team] [Bug 1625766] Re: Fallback networking doesn't handle IOError when reading sys/net//carrier

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: Triaged => Fix Committed

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

-- 
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/1625766

Title:
  Fallback networking doesn't handle IOError when reading
  sys/net//carrier

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Yakkety:
  New

Bug description:
  Sometimes reading from /sys/class/net//carrier returns an error
  and is unhangled causing fallback networking to not bring anything up.

  
  [Original Description]

  I am running Arch on a KVM vps provider. I installed using this
  template: Arch Linux 2016.03 64-bit (template). Everything was working
  fine until I decided to upgrade. I did pacman -Syu and everything
  upgraded without error until it restarted.

  I had to manually install certain python packages. But, I kept getting
  more errors so I joined IRC.

  Here's the log: https://irclogs.ubuntu.com/2016/09/20/%23cloud-
  init.html

  Was told to post it Here to sum up everything

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1625766/+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

[Yahoo-eng-team] [Bug 1639955] Re: bad test for snappy systems

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/1639955

Title:
  bad test for snappy systems

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  Reviewing the latest SRU for cloud-init, I noticed the following:

  def system_is_snappy():
  # channel.ini is configparser loadable.
  # snappy will move to using /etc/system-image/config.d/*.ini
  # this is certainly not a perfect test, but good enough for now.
  content = load_file("/etc/system-image/channel.ini", quiet=True)
  if 'ubuntu-core' in content.lower():
  return True
  if os.path.isdir("/etc/system-image/config.d/"):
  return True
  return False

  This isn't a good test for whether a system is an ubuntu-core system.
  'system-image' is historical baggage, and not likely to be present at
  all in future versions.

  I'm afraid I don't know a good alternative test offhand, but wanted to
  log the bug so someone could look into it rather than being caught by
  surprise when ubuntu-core image contents later change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1639955/+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

[Yahoo-eng-team] [Bug 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

[Scott Moser]

re-opening this for cloud-init as the change in cloud-init actually
regressed the behavior.


** Changed in: cloud-init (Ubuntu)
   Status: Fix Released => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Released => Confirmed

** Changed in: cloud-init
   Status: Fix Released => Confirmed

-- 
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:
  Confirmed
Status in MAAS:
  Triaged
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed

Bug description:
  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

[Yahoo-eng-team] [Bug 1538522] Re: Calls "service walinuxagent start" in Azure data source

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu)
   Status: New => 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/1538522

Title:
  Calls "service walinuxagent start" in Azure data source

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  Hi

  cloud-init calls "service walinuxagent start" in the Azure data source
  during "init" phase.

  Currently walinuxagent.service in Ubuntu 15.10 specifies:
  | After=cloud-final.service
  This asks systemd to start if much later, after the "final" phase.

  New enough systemd version as available in Ubuntu 15.10 and Debian
  Stretch will just ignore the relation, as it is a deadlock and start
  the service in this place. Older version as in Debian Jessie will
  block the whole boot.

  Is there a reason to explicitely start walinuxagent instead of relying
  on order in systemd?

  Bastian

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1538522/+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

[Yahoo-eng-team] [Bug 1643990] Re: cloud-init-local.service messages not written to /var/log/cloud-init.log in systemd

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

-- 
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/1643990

Title:
  cloud-init-local.service messages not written to /var/log/cloud-
  init.log in systemd

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  In Progress

Bug description:
  output of cloud-init-local.service can get lost in systemd.
  The result is that there is no output in /var/log/cloud-init.log from 
cloud-init-local.service.

  There is some information in 
https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729
  about how this occurrs and how it used to work.
  copying part of that here:

  
  Cloud-init's logging basically employed a "try syslog and fallback to direct 
log to file".
  The proposed "just log to a file" is definitely dramatically simpler and 
advantageous in some cases.

  The way the "try syslog and fallback" works (or worked) on Ubuntu up
  until systemd was:

  a.) cloud-init init --local
  1. read logging config,
  2. attempt to log to syslog ([ *log_base, *log_syslog ])
  3. that fail, so it log to file directly

  b.) cloud-init init
 1.) rsyslog would have /dev/log up functional at this point
 2.) cloud-init logging config read and ends up logging to syslog

  Systemd changed some things in teh way /dev/log was handled, and the
  above no longer worked well.

  Additionally, cloud-init installs a file
  /etc/rsyslog.d/21-cloudinit.conf which tells rsyslog to redirect
  messages generated by cloud-init to /var/log/cloud-init.log

  The value of doing this in this way was that we use syslog, so if the
  user had configured the system to log remotely, cloud-init's logs
  would go to that remote system as they desired.

  If we directly log to a file, then cloud-init's log messages will not
  without further configuration go to syslog.

  One other thing to be aware of is that cloud-init can itself configure
  rsyslog through cloudinit/config/cc_rsyslog.py . So, the user could
  provide in user-data some rsyslog configuration, and then the system's
  syslog (including cloud-init messages) would start goign to that
  remote server as soon as they realistically could.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1643990/+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

[Yahoo-eng-team] [Bug 1642679] Re: The OpenStack network_config.json implementation fails on Hyper-V compute nodes

[Scott Moser]

** Also affects: cloud-init (Ubuntu Vivid)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Wily)
   Importance: Undecided
   Status: New

** No longer affects: cloud-init (Ubuntu Vivid)

** No longer affects: cloud-init (Ubuntu Wily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1642679

Title:
  The OpenStack network_config.json implementation fails on Hyper-V
  compute nodes

Status in cloud-init:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  We have discovered an issue when booting Xenial instances on OpenStack
  environments (Liberty or newer) and Hyper-V compute nodes using config
  drive as metadata source.

  When applying the network_config.json, cloud-init fails with this error:
  http://paste.openstack.org/show/RvHZJqn48JBb0TO9QznL/

  The fix would be to add 'hyperv' as a link type here:
  /usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py, line 
587

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1642679/+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

[Yahoo-eng-team] [Bug 1642679] Re: The OpenStack network_config.json implementation fails on Hyper-V compute nodes

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Confirmed => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1642679

Title:
  The OpenStack network_config.json implementation fails on Hyper-V
  compute nodes

Status in cloud-init:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  We have discovered an issue when booting Xenial instances on OpenStack
  environments (Liberty or newer) and Hyper-V compute nodes using config
  drive as metadata source.

  When applying the network_config.json, cloud-init fails with this error:
  http://paste.openstack.org/show/RvHZJqn48JBb0TO9QznL/

  The fix would be to add 'hyperv' as a link type here:
  /usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py, line 
587

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1642679/+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

[Yahoo-eng-team] [Bug 1639930] Re: initramfs network configuration ignored if only ip6= on kernel command line

[Scott Moser]

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
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/1639930

Title:
  initramfs network configuration ignored if only ip6= on kernel command
  line

Status in cloud-init:
  Confirmed
Status in MAAS:
  New
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  In changes made under bug 1621615 (specifically a1cdebdea), we now
  expect that there may be a 'ip6=' argument on the kernel command line.
  The changes made did not test the case where there is 'ip6=' and no
  'ip='.

  The code currently will return with no network configuration found if
  there is only ip6=...


  Related bugs:
   * bug 1621615: network not configured when ipv6 netbooted into cloud-init 
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1639930/+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

[Yahoo-eng-team] [Bug 1644043] Re: Read Kernel Config tests missing MAC Address

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
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/1644043

Title:
  Read Kernel Config tests missing MAC Address

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  Unittests are broken [1] preventing cloud-init from building
  currently. The issue is the kernel config tests are looking for a MAC
  address that is not there.

  [1] https://jenkins.ubuntu.com/server/job/cloud-init-integration-
  lts/35/console

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1644043/+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

[Yahoo-eng-team] [Bug 1460715] Re: MBR disk setup fails because sfdisk no longer accepts M as a valid unit

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Confirmed => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

-- 
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/1460715

Title:
  MBR disk setup fails because sfdisk no longer accepts M as a valid
  unit

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  Specifically, we get the following output in
  cc_disk_setup.exec_mkpart_mbr:

  sfdisk: --Linux option is unnecessary and deprecated
  sfdisk: unsupported unit 'M'

  and the manpage says:

     -u, --unit S
    Deprecated option.  Only the sector unit is supported.

  So we'll need to shift to using sectors.

  Related bugs:
   * bug 1642383: Unable to configure swap space on ephemeral disk in Azure

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1460715/+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

[Yahoo-eng-team] [Bug 1646571] Re: apt failures non fatal, but cloud the log

[Scott Moser]

** Also affects: maas
   Importance: Undecided
   Status: New

-- 
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/1646571

Title:
  apt failures non fatal, but cloud the log

Status in cloud-init:
  New
Status in MAAS:
  New

Bug description:
  Better formatting: http://paste.ubuntu.com/23564366/

  Dec 01 17:29:15 kepler cloud-init[1134]: 2016-12-01 17:29:15,900 - 
util.py[WARNING]: Running module apt-configure () failed
  Dec 01 17:29:15 kepler cloud-init[1134]: [CLOUDINIT] util.py[WARNING]: 
Running module apt-configure () failed
  Dec 01 17:29:15 kepler cloud-init[1134]: [CLOUDINIT] util.py[DEBUG]: Running 
module apt-configure () failed
   Traceback (most recent call last):
     File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 792, in _run_modules
   freq=freq)
     File 
"/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 70, in run
   return self._runners.run(name, 
functor, args, freq, clear_on_fail)
     File 
"/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in run
   results = functor(*args)
     File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 
284, in handle
   ocfg = 
convert_to_v3_apt_format(ocfg)
     File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 
748, in convert_to_v3_apt_format
   cfg = 
convert_v2_to_v3_apt_format(cfg)
     File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 
714, in convert_v2_to_v3_apt_format
   oldkey))
   ValueError: Old and New apt format 
defined with unequal values True vs False @ apt_preserve_sources_list
  D

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1646571/+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

[Yahoo-eng-team] [Bug 1643990] [NEW] cloud-init-local.service messages not written to /var/log/cloud-init.log in systemd

[Scott Moser]

Public bug reported:

output of cloud-init-local.service can get lost in systemd.
The result is that there is no output in /var/log/cloud-init.log from 
cloud-init-local.service.

There is some information in 
https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729
about how this occurrs and how it used to work.
copying part of that here:


Cloud-init's logging basically employed a "try syslog and fallback to direct 
log to file".
The proposed "just log to a file" is definitely dramatically simpler and 
advantageous in some cases.

The way the "try syslog and fallback" works (or worked) on Ubuntu up
until systemd was:

a.) cloud-init init --local
1. read logging config,
2. attempt to log to syslog ([ *log_base, *log_syslog ])
3. that fail, so it log to file directly

b.) cloud-init init
   1.) rsyslog would have /dev/log up functional at this point
   2.) cloud-init logging config read and ends up logging to syslog

Systemd changed some things in teh way /dev/log was handled, and the
above no longer worked well.

Additionally, cloud-init installs a file
/etc/rsyslog.d/21-cloudinit.conf which tells rsyslog to redirect
messages generated by cloud-init to /var/log/cloud-init.log

The value of doing this in this way was that we use syslog, so if the
user had configured the system to log remotely, cloud-init's logs would
go to that remote system as they desired.

If we directly log to a file, then cloud-init's log messages will not
without further configuration go to syslog.

One other thing to be aware of is that cloud-init can itself configure
rsyslog through cloudinit/config/cc_rsyslog.py . So, the user could
provide in user-data some rsyslog configuration, and then the system's
syslog (including cloud-init messages) would start goign to that remote
server as soon as they realistically could.

** Affects: cloud-init
 Importance: Medium
 Status: Fix Committed

-- 
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/1643990

Title:
  cloud-init-local.service messages not written to /var/log/cloud-
  init.log in systemd

Status in cloud-init:
  Fix Committed

Bug description:
  output of cloud-init-local.service can get lost in systemd.
  The result is that there is no output in /var/log/cloud-init.log from 
cloud-init-local.service.

  There is some information in 
https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/301729
  about how this occurrs and how it used to work.
  copying part of that here:

  
  Cloud-init's logging basically employed a "try syslog and fallback to direct 
log to file".
  The proposed "just log to a file" is definitely dramatically simpler and 
advantageous in some cases.

  The way the "try syslog and fallback" works (or worked) on Ubuntu up
  until systemd was:

  a.) cloud-init init --local
  1. read logging config,
  2. attempt to log to syslog ([ *log_base, *log_syslog ])
  3. that fail, so it log to file directly

  b.) cloud-init init
 1.) rsyslog would have /dev/log up functional at this point
 2.) cloud-init logging config read and ends up logging to syslog

  Systemd changed some things in teh way /dev/log was handled, and the
  above no longer worked well.

  Additionally, cloud-init installs a file
  /etc/rsyslog.d/21-cloudinit.conf which tells rsyslog to redirect
  messages generated by cloud-init to /var/log/cloud-init.log

  The value of doing this in this way was that we use syslog, so if the
  user had configured the system to log remotely, cloud-init's logs
  would go to that remote system as they desired.

  If we directly log to a file, then cloud-init's log messages will not
  without further configuration go to syslog.

  One other thing to be aware of is that cloud-init can itself configure
  rsyslog through cloudinit/config/cc_rsyslog.py . So, the user could
  provide in user-data some rsyslog configuration, and then the system's
  syslog (including cloud-init messages) would start goign to that
  remote server as soon as they realistically could.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1643990/+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

[Yahoo-eng-team] [Bug 1603222] Re: Azure: incorrect entry in fstab for ephemeral disk

[Scott Moser]

This is fixed in commit
 9e904bbc3336b96475bfd00fb3bf1262ae4de49f
https://git.launchpad.net/cloud-init/commit/?id=9e904bbc3336b96475bfd00fb3bf1262ae4de49f

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Committed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: In Progress => Fix Committed

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Description changed:

  During provisioning cloud-init adds an entry for the ephemeral disk in
  /etc/fstab. After provisioning this entry is correct and points to
  "/dev/disk/azure/resource-part1". This symlink is created dynamically by
  66-azure-storage.rules.
  
  For some reason after the first reboot cloud-init overwrites the fstab
  entry and changes the "/dev/disk/azure/resource-part1" to the device
  name that it points to, i.e. /dev/sdb1.  However, this is incorrect
  since /dev/sd* device names are not persistent.
  
- 
  Repro:
  
  1) Provision an Ubuntu VM on Azure (I tested with 14.04.4)
  2) The fstab entry for the ephemeral disk (/mnt) correctly points to 
"/dev/disk/azure/resource-part1".
  3) Reboot the VM (sudo reboot)
  4) The fstab entry now incorrectly points to /dev/sdb1 instead of the symlink.
  
  Impact:
  There is a chance that the customer's ephemeral disk will not be mounted 
properly if the device names change after a reboot.
+ 
+ Related bugs:
+  * bug 1611074: Reformatting of ephemeral drive fails on resize of Azure VM

-- 
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/1603222

Title:
  Azure: incorrect entry in fstab for ephemeral disk

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Precise:
  New
Status in cloud-init source package in Trusty:
  Confirmed
Status in cloud-init source package in Xenial:
  Fix Committed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  During provisioning cloud-init adds an entry for the ephemeral disk in
  /etc/fstab. After provisioning this entry is correct and points to
  "/dev/disk/azure/resource-part1". This symlink is created dynamically
  by 66-azure-storage.rules.

  For some reason after the first reboot cloud-init overwrites the fstab
  entry and changes the "/dev/disk/azure/resource-part1" to the device
  name that it points to, i.e. /dev/sdb1.  However, this is incorrect
  since /dev/sd* device names are not persistent.

  Repro:

  1) Provision an Ubuntu VM on Azure (I tested with 14.04.4)
  2) The fstab entry for the ephemeral disk (/mnt) correctly points to 
"/dev/disk/azure/resource-part1".
  3) Reboot the VM (sudo reboot)
  4) The fstab entry now incorrectly points to /dev/sdb1 instead of the symlink.

  Impact:
  There is a chance that the customer's ephemeral disk will not be mounted 
properly if the device names change after a reboot.

  Related bugs:
   * bug 1611074: Reformatting of ephemeral drive fails on resize of Azure VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1603222/+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

[Yahoo-eng-team] [Bug 1642679] Re: The OpenStack network_config.json implementation fails on Hyper-V compute nodes

[Scott Moser]

Hi,
I've subscribed Xiang to this as he recently pinged me on a different string 
that may appear as a network device.  My response to him was:

| This non-sense really needs to stop.
| We need to fix openstack to stop sending arbitrary "types" of network
| devices that mean nothing to the guest.
| 
| No *new* ones should be allowed.
| 
| 'vhostuser' or 'ovs' means nothing to the guest.  They just see a nic.
| They can't possibly use that information in any way, so telling them is
| not helpful.  The type of the device should be 'tap' or 'ethernet'.
| 
| Can you submit a merge proposal upstream that does that?
| 
| We can take these things in, but they're silly and quite obviously busted,
| unless you have some information that shows why they're not.

I'm willing to take this, but lets *please* work to fix the source
of the problem.

Adrian,
Can you please file a merge proposal upstream to fix this?

You're welcome to use this bug.  I've made it "Also affects nova".


** Also affects: nova
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1642679

Title:
  The OpenStack network_config.json implementation fails on Hyper-V
  compute nodes

Status in cloud-init:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  We have discovered an issue when booting Xenial instances on OpenStack
  environments (Liberty or newer) and Hyper-V compute nodes using config
  drive as metadata source.

  When applying the network_config.json, cloud-init fails with this error:
  http://paste.openstack.org/show/RvHZJqn48JBb0TO9QznL/

  The fix would be to add 'hyperv' as a link type here:
  /usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py, line 
587

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1642679/+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

[Yahoo-eng-team] [Bug 1611074] Re: Reformatting of ephemeral drive fails on resize of Azure VM

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: Fix Released => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Confirmed

-- 
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/1611074

Title:
  Reformatting of ephemeral drive fails on resize of Azure VM

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  In some cases, cloud-init writes entries to /etc/fstab, and on azure it will
  even format a disk for mounting and then write the entry for that 'ephemeral'
  disk there.

  A supported operation on Azure is to "resize" the system.  When you do this
  the system is shut down, resized (given larger/faster disks and more CPU) and
  then brought back up.  In that process, the "ephemeral" disk re-initialized
  to its original NTFS format.  The designed goal is for cloud-init to recognize
  this situation and re-format the disk to ext4.

  The problem is that the mount of that disk happens before cloud-init can
  reformat.  Thats because the entry in fstab has 'auto' and is automatically
  mounted.  The end result is that after resize operation the user will be left
  with the ephemeral disk mounted at /mnt and having a ntfs filesystem rather
  than ext4.

  [Test Case]
  The text in comment 3 describes how to recreate by the original reporter.
  Another way to do this is to just re-format the ephemeral disk as
  ntfs and then reboot.  The result *should* be that after reboot it
  comes back up and has an ext4 filesystem on it.

  1.) boot system on azure
    (for this, i use https://gist.github.com/smoser/5806147, but you can
     use web ui or any other way).
 Save output of
   journalctl --no-pager > journalctl.orig
   systemctl status --no-pager > systemctl-status.orig
   systemctl --no-pager > systemctl.orig

  2.) unmount the ephemeral disk
     $ umount /mnt

  3.) repartition it so that mkfs.ntfs does less and is faster
     This is not strictly necessary, but mkfs.ntfs can take upwards of
     20 minutes.  shrinking /dev/sdb2 to be 200M means it will finish
     in < 1 minute.

     $ disk=/dev/disk/cloud/azure_resource
     $ part=/dev/disk/cloud/azure_resource-part1
     $ echo "2048,$((2*1024*100)),7" | sudo sfdisk "$disk"
     $ time mkfs.ntfs --quick "$part"

  4.) reboot
  5.) expect that /proc/mounts has /dev/disk/cloud/azure_resource-part1 as ext4
  and that fstab has x-systemd.requires in it.

  $ awk '$2 == "/mnt" { print $0 }' /proc/mounts
  /dev/sdb1 /mnt ext4 rw,relatime,data=ordered 0 0

  $ awk '$2 == "/mnt" { print $0 }' /etc/fstab
  /dev/sdb1 /mnt auto 
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig 0 2

  6.) collect journal and systemctl information as described in step 1 above.
  Compare output, specifically looking for case insensitve "breaks"

  [Regression Potential]
  Regression is unlikely.  Likely failure case is just that the problem is not
  correctly fixed, and the user ends up with either an NTFS formated disk that
  is mounted at /mnt or there is nothing mounted at /mnt.

  === End SRU Template ===

  After resizing a 16.04 VM on Azure, the VM is presented with a new
  ephemeral drive (of a different size), which initially is NTFS
  formatted. Cloud-init tries to format the appropriate partition ext4,
  but fails because it is mounted. Cloud-init has unmount logic for
  exactly this case in the get_data call on the Azure data source, but
  this is never called because fresh cache is found.

  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] handlers.py[DEBUG]: start: 
init-network/check-cache: attempting to read from cache [trust]
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Reading from 
/var/lib/cloud/instance/obj.pkl (quiet=False)
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Read 5950 bytes 
from /var/lib/cloud/instance/obj.pkl
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] stages.py[DEBUG]: restored from 
cache: DataSourceAzureNet [seed=/dev/sr0]
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] handlers.py[DEBUG]: finish: 
init-network/check-cache: SUCCESS: restored from cache: DataSourceAzureNet 
[seed=/dev/sr0]
  ...
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] cc_disk_setup.py[DEBUG]: Creating 
file system None on /dev/sdb1
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] cc_disk_setup.py[DEBUG]:  
Using cmd: /sbin/mkfs.ext4 /dev/sdb1
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Running command 
['/sbin/mkfs.ext4', '/dev/sdb1'] with allowed return codes [0] (shell=False, 
capture=True)
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Creating fs for 
/dev/disk/cloud/azure_resource took 0.052 seconds
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] 

[Yahoo-eng-team] [Bug 1642062] [NEW] cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud rather than /var/lib

[Scott Moser]

Public bug reported:

cloud-init-local.service writes to /var/lib/cloud/ and is more correct
to have that listed here than /var/lib.

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
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/1642062

Title:
  cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud
  rather than /var/lib

Status in cloud-init:
  New

Bug description:
  cloud-init-local.service writes to /var/lib/cloud/ and is more correct
  to have that listed here than /var/lib.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1642062/+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

[Yahoo-eng-team] [Bug 1619393] Re: cloud-init useradd/groupadd fails on ubuntu-core-16 with readonly /etc/passwd

[Scott Moser]

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

-- 
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/1619393

Title:
  cloud-init useradd/groupadd fails on ubuntu-core-16 with readonly
  /etc/passwd

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact] 
  When running under ubuntu-core 16 images, /etc/passwd is read-only.

  If my user-data includes any non-default username, creation fails due to
  the read-only nature of the image.

  This is addressed by useradd/groupadd including a command line flag, 
--extrausers
  which instructs the command to look for a different user/group database in
  /var/lib/extrausers , which is writable in the ubuntu-core 16 image.

  [Test Case]
  In a snappy image that has cloud-init enabled, launch image with the 
  following user-data:
   #cloud-config
   users:
 - name: bob
   snapuser: b...@bobcom.io

  And also:
   #cloud-config
   snappy:
 email: b...@bobcom.io

  where 'b...@bobcom.io' is your launchpad registered email address.
  Assume you can log in.

  [Regression Potential] 
  The code is intended to be backwards compatible and inert unless 
  cloud-config provided turns it on.  It is also gated by a 'system_is_snappy'
  method that checks if the system is snappy (ubuntu core).

  Unit tests are provided, so regression should be somewhat reduced.

  Some code was moved around to implement this, and a new config module
  was added.

  
  [Other Info]
  The upstream change made here is at [1]

  [1] https://git.launchpad.net/cloud-
  init/commit?id=d8534561ba76db25b6fc0044eb1bfda63686e859

  === End SRU Template ===


  When running under ubuntu-core 16 images, /etc/passwd is read-only.

  If my user-data includes any non-default username, creation fails due to
  the read-only nature of the image.

  This is addressed by useradd/groupadd including a command line flag, 
--extrausers
  which instructs the command to look for a different user/group database in
  /var/lib/extrausers , which is writable in the ubuntu-core 16 image.

  The cc_user_groups module though is not aware of this.

  The Distro base-class could check if the system it's running on is snappy 
(see cc_snappy.py)
  and if so, append the --extrausers parameter to the useradd/groupadd commands.

  1) release is Xenial (ubuntu-core 16)
  2) cloud-init present is: 0.7.7~bzr1256-0ubuntu1~16.04.1
  3) useradd bob -m should create the user bob
  4) useradd fails due to readonly /etc/{passwd,group,shadow}

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1619393/+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

[Yahoo-eng-team] [Bug 1640556] Re: support network configuration for lxd 2.3

[Scott Moser]

fixed in upstream commit 02f6c4bb8cef17b3fe04ef4dc1ef199e20aeb4d9


** Description changed:

+ === Begin SRU Template ===
+ [Impact] 
+ Support for lxd configuration of networking does not work with lxd 2.3+ as
+ the current path for configuration in cloud-init uses debconf but newer
+ lxd does not support configuration that way.
+ 
+ Prior to LXD 2.3, the bridge configuration was done through distro
+ packaging.  With 2.3 and higher, this is now done inside LXD itself, so we
+ need to use "lxc network" with 2.3 and higher.
+ 
+ All the old code has been thrown out so LXD 2.3 doesn't have any debconf
+ templates and doesn't manage the lxd bridge itself. LXD 2.3 packaging does
+ ship a script which will convert existing users in place, so folks
+ upgrading shouldn't actually notice anything except that
+ /etc/default/lxd-bridge will disappear and they'll need to use 
+   "lxc network edit lxdbr0"
+ to configure any extra thing.
+ 
+ [Test Case]
+  * Prepare an image with updated cloud-init from proposed.
+  * start instance with user-data like:
+#cloud-config
+lxd:
+  bridge:
+mode: new
+name: lxdbr1
+ipv4_address: 10.5.0.1
+ipv4_netmask: 24
+ipv4_nat: true
+ 
+  * wait for system to boot, check that lxdbr1 is configured as expected.
+# ip addr show dev lxdbr1
+2: lxdbr1:  mtu 1500 qdisc noqueue state
+   UNKNOWN group default qlen 1000
+ link/ether 2e:f8:cc:5f:57:81 brd ff:ff:ff:ff:ff:ff
+ inet 10.5.0.1/24 scope global lxdbr1
+valid_lft forever preferred_lft forever
+ inet6 fe80::2cf8:ccff:fe5f:5781/64 scope link 
+valid_lft forever preferred_lft forever
+ 
+ [Regression Potential]
+ New codepath is taken based on prsence of /etc/default/lxd-bridge.
+ If that file was present and a newer version of lxd installed, then
+ we would take the wrong path.
+ 
+ [Other Info]
+ The upstream MP that this was added under can be seen at
+  https://code.launchpad.net/~stgraber/cloud-init/+git/cloud-init/+merge/307127
+ 
+ === End SRU Template ===
+ 
+ 
  Added to trunk at 
https://code.launchpad.net/~stgraber/cloud-init/+git/cloud-init/+merge/307127
  cloud-init in xenial should be able to configure an lxd 2.3 network also.

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
   Status: New => Fix Committed

** Changed in: cloud-init
 Assignee: (unassigned) => Stéphane Graber (stgraber)

-- 
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/1640556

Title:
  support network configuration for lxd 2.3

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact] 
  Support for lxd configuration of networking does not work with lxd 2.3+ as
  the current path for configuration in cloud-init uses debconf but newer
  lxd does not support configuration that way.

  Prior to LXD 2.3, the bridge configuration was done through distro
  packaging.  With 2.3 and higher, this is now done inside LXD itself, so we
  need to use "lxc network" with 2.3 and higher.

  All the old code has been thrown out so LXD 2.3 doesn't have any debconf
  templates and doesn't manage the lxd bridge itself. LXD 2.3 packaging does
  ship a script which will convert existing users in place, so folks
  upgrading shouldn't actually notice anything except that
  /etc/default/lxd-bridge will disappear and they'll need to use 
"lxc network edit lxdbr0"
  to configure any extra thing.

  [Test Case]
   * Prepare an image with updated cloud-init from proposed.
   * start instance with user-data like:
 #cloud-config
 lxd:
   bridge:
 mode: new
 name: lxdbr1
 ipv4_address: 10.5.0.1
 ipv4_netmask: 24
 ipv4_nat: true

   * wait for system to boot, check that lxdbr1 is configured as expected.
 # ip addr show dev lxdbr1
 2: lxdbr1:  mtu 1500 qdisc noqueue state
UNKNOWN group default qlen 1000
  link/ether 2e:f8:cc:5f:57:81 brd ff:ff:ff:ff:ff:ff
  inet 10.5.0.1/24 scope global lxdbr1
 valid_lft forever preferred_lft forever
  inet6 fe80::2cf8:ccff:fe5f:5781/64 scope link 
 valid_lft forever preferred_lft forever

  [Regression Potential]
  New codepath is taken based on prsence of /etc/default/lxd-bridge.
  If that file was present and a newer version of lxd installed, then
  we would take the wrong path.

  [Other Info]
  The upstream MP that this was added under can be seen at
   https://code.launchpad.net/~stgraber/cloud-init/+git/cloud-init/+merge/307127

  === End SRU Template ===


  Added to trunk at 

[Yahoo-eng-team] [Bug 1611074] Re: Reformatting of ephemeral drive fails on resize of Azure VM

[Scott Moser]

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

-- 
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/1611074

Title:
  Reformatting of ephemeral drive fails on resize of Azure VM

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  In some cases, cloud-init writes entries to /etc/fstab, and on azure it will
  even format a disk for mounting and then write the entry for that 'ephemeral'
  disk there.

  A supported operation on Azure is to "resize" the system.  When you do this
  the system is shut down, resized (given larger/faster disks and more CPU) and
  then brought back up.  In that process, the "ephemeral" disk re-initialized
  to its original NTFS format.  The designed goal is for cloud-init to recognize
  this situation and re-format the disk to ext4.

  The problem is that the mount of that disk happens before cloud-init can
  reformat.  Thats because the entry in fstab has 'auto' and is automatically
  mounted.  The end result is that after resize operation the user will be left
  with the ephemeral disk mounted at /mnt and having a ntfs filesystem rather
  than ext4.

  [Test Case]
  The text in comment 3 describes how to recreate by the original reporter.
  Another way to do this is to just re-format the ephemeral disk as
  ntfs and then reboot.  The result *should* be that after reboot it
  comes back up and has an ext4 filesystem on it.

  1.) boot system on azure
    (for this, i use https://gist.github.com/smoser/5806147, but you can
     use web ui or any other way).

  2.) unmount the ephemeral disk
     $ umount /mnt

  3.) repartition it so that mkfs.ntfs does less and is faster
     This is not strictly necessary, but mkfs.ntfs can take upwards of
     20 minutes.  shrinking /dev/sdb2 to be 200M means it will finish
     in < 1 minute.

     $ disk=/dev/disk/cloud/azure_resource
     $ part=/dev/disk/cloud/azure_resource-part1
     $ echo "2048,$((2*1024*100)),7" | sudo sfdisk "$disk"
     $ time mkfs.ntfs --quick "$part"

  4.) reboot
  5.) expect that /proc/mounts has /dev/disk/cloud/azure_resource-part1 as ext4
  and that fstab has x-systemd.requires in it.

  $ awk '$2 == "/mnt" { print $0 }' /proc/mounts
  /dev/sdb1 /mnt ext4 rw,relatime,data=ordered 0 0

  $ awk '$2 == "/mnt" { print $0 }' /etc/fstab
  /dev/sdb1 /mnt auto 
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig 0 2

  [Regression Potential]
  Regression is unlikely.  Likely failure case is just that the problem is not
  correctly fixed, and the user ends up with either an NTFS formated disk that
  is mounted at /mnt or there is nothing mounted at /mnt.

  === End SRU Template ===

  After resizing a 16.04 VM on Azure, the VM is presented with a new
  ephemeral drive (of a different size), which initially is NTFS
  formatted. Cloud-init tries to format the appropriate partition ext4,
  but fails because it is mounted. Cloud-init has unmount logic for
  exactly this case in the get_data call on the Azure data source, but
  this is never called because fresh cache is found.

  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] handlers.py[DEBUG]: start: 
init-network/check-cache: attempting to read from cache [trust]
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Reading from 
/var/lib/cloud/instance/obj.pkl (quiet=False)
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Read 5950 bytes 
from /var/lib/cloud/instance/obj.pkl
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] stages.py[DEBUG]: restored from 
cache: DataSourceAzureNet [seed=/dev/sr0]
  Jun 27 19:07:47 azubuntu1604arm [CLOUDINIT] handlers.py[DEBUG]: finish: 
init-network/check-cache: SUCCESS: restored from cache: DataSourceAzureNet 
[seed=/dev/sr0]
  ...
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] cc_disk_setup.py[DEBUG]: Creating 
file system None on /dev/sdb1
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] cc_disk_setup.py[DEBUG]:  
Using cmd: /sbin/mkfs.ext4 /dev/sdb1
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Running command 
['/sbin/mkfs.ext4', '/dev/sdb1'] with allowed return codes [0] (shell=False, 
capture=True)
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[DEBUG]: Creating fs for 
/dev/disk/cloud/azure_resource took 0.052 seconds
  Jun 27 19:07:48 azubuntu1604arm [CLOUDINIT] util.py[WARNING]: Failed during 
filesystem operation#012Failed to exec of '['/sbin/mkfs.ext4', 
'/dev/sdb1']':#012Unexpected error while running command.#012Command: 
['/sbin/mkfs.ext4', '/dev/sdb1']#012Exit code: 1#012Reason: 

[Yahoo-eng-team] [Bug 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up

[Scott Moser]

** Also affects: dbus (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: dbus (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: Confirmed => Fix Released

** Changed in: dbus (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: dbus (Ubuntu Yakkety)
   Status: New => Invalid

** No longer affects: dbus (Ubuntu Xenial)

** No longer affects: dbus (Ubuntu Yakkety)

** Description changed:

- During boot, cloud-init does DNS resolution checks to if particular
- metadata services are available (in order to determine which cloud it is
- running on).  These checks happen before systemd-resolved is up[0] and
- if they resolve unsuccessfully they take 25 seconds to complete.
+ === Begin SRU Template ===
+ [Impact] 
+ In cases where cloud-init used dns during early boot and system was
+ configured in nsswitch.conf to use systemd-resolvd, the system would
+ timeout on dns attempts making system boot terribly slow.
+ 
+ [Test Case]
+ Boot a system on GCE.
+ check for WARN in /var/log/messages
+ check that time to boot is reasonable (<30 seconds).  In failure case the
+ times would be minutes.
+ 
+ [Regression Potential]
+ Changing order in boot can be dangerous.  There is real chance for 
+ regression here, but it should be fairly small as xenial does not include
+ systemd-resolved usage.  This was first noticed on yakkety where it did.
+ 
+ [Other Info]
+ It seems useful to SRU this in the event that systemd-resolvd is used
+ on 16.04 or the case where user upgrades components (admittedly small use
+ case).
+ 
+ === End SRU Template ===
+ 
+ 
+ 
+ During boot, cloud-init does DNS resolution checks to if particular metadata 
services are available (in order to determine which cloud it is running on).  
These checks happen before systemd-resolved is up[0] and if they resolve 
unsuccessfully they take 25 seconds to complete.
  
  This has substantial impact on boot time in all contexts, because cloud-
  init attempts to resolve three known-invalid addresses ("does-not-
  exist.example.com.", "example.invalid." and a random string) to enable
  it to detect when it's running in an environment where a DNS server will
  always return some sort of redirect.  As such, we're talking a minimum
  impact of 75 seconds in all environments.  This increases when cloud-
  init is configured to check for multiple environments.
  
  This means that yakkety is consistently taking 2-3 minutes to boot on
  EC2 and GCE, compared to the ~30 seconds of the first boot and ~10
  seconds thereafter in xenial.

-- 
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/1629797

Title:
  resolve service in nsswitch.conf adds 25 seconds to failed lookups
  before systemd-resolved is up

Status in cloud-init:
  Fix Committed
Status in D-Bus:
  Unknown
Status in cloud-init package in Ubuntu:
  Fix Released
Status in dbus package in Ubuntu:
  Won't Fix
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact] 
  In cases where cloud-init used dns during early boot and system was
  configured in nsswitch.conf to use systemd-resolvd, the system would
  timeout on dns attempts making system boot terribly slow.

  [Test Case]
  Boot a system on GCE.
  check for WARN in /var/log/messages
  check that time to boot is reasonable (<30 seconds).  In failure case the
  times would be minutes.

  [Regression Potential]
  Changing order in boot can be dangerous.  There is real chance for 
  regression here, but it should be fairly small as xenial does not include
  systemd-resolved usage.  This was first noticed on yakkety where it did.

  [Other Info]
  It seems useful to SRU this in the event that systemd-resolvd is used
  on 16.04 or the case where user upgrades components (admittedly small use
  case).

  === End SRU Template ===


  
  During boot, cloud-init does DNS resolution checks to if particular metadata 
services are available (in order to determine which cloud it is running on).  
These checks happen before systemd-resolved is up[0] and if they resolve 
unsuccessfully they take 25 seconds to complete.

  This has substantial impact on boot time in all contexts, because
  cloud-init attempts to resolve three known-invalid addresses ("does-
  

[Yahoo-eng-team] [Bug 1635350] Re: unit tests fail as non-root on maas deployed system

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Low

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Low

** Description changed:

+ === Begin SRU Template ===
+ [Impact] 
+ Running cloud-init's unit test cases on a system deployed by MAAS would
+ fail.  The reason is that the non-root user would not be able to read 
+ files with MAAS node credentials in /etc/cloud/cloud.cfg.d 
+   
+ [Test Case]
+ Run unit tests on a system deployed by maas, or even just with:
+   f=/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg
+   sh -c 'mkdir -p "${1%/*}" && touch "$1" && chmod ugo-r "$1"' -- "$f"
+   tox -e py3
+ 
+ [Regression Potential] 
+ This was just to fix a build break or unit tests being run.
+ Changes are only to unit tests.
+ === End SRU Template ===
+ 
+ 
  Observed Behavior:
  
  On a system deployed by MAAS I checked out master and then tried to 
immediately build it:
  > git clone https://git.launchpad.net/cloud-init
  > cd cloud-init
  > ./packages/bddeb
  
  I get a number of errors around permission issues around this file:
  PermissionError: [Errno 13] Permission denied: 
\'/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg\'
  
  See: https://paste.ubuntu.com/23354559/
-  or formatted better: http://paste.ubuntu.com/23374383/
+  or formatted better: http://paste.ubuntu.com/23374383/
  
  If I run as root however, it build as expected.
  
  Expected Behavior:
  Running bddeb works as a non-root user.

** Description changed:

  === Begin SRU Template ===
- [Impact] 
+ [Impact]
  Running cloud-init's unit test cases on a system deployed by MAAS would
- fail.  The reason is that the non-root user would not be able to read 
- files with MAAS node credentials in /etc/cloud/cloud.cfg.d 
-   
+ fail.  The reason is that the non-root user would not be able to read
+ files with MAAS node credentials in /etc/cloud/cloud.cfg.d
+ 
+ We want this change SRU so that an attempt to build and run tests on a
+ system deployed by maas will work rather than fail due to unit test failure.
+ 
  [Test Case]
  Run unit tests on a system deployed by maas, or even just with:
-   f=/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg
-   sh -c 'mkdir -p "${1%/*}" && touch "$1" && chmod ugo-r "$1"' -- "$f"
-   tox -e py3
- 
- [Regression Potential] 
+   f=/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg
+   sh -c 'mkdir -p "${1%/*}" && touch "$1" && chmod ugo-r "$1"' -- "$f"
+   tox -e py3
+ 
+ [Regression Potential]
  This was just to fix a build break or unit tests being run.
  Changes are only to unit tests.
  === End SRU Template ===
- 
  
  Observed Behavior:
  
  On a system deployed by MAAS I checked out master and then tried to 
immediately build it:
  > git clone https://git.launchpad.net/cloud-init
  > cd cloud-init
  > ./packages/bddeb
  
  I get a number of errors around permission issues around this file:
  PermissionError: [Errno 13] Permission denied: 
\'/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg\'
  
  See: https://paste.ubuntu.com/23354559/
   or formatted better: http://paste.ubuntu.com/23374383/
  
  If I run as root however, it build as expected.
  
  Expected Behavior:
  Running bddeb works as a non-root user.

-- 
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/1635350

Title:
  unit tests fail as non-root on maas deployed system

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  Running cloud-init's unit test cases on a system deployed by MAAS would
  fail.  The reason is that the non-root user would not be able to read
  files with MAAS node credentials in /etc/cloud/cloud.cfg.d

  We want this change SRU so that an attempt to build and run tests on a
  system deployed by maas will work rather than fail due to unit test failure.

  [Test Case]
  Run unit tests on a system deployed by maas, or even just with:
    f=/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg
    sh -c 'mkdir -p "${1%/*}" && touch "$1" && chmod ugo-r "$1"' -- "$f"
    tox -e py3

  [Regression Potential]
  This was just to fix a build break or unit tests being run.
  Changes are only to unit tests.
  === End SRU Template ===

  Observed Behavior:

  On a system deployed by MAAS I checked out master and then tried to 
immediately build it:

[Yahoo-eng-team] [Bug 1639930] Re: initramfs kernel configuration ignored if only ip6= on kernel command line

[Scott Moser]

The initial fix is easy, but bug 1621615 changes sneaked in without a
unit test.

I'd really like a unit test of read_kernel_cmdline_config to accompany this 
change.
Also, a change to 'DHCP6_CONTENT_1' in tests/unittests/test_net.py to contain 
what we're currently expecting.


diff --git a/cloudinit/net/cmdline.py b/cloudinit/net/cmdline.py
index 4075a27..a077730 100644
--- a/cloudinit/net/cmdline.py
+++ b/cloudinit/net/cmdline.py
@@ -199,7 +199,7 @@ def read_kernel_cmdline_config(files=None, mac_addrs=None, 
cmdline=None):
 if data64:
 return util.load_yaml(_b64dgz(data64))
 
-if 'ip=' not in cmdline:
+if 'ip=' not in cmdline and 'ip6=' not in cmdline:
 return None


** Summary changed:

- initramfs kernel configuration ignored if only ip6= on kernel command line
+ initramfs network configuration ignored if only ip6= on kernel command line

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

-- 
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/1639930

Title:
  initramfs network configuration ignored if only ip6= on kernel command
  line

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  In changes made under bug 1621615 (specifically a1cdebdea), we now
  expect that there may be a 'ip6=' argument on the kernel command line.
  The changes made did not test the case where there is 'ip6=' and no
  'ip='.

  The code currently will return with no network configuration found if
  there is only ip6=...


  Related bugs:
   * bug 1621615: network not configured when ipv6 netbooted into cloud-init 
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1639930/+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

[Yahoo-eng-team] [Bug 1639930] [NEW] initramfs network configuration ignored if only ip6= on kernel command line

[Scott Moser]

Public bug reported:

In changes made under bug 1621615 (specifically a1cdebdea), we now
expect that there may be a 'ip6=' argument on the kernel command line.
The changes made did not test the case where there is 'ip6=' and no
'ip='.

The code currently will return with no network configuration found if
there is only ip6=...


Related bugs:
 * bug 1621615: network not configured when ipv6 netbooted into cloud-init 
 * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
 * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)

** Affects: cloud-init
 Importance: Medium
 Status: Confirmed

** Affects: cloud-init (Ubuntu)
 Importance: Medium
 Status: Confirmed

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/1639930

Title:
  initramfs network configuration ignored if only ip6= on kernel command
  line

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  In changes made under bug 1621615 (specifically a1cdebdea), we now
  expect that there may be a 'ip6=' argument on the kernel command line.
  The changes made did not test the case where there is 'ip6=' and no
  'ip='.

  The code currently will return with no network configuration found if
  there is only ip6=...


  Related bugs:
   * bug 1621615: network not configured when ipv6 netbooted into cloud-init 
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1639930/+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

[Yahoo-eng-team] [Bug 1626243] Re: Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive

[Scott Moser]

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Zesty)
   Importance: Medium
   Status: Fix Released

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Yakkety)
   Importance: Undecided => Medium

-- 
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/1626243

Title:
  Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  Confirmed
Status in cloud-init source package in Zesty:
  Fix Released

Bug description:
  The symptom is similar to bug 1611074 but the cause is different. In
  this case it seems there is an error accessing /dev/sdb1 when lsblk is
  run, possibly because sgdisk isn't done creating the partition. The
  specific error message is "/dev/sdb1: not a block device." A simple
  wait and retry here may resolve the issue.

  util.py[DEBUG]: Running command ['/sbin/sgdisk', '-p', '/dev/sdb'] with 
allowed return codes [0] (shell=False, capture=True)
  cc_disk_setup.py[DEBUG]: Device partitioning layout matches
  util.py[DEBUG]: Creating partition on /dev/disk/cloud/azure_resource took 
0.056 seconds
  cc_disk_setup.py[DEBUG]: setting up filesystems: [{'filesystem': 'ext4', 
'device': 'ephemeral0.1', 'replace_fs': 'ntfs'}]
  cc_disk_setup.py[DEBUG]: ephemeral0.1 is mapped to 
disk=/dev/disk/cloud/azure_resource part=1
  cc_disk_setup.py[DEBUG]: Creating new filesystem.
  cc_disk_setup.py[DEBUG]: Checking /dev/sdb against default devices
  cc_disk_setup.py[DEBUG]: Manual request of partition 1 for /dev/sdb1
  cc_disk_setup.py[DEBUG]: Checking device /dev/sdb1
  util.py[DEBUG]: Running command ['/sbin/blkid', '-c', '/dev/null', 
'/dev/sdb1'] with allowed return codes [0, 2] (shell=False, capture=True)
  cc_disk_setup.py[DEBUG]: Device /dev/sdb1 has None None
  cc_disk_setup.py[DEBUG]: Device /dev/sdb1 is cleared for formating
  cc_disk_setup.py[DEBUG]: File system None will be created on /dev/sdb1
  util.py[DEBUG]: Running command ['/bin/lsblk', '--pairs', '--output', 
'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', '--nodeps'] with allowed return codes 
[0] (shell=False, capture=True)
  util.py[DEBUG]: Creating fs for /dev/disk/cloud/azure_resource took 0.008 
seconds
  util.py[WARNING]: Failed during filesystem operation#012Failed during disk 
check for /dev/sdb1#012Unexpected error while running command.#012Command: 
['/bin/lsblk', '--pairs', '--output', 'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', 
'--nodeps']#012Exit code: 32#012Reason: -#012Stdout: ''#012Stderr: 'lsblk: 
/dev/sdb1: not a block device\n'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1626243/+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

[Yahoo-eng-team] [Bug 1635350] Re: unit tests fail as non-root on maas deployed system

[Scott Moser]

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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/1635350

Title:
  unit tests fail as non-root on maas deployed system

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  New

Bug description:
  Observed Behavior:

  On a system deployed by MAAS I checked out master and then tried to 
immediately build it:
  > git clone https://git.launchpad.net/cloud-init
  > cd cloud-init
  > ./packages/bddeb

  I get a number of errors around permission issues around this file:
  PermissionError: [Errno 13] Permission denied: 
\'/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg\'

  See: https://paste.ubuntu.com/23354559/
   or formatted better: http://paste.ubuntu.com/23374383/

  If I run as root however, it build as expected.

  Expected Behavior:
  Running bddeb works as a non-root user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1635350/+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

[Yahoo-eng-team] [Bug 1638931] [NEW] enable AliYun datasource by default

[Scott Moser]

Public bug reported:

As discussed at [1], the addition of AliYun datasource did not enable it by 
default.
This is because it has no definitive check before polling the network for data.

Lawrence suggested he has a solution for this.

[1] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-
init/+merge/309614

** Affects: cloud-init
 Importance: Medium
 Assignee: lawrence peng (kaihuan-pkh)
 Status: Confirmed

** Changed in: cloud-init
 Assignee: (unassigned) => lawrence peng (kaihuan-pkh)

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

-- 
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/1638931

Title:
  enable AliYun datasource by default

Status in cloud-init:
  Confirmed

Bug description:
  As discussed at [1], the addition of AliYun datasource did not enable it by 
default.
  This is because it has no definitive check before polling the network for 
data.

  Lawrence suggested he has a solution for this.

  [1] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-
  init/+merge/309614

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1638931/+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

[Yahoo-eng-team] [Bug 1621994] Re: Restarted instance after resize, fails init-local

[Scott Moser]

*** This bug is a duplicate of bug 1575055 ***
https://bugs.launchpad.net/bugs/1575055

** This bug has been marked a duplicate of bug 1575055
   check_instance_id() error on reboots when using config-drive

-- 
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/1621994

Title:
  Restarted instance after resize, fails init-local

Status in cloud-init:
  New

Bug description:
  [7.464278] cloud-init[601]: Cloud-init v. 0.7.7 running 'init-local' at 
Fri, 09 Sep 2016 19:51:20 +. Up 7.37 seconds.
  [7.466742] cloud-init[601]: 2016-09-09 19:51:20,144 - util.py[WARNING]: 
failed of stage init-local
  [7.471852] cloud-init[601]: failed run of stage init-local
  [7.473345] cloud-init[601]: 

  [7.475069] cloud-init[601]: Traceback (most recent call last):
  [7.476528] cloud-init[601]:   File "/usr/bin/cloud-init", line 520, in 
status_wrapper
  [7.478138] cloud-init[601]: ret = functor(name, args)
  [7.479436] cloud-init[601]:   File "/usr/bin/cloud-init", line 250, in 
main_init
  [7.481019] cloud-init[601]: init.fetch(existing=existing)
  [7.482307] cloud-init[601]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 322, in fetch
  [7.484147] cloud-init[601]: return 
self._get_data_source(existing=existing)
  [7.485736] cloud-init[601]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in 
_get_data_source
  [7.487611] cloud-init[601]: ds.check_instance_id(self.cfg)):
  [7.488956] cloud-init[601]: TypeError: check_instance_id() takes 1 
positional argument but 2 were given
  [7.490642] cloud-init[601]: 

  [[0;1;31mFAILED[0m] Failed to start Initial cloud-init job (pre-networking).
  See 'systemctl status cloud-init-local.service' for details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1621994/+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

[Yahoo-eng-team] [Bug 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up

[Scott Moser]

** Changed in: cloud-init (Ubuntu)
   Status: Fix Released => In Progress

-- 
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/1629797

Title:
  resolve service in nsswitch.conf adds 25 seconds to failed lookups
  before systemd-resolved is up

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  In Progress
Status in dbus package in Ubuntu:
  Triaged

Bug description:
  During boot, cloud-init does DNS resolution checks to if particular
  metadata services are available (in order to determine which cloud it
  is running on).  These checks happen before systemd-resolved is up[0]
  and if they resolve unsuccessfully they take 25 seconds to complete.

  This has substantial impact on boot time in all contexts, because
  cloud-init attempts to resolve three known-invalid addresses ("does-
  not-exist.example.com.", "example.invalid." and a random string) to
  enable it to detect when it's running in an environment where a DNS
  server will always return some sort of redirect.  As such, we're
  talking a minimum impact of 75 seconds in all environments.  This
  increases when cloud-init is configured to check for multiple
  environments.

  This means that yakkety is consistently taking 2-3 minutes to boot on
  EC2 and GCE, compared to the ~30 seconds of the first boot and ~10
  seconds thereafter in xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1629797/+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

[Yahoo-eng-team] [Bug 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up

[Scott Moser]

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Fix Committed

** Changed in: cloud-init
   Importance: Undecided => High

-- 
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/1629797

Title:
  resolve service in nsswitch.conf adds 25 seconds to failed lookups
  before systemd-resolved is up

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in dbus package in Ubuntu:
  Triaged

Bug description:
  During boot, cloud-init does DNS resolution checks to if particular
  metadata services are available (in order to determine which cloud it
  is running on).  These checks happen before systemd-resolved is up[0]
  and if they resolve unsuccessfully they take 25 seconds to complete.

  This has substantial impact on boot time in all contexts, because
  cloud-init attempts to resolve three known-invalid addresses ("does-
  not-exist.example.com.", "example.invalid." and a random string) to
  enable it to detect when it's running in an environment where a DNS
  server will always return some sort of redirect.  As such, we're
  talking a minimum impact of 75 seconds in all environments.  This
  increases when cloud-init is configured to check for multiple
  environments.

  This means that yakkety is consistently taking 2-3 minutes to boot on
  EC2 and GCE, compared to the ~30 seconds of the first boot and ~10
  seconds thereafter in xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1629797/+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

[Yahoo-eng-team] [Bug 1629868] Re: times out because of no dbus

[Scott Moser]

*** This bug is a duplicate of bug 1629797 ***
https://bugs.launchpad.net/bugs/1629797

I'm 95% sure that this is a dupe of bug 1629797
I'm going to mark it as such, and if we find out otherwise un-dupe it.


** This bug has been marked a duplicate of bug 1629797
   resolve service in nsswitch.conf adds 25 seconds to failed lookups before 
systemd-resolved is up

-- 
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/1629868

Title:
  times out because of no dbus

Status in cloud-init:
  New
Status in MAAS:
  New
Status in cloud-init package in Ubuntu:
  New

Bug description:
  Given this command line:
  BOOT_IMAGE=ubuntu/amd64/hwe-y/yakkety/daily/boot-kernel nomodeset 
iscsi_target_name=iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily
 iscsi_target_ip=2001:67c:1562:8010::2:1 iscsi_target_port=3260 
iscsi_initiator=kearns ip=kearns:BOOTIF ro 
root=/dev/disk/by-path/ip-2001:67c:1562:8010::2:1:3260-iscsi-iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily-lun-1
 overlayroot=tmpfs 
cloud-config-url=http://maas-boot-vm-xenial.dt-maas:5240/MAAS/metadata/latest/by-id/8w4gkk/?op=get_preseed
 log_host=maas-boot-vm-xenial.dt-maas log_port=514 --- console=ttyS1 
BOOTIF=01-38:63:bb:43:b8:bc

  Where:
  root@ubuntu:~# host maas-boot-vm-xenial.dt-maas
  maas-boot-vm-xenial.dt-maas is an alias for maas-boot-vm-xenial.maas.
  maas-boot-vm-xenial.maas has address 10.246.0.5
  maas-boot-vm-xenial.maas has IPv6 address 2001:67c:1562:8010::2:1

  cloud-init takes "forever" to run, because there is a 25 second pause
  every time it tries to report status to the maas server.  This is
  because hostname resolution assumes a working dbus, and takes 25
  seconds to timeout on connecting to dbus to get the answer.

  Related bugs:
   * bug 1611074: Reformatting of ephemeral drive fails on resize of Azure VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1629868/+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

[Yahoo-eng-team] [Bug 1629868] Re: times out because of no dbus

[Scott Moser]

** Description changed:

  Given this command line:
  BOOT_IMAGE=ubuntu/amd64/hwe-y/yakkety/daily/boot-kernel nomodeset 
iscsi_target_name=iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily
 iscsi_target_ip=2001:67c:1562:8010::2:1 iscsi_target_port=3260 
iscsi_initiator=kearns ip=kearns:BOOTIF ro 
root=/dev/disk/by-path/ip-2001:67c:1562:8010::2:1:3260-iscsi-iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily-lun-1
 overlayroot=tmpfs 
cloud-config-url=http://maas-boot-vm-xenial.dt-maas:5240/MAAS/metadata/latest/by-id/8w4gkk/?op=get_preseed
 log_host=maas-boot-vm-xenial.dt-maas log_port=514 --- console=ttyS1 
BOOTIF=01-38:63:bb:43:b8:bc
  
  Where:
  root@ubuntu:~# host maas-boot-vm-xenial.dt-maas
  maas-boot-vm-xenial.dt-maas is an alias for maas-boot-vm-xenial.maas.
  maas-boot-vm-xenial.maas has address 10.246.0.5
  maas-boot-vm-xenial.maas has IPv6 address 2001:67c:1562:8010::2:1
  
  cloud-init takes "forever" to run, because there is a 25 second pause
  every time it tries to report status to the maas server.  This is
  because hostname resolution assumes a working dbus, and takes 25 seconds
  to timeout on connecting to dbus to get the answer.
+ 
+ Related bugs:
+  * bug 1629868: Reformatting of ephemeral drive fails on resize of Azure VM

** Description changed:

  Given this command line:
  BOOT_IMAGE=ubuntu/amd64/hwe-y/yakkety/daily/boot-kernel nomodeset 
iscsi_target_name=iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily
 iscsi_target_ip=2001:67c:1562:8010::2:1 iscsi_target_port=3260 
iscsi_initiator=kearns ip=kearns:BOOTIF ro 
root=/dev/disk/by-path/ip-2001:67c:1562:8010::2:1:3260-iscsi-iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily-lun-1
 overlayroot=tmpfs 
cloud-config-url=http://maas-boot-vm-xenial.dt-maas:5240/MAAS/metadata/latest/by-id/8w4gkk/?op=get_preseed
 log_host=maas-boot-vm-xenial.dt-maas log_port=514 --- console=ttyS1 
BOOTIF=01-38:63:bb:43:b8:bc
  
  Where:
  root@ubuntu:~# host maas-boot-vm-xenial.dt-maas
  maas-boot-vm-xenial.dt-maas is an alias for maas-boot-vm-xenial.maas.
  maas-boot-vm-xenial.maas has address 10.246.0.5
  maas-boot-vm-xenial.maas has IPv6 address 2001:67c:1562:8010::2:1
  
  cloud-init takes "forever" to run, because there is a 25 second pause
  every time it tries to report status to the maas server.  This is
  because hostname resolution assumes a working dbus, and takes 25 seconds
  to timeout on connecting to dbus to get the answer.
  
  Related bugs:
-  * bug 1629868: Reformatting of ephemeral drive fails on resize of Azure VM
+  * bug 1611074: Reformatting of ephemeral drive fails on resize of Azure VM

** Also affects: cloud-init
   Importance: Undecided
   Status: New

-- 
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/1629868

Title:
  times out because of no dbus

Status in cloud-init:
  New
Status in MAAS:
  New
Status in cloud-init package in Ubuntu:
  New

Bug description:
  Given this command line:
  BOOT_IMAGE=ubuntu/amd64/hwe-y/yakkety/daily/boot-kernel nomodeset 
iscsi_target_name=iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily
 iscsi_target_ip=2001:67c:1562:8010::2:1 iscsi_target_port=3260 
iscsi_initiator=kearns ip=kearns:BOOTIF ro 
root=/dev/disk/by-path/ip-2001:67c:1562:8010::2:1:3260-iscsi-iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu-amd64-hwe-y-yakkety-daily-lun-1
 overlayroot=tmpfs 
cloud-config-url=http://maas-boot-vm-xenial.dt-maas:5240/MAAS/metadata/latest/by-id/8w4gkk/?op=get_preseed
 log_host=maas-boot-vm-xenial.dt-maas log_port=514 --- console=ttyS1 
BOOTIF=01-38:63:bb:43:b8:bc

  Where:
  root@ubuntu:~# host maas-boot-vm-xenial.dt-maas
  maas-boot-vm-xenial.dt-maas is an alias for maas-boot-vm-xenial.maas.
  maas-boot-vm-xenial.maas has address 10.246.0.5
  maas-boot-vm-xenial.maas has IPv6 address 2001:67c:1562:8010::2:1

  cloud-init takes "forever" to run, because there is a 25 second pause
  every time it tries to report status to the maas server.  This is
  because hostname resolution assumes a working dbus, and takes 25
  seconds to timeout on connecting to dbus to get the answer.

  Related bugs:
   * bug 1611074: Reformatting of ephemeral drive fails on resize of Azure VM

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1629868/+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

[Yahoo-eng-team] [Bug 1618572] Re: apt-key add fails in overlayfs

[Scott Moser]

** No longer affects: cloud-init

-- 
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/1618572

Title:
  apt-key add fails in overlayfs

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Released

Bug description:
  Sending a custom APT config to cloud-init fails to:
  1. add keys
  2. configure sources
  3. configura additional repository.

  The same config is being sent to curtin, and curtin doesn't seem to
  fail (curtin install log http://paste.ubuntu.com/23112826/ just in
  case).

  config sent by maas = http://pastebin.ubuntu.com/23112834/
  cloud-init.log = http://paste.ubuntu.com/23112820/
  cloud-init-output.log = http://paste.ubuntu.com/23112822/
  sources.list = http://paste.ubuntu.com/23112824/
  ubuntu@node03:/var/log$ ls -l /etc/apt/sources.list.d/
  total 0

  
  ubuntu@node03:/var/log$ sudo apt-get update
  Hit:2 http://us.archive.ubuntu.com/ubuntu yakkety-updates InRelease
  Get:3 http://us.archive.ubuntu.com/ubuntu yakkety-backports InRelease [92.2 
kB]
  Err:2 http://us.archive.ubuntu.com/ubuntu yakkety-updates InRelease
The following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  Ign:3 http://us.archive.ubuntu.com/ubuntu yakkety-backports InRelease
  Hit:4 http://us.archive.ubuntu.com/ubuntu yakkety-security InRelease
  Get:1 http://us.archive.ubuntu.com/ubuntu yakkety InRelease [247 kB]
  Err:4 http://us.archive.ubuntu.com/ubuntu yakkety-security InRelease
The following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  Err:1 http://us.archive.ubuntu.com/ubuntu yakkety InRelease
The following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  Fetched 339 kB in 0s (388 kB/s)
  Reading package lists... Error!
  W: An error occurred during the signature verification. The repository is not 
updated and the previous index files will be used. GPG error: 
http://us.archive.ubuntu.com/ubuntu yakkety-updates InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  W: GPG error: http://us.archive.ubuntu.com/ubuntu yakkety-backports 
InRelease: The following signatures couldn't be verified because the public key 
is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  W: The repository 'http://us.archive.ubuntu.com/ubuntu yakkety-backports 
InRelease' is not signed.
  N: Data from such a repository can't be authenticated and is therefore 
potentially dangerous to use.
  N: See apt-secure(8) manpage for repository creation and user configuration 
details.
  W: An error occurred during the signature verification. The repository is not 
updated and the previous index files will be used. GPG error: 
http://us.archive.ubuntu.com/ubuntu yakkety-security InRelease: The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  W: An error occurred during the signature verification. The repository is not 
updated and the previous index files will be used. GPG error: 
http://us.archive.ubuntu.com/ubuntu yakkety InRelease: The following signatures 
couldn't be verified because the public key is not available: NO_PUBKEY 
40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  W: Failed to fetch 
http://us.archive.ubuntu.com/ubuntu/dists/yakkety/InRelease  The following 
signatures couldn't be verified because the public key is not available: 
NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  W: Failed to fetch 
http://us.archive.ubuntu.com/ubuntu/dists/yakkety-updates/InRelease  The 
following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  W: Failed to fetch 
http://us.archive.ubuntu.com/ubuntu/dists/yakkety-security/InRelease  The 
following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  E: Problem renaming the file /var/cache/apt/srcpkgcache.bin.3HKvbX to 
/var/cache/apt/srcpkgcache.bin - rename (116: Stale file handle)
  E: Problem renaming the file /var/cache/apt/pkgcache.bin.d0JUHJ to 
/var/cache/apt/pkgcache.bin - rename (116: Stale file handle)
  W: You may want to run apt-get update to correct these problems
  E: The package cache file is corrupted

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1618572/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : 

[Yahoo-eng-team] [Bug 1621615] Re: network not configured when ipv6 netbooted into cloud-init

[Scott Moser]

** Merge proposal linked:
   https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/306345

** Also affects: cloud-init
   Importance: Undecided
   Status: New

-- 
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/1621615

Title:
  network not configured when ipv6 netbooted into cloud-init

Status in cloud-init:
  New
Status in MAAS:
  New
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of
  how ipv6 netboot with iscsi root disk doesn't work, blocking ipv6-only
  MAAS.

  After I hand-walked busybox through getting an IPv6 address,
  everything worked just fine until cloud-init couldn't fetch the
  instance data, because it insisted on bringing up the interface in
  IPv4, and there is no IPv4 DHCP on that vlan.

  Please work with initramfs and friends on getting ipv6 netboot to
  actually configure the interface.  This may be as simple as teaching
  it about "inet6 dhcp" interfaces, and bolting the pieces together.
  Note that "use radvd" is not really an option for our use case.

  Related bugs:
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp ipv6 
addresses

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1621615/+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

[Yahoo-eng-team] [Bug 1623570] Re: Azure: cannot start walinux agent (Transaction order is cyclic.)

[Scott Moser]

** No longer affects: cloud-init

-- 
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/1623570

Title:
  Azure: cannot start walinux agent (Transaction order is cyclic.)

Status in cloud-init package in Ubuntu:
  Confirmed
Status in walinuxagent package in Ubuntu:
  In Progress
Status in cloud-init source package in Xenial:
  Confirmed
Status in walinuxagent source package in Xenial:
  Confirmed

Bug description:
  When bringing up the Azure datasource in cloud-init.service, cloud-
  init tries 'service start walinuxagent'.

  That previously worked fine, and the agent would start and then would
  produce the certificate files that cloud-init needed (for ssh keys and
  things).

  I found this when testing SRU for 0.7.7-31-g65ace7b-0ubuntu1~16.04.1
  but it is likely present also in 0.7.7-31-g65ace7b-0ubuntu1 (yakkety)

  Now, however we see a log like:
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] DataSourceAzure.py[DEBUG]: Getting 
metadata via agent.  hostname=smoser0914x cmd=['service', 'walinuxagent', 
'start']
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[DEBUG]: Running command 
hostname with allowed return codes [0] (shell=False, capture=True)
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] DataSourceAzure.py[DEBUG]: invoking 
agent: ['service', 'walinuxagent', 'start']
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[DEBUG]: Running command 
['service', 'walinuxagent', 'start'] with allowed return codes [0] 
(shell=False, capture=True)
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[WARNING]: agent command 
'['service', 'walinuxagent', 'start']' failed.
  Sep 14 14:53:19 smoser0914x [CLOUDINIT] util.py[DEBUG]: agent command 
'['service', 'walinuxagent', 'start']' failed.
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 145, in get_metadata_from_agent
  invoke_agent(agent_cmd)
    File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 452, in invoke_agent
  util.subp(cmd, shell=(not isinstance(cmd, list)))
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1832, in subp
  cmd=args)
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['service', 'walinuxagent', 'start']
  Exit code: 1
  Reason: -
  Stdout: ''
  Stderr: "
    Failed to start walinuxagent.service: Transaction order is cyclic. See 
system logs for details.
    See system logs and 'systemctl status walinuxagent.service' for details

  I believe the relevant change is in 34a26f7f
    
https://git.launchpad.net/cloud-init/commit/?id=34a26f7f59f2963691e36ca0476bec9fc9ccef63
  That added multi-user.target to the list of After for 
cloud-init-final.service.

  Related bugs:
   * bug 1576692:  fully support package installation in systemd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1623570/+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

[Yahoo-eng-team] [Bug 1623570] Re: Azure: cannot start walinux agent (Transaction order is cyclic.)

[Scott Moser]

So we have a couple of options here:
a.) use '__builtin__' mode in cloud-init for the walinux agent functionality.
this in theory should work, but we have not largely tested it.   Basically
this path has cloud-init doing the metadata service exchange itself rather than 
relying on walinux-agent to pull the files it needs and then using them.

I've noticed one issue with this, is that walinuxagent.service is not started.  
Per journalctl, 
  multi-user.target: Breaking ordering cycle by deleting job 
walinuxagent.service/start

b.) remove or change 'After' 'cloud-final' in walinuxagent.service
I'm not exactly sure why this is here, but I believe it was so that cloud-init 
had an opportunity to configure walinuxagent or otherwise stop them from 
fighting.  That said, since cloud-init.service is starting walinux-agent (and 
has been for quite some time), it would seem that an After of 'cloud-init' 
should be sufficient.

It seems that because of the cyclic issue, 'b' is basically required.


** Also affects: walinuxagent (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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/1623570

Title:
  Azure: cannot start walinux agent (Transaction order is cyclic.)

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in walinuxagent package in Ubuntu:
  New
Status in cloud-init source package in Xenial:
  Confirmed
Status in walinuxagent source package in Xenial:
  New

Bug description:
  When bringing up the Azure datasource in cloud-init.service, cloud-
  init tries 'service start walinuxagent'.

  That previously worked fine, and the agent would start and then would
  produce the certificate files that cloud-init needed (for ssh keys and
  things).

  I found this when testing SRU for 0.7.7-31-g65ace7b-0ubuntu1~16.04.1
  but it is likely present also in 0.7.7-31-g65ace7b-0ubuntu1 (yakkety)

  Now, however we see a log like:
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] DataSourceAzure.py[DEBUG]: Getting 
metadata via agent.  hostname=smoser0914x cmd=['service', 'walinuxagent', 
'start']
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[DEBUG]: Running command 
hostname with allowed return codes [0] (shell=False, capture=True)
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] DataSourceAzure.py[DEBUG]: invoking 
agent: ['service', 'walinuxagent', 'start']
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[DEBUG]: Running command 
['service', 'walinuxagent', 'start'] with allowed return codes [0] 
(shell=False, capture=True)
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[WARNING]: agent command 
'['service', 'walinuxagent', 'start']' failed.
  Sep 14 14:53:19 smoser0914x [CLOUDINIT] util.py[DEBUG]: agent command 
'['service', 'walinuxagent', 'start']' failed.
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 145, in get_metadata_from_agent
  invoke_agent(agent_cmd)
    File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 452, in invoke_agent
  util.subp(cmd, shell=(not isinstance(cmd, list)))
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1832, in subp
  cmd=args)
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['service', 'walinuxagent', 'start']
  Exit code: 1
  Reason: -
  Stdout: ''
  Stderr: "
    Failed to start walinuxagent.service: Transaction order is cyclic. See 
system logs for details.
    See system logs and 'systemctl status walinuxagent.service' for details

  I believe the relevant change is in 34a26f7f
    
https://git.launchpad.net/cloud-init/commit/?id=34a26f7f59f2963691e36ca0476bec9fc9ccef63
  That added multi-user.target to the list of After for 
cloud-init-final.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1623570/+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

[Yahoo-eng-team] [Bug 1623570] [NEW] Azure: cannot start walinux agent (Transaction order is cyclic.)

[Scott Moser]

Public bug reported:

When bringing up the Azure datasource in cloud-init.service, cloud-init
tries 'service start walinuxagent'.

That previously worked fine, and the agent would start and then would
produce the certificate files that cloud-init needed (for ssh keys and
things).

I found this when testing SRU for 0.7.7-31-g65ace7b-0ubuntu1~16.04.1
but it is likely present also in 0.7.7-31-g65ace7b-0ubuntu1 (yakkety)

Now, however we see a log like:
Sep 14 14:53:18 smoser0914x [CLOUDINIT] DataSourceAzure.py[DEBUG]: Getting 
metadata via agent.  hostname=smoser0914x cmd=['service', 'walinuxagent', 
'start']
Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[DEBUG]: Running command 
hostname with allowed return codes [0] (shell=False, capture=True)
Sep 14 14:53:18 smoser0914x [CLOUDINIT] DataSourceAzure.py[DEBUG]: invoking 
agent: ['service', 'walinuxagent', 'start']
Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[DEBUG]: Running command 
['service', 'walinuxagent', 'start'] with allowed return codes [0] 
(shell=False, capture=True)
Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[WARNING]: agent command 
'['service', 'walinuxagent', 'start']' failed.
Sep 14 14:53:19 smoser0914x [CLOUDINIT] util.py[DEBUG]: agent command 
'['service', 'walinuxagent', 'start']' failed.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 145, in get_metadata_from_agent
invoke_agent(agent_cmd)
  File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 452, in invoke_agent
util.subp(cmd, shell=(not isinstance(cmd, list)))
  File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1832, in subp
cmd=args)
cloudinit.util.ProcessExecutionError: Unexpected error while running command.
Command: ['service', 'walinuxagent', 'start']
Exit code: 1
Reason: -
Stdout: ''
Stderr: "
  Failed to start walinuxagent.service: Transaction order is cyclic. See system 
logs for details.
  See system logs and 'systemctl status walinuxagent.service' for details

I believe the relevant change is in 34a26f7f
  
https://git.launchpad.net/cloud-init/commit/?id=34a26f7f59f2963691e36ca0476bec9fc9ccef63
That added multi-user.target to the list of After for cloud-init-final.service.

** Affects: cloud-init
 Importance: Undecided
 Status: Confirmed

** Affects: cloud-init (Ubuntu)
 Importance: High
 Status: Confirmed

** Affects: cloud-init (Ubuntu Xenial)
 Importance: High
 Status: Confirmed

** Also affects: ubuntu (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** No longer affects: ubuntu (Ubuntu)

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => High

** Description changed:

  When bringing up the Azure datasource in cloud-init.service, cloud-init
  tries 'service start walinuxagent'.
  
  That previously worked fine, and the agent would start and then would
  produce the certificate files that cloud-init needed (for ssh keys and
  things).
+ 
+ I found this when testing SRU for 0.7.7-31-g65ace7b-0ubuntu1~16.04.1
+ but it is likely present also in 0.7.7-31-g65ace7b-0ubuntu1 (yakkety)
  
  Now, however we see a log like:
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] DataSourceAzure.py[DEBUG]: Getting 
metadata via agent.  hostname=smoser0914x cmd=['service', 'walinuxagent', 
'start']
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[DEBUG]: Running command 
hostname with allowed return codes [0] (shell=False, capture=True)
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] DataSourceAzure.py[DEBUG]: invoking 
agent: ['service', 'walinuxagent', 'start']
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[DEBUG]: Running command 
['service', 'walinuxagent', 'start'] with allowed return codes [0] 
(shell=False, capture=True)
  Sep 14 14:53:18 smoser0914x [CLOUDINIT] util.py[WARNING]: agent command 
'['service', 'walinuxagent', 'start']' failed.
  Sep 14 14:53:19 smoser0914x [CLOUDINIT] util.py[DEBUG]: agent command 
'['service', 'walinuxagent', 'start']' failed.
  Traceback (most recent call last):
-   File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 145, in get_metadata_from_agent
- invoke_agent(agent_cmd)
-   File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py", 
line 452, in invoke_agent
- util.subp(cmd, shell=(not isinstance(cmd, list)))
-   File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1832, in subp
- cmd=args)
+   File "/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceAzure.py",