[Yahoo-eng-team] [Bug 1684978] Re: Nova could not communicate with Glance in IPv6 environment

[Launchpad Bug Tracker]

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete => Expired

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

Title:
  Nova could not communicate with Glance in IPv6 environment

Status in OpenStack Compute (nova):
  Expired

Bug description:
  Description
  ===
  Hi, 
  Nova could not communicate with glance in IPv6 environment.
  I wanted to introduce OpenStack Mitaka to my servers (Ubuntu16.04 LTS) which 
have only IPv6 address.

  Steps to reproduce
  ==
  First, I edited hosts file.

  Keystone setting is fine.

  controller# vim /etc/hosts
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  #127.0.0.1 controller ← comment out
  ...
  2001:200:0:::a controller  ← added (IPv6 only)
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  Next, go on to  Glance as following.

  controller# openstack role add --project service --user glance admin
  controller# openstack service create --name glance --description "OpenStack 
Image service" image
  controller# openstack endpoint create --region RegionOne image public 
http://controller:9292
  controller# openstack endpoint create --region RegionOne image internal 
http://controller:9292
  controller# openstack endpoint create --region RegionOne image admin 
http://controller:9292

  controller# vi /etc/glance/glance-api.conf

  controller# vi /etc/glance/glance-registry.conf

  
  controller# service glance-registry restart && service glance-api restart
  controller# tailf /var/log/glance/glance-api.log   ←
  controller# tailf /var/log/glance/glance-registry.log   ← both files have no 
error log
  controller# rm /var/lib/glance/glance.sqlite

  Get OS image and register it to Glance
  controller# wget 
http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
  controller# glance image-create --name "cirros-0.3.4-x86_64" --file 
cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare  
--visibility public --progress
  controller# openstack image list

  I checked Glance is file

  Then, Nova setting...
  controller# openstack endpoint create --region RegionOne compute public 
http://controller:8774/v2.1/%\(tenant_id\)s
  controller# openstack endpoint create --region RegionOne compute internal 
http://controller:8774/v2.1/%\(tenant_id\)s
  controller# openstack endpoint create --region RegionOne compute admin 
http://controller:8774/v2.1/%\(tenant_id\)s

  controller# vi /etc/nova/nova.conf

  
  controller# su -s /bin/sh -c "nova-manage api_db sync" nova
  controller# su -s /bin/sh -c "nova-manage db sync" nova
  controller# service nova-api restart && service nova-consoleauth restart && 
service nova-scheduler restart && service nova-conductor restart && service 
nova-novncproxy restart

  ↑no error happened

  controller# rm /var/lib/nova/nova.sqlite
  controller# nova image-list (the log file of nova-api at this command is 
attached)

  Expected result
  ===
  controller# nova image-list
  
+--+-+++
  | ID   | Name| Status | 
Server |
  
+--+-+++
  | 12d67808-c7d2-44b4-8bc6-b0ced1878f06 | cirros-0.3.4-x86_64 | ACTIVE |   
 |
  
+--+-+++

  Actual result
  =
  controller # nova image-list
  ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-978e02bb-998a-4f34-bcb2-1baf9707aec1)

  Environment
  ===
  controller ~(admin)# dpkg -l | grep nova
  ii  nova-api   2:13.1.3-0ubuntu1  
all  OpenStack Compute - API frontend
  ii  nova-common2:13.1.3-0ubuntu1  
all  OpenStack Compute - common files
  ii  nova-conductor 2:13.1.3-0ubuntu1  
all  OpenStack Compute - conductor service
  ii  nova-consoleauth   2:13.1.3-0ubuntu1  
all  OpenStack Compute - Console Authenticator
  ii  nova-novncproxy2:13.1.3-0ubuntu1  
all  OpenStack Compute - NoVNC proxy
  ii  nova-scheduler 2:13.1.3-0ubuntu1  
all  OpenStack Compute - virtual machine scheduler
  ii  python-nova2:13.1.3-0ubuntu1  
all  OpenStack Compute Python libraries
  ii  python-novaclient  2:3.3.1-2ubuntu1   
all

[Yahoo-eng-team] [Bug 1686540] Re: test_create_server_invalid_bdm_in_2nd_dict Failed

[Launchpad Bug Tracker]

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete => Expired

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

Title:
  test_create_server_invalid_bdm_in_2nd_dict Failed

Status in OpenStack Compute (nova):
  Expired

Bug description:
  When I run the test case test_create_server_invalid_bdm_in_2nd_dict in
  tempest - the test case failed with the below result.

  Openstack Version: Newton

  ==
  Failed 1 tests - output below:
  ==

  
tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_create_server_invalid_bdm_in_2nd_dict[id-12146ac1-d7df-4928-ad25-b1f99e5286cd,negative]
  
--

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "tempest/test.py", line 163, in wrapper
  raise exc
  tempest.lib.exceptions.ServerFault: Got server fault
  Details: Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
  

  
  Captured pythonlogging:
  ~~~
  2017-04-26 14:57:42,265 22886 INFO [tempest.lib.common.rest_client] 
Request (ServersNegativeTestJSON:setUp): 200 GET 
http://172.26.232.170:8774/v2/84fddff4dcc44eecbfa6e8dc824e291d/servers/6239b0ff-6900-4af8-8e49-5c4e0199afa5
 0.138s
  2017-04-26 14:57:42,266 22886 DEBUG[tempest.lib.common.rest_client] 
Request - Headers: {'Content-Type': 'application/json', 'Accept': 
'application/json', 'X-Auth-Token': ''}
  Body: None
  Response - Headers: {'status': '200', u'content-length': '1676', 
'content-location': 
'http://172.26.232.170:8774/v2/84fddff4dcc44eecbfa6e8dc824e291d/servers/6239b0ff-6900-4af8-8e49-5c4e0199afa5',
 u'date': 'Wed, 26 Apr 2017 21:57:42 GMT', u'x-compute-request-id': 
'req-b24ea609-e7bb-4806-8679-98c32d75a780', u'content-type': 
'application/json', u'connection': 'close'}
  Body: {"server": {"OS-EXT-STS:task_state": null, "addresses": 
{"rally_verify_3842fe6d_39ORN5Gi": [{"OS-EXT-IPS-MAC:mac_addr": 
"fa:16:3e:30:8d:2a", "version": 4, "addr": "10.2.0.4", "OS-EXT-IPS:type": 
"fixed"}]}, "links": [{"href": 
"http://172.26.232.170:8774/v2/84fddff4dcc44eecbfa6e8dc824e291d/servers/6239b0ff-6900-4af8-8e49-5c4e0199afa5;,
 "rel": "self"}, {"href": 
"http://172.26.232.170:8774/84fddff4dcc44eecbfa6e8dc824e291d/servers/6239b0ff-6900-4af8-8e49-5c4e0199afa5;,
 "rel": "bookmark"}], "image": {"id": "2897cc0b-1d3c-40b9-8587-447b8d3e0445", 
"links": [{"href": 
"http://172.26.232.170:8774/84fddff4dcc44eecbfa6e8dc824e291d/images/2897cc0b-1d3c-40b9-8587-447b8d3e0445;,
 "rel": "bookmark"}]}, "OS-EXT-STS:vm_state": "active", 
"OS-SRV-USG:launched_at": "2017-04-26T21:57:41.00", "flavor": {"id": 
"c742038a-4d78-4899-aa5f-269f502c8665", "links": [{"href": 
"http://172.26.232.170:8774/84fddff4dcc44eecbfa6e8dc824e291d/flavors/c742038a-4d78-4899-aa5f-269f502c8665;,
 "rel": "boo
 kmark"}]}, "id": "6239b0ff-6900-4af8-8e49-5c4e0199afa5", "security_groups": 
[{"name": "default"}], "user_id": "5104ec988e964669997b4f8a80914288", 
"OS-DCF:diskConfig": "MANUAL", "accessIPv4": "", "accessIPv6": "", "progress": 
0, "OS-EXT-STS:power_state": 1, "OS-EXT-AZ:availability_zone": "nova", 
"metadata": {}, "status": "ACTIVE", "updated": "2017-04-26T21:57:41Z", 
"hostId": "e49a0d4ef3c82f4d32305bbfd64ae2131f549992e45b4c1cb9be0de7", 
"OS-SRV-USG:terminated_at": null, "key_name": null, "name": 
"tempest-ServersNegativeTestJSON-server-1443765423", "created": 
"2017-04-26T21:57:35Z", "tenant_id": "84fddff4dcc44eecbfa6e8dc824e291d", 
"os-extended-volumes:volumes_attached": [], "config_drive": ""}}
  2017-04-26 14:57:42,891 22886 INFO [tempest.lib.common.rest_client] 
Request (ServersNegativeTestJSON:test_create_server_invalid_bdm_in_2nd_dict): 
200 POST http://172.26.232.170:8776/v1/84fddff4dcc44eecbfa6e8dc824e291d/volumes 
0.620s
  2017-04-26 14:57:42,892 22886 DEBUG[tempest.lib.common.rest_client] 
Request - Headers: {'Content-Type': 'application/json', 'Accept': 
'application/json', 'X-Auth-Token': ''}
  Body: {"volume": {"display_name": 
"tempest-ServersNegativeTestJSON-volume-1449183921", "size": 1}}
  Response - Headers: {'status': '200', u'content-length': '426', 
'content-location': 
'http://172.26.232.170:8776/v1/84fddff4dcc44eecbfa6e8dc824e291d/volumes', 
u'x-compute-request-id': 'req-e4dcf42c-7c6c-4339-807a-a12de5627b28', 
u'connection': 'close', u'date': 'Wed, 26 Apr 2017 21:57:42 GMT', 
u'content-type': 'application/json', u'x-openstack-request-id': 
'req-e4dcf42c-7c6c-4339-807a-a12de5627b28'}
  

[Yahoo-eng-team] [Bug 1703486] Re: instance catalogue residual after excute resize-revert

[Launchpad Bug Tracker]

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete => Expired

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

Title:
  instance catalogue residual after excute resize-revert

Status in OpenStack Compute (nova):
  Expired

Bug description:
  images_type configuration is rbd,but the instance catalogue is not
  shared.After exceute resize revert, the instance catalogue will
  residual in destination node.This will affect live-migration
  later.When the imagebacken is RBd, we think this is shared storage,
  but in actual environment,the instance catalogue can be not in shared
  storage.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1703486/+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 1704975] Re: Nova API floating IP delete fails

[Launchpad Bug Tracker]

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete => Expired

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

Title:
  Nova API floating IP delete fails

Status in OpenStack Compute (nova):
  Expired

Bug description:
  This happens with OpenStack Newton.
  We use some outdated openstack clients, that do not provide the "floating ip 
delete" command. Therefore we use the "ip floating delete" command.

  The floating IP is allocated using the "ip floating create" command. The 
floating IP is then associated to a newly started virtual machine.
  After some automated tests, the command to delete the virtual machine is 
sent. To keep the project clean, the floating IP is deleted afterwards using 
the "ip floating delete" command. This command fails from time to time due to 
some race condition.

  This race condition seems to be the following. Nova API requests
  information about the floating IP from neutron:

  GET /v2.0/floatingips/3aeb2a7e-ac37-4712-ac69-80dc83a060e6.json HTTP/1.1
  Host: controller:9696
  Connection: keep-alive
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-neutronclient
  X-Auth-Token: 
gABZbYLBVmPuNg6lSJzyQEuUbSfAcUgJTWDYrYaRJM2ZVzfRSpKPINNfl61M7Ohdfm-1lfx03_RqXhCGBRUKrPYgBpeKWCmiF-hsd2CActr6LMw3dbOHPrrPl8JOvVQ36caRyiDSFa4xY2getQjAfitJgdQknspRUdzpJAU8jvPxxHPSXvfrAWM8J1M2NzDnJKs0-JnZmYK5NlbJDcRMgfLtknzTGJJs6TnhqaDts_i234RsWf8

  {"floatingip": {"router_id": "aaab3136-d551-4e23-a62a-d16f89d34ec5",
  "status": "ACTIVE", "description": "", "updated_at":
  "2017-07-18T03:37:33Z", "dns_domain": "", "floating_network_id":
  "f3d64d76-a4e5-473b-878f-78b032ab89df", "fixed_ip_address":
  "192.168.3.10", "floating_ip_address": "10.50.0.62",
  "revision_number": 2, "port_id":
  "4b082eae-a527-45e6-8603-0d0882098e39", "id": "3aeb2a7e-
  ac37-4712-ac69-80dc83a060e6", "dns_name": "", "created_at":
  "2017-07-18T03:37:04Z", "tenant_id":
  "7829521236b143d2a6778e09ba588ec0", "project_id":
  "7829521236b143d2a6778e09ba588ec0"}}

  In the response the floating IP still seems to be associated to the
  virtual machine - but the request to delete the virtual machine was
  already sent.

  Nova API requests information about the port, too:

  GET /v2.0/ports/4b082eae-a527-45e6-8603-0d0882098e39.json HTTP/1.1
  Host: controller:9696
  Connection: keep-alive
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-neutronclient
  X-Auth-Token: 
gABZbYLBVmPuNg6lSJzyQEuUbSfAcUgJTWDYrYaRJM2ZVzfRSpKPINNfl61M7Ohdfm-1lfx03_RqXhCGBRUKrPYgBpeKWCmiF-hsd2CActr6LMw3dbOHPrrPl8JOvVQ36caRyiDSFa4xY2getQjAfitJgdQknspRUdzpJAU8jvPxxHPSXvfrAWM8J1M2NzDnJKs0-JnZmYK5NlbJDcRMgfLtknzTGJJs6TnhqaDts_i234RsWf8

  {"NeutronError": {"message": "Port
  4b082eae-a527-45e6-8603-0d0882098e39 could not be found.", "type":
  "PortNotFound", "detail": ""}}

  But the virtual machine and its floating IP association seems to be
  deleted in the meantime. This makes Nova API fail to delete the
  floating IP:

  2017-07-18 05:38:41.798 7170 INFO nova.api.openstack.wsgi 
[req-b8f7414b-6398-4738-b660-fac693a187ab 
807ca03b46124ca28309d06a8e66d25e7b7adfe872a6f58903552439304fa173 
7829521236b143d2a6778e09ba588ec0 - 27a851d6a3de43b8a4a4900dfa0c3141 
27a851d6a3de43b8a4a4900dfa0c3141] HTTP exception thrown: Floating IP not found 
for ID 3aeb2a7e-ac37-4712-ac69-80dc83a060e6
  2017-07-18 05:38:41.800 7170 INFO nova.osapi_compute.wsgi.server 
[req-b8f7414b-6398-4738-b660-fac693a187ab 
807ca03b46124ca28309d06a8e66d25e7b7adfe872a6f58903552439304fa173 
7829521236b143d2a6778e09ba588ec0 - 27a851d6a3de43b8a4a4900dfa0c3141 
27a851d6a3de43b8a4a4900dfa0c3141] 10.20.30.237 "GET 
/v2.1/7829521236b143d2a6778e09ba588ec0/os-floating-ips/3aeb2a7e-ac37-4712-ac69-80dc83a060e6
 HTTP/1.1" status: 404 len: 466 time: 0.2575810

  openstack ip floating delete 3aeb2a7e-ac37-4712-ac69-80dc83a060e6

  2017-07-18 11:32:50.867 7171 INFO nova.osapi_compute.wsgi.server 
[req-dafa9bec-fe87-47f6-8c44-4420b074da4d 
807ca03b46124ca28309d06a8e66d25e7b7adfe872a6f58903552439304fa173 
7829521236b143d2a6778e09ba588ec0 - 27a851d6a3de43b8a4a4900dfa0c3141 
27a851d6a3de43b8a4a4900dfa0c3141] 10.20.30.237 "GET 
/v2.1/7829521236b143d2a6778e09ba588ec0/os-floating-ips/3aeb2a7e-ac37-4712-ac69-80dc83a060e6
 HTTP/1.1" status: 200 len: 475 time: 0.2409530
  2017-07-18 11:32:51.654 7171 INFO nova.osapi_compute.wsgi.server 
[req-8f93afcb-40ff-4d8e-9f2f-c6fa860a8931 
807ca03b46124ca28309d06a8e66d25e7b7adfe872a6f58903552439304fa173 
7829521236b143d2a6778e09ba588ec0 - 27a851d6a3de43b8a4a4900dfa0c3141 
27a851d6a3de43b8a4a4900dfa0c3141] 10.20.30.237 "DELETE 
/v2.1/7829521236b143d2a6778e09ba588ec0/os-floating-ips/3aeb2a7e-ac37-4712-ac69-80dc83a060e6
 HTTP/1.1" status: 202 len: 337 time: 0.7844548

  GET 

[Yahoo-eng-team] [Bug 1706016] Re: Unexpected API Error : (HTTP 500)

[Launchpad Bug Tracker]

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete => Expired

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

Title:
  Unexpected API Error : (HTTP
  500)

Status in OpenStack Compute (nova):
  Expired

Bug description:
  Configuration
  
  Release name: Ocata

  One controller node and one compute node of Intel Xeon processor with
  64 GB RAM and 1.5 TB HDD

  keystone,cinder,neutron,dashboard all are in controller and compute on
  second server.

  Provider network configuration


  the setup runs fine and after instance starts running the following
  error showed up on some commands.

  ---Start---
  [root@controller ~]# openstack server list
  Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ 
and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-c5fc6b38-f111-4b59-8d9b-75afba138175)
  [root@controller~]#
  ---End--

  when I look in to the nova-api.log file I could find the following
  error

  OperationalError: (pymysql.err.OperationalError) (1040, u'Too many
  connections')

  
  The error goes off after restarting the mariadb.service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1706016/+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 1685534] Re: Unit tests for RHEL OpenStack need to be changed not to use alias files

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1685534

Title:
  Unit tests for RHEL OpenStack need to be changed not to use alias
  files

Status in cloud-init:
  Fix Released

Bug description:
  Unit tests for RHEL OpenStack need to be changed not to use alias
  files

  Alias files for IPv4 have fallen out of favor and alias files for IPv6
  do not work. Unit tests for openstack need to be modified accordingly
  in /home/akaris/cloud-init/tests/unittests/test_net.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1685534/+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 1686485] Re: cc_ntp fails to work when deploying ubuntu-core

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1686485

Title:
  cc_ntp fails to work when deploying ubuntu-core

Status in cloud-init:
  Fix Released
Status in MAAS:
  Invalid

Bug description:
  When deploying Ubuntu Core with MAAS I am seeing this error in
  /var/log/cloud-init.log:

  2017-04-26 18:11:45,172 - cc_apt_configure.py[DEBUG]: Nothing to do: No apt 
config and running on snappy
  2017-04-26 18:11:45,172 - handlers.py[DEBUG]: finish: 
modules-config/config-apt-configure: SUCCESS: config-apt-configure ran 
successfully
  2017-04-26 18:11:45,172 - stages.py[DEBUG]: Running module ntp () with frequency 
once-per-instance
  2017-04-26 18:11:45,172 - handlers.py[DEBUG]: start: 
modules-config/config-ntp: running config-ntp with frequency once-per-instance
  2017-04-26 18:11:45,173 - util.py[DEBUG]: Writing to 
/var/lib/cloud/instances/mpcgqp/sem/config_ntp - wb: [420] 24 bytes
  2017-04-26 18:11:45,173 - helpers.py[DEBUG]: Running config-ntp using lock 
()
  2017-04-26 18:11:45,175 - util.py[DEBUG]: Writing to 
/var/lib/cloud/instances/mpcgqp/sem/update_sources - wb: [420] 24 bytes
  2017-04-26 18:11:45,176 - helpers.py[DEBUG]: Running update-sources using 
lock ()
  2017-04-26 18:11:45,176 - util.py[DEBUG]: Running command ['apt-get', 
'--option=Dpkg::Options::=--force-confold', 
'--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 
'update'] with allowed return codes [0] (shell=False, capture=False)
  2017-04-26 18:11:45,186 - util.py[DEBUG]: apt-update [apt-get 
--option=Dpkg::Options::=--force-confold 
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet update] took 
0.010 seconds
  2017-04-26 18:11:45,186 - util.py[DEBUG]: Running command ['apt-get', 
'--option=Dpkg::Options::=--force-confold', 
'--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 
'install', 'ntp'] with allowed return codes [0] (shell=False, capture=False)
  2017-04-26 18:11:45,191 - util.py[DEBUG]: apt-install [apt-get 
--option=Dpkg::Options::=--force-confold 
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install ntp] 
took 0.005 seconds
  2017-04-26 18:11:45,193 - util.py[DEBUG]: Reading from 
/etc/cloud/templates/ntp.conf.ubuntu.tmpl (quiet=False)
  2017-04-26 18:11:45,193 - util.py[DEBUG]: Read 2509 bytes from 
/etc/cloud/templates/ntp.conf.ubuntu.tmpl
  2017-04-26 18:11:45,193 - templater.py[DEBUG]: Rendering content of 
'/etc/cloud/templates/ntp.conf.ubuntu.tmpl' using renderer jinja
  2017-04-26 18:11:45,197 - util.py[DEBUG]: Writing to /etc/ntp.conf - wb: 
[420] 2330 bytes
  2017-04-26 18:11:45,200 - handlers.py[DEBUG]: finish: 
modules-config/config-ntp: FAIL: running config-ntp with frequency 
once-per-instance
  2017-04-26 18:11:45,200 - util.py[WARNING]: Running module ntp () failed
  2017-04-26 18:11:45,202 - util.py[DEBUG]: Running module ntp () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 787, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_ntp.py", line 80, 
in handle
  write_ntp_config_template(ntp_cfg, cloud)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_ntp.py", line 126, 
in write_ntp_config_template
  templater.render_to_file(template_fn, NTP_CONF, params)
File "/usr/lib/python3/dist-packages/cloudinit/templater.py", line 131, in 
render_to_file
  util.write_file(outfn, contents, mode=mode)
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1711, in 
write_file
  with open(filename, omode) as fh:
  OSError: [Errno 30] Read-only file system: '/etc/ntp.conf'

  Note: This doesn't break deployment. Deployment still succeeds, except
  for ntp syncing is not setup to point to MAAS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1686485/+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 1687712] Re: cc_disk_setup: fs_setup with cmd doesn't work

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1687712

Title:
  cc_disk_setup: fs_setup with cmd doesn't work

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]
  If the user specifies cloud-config with a 'fs_setup' entry containing
  a 'cmd', then warning will appear in cloud-init.log and expected filesystem
  will not be created.

  This is because cloud-init would essentially try to execute a name like:
"mkfs -t TYPE -L LABEL DEVICE"
  rather than a name 'mkfs' with arguments '-t', TYPE, ...
  No split was done on space.  The fix was to enable
  shell intrepretation so that the split would be done.

  [Test Case]
  This test case assumes a disk will be attached named '/dev/vdb'.
  You can change the 'dev=' to be 'sdb' if that will be the device name.
  The test cases boots an instance, ads proposed and then 'cleans' the
  instance, but similarly this will work if the config is provided
  in user-data.

  $ dev=vdb
  $ sudo tee /etc/cloud/cloud.cfg.d/disk-setup.cfg 

[Yahoo-eng-team] [Bug 1684349] Re: mask2cidr error with integer value - argument of type 'int' is not iterable

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1684349

Title:
   mask2cidr error with integer value - argument of type 'int' is not
  iterable

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]
  On Openstack instances, when rendering sysconfig output, cloud-init
  would stacktrace due to a TypeError.
  This affects runtime only when rendering sysconfig networking, which
  is what is used on CentOS and RedHat systems.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, get cloud-init's network rendering tool from trunk
   c.) run the rendering tool against a config that failed before.
   d.) check rendered netplan config to verify it has the correct format.
   The failed output would have 'addresses' with a format like:
   172.19.1.34/255.255.255.0
   The expected output would be 'cidr' format:
   172.19.1.34/24

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc launch $ref $name
  $ lxc exec $name

  ## get render tool
  % wget 
https://git.launchpad.net/~cloud-init-dev/cloud-init/plain/tools/net-convert.py 
-O net-convert.py

  ## write the network_data.json
  % cat > simple-ipv6.yaml 

[Yahoo-eng-team] [Bug 1686514] Re: Azure: cloud-init does not handle reformatting GPT partition ephemeral disks

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1686514

Title:
  Azure: cloud-init does not handle reformatting GPT partition ephemeral
  disks

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

Bug description:
  === Begin SRU Template ===
  [Impact]
  On Azure, cloud-init handles re-formatting the ephemeral disk.
  The contents of the ephemeral disk for a system will be replaced with
  a stock ephemeral disk in the following scenarios:
   a.) first boot
   b.) after a resize.
   c.) after a VM has been migrated from one host to another.

  That ephemeral disk is either
   1. mbr partitioned with 1 ntfs partition
   2. gpt partitioned with 2 partitions, a msft reserved partition and a
  ntfs partition.  This scenario is newer, and only occurs on
  larger instance types that have large ephemeral disks.

  cloud-init previously did not handle '2' above.

  [Test Case]
  Generically this is re-creatable by:
   1.) launch an instance on Azure
   2.) resize it to a L32 or G5 size
   3.) check to see that the ephemeral disk (/dev/disk/cloud/azure_resource)
   has been formatted to ext4.

  It is more easily recreated for testing and verification by:

  1. launch instance on azure
  2. re-partition the ephemeral disk to look like a "clean" disk above
  3. remove old logs, reboot
 $ dir=logs-$(date +"%Y%m%d-%H%M%S");
 $ mkdir -p $dir; mv /var/log/cloud-init* $dir
  4. ssh back in, expect that this the disk has an ext4 filesystem on it.
 And that it is mounted on /mnt.

 $ grep reformattable= /var/log/cloud-init.log
 2017-05-12 15:14:57,125 - DataSourceAzure.py[DEBUG]: reformattable=False: 
partition 1 (/dev/sdb1) on device /dev/disk/cloud/azure_resource was not ntfs 
formatted

 Or, if it was formatted, you'll see something like:
 2017-05-12 15:17:47,021 - DataSourceAzure.py[DEBUG]: reformattable=True: 
partition 2 (/dev/sdb2) on device /dev/disk/cloud/azure_resource was ntfs 
formatted and had no important files. Safe for reformatting.

 $ grep /mnt /proc/mounts
 /dev/sdb1 /mnt ext4 rw,relatime,data=ordered 0 0

  
  [Regression Potential]
  The change makes cloud-init accept another situation when it decides
  to be reformat a disk.  Reformatting of a disk could result in loss of
  customer data if the decision to do so results in a false positive.

  The fix came with some fairly extensive unit tests (TestCanDevBeReformatted)
  on the 'can_dev_be_reformatted' method.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=31b6f1732

  === End SRU Template ===

  
  Some Azure instances such as L32 or G5 have very large ephemeral disks which 
are partitioned via GPT vs. smaller ephemeral disks that have dos disklabels.

  At first boot of an instance the ephemeral disk is prepared and
  formatted properly. But if the instance is deallocated and then
  reallocated (thus receiving a new ephemeral disk) then cloud-init does
  not handle reformatting GPT partition ephemeral disks properly.
  Therefore /mnt is never mounted again.

  Test cases:
   1. Deploy an L32(s) VM on Azure
   2. Log in and ensure that the ephemeral disk is formatted and mounted to /mnt
   3. Via the portal you can "Redeploy" the VM to a new Azure Host (or 
alternatively stop and deallocate the VM for some time, and then 
restart/reallocate the VM).

  Expected Results:
   - After reallocation we expect the ephemeral disk to be formatted and 
mounted to /mnt.

  Actual Results:
   - After reallocation /mnt is not mounted and there are errors in the 
cloud-init log.

  *This was tested on Ubuntu 16.04 - but may affect other releases.

  Note: This bug a regression from previous cloud-init releases. GPT
  support for Azure ephemeral disk handling was added to cloud-init via
  this bug: https://bugs.launchpad.net/ubuntu/+source/cloud-
  init/+bug/1422919.

  Related bugs:
   * bug 1691489: fstab entries written by cloud-config may not be mounted

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1686514/+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 1687485] Re: sysconfig route object reference removed class attribute

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1687485

Title:
  sysconfig route object reference removed class attribute

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]
  This code path is not applicable to Ubuntu.
  The bug resolved properly detecting and raising ValueErrors if multiple 
default
  gateways were defined in ipv4 or or ipv6 addresses for sysconfig
  (Redhat/centos) format.

  [Test Case]
  Launch an instance on lxd, make sure it has network.

  [Regression Potential]
  Changes to network rendering could have negatively affected Ubuntu
  the test above is valid to check that that didn't go horribly wrong.

  [Other Info]
  Upstream commit:
   
https://git.launchpad.net/cloud-init/commit/?id=dd03bb411c9a6f10854a3bbc3223b204c3d4d174

  === End SRU Template ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1687485/+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 1719055] [NEW] Add unnamed argument on translation file.

[Sungjin Kang]

Public bug reported:

This bus is refectoring bug.

Nest message is an easy translation.
Way? %s is naming.

```
gettext('The selected %(sourceType)s source requires a flavor with at least 
%(minRam)s MB of RAM. Select a flavor with more RAM or use a different 
%(sourceType)s source.')
```

It is difficult for some messages to translate work without naming `%s`.
So I will change the text used in all the plugins used in `Horizon`.

** Affects: horizon
 Importance: Undecided
 Assignee: Sungjin Kang (sungjin)
 Status: In Progress


** Tags: i18n

** Changed in: horizon
 Assignee: (unassigned) => Sungjin Kang (sungjin)

** Changed in: horizon
   Status: New => In Progress

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

Title:
  Add unnamed argument on translation file.

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  This bus is refectoring bug.

  Nest message is an easy translation.
  Way? %s is naming.

  ```
  gettext('The selected %(sourceType)s source requires a flavor with at least 
%(minRam)s MB of RAM. Select a flavor with more RAM or use a different 
%(sourceType)s source.')
  ```

  It is difficult for some messages to translate work without naming
  `%s`. So I will change the text used in all the plugins used in
  `Horizon`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1719055/+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 1719054] [NEW] Add unnamed argument on translation file.

[Sungjin Kang]

Public bug reported:

This bus is refectoring bug.

Nest message is an easy translation.
Way? %s is naming.

```
gettext('The selected %(sourceType)s source requires a flavor with at least 
%(minRam)s MB of RAM. Select a flavor with more RAM or use a different 
%(sourceType)s source.')
```

It is difficult for some messages to translate work without naming `%s`.
So I will change the text used in all the plugins used in `Horizon`.

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: i18n

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

Title:
  Add unnamed argument on translation file.

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  This bus is refectoring bug.

  Nest message is an easy translation.
  Way? %s is naming.

  ```
  gettext('The selected %(sourceType)s source requires a flavor with at least 
%(minRam)s MB of RAM. Select a flavor with more RAM or use a different 
%(sourceType)s source.')
  ```

  It is difficult for some messages to translate work without naming
  `%s`. So I will change the text used in all the plugins used in
  `Horizon`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1719054/+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 1689346] Re: cloud-init and nplan do not parse and use OpenStack networking correctly with netmask

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1689346

Title:
  cloud-init and nplan do not parse and use OpenStack networking
  correctly with netmask

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]
  On Openstack instances, cloud-init incorrectly rendered netplan
  configuration files.  The result is that networking does not work
  as expected.

  Note that this is not a default configuration on any Ubuntu provided images.
  Default images use ifupdown (eni) rendering which did not have this issue.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, get cloud-init's network rendering tool from trunk
   c.) run the rendering tool against a config that failed before.
   d.) check rendered netplan config to verify it has the correct format.
   The failed output would have 'addresses' with a format like:
   172.19.1.34/255.255.255.0
   The expected output would be 'cidr' format:
   172.19.1.34/24

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc init $ref $name

  ## get render tool
  $ wget 
https://git.launchpad.net/~cloud-init-dev/cloud-init/plain/tools/net-convert.py 
-O net-convert.py

  ## write the network_data.json
  $ cat >network_data.json 

[Yahoo-eng-team] [Bug 1685944] Re: tools/net-convert: fix argument order for render_network_state

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1685944

Title:
  tools/net-convert: fix argument order for render_network_state

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] 
  Rendering of netplan content was broken due to an incorrect
  function signature in net/netplan.py:render_network_state.

  The end result was that rendering of netplan configuration was
  broken in actual usage.  Note, though that no official Ubuntu images
  use this path at the current time.  Ubuntu image all use ifupdown.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, run the test case.  That would stack trace
   as seen in the bug on prior versions of cloud-init.
   c.) show the output.

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc launch $ref $name
  $ lxc exec $name

  % cat > render-test.py <<"EOF"
  #!/usr/bin/python3
  import sys
  from cloudinit.net import netplan, eni, network_state
  out_d = "./out.d" if len(sys.argv) < 2 else sys.argv[1]

  cfg = {'version': 1,
 'config': [{'name': 'eth1', 'type': 'physical',
'subnets': [{'type': 'dhcp'}]}]}

  # Render eni and netplan to show that they both work.
  ns = network_state.parse_net_config_data(cfg)
  for renderer in netplan.Renderer(), eni.Renderer():
  print("Rendering %s" % renderer)
  renderer.render_network_state(ns, out_d)
  EOF

  $ python3 render-test.py out.d
  Rendering 
  Rendering 

  $ ( cd out.d && for f in $(find . -type f); do echo == $f ==; cat $f; done )
  == ./etc/network/interfaces ==
  auto lo
  iface lo inet loopback

  auto eth1
  iface eth1 inet dhcp
  == ./etc/netplan/50-cloud-init.yaml ==
  network:
  version: 2
  ethernets:
  eth1:
  dhcp4: true
  == ./etc/udev/rules.d/70-persistent-net.rules ==

  $ dpkg-query --show cloud-init

  [Regression Potential] 
  This specific change has basically zero regression potential as it
  was in netplan specific path that was only previously excercised
  with test cases.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=a6572d9415e59

  lxc-proposed-snapshot is

https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.
  === End SRU Template ===

  
  % cat simple-v2.yaml
  network:
    version: 2
    # comment above ethernets
    ethernets:
    ens0:
   dhcp4: true
   match:
     macaddress: 00:11:22:33:44:55
   set-name: ens0
    switchports:
  # all cards on second PCI bus; unconfigured by themselves, will be 
added
  # to br0 below
  match:
    name: enp2*
  mtu: 1280

  % PYTHONPATH=`pwd` ./tools/net-convert.py --network-data simple-v2.yaml \
    --kind yaml \
    --output-kind netplan \
    --directory ./target

  Traceback (most recent call last):
    File "./tools/net-convert.py", line 82, in 
  main()
    File "./tools/net-convert.py", line 78, in main
  r.render_network_state(ns, target=args.directory)
  TypeError: render_network_state() got multiple values for argument 'target'

  This is broken on master.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1685944/+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 1686751] Re: cloud-init boot errors on centos7

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1686751

Title:
  cloud-init boot errors on centos7

Status in cloud-init:
  Fix Released

Bug description:
  [root@localhost ubuntu]# systemctl status cloud-init-local -l
  ● cloud-init-local.service - LSB: The initial cloud-init job (local fs 
contingent)
 Loaded: loaded (/etc/rc.d/init.d/cloud-init-local; bad; vendor preset: 
disabled)
 Active: failed (Result: exit-code) since Thu 2017-04-27 14:39:57 UTC; 35s 
ago
   Docs: man:systemd-sysv-generator(8)
Process: 462 ExecStart=/etc/rc.d/init.d/cloud-init-local start 
(code=exited, status=1/FAILURE)

  Apr 27 14:39:57 localhost cloud-init-local[462]: 
self.selinux.restorecon(path, recursive=self.recursive)
  Apr 27 14:39:57 localhost cloud-init-local[462]: File 
"/usr/lib64/python2.7/site-packages/selinux/__init__.py", line 100, in 
restorecon
  Apr 27 14:39:57 localhost cloud-init-local[462]: 
restorecon(os.path.join(root, name))
  Apr 27 14:39:57 localhost cloud-init-local[462]: File 
"/usr/lib64/python2.7/site-packages/selinux/__init__.py", line 85, in restorecon
  Apr 27 14:39:57 localhost cloud-init-local[462]: status, context = 
matchpathcon(path, mode)
  Apr 27 14:39:57 localhost cloud-init-local[462]: OSError: [Errno 2] No such 
file or directory
  Apr 27 14:39:57 localhost systemd[1]: cloud-init-local.service: control 
process exited, code=exited status=1
  Apr 27 14:39:57 localhost systemd[1]: Failed to start LSB: The initial 
cloud-init job (local fs contingent).
  Apr 27 14:39:57 localhost systemd[1]: Unit cloud-init-local.service entered 
failed state.
  Apr 27 14:39:57 localhost systemd[1]: cloud-init-local.service failed.

  cloud-init (net) errors:

  Apr 27 14:30:48 localhost cloud-init: Starting cloud-init: Cloud-init v. 
0.7.9 running 'init' at Thu, 27 Apr 2017 14:30:48 +. Up 4.77 seconds.
  Apr 27 14:30:48 localhost cloud-init: 2017-04-27 14:30:48,387 - 
util.py[WARNING]: Route info failed: Unexpected error while running command.
  Apr 27 14:30:48 localhost cloud-init: Command: ['netstat', '-rn']

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1686751/+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 1686856] Re: sysconfig renderer does not render gateway settings in ifcfg-$iface files

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1686856

Title:
  sysconfig renderer does not render gateway settings in ifcfg-$iface
  files

Status in cloud-init:
  Fix Released
Status in oVirt:
  Unknown
Status in CentOS:
  Unknown

Bug description:
  cloud-init trunk with the following network config:

  network:
  version: 1
  config:
  - type: physical
name: interface0
mac_address: "52:54:00:12:34:00"
subnets:
- type: static
  address: 10.0.2.15
  netmask: 255.255.255.0
  gateway: 10.0.2.2

  
  renders an ifcfg-interface0 file without a GATEWAY=10.0.2.2

  % cat /etc/sysconfig/network-scripts/ifcfg-interface0
  # Created by cloud-init on instance boot automatically, do not edit.
  #
  BOOTPROTO=static
  DEVICE=interface0
  HWADDR=52:54:00:12:34:00
  IPADDR=10.0.2.15
  NETMASK=255.255.255.0
  NM_CONTROLLED=no
  ONBOOT=yes
  TYPE=Ethernet
  USERCTL=no

  
  Subsequently, route -n shows that a default gateway is not set.

  % route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  10.0.2.00.0.0.0 255.255.255.0   U 0  00 
interface0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1002   00 
interface0

  
  If you add GATEWAY=10.0.2.2 you see a route like this:

  % route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 10.0.2.20.0.0.0 UG0  00 
interface0
  10.0.2.00.0.0.0 255.255.255.0   U 0  00 
interface0
  169.254.0.0 0.0.0.0 255.255.0.0 U 1002   00 
interface0

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1686856/+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 1685810] Re: nova-lxd needs to read 'product_name' in environment, not 'platform'

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1685810

Title:
  nova-lxd needs to read 'product_name' in environment, not 'platform'

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

Bug description:
  === Begin SRU Template ===
  [Impact]
  Warning message for nova-lxd images in openstack clouds due to no valid 
datasource found.

  [Test Case]
  # It downloads a cloud image of a given release, and then creates a -proposed
  image with cloud-init upgraded.
  wget 
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/lxc-proposed-snapshot
  chmod 755 get-proposed-image

  source novarc

  for release in xenial yakkety zesty do;
   ref=$release-proposed;
   lxc-proposed-snapshot --proposed --publish $release $ref;
   lxc image export $ref .;
   imagefile=`ls -tr *gz | tail -n 1`
   mkdir $ref;
   cd $ref;
   sudo tar -zxvpf ../$imagefile;  # preserve permissions
   cd rootfs;
   sudo tar zcpvf $ref.tar.gz *;
   #upload raw image to your cloud
    openstack image create --disk-format raw --container-format bare --file 
$ref.tar.gz testing/$ref.tar.gz;
    openstack server create --image testing/$ref.tar.gz --flavor=m1.tiny 
lxd-$release --key-name ;
    nova floating-ip-create;
    nova foating-ip-associate  ;
    ssh ubuntu@ 'sudo DEBUG_LEVEL=2 DI_LOG=stderr 
/usr/lib/cloud-init/ds-identify --force 2>&1 | grep Found';   # single 
datasource: OpenStack
  done

  [Regression Potential]
  Low as this only addresses the warning by correctly identifying the OpenStack 
cloud datasource.

  [Other Info]

  === End SRU Template ===

  It seems that signals were crossed in bug 1661797.
  cloud-init implementation reads the environment variable 'platform' from 
pid1, and nova-lxd implementation exported 'product_name'.

  Thus, ssh to nova-lxd provided container, user sees a warning.
  Also
  $ sudo DEBUG_LEVEL=2 DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force 
2>&1 | grep PLAT
  PID_1_PLATFORM=unavailable

  While:
  $ sudo cat /proc/1/environ | tr '\0' '\n'
  product_name=OpenStack Nova
  container=lxc

  Related bugs:
   * bug 1661797: identify lxd-nova platform to enable Openstack datasource

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1685810/+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 1684869] Re: growing root partition does not always work with root=PARTUUID=

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1684869

Title:
  growing root partition does not always work with root=PARTUUID=

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

Bug description:
  === Begin SRU Template ===
  [Impact]
  Growing the root partition would fail in either of two cases:
   a.) if the device /dev/root existed
   This occurs on yakkety systems.

   b.) the kernel command line had upper case letters in PARTUUID=
   This can be fed via root= on either xenial or yakkety.

  
  [Test Case]
  get-proposed-image is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/get-proposed-image
  It downloads a cloud image of a given release, and then creates a -proposed
  image with cloud-init upgraded.

  1.) get a (proposed) disk image image.
    and convert it to raw so you can read the partuuid with sfdisk
    (get-proposed-image does this, if not,
    'qemu-img convert -O raw orig.img orig.raw')
    ./get-proposed-image

  2.) get the partition uuid of the first partition
     $ raw=yakkety-server-cloudimg-amd64-proposed.raw
     $ ptuuid=$(sfdisk --part-uuid $raw 1)
 # sfdisk will normally output in upper case, but be explicit here.
 $ ptuuid=$(echo "$ptuuid" | tr '[a-z]' '[A-Z]')

  3.) create a nocloud seed
     $ printf "%s\n%s\n%s\n%s\n" "#cloud-config" "password: passw0rd" \
  "chpasswd: {expire: False}" "ssh_pwauth: True" > my-user-data
     $ echo "instance-id: $(uuidgen || echo i-abcdefg)" > my-meta-data
     $ cloud-localds my-seed.img my-user-data my-meta-data

  4.) extract kernel from inside the image
     $ sudo mount-image-callback $raw -- mchroot sh -xc 'cat /boot/vmlinu?-*' > 
kernel

  5.) boot instance with disk backed by the raw disk above.

     $ qemu-img create -f qcow2 -b $raw disk.img 10G
     $ qemu-system-x86_64 -enable-kvm \
     -drive file=disk.img,if=ide,index=0 -drive file=my-seed.img,if=ide \
     -net nic -net user,hostfwd=tcp::-:22 \
     -snapshot -m 768 -nographic -echr 0x05 \
     -kernel kernel \
     -append "root=PARTUUID=${ptuuid} ro console=tty1 console=ttyS0"

  6.) log in, verify / has been resized.
     log in with 'ubuntu' and password 'passw0rd'
  $ df -h /
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/root   9.6G 1009M  8.6G  11% /

  [Regression Potential]
  The regression path is really the case where devent2dev finds /dev/root
  and /dev/root exists.  In that case, we now possibly return a /dev/
  path when previously it would have returned /dev/root.

  [Other Info]
  The qemu-system-x86 command above uses ide devices.  This is because
  the ide device emulated by qemu is built into the -generic kernel,
  whilei the more common virtio-block or virtio-scsi are not.  If you
  attach those device types, it will fail with 'cant find root'.

  === End SRU Template ===

  When trying to verify I found a couple cases where this still does not
  work.

  Related bugs:
   * bug 1677376: growing partitions does not work when booted without initramfs
   * bug 1685291: RFC: virtio and virtio-scsi should be built in

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1684869/+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 1685532] Re: Unit tests for sysconfig are flawed:

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1685532

Title:
  Unit tests for sysconfig are flawed:

Status in cloud-init:
  Fix Released

Bug description:
  Unit tests for sysconfig are flawed:

  E.g.:
  # Created by cloud-init on instance boot automatically, do not edit.
  #
  BOOTPROTO=static
  DEVICE=eth0
  IPV6ADDR=2607:f0d0:1002:0011::2
  IPV6INIT=yes
  NETMASK=64
  NM_CONTROLLED=no
  ONBOOT=yes
  TYPE=Ethernet
  USERCTL=no
  '''

  Compare this to the doc:
  
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-networkscripts-interfaces.html

   IPV6ADDR=address
  where address is the first static, or primary, IPv6 address on an 
interface.
  The format is Address/Prefix-length. If no prefix length is specified, 
/64 is assumed. Note that this setting depends on IPV6INIT being enabled.

  NETMASK is a parameter for ipv4.

   NETMASKn=mask
  where mask is the netmask value and the n is expected to be consecutive 
positive integers starting from 0 (for example, NETMASK0). It is used for 
configurations with multiple IP addresses on an interface. It can be omitted if 
there is only one address being configured.

  The tests are also incomplete, lacking several scenarios.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1685532/+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 1685935] Re: make deb breaks due to missing debuild script

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1685935

Title:
  make deb breaks due to missing debuild script

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  New
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]
  Minor tweak to Makefile target make deb to announce missing devscripts 
package dependency in developer environments.

  [Test Case]
  No test case as this Makefile and related bddeb script are developer tools 
and aren't part of cloud-init deb package.

  [Regression Potential]
  None
  [Other Info]

  === End SRU Template ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1685935/+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 1692093] Re: Cloud init is re-executing fs and disk setup during reboot

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1692093

Title:
  Cloud init is re-executing fs and disk setup during reboot

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]
  VMs on MS Azure have an ephemeral disk attached to them.
  On first boot, cloud-init properly notices the empty ntfs filesystem and
  reformats it ext4.

  After deallocating the instance or moving to a new azure host,
  the filesystem reformat is logged, but isn't actually performed because
  the udev device creation may not have settled.

  [Test Case]
  Test cases:
   1. Deploy an instance VM on Azure
   2. Log in and ensure that the ephemeral disk is formatted and mounted to /mnt
   3. Via the portal you can "Redeploy" the VM to a new Azure Host (or 
alternatively stop and deallocate the VM for some time, and then 
restart/reallocate the VM).

  Expected Results:a
   - Check cloud-init.log expecting to see logs from cc_disk_setup about the 
mount.
   - After reallocation we expect the ephemeral disk to be formatted and 
mounted to /mnt.

  Actual Results:
   - After reallocation /mnt is not mounted and there are errors in the 
cloud-init log.

  [Regression Potential]
  Regression potential should be extremely low on this change.
  Essentially the change was to add the function 'assert_and_settle_device' and
  then to use it.  See the commit linked below.

  The most likely regression is just slower boot.  The most likely
  unexpected change in behavior is getting a RunTimeError due to
  'assert_and_settle_device' realizing that there is no device present.
  That would have ultimately just resulted in a different error with
  less obvious error message.

  [Other Info]
  Upstream commit at
    
https://git.launchpad.net/cloud-init/commit/?id=1815c6d801933c47a01f1a94a8e689824f6797b4

  === End SRU Template ===

  Cloud Provider: Azure
  dpkg-query -W -f='${Version}' cloud-init output: 
0.7.9-90-g61eb03fe-0ubuntu1~16.04.1

  When the following is specified in cloud init it seems to be re-executing fs 
and disk setup (even though run command does not seem to re run)
  disk_setup:
    /dev/sdc:
    table_type: gpt
    layout: true
    overwrite: false

  fs_setup:
  - label: etcd_disk
    filesystem: ext4
    device: /dev/sdc1
    extra_opts:
  - "-F"
  - "-E"
  - "lazy_itable_init=1,lazy_journal_init=1"

  mounts:
  - - /dev/sdc1
    - /var/lib/etcddisk

  From cloud-init-output.log:

  Cloud-init v. 0.7.9 running 'modules:final' at Mon, 15 May 2017 18:33:15 
+. Up 64.24 seconds.
  Cloud-init v. 0.7.9 finished at Mon, 15 May 2017 18:34:46 +. Datasource 
DataSourceAzureNet [seed=/dev/sr0].  Up 155.34 seconds
  Cloud-init v. 0.7.9 running 'init-local' at Tue, 16 May 2017 01:52:37 +. 
Up 10.33 seconds.
  Cloud-init v. 0.7.9 running 'init' at Tue, 16 May 2017 01:52:39 +. Up 
12.06 seconds.

  From cloud-init.log for the initial provision:

  2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]: Creating file system 
etcd_disk on /dev/sdc1
  2017-05-15 18:32:46,820 - cc_disk_setup.py[DEBUG]:  Using cmd: 
/sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E 
lazy_itable_init=1,lazy_journal_init=1
  2017-05-15 18:32:46,820 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', 
'/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 
'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] 
(shell=False, capture=True)
  2017-05-15 18:33:04,054 - util.py[DEBUG]: Creating fs for /dev/sdc1 took 
17.237 seconds

  and after reboot (cloud-init.log)

  2017-05-16 01:52:40,245 - cc_disk_setup.py[DEBUG]: Creating file system 
etcd_disk on /dev/sdc1
  2017-05-16 01:52:40,246 - cc_disk_setup.py[DEBUG]:  Using cmd: 
/sbin/mkfs.ext4 /dev/sdc1 -L etcd_disk -F -E 
lazy_itable_init=1,lazy_journal_init=1
  2017-05-16 01:52:40,246 - util.py[DEBUG]: Running command ['/sbin/mkfs.ext4', 
'/dev/sdc1', '-L', 'etcd_disk', '-F', '-E', 
'lazy_itable_init=1,lazy_journal_init=1'] with allowed return codes [0] 
(shell=False, capture=True)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1692093/+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 1718640] Re: systemd and config template expansion fail for SUSE distros

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: cloud-init
   Status: In Progress => 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/1718640

Title:
  systemd and config template expansion fail for SUSE distros

Status in cloud-init:
  Fix Released

Bug description:
  During install template expansion for SUSE distributions fails for
  config and systemd templates.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1718640/+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 1710932] Re: Doesn't configure landscape client on py3

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1710932

Title:
  Doesn't configure landscape client on py3

Status in cloud-init:
  Fix Released

Bug description:
  Attempting to configure landscape-client on a py3 system falls over
  due to string/byte-string conversion issues

  Here's a sample run from MAAS:

  2017-08-15 17:58:11,883 - util.py[DEBUG]: Running module landscape () failed
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 793, in 
_run_modules
  freq=freq)
    File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
    File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
    File "/usr/lib/python3/dist-packages/cloudinit/config/cc_landscape.py", 
line 113, in handle
  merged.write(contents)
    File "/usr/lib/python3/dist-packages/configobj.py", line 2126, in write
  outfile.write(output_bytes)
  TypeError: string argument expected, got 'bytes'

  ubuntu@withkvm:/etc/landscape$ cat 
/etc/cloud/cloud.cfg.d/99_landscape_client.cfg
  landscape:
    client:
  url: "https://192.168.122.1/message-system;
  ping_url: "http://192.168.122.1/ping;
  data_path: "/var/lib/landscape/client"
  #http_proxy: "http://my.proxy.com/foobar;
  tags: "maas"
  computer_title: withkvm
  #https_proxy: fooproxy
  registration_key: test
  account_name: standalone

  Ryan validated py3 falling over just on basic ConfigObj.write() attempts:
  (foudres) ~ % python3
  Python 3.5.2 (default, Nov 17 2016, 17:05:23)
  [GCC 5.4.0 20160609] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from configobj import ConfigObj
  >>> from six import StringIO
  >>> contents = StringIO()
  >>> merged = cfg = ConfigObj({})
  >>> merged
  ConfigObj({})
  >>> cfg.merge({'a': 1})
  >>> cfg
  ConfigObj({'a': 1})
  >>> type(contents)
  
  >>> merged.write(contents)
  Traceback (most recent call last):
    File "", line 1, in 
    File "/usr/lib/python3/dist-packages/configobj.py", line 2126, in write
  outfile.write(output_bytes)
  TypeError: string argument expected, got 'bytes'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1710932/+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 1717611] Re: Azure: Azure datasource needs to wait longer for SSH pubkey to be dropped by waagent

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1717611

Title:
  Azure: Azure datasource needs to wait longer for SSH pubkey to be
  dropped by waagent

Status in cloud-init:
  Fix Released

Bug description:
  In Azure SSH pubkeys are transported in a certificate through the wireserver 
protocol. When cloud-init is configured to use waagent, which is the current 
default, cloud-init will wait maxwait=60 seconds for waagent to drop the .crt 
files corresponding to the fingerprint that was mentioned in the ovf-env.xml.
  We've had a couple of cases where the wireserver was flaky from more than 1 
minute during provisioning which yielded a user without password or keys. These 
VM's are not usable without further action, we would rather have cloud-init 
wait forever for these .crt files to be provided. Azure VM provisioning will 
timeout and kill the VM when provisioning takes too long.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1717611/+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 1717627] Re: permission denied when executing dhclient in Ec2 datasource

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1717627

Title:
  permission denied when executing dhclient in Ec2 datasource

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

Bug description:
  in the ec2 datasource, cloud-init runs dhclient from a tmp file in
  order to avoid apparmor restrictions and side affects.

  In a change for bug 1707222 we started using /run/cloud-init for tmpfiles.
  /run is mounted noexec.  See example:

  $ sudo /run/cloud-init/tmp/dhclient -1 -v -lf 
/run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhcp.leases -pf 
/run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhclient.pid eth0 -sf /bin/true
  sudo: unable to execute /run/cloud-init/tmp/dhclient: Permission denied

  So, we need a tmp file in a place that allows execution.

  Related bugs:
   * bug 1709772: Enable ipv6 support on EC2
   * bug 1707222: usage of /tmp during boot is not safe may get files deleted.
   * bug 1717627: permission denied executing dhclient from /run

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1717627/+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 1709761] Re: Add cloudinit-analyze reporting to cloudinit proper

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1709761

Title:
  Add cloudinit-analyze reporting to cloudinit proper

Status in cloud-init:
  Fix Released

Bug description:
  Pull in functionality from Ryan Harper's
  https://git.launchpad.net/~raharper/+git/cloudinit-analyze  into
  cloudinit proper so that this tooling can be leveraged more easily by
  any cloud-init consumer.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1709761/+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 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

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

Bug description:
  [Impact]

   * When vlan interfaces are created, their mac address is copied from
  the underlying interface, but it is not marked by kernel as stolen.

   * When underlying interface MAC address is changed, it does not
  propagate to the vlan interfaces.

  [Test Case]

   * Create vlan interface, check the addr_assign_type sysfs attribute,
  it should be 2, not 0.

   * Update the base interface mac address, the mac address of the vlan
  interface should change too.

   * cloud-init test case

  
  
  wget 
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/get-proposed-cloudimg;
  chmod 755 get-proposed-cloudimg;

  for release in xenial yakkety zesty; do
./get-proposed-cloudimg $release;
MODE=vlan ./btest-launch.sh $release-server-cloudimg-amd64-proposed.img 
;
# ubuntu/passw0rd
python3 -c 'from cloudinit.net import get_interfaces_by_mac; 
print(get_interfaces_by_mac())'; # results in no runtime error and doesn't 
report vlan interface name
  done
   


  
  [Regression Potential]

   * Userspace may rely on non-propagating MAC addresses, and the fact
  that vlan mac address type is wrongly stated as non-stolen; however
  this behaviour will be consistent with 4.7+ kernels.

  [Other Info]

   * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into
  v4.4 kernels

  commit 308453aa9156a3b8ee382c0949befb507a32b0c1
  Author: Mike Manning 
  Date:   Fri May 27 17:45:07 2016 +0100

  vlan: Propagate MAC address to VLANs

  The MAC address of the physical interface is only copied to the VLAN
  when it is first created, resulting in an inconsistency after MAC
  address changes of only newly created VLANs having an up-to-date MAC.

  The VLANs should continue inheriting the MAC address of the physical
  interface until the VLAN MAC address is explicitly set to any value.
  This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
  to the MAC of the physical interface and thus for DAD to behave as
  expected.

  Signed-off-by: Mike Manning 
  Signed-off-by: David S. Miller 

   * Original bug report

  When attempting to verify sru for bug 1669860, I found that vlans
  are not properly filtered out by 'get_interfaces_by_mac'.  That means
  that the bug is still present with vlans.

  The reason for this is that /sys/class/net//addr_assign_type
  shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
  See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  for doc on addr_assign_type.

  Related bugs:
   * bug 1669860: cloud-init attempts to rename bonds

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1682871/+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 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1693361

Title:
  cloud-init sometimes fails on dpkg lock due to concurrent apt-
  daily.service execution

Status in APT:
  Confirmed
Status in cloud-init:
  Fix Released
Status in apt package in Ubuntu:
  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:
  Won't Fix
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  A cloud-config that contains packages to install (see below) or
  'package_upgrade' will run 'apt-get update'.  That can sometimes fail as a
  result of contention with the apt-daily.service that updates that information.

  Cloud-config showing the problem is just like:

    $ cat my.yaml
    #cloud-config
    packages: ['hello']

  [Test Case]
  lxc-proposed-snapshot is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  a.) launch an instance with proposed version of cloud-init and some user-data.
     This is platform independent.  The test case demonstrates lxd.
     $ printf "%s\n%s\n%s\n" "#cloud-config" "packages: ['hello']" \
     "package_upgrade: true" > config.yaml
     $ release=xenial
     $ ref=proposed-$release
     $ ./lxc-proposed-snapshot --proposed --publish $release $ref;

  b.) start the instance
     $ name=$release-1693361
     $ lxc launch my-xenial "--config=user.user-data=$(cat config.yaml)
     $ sleep 1
     $ lxc exec $name -- tail -f /var/log/cloud-init.log 
/var/log/cloud-init-output.log
     # watch this boot.

   c.) Look for evidence of systemd failure
     journalctl -o short-precise | grep -i break
     journalctl -o short-precise | grep -i order

  [Regression Potential]
  Regression chance here is low.  Its possible that ordering loops
  could occur.  When that does happen, journalctl will mention it.  
Unfortunately
  in such cases systemd somewhat randomly picks a service to kil so behavior
  is somewhat undefined.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=11121fe4

  === End SRU Template ===

  apt-daily is now a systemd service rather than being invoked by
  cron.daily.  If one builds a custom AMI it is possible that the apt-
  daily.timer will fire during boot.  This can fire at the same time
  cloud-init is running and if cloud-init loses the race the invocation
  of apt (e.g. use of "packages:" in the config) will fail.

  There is a lot of discussion online about this change to apt-daily
  (e.g. unattended upgrades happening during business hours, delaying
  boot, etc.) and discussion of potential systemd changes regarding
  timers firing during boot (c.f.
  https://github.com/systemd/systemd/issues/5659).

  While it would be better to solve this in apt itself, I suggest that
  cloud-init be defensive when calling apt and implement some retry
  mechanism.

  Various instances of people running into this issue:

  https://github.com/chef/bento/issues/609
  https://clusterhq.atlassian.net/browse/FLOC-4486
  https://github.com/boxcutter/ubuntu/issues/73
  
https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image

To manage notifications about this bug go to:
https://bugs.launchpad.net/apt/+bug/1693361/+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 1692028] Re: duplicate mac address during config-drive configuration with LXD container on openstack

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1692028

Title:
  duplicate mac address during config-drive configuration with LXD
  container on openstack

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

Bug description:
  === Begin SRU Template ===
  [Impact] 
  When the 'ip_gre' module is loaded, the kernel creates two network
  devices 'gre0' and 'gretap0' that appear in all network namespaces.
  (For example, if you create an lxd container, and then load the ip_gre
  module from outside the container, the container will see 2 new
  network devices).
  The hardware address of these devices is 00:00:00:00:00 as seen below.
 # ( cd /sys/class/net/ && grep . gre*/address )
 gre0/address:00:00:00:00
 gretap0/address:00:00:00:00:00:00

  This "duplicate" mac address caused cloud-init to raise a
  RuntimeError.

  The overall impact is that cloudinit's network rendering code will
  not work if the ip_gre module is loaded on the system.  That will
  happen in some nova-lxd environments, but also anywhere where a user
  has loaded that module and is running lxc.

  [Test Case]

  1.) load a module on your host
  sudo modprobe ip_gre

  2.) Launch an instance in lxd.

   $ rel=xenial
   $ name=x1
   $ lxc launch ubuntu-daily:$rel $name

  3.) see the stack trace by running 'get_interfaces_by_mac()' in the
  guest.

   $ lxc exec $name -- \
   python3 -c 'from cloudinit import net; 
print(net.get_interfaces_by_mac())'

  4.) upgrade instance to proposed cloud-init
   $ lxc exec $name -- sh -c '
  mirror=http://archive.ubuntu.com/ubuntu
  echo deb $mirror $(lsb_release -sc)-proposed main |
 tee /etc/apt/sources.list.d/proposed.list
  apt-get update -q
  apt-get install -qy cloud-init'
   $ lxc exec $name -- dpkg-query --show cloud-init

  5.) see that get_interfaces_by_mac() no longer stack traces.   
   $ lxc exec $name -- \
   python3 -c 'from cloudinit import net; 
print(net.get_interfaces_by_mac())'

  A more complete test case is to load an image into nova-lxd with gre
  tunneling loaded on the host, but that is much more involved setup.

  [Regression Potential] 
  Regression potential should be pretty low.  We are simply ignoring
  network interfaces not named 'lo' that have a mac address of '00:00:00:00:00'

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=2c0655feb9

  === End SRU Template ===

  Whilst testing the changes for nova-lxd to resolve issues with use of
  config-drive, I tripped over this issue; specifically the networking
  on a config-drive configured LXD instance never starts due to a
  duplicate MAC address on the lo and greptap0 devices.

  Cloud-init v. 0.7.9 running 'init' at Fri, 19 May 2017 13:41:00 +. Up 2.0 
seconds.
  ci-info: Net device 
info+
  ci-info: 
+-+---+--+---+---+-+
  ci-info: |  Device |   Up  |   Address|Mask   | Scope 
|Hw-Address   |
  ci-info: 
+-+---+--+---+---+-+
  ci-info: | gretap0 | False |  .   | . |   .   
|00:00:00:00:00:00|
  ci-info: |   eth0  |  True |  .   | . |   .   
|fa:16:3e:1d:aa:ac|
  ci-info: |   eth0  |  True | fe80::f816:3eff:fe1d:aaac/64 | . |  link 
|fa:16:3e:1d:aa:ac|
  ci-info: |lo   |  True |  127.0.0.1   | 255.0.0.0 |   .   
|.|
  ci-info: |lo   |  True |   ::1/128| . |  host 
|.|
  ci-info: |   gre0  | False |  .   | . |   .   
| 00-00-00-00-31-36-3a-33-00-00-00-00-00-00-00-00 |
  ci-info: 
+-+---+--+---+---+-+
  2017-05-19 13:41:01,017 - util.py[WARNING]: failed stage init
  failed run of stage init
  

[Yahoo-eng-team] [Bug 1691135] Re: address field not set when reading cmdline/initramfs configured network

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1691135

Title:
  address field not set when reading cmdline/initramfs configured
  network

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]
  When cloud-init sees 'ip=' on the kernel command line, it will take
  the networking configuration that is written by the ipconfig tool,
  and convert it into the proper network config for the system
  (/etc/network/interfaces).

  This works well for the 'ip=dhcp' and 'ip=dhcp6' cases, but did not
  work correctly for the "statick" path with a command line like:
 ip=:device:...

  Cloud-init would stack trace when trying to bring up this networking
  resulting in a system that did not boot properly.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, use cloud-init's net library to convert
   'net-eth1.cfg' into a different format, and the render that format
   using cloud-init's trunk tool 'net-convert.py'

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc launch $ref $name
  $ lxc exec $ref $name /bin/bash

  ## get render tool
  % wget 
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1691135/+attachment/4888001/+files/bug-1691135.sh
 -O bug-1691135.sh
  % sh ./bug-1691135.sh

  ## if that runs to completion, then it will show the /etc/network/interfaces
  ## file and the netplan etc/netplan/50-cloud-init.yaml file.
  ## if it fails it will stack trace.

  As seen in the upstream commit, the change is in a very focused path,
  only changing something when the protocol was 'static'.

  [Regression Potential]
  Potential for regression would be limited to the 'ip=' command line path.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=9d437489b

  === End SRU Template ===

  As reported by user niluje, if the initramfs tools write a config that
  has static networking, then cloud-init would not populate the address
  field in its rendered network config (_klibc_to_config_entry).

  The result would be incomplete or invalid configuration, and attempt
  to render that configuration would result in stacktrace due to
  KeyError.

  This can be seen in trunk with the net-convert tool as below.  Editing
  the yaml and uncommenting the 'address' line will work.

  $ cat /tmp/foo.yaml
  network:
    version: 1
    config:
     - name: eth1
   type: physical
   subnets:
    - 'type': 'static'
  'broadcast': '10.0.0.255'
  'control': 'manual'
  'gateway': '10.0.0.1'
  'dns_search': ['foo.com']
  'netmask': '255.255.255.0'
  'dns_nameservers': ['10.0.1.1']
  #'address': '10.0.0.2'
  EOF

  $ PYTHONPATH=$PWD ./tools/net-convert.py  --network-data=/tmp/foo.yaml 
--kind=yaml --output-kind=eni -d /tmp/out.d
  Input YAML
  config:
  -   name: eth1
  subnets:
  -   broadcast: 10.0.0.255
  control: manual
  dns_nameservers:
  - 10.0.1.1
  dns_search:
  - foo.com
  gateway: 10.0.0.1
  netmask: 255.255.255.0
  type: static
  type: physical
  version: 1

  Traceback (most recent call last):
    File "./tools/net-convert.py", line 82, in 
  main()
    File "./tools/net-convert.py", line 58, in main
  ns = network_state.parse_net_config_data(pre_ns)
    File 
"/home/smoser/src/cloud-init/cloud-init/cloudinit/net/network_state.py", line 
42, in parse_net_config_data
  nsi.parse_config(skip_broken=skip_broken)
    File 
"/home/smoser/src/cloud-init/cloud-init/cloudinit/net/network_state.py", line 
225, in parse_config
  self.parse_config_v1(skip_broken=skip_broken)
    File 
"/home/smoser/src/cloud-init/cloud-init/cloudinit/net/network_state.py", line 
240, in parse_config_v1
  handler(self, command)
    File 
"/home/smoser/src/cloud-init/cloud-init/cloudinit/net/network_state.py", line 
89, in decorator
  return func(self, command, *args, **kwargs)
    File 
"/home/smoser/src/cloud-init/cloud-init/cloudinit/net/network_state.py", line 
296, in handle_physical
  if ':' in subnet['address']:
  KeyError: 'address'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1691135/+subscriptions

-- 

[Yahoo-eng-team] [Bug 1675185] Re: cannot disable apt_configure via cloud-config

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1675185

Title:
  cannot disable apt_configure via cloud-config

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] 
  In work targeted at getting cloud-init into the Ubuntu core image,
  it was noticed that the apt_configure module would fail on Ubuntu core.
  The result was cloud-init reporting failure.

  The changes made were to return early if both:
a.) there is no 'apt' configuration provided
b.) there is no 'apt-get' command or the system is snappy.

  [Test Case]
  lxc-proposed-snapshot is 

https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref

  # launch 3 containers 
  #  release-default: no apt config, no files modified. apt_configure module 
should run.
  #  release-corepass: no apt config, look like ubuntu core. apt_configure 
should not run.
  #  release-coreapt: apt config, look like ubuntu core. apt_configure should 
run (and will succeed because this is not core)

  $ apt_cfg=$(printf "#cloud-config\n%s\n" 'apt: {sources: {citest: {source: 
"ppa:cloud-init-dev/test-archive"}}}')
  $ lxc init $ref $release-default "--config=user.user-data=$apt_cfg"
  $ lxc init $ref $release-coreapt "--config=user.user-data=$apt_cfg"
  $ lxc init $ref $release-corepass

  # create a file that makes cloud-init assume this is core.
  $ for n in $release-coreapt $release-corepass; do
 echo ubuntu-core | lxc file push --create-dirs - 
$n/etc/system-image/channel.ini; done

  # do not lock default user's passwd (LP: #1679765)
  $ for n in $names; do
 echo "system_info:  {default_user: {lock_passwd: False}}" |
   lxc file push - $n/etc/cloud/cloud.cfg.d/99-nolock-passwd.cfg; done
  # populate /var/lib/extrausers so that adduser --extrausers works.
  $ for n in $names; do
 for f in passwd group gshadow subuid subgid shadow; do lxc file push 
--create-dirs - $n/var/lib/extrausers/$f https://bugs.launchpad.net/cloud-init/+bug/1675185/+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 1715690] Re: Defining distros = 'all' in a module for documentation results in a module skip as 'all' doesn't match distro 'x'

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1715690

Title:
  Defining distros = 'all' in a module for documentation results in a
  module skip as 'all' doesn't match distro 'x'

Status in cloud-init:
  Fix Released

Bug description:
  2017-09-07 06:03:25,838 - stages.py[INFO]: Skipping modules ['runcmd']
  because they are not verified on distro 'ubuntu'.  To run anyway, add
  them to 'unverified_modules' in config.

  Seen after introduction of distros attribute on cc_runcmd.py in
  revision cc9762a2d737ead386ffb9f067adc5e543224560

  Also validated that Skipping a module is only a log, the module is
  still run:

  # later in the same log
  Running module runcmd () with frequency 
once-per-instance

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1715690/+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 1712676] Re: Cloud-init analyzeand devel commandline traceback

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1712676

Title:
  Cloud-init analyzeand devel  commandline traceback

Status in cloud-init:
  Fix Released

Bug description:
  Calling cloud-init analyze from the command line  results in a
  traceback due to the argument parser not properly setting up subparser
  default behavior.

  
  $ cloud-init devel
  Traceback (most recent call last):
File "/usr/bin/cloud-init", line 9, in 
  load_entry_point('cloud-init==0.7.9', 'console_scripts', 'cloud-init')()
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 784, in 
main
  (name, functor) = args.action
  AttributeError: 'Namespace' object has no attribute 'action'

  
  $ cloud-init analyze

  # But direct python module calls work

  $ python3 -m cloudinit.cmd.main devel
  usage: /usr/lib/python3/dist-packages/cloudinit/cmd/main.py analyze
 [-h] {blame,show,dump} ...
  /usr/lib/python3/dist-packages/cloudinit/cmd/main.py analyze: error: the 
following arguments are required: subcommand

  
  $ python3 -m cloudinit.cmd.main analyze
  usage: /usr/lib/python3/dist-packages/cloudinit/cmd/main.py analyze
 [-h] {blame,show,dump} ...
  /usr/lib/python3/dist-packages/cloudinit/cmd/main.py analyze: error: the 
following arguments are required: subcommand

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1712676/+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 1693939] Re: Switch Azure detection to use chassis_asset_tag

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1693939

Title:
  Switch Azure detection to use chassis_asset_tag

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

Bug description:
  === Begin SRU Template ===
  [Impact]
  Azure identifies itself to guests by setting a well known value in the 
chassis asset field of dmi data.  This is done both in Azure public cloud and 
in Azure Stack (the on-premise variant of Azure).

  By checking for this value cloud-init can more quickly identify
  whether or not it is running on Azure.

  [Test Case]
   - Launch an instance, enable proposed, upgrade.
   - Clean instance and re-boot
     $ rm -Rf /var/lib/cloud /var/log/cloud-init*
     $ rm -f /etc/cloud/cloud.cfg.d/91_walinuxagent.cfg  # bug 1700769
     $ reboot

   - ssh back in look around
     - confirm 'WARN' does not appear in /var/log/cloud-init*
     - look in /run/cloud-init/ds-identify.log.  It should say:
    Found single datasource: Azure

   - reboot, ssh back in and verify all still good.

  [Regression Potential]
  Instances running in Azure or Azure Stack that did *not* have this value
  would not be identified as Azure.  We have been told by representatives
  from Microsoft that that will not be the case.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=5fb49bac

  === End SRU Template ===

  I've got confirmation that the chassis_asset_tag DMI value is a hard-
  coded identifier for the Azure platform (both Azure and Azure Stack
  (the on-premise variant of Azure)).

  $ cat /sys/class/dmi/id/chassis_asset_tag
  7783-7084-3265-9085-8269-3286-77

  The detection logic in both ds-identify and Azure ds should be updated
  to use this value.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1693939/+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 1689944] Re: util.system_is_snappy needs additional checks

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1689944

Title:
  util.system_is_snappy needs additional checks

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]
  Cloud-init when running in Ubuntu core does not recognize it is
  running on a 'snappy.  As a result the snappy specific code paths are not
  taken.

  [Test Case]
  There are fairly extensive unit tests added to cover the code path
  that has been added to detect when system is snappy.  See the upstream
  commit link below for that.  Those tests run on package build, so
  the fact that this is in the archive means those have run.

  In addition to that we will:
  a.) boot an instance of Ubuntu in lxd with cloud-init from proposed
  to verify it is not regressed.
  b.) craft an lxd instance with /etc/os-release that appears to be snappy.
  and then verify via log inspection that it thinks it is.

  The test is admittedly superficial, the real end test is having cloud-init
  inside a ubuntu core image and it recognizing that it is snappy there.
  That test is much more involved.

  ## launch an instance
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc launch $ref $name
  $ lxc exec $name

  ## let it boot
  $ sleep 10
  ## check log for warnings
  $ lxc exec $name -- cat /run/cloud-init/result.json
  {
   "v1": {
"datasource": "DataSourceNoCloud 
[seed=/var/lib/cloud/seed/nocloud-net][dsmode=net]",
"errors": []
   }
  }

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

  
  ## write to /etc/os-release so it thinks it is Ubuntu core.
  $ lxc exec $name -- sh -c 'echo ID=ubuntu-core >> /etc/os-release'
  $ lxc exec $name -- sh -c 'd=/etc/system-image; mkdir -p $d; cd $d; echo 
ubuntu-core > channel.ini'

  ## Now clear the instance state so it thinks it is first boot.
  $ lxc exec $name -- sh -c 'rm -Rf /var/log/cloud-init*'
  $ lxc exec $name -- sh -xec 'cd /var/lib/cloud; mv seed .x; rm -Rf *; mv .x 
seed'
  + cd /var/lib/cloud
  + mv seed .x
  + rm -Rf data handlers instance instances scripts sem
  + mv .x seed

  $ lxc restart $name
  $ sleep 10
  $ lxc exec $name -- grep "running on snappy" /var/log/cloud-init.log
  2017-06-01 20:53:24,346 - cc_apt_configure.py[DEBUG]: Nothing to do: No apt 
config and running on snappy

  [Regression Potential] 
  The regression potential would be
  a.) cloud-init falsely identifies it is running on snappy when it is not.
  b.) cloud-init does not recognize it is on snappy when it is.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=4bcc947301b

  lxc-proposed-snapshot is

https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  === End SRU Template ===

  Recent core snap images (edge channel revision 1886) do not contain
  the previously known files used to detect that a system is ubuntu
  core.

  In this bug, we should collect as many known paths/files/commands so
  we're hopefully defensive against further changes.

  Ubuntu Core 16
  --
  % cat etc/os-release
  NAME="Ubuntu Core"
  VERSION="16"
  ID=ubuntu-core
  PRETTY_NAME="Ubuntu Core 16"
  VERSION_ID="16"
  HOME_URL="http://www.snapcraft.io/;
  BUG_REPORT_URL="http://bugs.launchpad.net/snappy/;

  % snap version
  snap2.24+201704201952.git.2ba71ec~ubuntu16.04.1
  snapd   2.24+201704201952.git.2ba71ec~ubuntu16.04.1
  series  16
  kernel  4.4.0-59-generic

  % lsb_release -rd
  bash: lsb_release: command not found

  % test -e /writable/system-data/var/lib/snapd; echo $?
  0

  Ubuntu 16.04 (Classic)
  ---
   % cat /etc/os-release
  NAME="Ubuntu"
  VERSION="16.04.2 LTS (Xenial Xerus)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 16.04.2 LTS"
  VERSION_ID="16.04"
  HOME_URL="http://www.ubuntu.com/;
  SUPPORT_URL="http://help.ubuntu.com/;
  BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/;
  VERSION_CODENAME=xenial
  UBUNTU_CODENAME=xenial

  % snap version
  snapunknown
  snapd   2.24.1
  series  16
  ubuntu  16.04
  kernel  4.4.0-75-generic

  % lsb_release -rd
  Description:  Ubuntu 16.04.2 LTS
  Release:  16.04

  % test -e /writable/system-data/var/lib/snapd; echo $?
  1

To manage notifications about this 

[Yahoo-eng-team] [Bug 1715241] Re: ds-identify openstack returns not found on non-intel

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1715241

Title:
  ds-identify openstack returns not found on non-intel

Status in cloud-init:
  Fix Released

Bug description:
  on non-intel arch, ds-identify will not identify openstack.
  Arches other than intel do not properly identify themselves in nova.

  See bugs file with 'dsid-nova' for individual tracking bugs.

   https://bugs.launchpad.net/cloud-init/+bugs?field.tag=dsid-nova

  The needed change is to make openstack's search return MAYBE on arch
  other than intel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1715241/+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 1693582] Re: cloud-init uses a deprecated metadata path for GCE instance SSH keys

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1693582

Title:
  cloud-init uses a deprecated metadata path for GCE instance SSH keys

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]
  This code path is only exercised on GCE datasources and in such cases get_data
  would have not configured GCE-configured authorized ssh keys for the default 
user.

  [Test Case]
  Launch an instance on GCE
  Update cloud-init deb
  run sudo cloud-init single -n cc_ntp
  curl -H "Metadata-Flavor: Google" 
http://metadata.google.internal/computeMetadata/v1/instance/attributes/ssh-keys
  validate .ssh/authorized_keys contains keys listed in the above curl

  [Regression Potential]
  GCE instances which don't support instance/attributes/ssh-keys would only be 
able
  to configure ssh access via #cloud-config ssh declarations.

  [Other Info]
  Upstream commit:
   
https://git.launchpad.net/cloud-init/commit/?id=d27c49391df343d25bd2e24045d2be6bf39c30d2
  GCE metadata docs:
   https://cloud.google.com/compute/docs/storing-retrieving-metadata

  === End SRU Template ===
  ~

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1693582/+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 1709772] Re: EC2 datasource moved to init-local stage

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1709772

Title:
  EC2 datasource moved to init-local stage

Status in cloud-init:
  Fix Released

Bug description:
  In EC2 clouds, the only way to determine whether an instance is
  configured for IPv6 is by querying the metadata service. In order to
  query metadata to determine network configuration, DataSourceEc2 needs
  to configure the network with dhcp and then query the datasource.

  Add optional functionality for DataSourceEc2 to query metatadata
  sevice in init-local timeframe using dhcp.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1709772/+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 1709180] Re: cloud-init v2 yaml doesn't preserve bond/bridge parameters when rendering

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1709180

Title:
  cloud-init v2 yaml doesn't preserve bond/bridge parameters when
  rendering

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init/master:

  % cat bonding.yaml
  network:
version: 2
ethernets:
  eth0:
match:
  macaddress: 52:54:00:12:34:00
  driver: virtio
set-name: eth0
  ens4:
match:
  macaddress: 52:54:00:12:34:02 
  driver: e1000
set-name: ens4
bonds:
  bond0:
interfaces: [eth0, ens4]
parameters:
  mode: active-backup
  mii-monitor-interval: 100
dhcp4: true

  Should result in a netplan yaml of:

  network:
  version: 2
  ethernets:
  ens4:
  match:
  macaddress: '52:54:00:12:34:02'
  set-name: ens4
  eth0:
  match:
  macaddress: '52:54:00:12:34:00'
  set-name: eth0
  bonds:
  bond0:
  dhcp4: true
  interfaces:
  - ens4
  - eth0
  parameters:
  mii-monitor-interval: 100
  mode: active-backup

  Multiple issues:

  1) the common bond/bridge handler needs to call the right _handle
  function depending on the command type (bond or bridge)

  2) network_state needs to translate v2 'parameters' key to v1 since we
  utilize the v1 type handlers

  3) the v2 handle_ethernets fails to set the v1 'mac_address' property
  which prevents v2 match/set-name from getting rendered

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1709180/+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 1714117] Re: unittests: ec2 tests escape to network

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1714117

Title:
  unittests: ec2 tests escape to network

Status in cloud-init:
  Fix Released

Bug description:
  On Aug 10, 2017 the nightly and CI tests began taking 20 additional
  minutes. The additional time is occurring during the tox run,
  specifically during the 'py27' and 'xenial' environments. Here are
  comparisons of run times:

  Aug 8: 1 min 52 seconds
  Aug 9: 1 min 47 seconds
  Aug 10: 19 mins

  These tests are run at ~23:40 UTC each day, therefore a change would
  have occurred during the day resulting in the end-of-day run to see
  the effect.

  From the Aug 10 run these two tox environments are adding a huge amount of 
time:
  py27: Ran 980 tests in 525.871s
  xenial: Ran 980 tests in 518.678s

  Here are timing results from the Aug 9 run:
  py27: Ran 978 tests in 9.051s
  xenial: Ran 978 tests in 14.122s

  Per the git log I believe it is tied to this revision:
  
https://git.launchpad.net/cloud-init/commit/?id=d5f855dd96ccbea77f61b0515b574ad2c43d116d

  Which added two new tests:
  test_ec2_local_returns_false_on_bsd
  test_ec2_local_performs_dhcp_on_non_bsd
  hence the increase the number of tests run. I am not however, saying that 
these two tests are the cause of the additional test time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1714117/+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 1692794] Re: Add loghandler helper to unitests

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1692794

Title:
  Add loghandler helper to unitests

Status in cloud-init:
  Fix Released

Bug description:
  We need a simple facility for unit tests to inspect and assert on
  logging which is generated by the test runs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1692794/+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 1714376] Re: unittests: OpenStack DS escape or timeout

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: cloud-init
   Status: In Progress => 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/1714376

Title:
  unittests: OpenStack DS escape or timeout

Status in cloud-init:
  Fix Released

Bug description:
  Similar to LP: #1714117, there appears to be a pair of tests that are
  escaping and timing out, resulting in extra time that is not required
  for the unit tests:

  
tests.unittests.test_datasource.test_openstack.TestOpenStackDataSource.test_datasource
  
tests.unittests.test_datasource.test_openstack.TestOpenStackDataSource.test_bad_datasource_meta

  Here are the raw results and methodology:
  Python 2 results: https://paste.ubuntu.com/25441590/
  Python 3 results: https://paste.ubuntu.com/25441592/

  $ git clone https://git.launchpad.net/cloud-init
  $ cd cloud-init
  # pip[3] install --user -r requirements.txt -r test-requirements.txt 
nose-timer
  $ python[3] -m nose --with-timer --timer-ok 1 --timer-warning 1 --timer-top-n 
10 tests/unittests

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1714376/+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 1701325] Re: attempt to read dmi data can cause warning and stacktrace in logs in a container.

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1701325

Title:
  attempt to read dmi data can cause warning and stacktrace in logs in a
  container.

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 Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  lxc containers would show warnings in /var/log/cloud-init.log.
  This was because attempts were made to read dmi information from
  inside the (unpriviledged) container.  Such attempts to read
  dmi data like /sys/class/dmi/id/product_serial would then result
  in an attempt to run dmidecode which would also fail.

  [Test Case]
  To test this, simply
  a.) create an lxd instance from a image with -proposed version of cloud-init
 $ release=xenial
 $ ref=$release-1701325
 $ lxc-proposed-snapshot --proposed --publish $release $ref
 $ lxc launch $ref $name
  b.) lxc exec $name -- grep WARN /var/log/cloud-init.log

  [Regression Potential]
  A regression caused by this change is possible on some system where
  systemd identified the system as a container but the container platform 
provided
  simulated/virtualized dmi information in /sys/class/dmi/id.

  The check for for container is done with:
systemd-detect-virt --quite --container

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=4d9f24f5c3

  This was actually a regression of the upstream fix for bug 1691772.
  That never entered a stable Ubuntu release.  The testing here is
  actually a test against regression.
  The upstream commit for that change is at
https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da

  lxc-proposed-snapshot is

https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.
  === End SRU Template ===

  
  I launched an instance of artful.
  Looked in /var/log/cloud-init.log and saw:
  2017-06-29 16:00:15,222 - util.py[DEBUG]: Reading from 
/sys/class/dmi/id/product_serial (quiet=False)
  2017-06-29 16:00:15,222 - util.py[WARNING]: failed read of 
/sys/class/dmi/id/product_serial
  2017-06-29 16:00:15,223 - util.py[DEBUG]: failed read of 
/sys/class/dmi/id/product_serial
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2359, in 
_read_dmi_syspath
  key_data = load_file(dmi_key_path, decode=False)
    File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1283, in 
load_file
  with open(fname, 'rb') as ifh:
  PermissionError: [Errno 13] Permission denied: 
'/sys/class/dmi/id/product_serial'
  2017-06-29 16:00:15,225 - util.py[DEBUG]: Running command 
['/usr/sbin/dmidecode', '--string', 'system-serial-number'] with allowed return 
codes [0] (shell=False, capture=True)
  2017-06-29 16:00:15,228 - util.py[DEBUG]: failed dmidecode cmd: 
['/usr/sbin/dmidecode', '--string', 'system-serial-number']
  Unexpected error while running command.
  Command: ['/usr/sbin/dmidecode', '--string', 'system-serial-number']
  Exit code: 1
  Reason: -
  Stdout: -
  Stderr: /sys/firmware/dmi/tables/smbios_entry_point: Permission denied
  /dev/mem: No such file or directory

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: cloud-init 0.7.9-197-gebc9ecbc-0ubuntu1
  ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15
  Uname: Linux 4.10.0-22-generic x86_64
  ApportVersion: 2.20.5-0ubuntu5
  Architecture: amd64
  Date: Thu Jun 29 16:47:51 2017
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: cloud-init
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701325/+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 1713158] Re: cloud-init.log message do not contain timezone offset info and thus may appear to go backwards

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1713158

Title:
  cloud-init.log message do not contain timezone offset info and thus
  may appear to go backwards

Status in cloud-init:
  Fix Released

Bug description:
  the logging info in /var/log/cloud-init.log does not include a
  timezone offset:

  2017-08-23 19:11:08,115 - util.py[DEBUG]: Attempting to remove
  /var/lib/cloud/instance

  
  that causes a problem when cloud-init applies the timezone during boot it can 
appear
  to jump forward or backward.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1713158/+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 1691772] Re: provide a way to seed NoCloud from network without image modification.

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1691772

Title:
  provide a way to seed NoCloud from network without image modification.

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 Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  In bug 1660385, we made imitating the EC2 datasource more difficult.
  By design, that broke some users or platforms who have done so in the past.

  The change here gives users who were using the Ubuntu images in a low-tech
  "No Cloud" fashion an easier way to regain that functionality.

  The solution was to read the 'system-serial-number' field in DMI data and
  consider it as as input to the nocloud datasource in a similar way to
  what we had done in the past with the kernel command line.

  [Test Case]
  a.) download a cloud image, update its cloud-init

 # see below for 'get-proposed-cloudimg'
 $ release=xenial
 $ get-proposed-cloudimg $release

  b.) boot that image with command line pointing at a 'seed'

 $ img=${release}-server-cloudimg-amd64-proposed.img
 # url has to provide '/user-data' and '/meta-data'
 $ 
url=https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/
 $ qemu-system-x86_64 -snapshot -enable-kvm -m 512 \
-device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 \
-drive "file=$img,if=virtio" \
-smbios "type=1,serial=ds=nocloud-net;seedfrom=$url" \
-nographic

 # note,  you can hit 'ctrl-a c' to toggle between the qemu monitor
 # and the serial console in '-nographic' mode.

  c.) Log in with 'ubuntu:passw0rd' and check hostname.
 If the above url was correctly used, then:
   * you can log in with 'ubuntu:passw0rd'
   * the hostname will be set to 'nocloud-guest'
   * /run/cloud-init/result.json will show that the url has been used.

 ubuntu@nocloud-guest:~$ hostname
 nocloud-guest
 ubuntu@nocloud-guest$ cat /run/cloud-init/result.json
 {
  "v1": {
   "datasource": "DataSourceNoCloudNet 
[seed=dmi,https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/][dsmode=net];,
   "errors": []
  }
 }

  [Regression Potential]
  The code attempts to parse the 'system-serial-number' entry in dmi data as a
  string with data in it.  If that field had the string 'ds=nocloud' that was
  not intended as consumable for cloud-init, a false positive could occur and
  an exception cause the NoCloud datasource to not read data from another
  location.

  This seems somewhat unlikely and other paths should result in simply no
  new action being taken.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8

  get-proposed-cloudimg is available at [1], it basically downloads an
  ubuntu cloud image, enables -proposed and upgrade/installs cloud-init.

  --
  [1] 
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/get-proposed-cloudimg

  === End SRU Template ===

  
  Vladimir suggested this in bug 1660385 comment 12 [1].
  The idea would be to have a supported way that you could seed images with 
cloud-init using Nocloud without any tinkering in the image.  That would mean
   a.) no second block device
   b.) no usage of kernel command line.

  --
  [1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1691772/+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 1692916] Re: Cloudinit modules should provide schema validation to better alert consumers to unsupported config

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1692916

Title:
  Cloudinit modules should provide schema validation to better alert
  consumers to unsupported config

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 Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  New feature to validate and log invalid schema warnings from cc_ntp 
cloud-config module.

  [Test Case]
  if [ ! -f lxc-proposed-snapshot ]; then
    wget 
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/lxc-proposed-snapshot
    chmod 755 lxc-proposed-snapshot
  fi

  cat < valid.conf
  #cloud-config
  ntp:
  EOF
  cat < invalid.conf
  #cloud-config
  ntp: -1
  EOF
  for release in xenial zesty; do
  ref=$release-proposed;
  echo "$release START --";
  ./lxc-proposed-snapshot --proposed --publish $release $ref;
  lxc init $ref test-$release;
  lxc start test-$release;
  sleep 10;
  lxc exec test-$release -- sudo apt update;
  lxc file push valid.conf test-$release/valid.conf;
  lxc file push invalid.conf test-$release/invalid.conf;
  lxc exec test-$release -- python3 
/usr/lib/python3/dist-packages/cloudinit/config/schema.py -c /valid.conf | grep 
Valid;
  lxc exec test-$release -- apt-cache depends cloud-init | grep 
jsonschema # should be empty;
  # invalid.conf will not generate errors when jsonschema is not present
  lxc exec test-$release -- python3 
/usr/lib/python3/dist-packages/cloudinit/config/schema.py -c /invalid.conf | 
grep invalid;
  lxc exec test-$release -- sudo apt install python3-jsonschema
  # invalid.conf *will* generate errors when jsonschema is not present
   lxc exec test-$release -- python3 
/usr/lib/python3/dist-packages/cloudinit/config/schema.py -c /invalid.conf | 
grep invalid;
  done;

  [Regression Potential]
  We don't want to introduce a mandatory jsonschema dependency in older series.
  Validate that older releases can run without errors when jsonschema is *not* 
installed.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=0a448dd034

  === End SRU Template ===

  cloudinit needs a mechanism to parse and validate a strict schema
  definition for modules that parse user created #cloud-config yaml
  files.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1692916/+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 1717147] Re: cloud-init 0.7.9 fails for CentOS 7.4 in Cloudstack

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1717147

Title:
  cloud-init 0.7.9 fails for CentOS 7.4 in Cloudstack

Status in cloud-init:
  Fix Released
Status in cloud-init package in CentOS:
  Unknown

Bug description:
  Environment:
  CentOS 7.4, cloud-init-0.7.9-9.el7.centos.2.x86_64

  Problem (quick):
  CentOS 7.4 builds on Cloudstack 4.8 don't run cloud-init because the newer 
version of cloud-init doesn't appear to like the way the dhclient lease file is 
named.

  Problem (long):

  I've just built a CentOS 7.4 instance in one of my CloudStack 4.8
  clusters.  Unfortunately, cloud-init fails with the following in
  snippet in /var/log/cloud-init.log:

  2017-09-13 18:53:00,118 - __init__.py[DEBUG]: Seeing if we can get any data 
from 
  2017-09-13 18:53:00,118 - DataSourceCloudStack.py[DEBUG]: Using 
/var/lib/dhclient lease directory
  2017-09-13 18:53:00,118 - DataSourceCloudStack.py[DEBUG]: No lease file 
found, using default gateway

  Where it then tries to use the default route to download userdata.
  The problem is that we're not using the Cloudstack VR as a default
  router, so I expected it to parse /var/lib/dhclient/dhclient--
  eth0.lease for the "dhcp-server-identifier" line.

  Theory as to cause:
  I believe that this change 
(https://github.com/cloud-init/cloud-init/commit/aee0edd93cb4d78b5e0d1aec71e977aabf31cdd0#diff-5bc9de2bb7889d66205845400c7cf99b)
 breaks cloud-init beyond the 7.3-distributed cloud-0.7.5 when 7.4 includes 
0.7.9-9.

  Fix:

  Changing it from "dhclient." to "dhclient-" in /usr/lib/python2.7
  /site-packages/cloudinit/sources/DataSourceCloudStack.py on the
  running box with an installed RPM did the trick theoretically (after
  removing the pyc and pyo files, of course).

  This *can* be patched around by RedHat/CentOS (and hopefully will),
  but I figure it might be better to take it straight upstream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1717147/+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 1701097] Re: eni rendering of ipv6 gateways fails

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1701097

Title:
  eni rendering of ipv6 gateways fails

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

Bug description:
  === Begin SRU Template ===
  [Impact]
  Network configuration provided to cloud-init that has an ipv6 address
  and additional manual default route will fail to bring up the routes
  correctly.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, get cloud-init's network rendering tool from trunk
   c.) run the rendering tool against a config that failed before.
   d.) check rendered ENI config to verify it looks correct.

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc launch $ref $name
  $ lxc exec $ref $name /bin/bash

  ## get render tool
  % wget 
https://git.launchpad.net/~cloud-init-dev/cloud-init/plain/tools/net-convert.py 
-O net-convert.py

  % cat > net-config.yaml <<"EOF"
  version: 1
  config:
   - type: physical
 name: eth0
 mac_address: "c0:d6:9f:2c:e8:80"
 subnets:
  - type: static
address: "2001:1::2/64"
routes:
 - gateway: "2001:4800:78ff:1b::1"
   netmask: "::"
   network: "::"
  EOF

  $ python3 ./net-convert.py \
  --network-data=net-config.yaml --kind=yaml \
  --output-kind=eni \
  --mac=eth0,c0:d6:9f:2c:e8:80 \
  --directory=out.d

  % cat out.d/etc/network/interfaces
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet6 static
  address 2001:1::2/64
  post-up route add -A inet6 default gw 2001:4800:78ff:1b::1 || true
  pre-down route del -A inet6 default gw 2001:4800:78ff:1b::1 || true

  
  ## The output above is the expected output.  The failure path
  ## would have post-up and pre-down like:
  post-up route add -net :: netmask :: gw 2001:4800:78ff:1b::1 || true
  pre-down route del -net :: netmask :: gw 2001:4800:78ff:1b::1 || true

  [Regression Potential]
  Regressions for this change are almost certainly limited to
  rendering of ipv6 networking configuration and most likely limited
  to routing.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=811ce49d74af

  === End SRU Template ===

  
  cloud-init trunk and xenial, yakkety, zesty and artful all fail

  A network config with a ipv6 gateway route like:

  subnets:
    - type: static
  address: 2001:4800:78ff:1b:be76:4eff:fe06:96b3
  netmask: ':::::'
  routes:
    - gateway: 2001:4800:78ff:1b::1
  netmask: '::'
  network: '::'

  For eni rendering, this should create a post-up/post-down route
  command that generates a default ipv6 route entry, like this:

  post-up route add -A inet6 default gw 2001:4800:78ff:1b::1 || true
  pre-down route del -A inet6 default gw 2001:4800:78ff:1b::1 || true

  However, what is currently generated is this:

  post-up route add -net :: netmask :: gw 2001:4800:78ff:1b::1 || true
  pre-down route del -net :: netmask :: gw 2001:4800:78ff:1b::1 || true

  That does not install the route correctly as a default gateway route.

  This is fallout from commit d00da2d5b0d45db5670622a66d833d2abb907388
  net: normalize data in network_state object

  This commit removed ipv6 route 'netmask' values, and converted them to
  prefix length values, but failed to update the eni renderer's check for
  ipv6 default gateway.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701097/+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 1678145] Re: example chef config broken: upstream apt source has changed

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: cloud-init
   Status: In Progress => 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/1678145

Title:
  example chef config broken: upstream apt source has changed

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

Bug description:
  http://cloudinit.readthedocs.io/en/latest/topics/examples.html
  #install-and-run-chef-recipes

  The apt source provided in the example chef config is broken, as
  upstream has changed.

  It should now be:

  source: "deb http://packages.chef.io/repos/apt/stable $RELEASE main"

  and pull in corresponding gpg key from:

   https://packages.chef.io/chef.asc

  
  I've fixed up and tested locally and will try to get a MR up today.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1678145/+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 1718649] Re: sysV-init SUSE integration is broken

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1718649

Title:
  sysV-init SUSE integration is broken

Status in cloud-init:
  Fix Released

Bug description:
  On older SUSE distributions (SLES 11) the init script integration is
  broken.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1718649/+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 1690480] Re: cloud-init / nplan - missing bond mode miimon xmit_hash_policy

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1690480

Title:
  cloud-init / nplan - missing bond mode miimon xmit_hash_policy

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] 
  When rendering netplan output from OpenStack network configuration format
  (network_data.json), cloud-init would not correctly represent some
  bond attributes.  The result is that those attributes are not set as
  desired.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, get cloud-init's network rendering tool from trunk
   c.) run the rendering tool against a config that failed before.
   d.) check rendered netplan config to verify it has expected bond attributes.

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc launch $name
  $ sleep 10
  $ lxc exec $name /bin/bash

  ## get render tool
  % wget 
https://git.launchpad.net/~cloud-init-dev/cloud-init/plain/tools/net-convert.py 
-O net-convert.py
  % wget 
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1690480/+attachment/4887940/+files/network_data.json
 -O network_data.json

  % python3 ./net-convert.py \
  --network-data=network_data.json --kind=network_data.json \
  --output-kind=netplan \
  --mac=eth0,a0:36:9f:2d:93:80 --mac=eth1,a0:36:9f:2d:93:81 \
  --directory=out.d

  ## Now see that the 'mii-monitor-interval', 'mode', and 
  ## 'transmit-hash-policy' are present in output.
  % egrep --context=5 '(mii-monitor-interval|mode|transmit-hash-policy)' \
   out.d/etc/netplan/50-cloud-init.yaml
  bond0:
  interfaces:
  - eth0
  - eth1
  parameters:
  mii-monitor-interval: 100
  mode: 802.3ad
  transmit-hash-policy: layer3+4
  vlans:
  bond0.101:
  addresses:
  - 104.130.20.119/24
  id: 101

  
  [Regression Potential] 
  Fairly low chance for regression. The bond attributes were just not
  being written and now they will be.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=910ed46124e

  lxc-proposed-snapshot is

https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  === End SRU Template ===

  
  Given network-data.json http://paste.ubuntu.com/24561026/
  cloud-init generates http://paste.ubuntu.com/24564006/

  which is missing

   "bond_mode" : "802.3ad",
   "bond_miimon" : 100,
   "bond_xmit_hash_policy" : "layer3+4"

  For the bond specification

  As per nplan docs it should be defined as parameters dictionary
  https://git.launchpad.net/netplan/tree/doc/netplan.md#n302

  mode: 802.3ad
  mii-monitor-interval: 100
  transmit-hash-policy: layer3+4

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1690480/+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 1692087] Re: check_partition_layout has false positives when partitioned with gpt

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1692087

Title:
  check_partition_layout has false positives when partitioned with gpt

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]
  The disk setup module (disk_setup) of cloud-init had several issues
  when dealing with GPT formatted devices.  The result was that the user
  didn't get expected behavior if they were requesting GPT disk labels
  or if the disk present already had a GPT label.

  [Test Case]
  1.) launch an instance with a second disk "/dev/vdb".
  This can be done on openstack or azure.

  2.) write a config to system.
     $ sudo tee /etc/cloud/cloud.cfg.d/disk-setup.cfg https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bugs/lp-1686514/disk-setup
 -O disk-setup
     # format /dev/vdb with GPT disk label and 2 partitions.
     $ sudo LABEL=gpt ./disk-setup ntfs2 /dev/vdb

  4. remove state from the instance and reboot.  We expect that the desired
     partitioning will be done and the mount written and used on reboot.

     $ sudo rm -Rf /var/lib/cloud/ /var/log/cloud-init*
     $ sudo reboot

  5. ssh back in and look around
     $ grep vdb /proc/mounts
     $ grep mnt /etc/fstab

     $ sfdisk -l /dev/vdb

  6. sudo reboot
  7. ssh back in and look around.

  [Regression Potential]
  Regressions will be limited to places where the disk_setup module is used.
  That is
   a.) Azure (by default on new instances or re-deployed instance)
   b.) instances with custom user-data or system configuration.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=3507b59eaa4

  === End SRU Template ===

  As reported in bug 1686514 (comment 11), there is a bug in the code
  that determines if a device layout is "the same" and will thus be re-used.

  Even when functional, this code has some serious shortcomings:
  a.) it does not check sizes at all, only partition types
  b.) it does not check the partition table correctly

  The bug to fix here is simply some issues with its usage of sgdisk.
   * 'sgdisk -p' was being used to determine the size of a disk.
     this can fail if it believes there is a bad gpt partition table.
   * parsing of sgdisk -p output assumed that the 'name' of the partition
     type would not have any spaces (Microsoft basic data)
   * interaction with sgdisk did not realize that sgdisk wants input
     of '8300' rather than '83'.

  Related bugs:
   * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition 
ephemeral disks
   * bug 1691489: fstab entries written by cloud-config may not be mounted

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1692087/+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 1677710] Re: ds-identify does not find maas datasource

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1677710

Title:
  ds-identify does not find maas datasource

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]
  On Ubuntu core systems deployed with MAAS xenial and yakkety systems
  would put a warning on the login screen stating that the datasource was
  not found.

  The issue only occurred on Ubuntu core.  Ubuntu systems were not affected
  as recent maas versions preseed cloud-init with 'datasource_list: [MAAS]'
  which results in ds-identify just accepting the single entry as defined.

  [Test Case]
  The full test case involves
   * deploying through MAAS
   * enabling -proposed (without -proposed should show failure)
   * setting curtin config to show:
     system_upgrade: {enabled: True}}

  [Regression Potential]
  The changes that were done
   a.) renamed some variables to make code more readable
   b.) make searching for config less restrictive

  due to 'a', there could be unintended bugs, but testing for
  other datasources would likely have turned that up.

  [Other Info]

  === End SRU Template ===

  In ds-identify, the dscheck_MAAS calls check_config incorrectly, and
  as a result does not enable the MAAS datasource.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1677710/+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 1715738] Re: Cloud config modules are not skipped based on distro support

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1715738

Title:
  Cloud config modules are not skipped based on distro support

Status in cloud-init:
  Fix Released

Bug description:
  cloudinit.stages emits logs messages like the following when the
  cloudconfig module's distro attribute doesn't match the running
  disribution

  When a cloudinit.config.cc*py module distros attribute doesn't match
  the discovered Distribution.name, cloudinit.stages emits a log message
  about skipping the module in the following form:

  2017-09-07 06:03:25,838 - stages.py[INFO]: Skipping modules ['runcmd']
  because they are not verified on distro 'ubuntu'. To run anyway, add
  them to 'unverified_modules' in config.

  But, it doesn't actually skip running the module, we can see in the logging 
that follows:
  Running module runcmd () with frequency 
once-per-instance.

  cloudinit.stages should honor a skipped module and avoid running its
  handler.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1715738/+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 1690388] Re: wrong hwaddr on the vlan bond with nplan and cloud-init

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1690388

Title:
  wrong hwaddr on the vlan bond with nplan and cloud-init

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

Bug description:
  === Begin netplan SRU Template ===
  [Impact]
  Virtual devices such as VLANs, bridges and bonds may require the user to set 
a specific MAC address for proper operation on networks; where the same MAC may 
be used by default by the systems due to the methods used to create them.

  [Test case]
  /!\ This only works with the networkd renderer; NetworkManager does not 
currently support setting a MAC on bonds and bridges.

  1) Set a MAC address for a virtual device (bond, bridge or vlan),
  using the following syntax in netplan config:

  macaddress: ##:##:##:##:##:##

  2) Validate that the device gets the MAC address applied.

  [Regression potential]
  Failure to bring up a device configured in netplan or to set the MAC should 
be looked at as a possible regression. Other issues could include failure to 
write the configuration for networkd or NetworkManager.
  === End netplan SRU Template ===
  http://pad.lv/1690388
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1690388
  
  === Begin cloud-init SRU Template ===
  [Impact] 
  Virtual devices such as VLANs, bridges and bonds may require the user to set a
  specific MAC address for proper operation on networks; where the same MAC may
  be used by default by the systems due to the methods used to create them.

  cloud-init would not render the mac address of the vlan into its
  ifupdown/eni or netplan output.  The result is that the vlan device
  would not get the desired mac address.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, get cloud-init's network rendering tool from trunk
   c.) run the rendering tool against a config that failed before.
   d.) check rendered netplan config to verify it has vlan mac addresses 
present.

  [Regression Potential] 
  Fairly low chance for regression.  The mac address fields were just
  not being written, and now they will be.

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc init $ref $name

  ## get render tool
  $ wget 
https://git.launchpad.net/~cloud-init-dev/cloud-init/plain/tools/net-convert.py 
-O net-convert.py

  ## write a network config with vlan and mac address.
  $ cat > net-config.yaml <<"EOF"
  version: 1
  config:
  - type: physical
name: eth0
mac_address: "fa:35:9c:85:55:00"
subnets: [{type: dhcp}]
  - type: vlan
name: eth0.101
vlan_link: eth0
vlan_id: 101
mac_address: fe:35:9c:85:55:ee
mtu: 1500
subnets:
  - type: static
address: 192.168.2.10/24
  EOF

  $ for k in eni netplan; do 
 PYTHONPATH=$PWD python3 ./net-convert.py \
  --network-data=net-config.yaml --kind=yaml \
  --output-kind=$k --mac=eth0,fa:35:9c:85:55:00 \
  --directory=out.d ; done

  $ cat out.d/etc/network/interfaces
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  auto eth0.101
  iface eth0.101 inet static
  address 192.168.2.10/24
  hwaddress fe:35:9c:85:55:ee
  mtu 1500
  vlan-raw-device eth0
  vlan_id 101

  
  $ cat out.d/etc/netplan/50-cloud-init.yaml
  network:
  version: 2
  ethernets:
  eth0:
  dhcp4: true
  match:
  macaddress: fe:35:9c:85:55:00
  set-name: eth0
  vlans:
  eth0.101:
  addresses:
  - 192.168.2.10/24
  id: 101
  link: eth0
  macaddress: fe:35:9c:85:55:ee

  
  ## If you're running on a openstack system, you can actually take
  ## this a step further and replace the system networking with the
  ## newly generated config, reboot and see the vlan come up.
  ## You'll need to update the 'mac_address' for eth0 in net-config.yaml
  ## to match your system, then re-run the net-convert and update the
  ## system.
  $ sudo cp out.d/etc/network/interfaces 

[Yahoo-eng-team] [Bug 1687725] Re: sysconfig render does not support type manual subnets

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1687725

Title:
  sysconfig render does not support type manual subnets

Status in cloud-init:
  Fix Released

Bug description:
  Attempting to a render a network configuration like this:

  % cat manual_subnet.yaml 
  network:
  version: 1
  config:
  # Physical interfaces.
  - type: physical
name: interface0
mac_address: "52:54:00:12:34:00"
subnets:
- type: manual
  address: 10.0.2.100/24

  Attempting to render this into sysconfig results in a traceback.
  % PYTHONPATH=`pwd` ./tools/net-convert.py --network-data manual_subnet.yaml 
--kind yaml --output-kind sysconfig -d target 

  Traceback (most recent call last):
File "./tools/net-convert.py", line 82, in 
  main()
File "./tools/net-convert.py", line 78, in main
  r.render_network_state(ns, target=args.directory)
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
410, in render_network_state
  network_state).items():
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
391, in _render_sysconfig
  cls._render_physical_interfaces(network_state, iface_contents)
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
311, in _render_physical_interfaces
  cls._render_subnet(iface_cfg, route_cfg, iface_subnets[0])
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
238, in _render_subnet
  iface_cfg.name))
  ValueError: Unknown subnet type 'manual' found for interface 'interface0'


  Sysconfig does have an equivalent of eni's 'manual' control mode, the
  ONBOOT=N setting tells sysconfig to ignore this interface when
  booting.  Later users can ifup the interface.

  
  1. no cloud, just in-tree rendering
  2. cloud-init master branch

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1687725/+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 1693251] Re: cloud-init should configure networkmanager to not manage /etc/resolv.conf

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1693251

Title:
  cloud-init should configure networkmanager to not manage
  /etc/resolv.conf

Status in cloud-init:
  Fix Released

Bug description:
  Currently, cloud-init adds nameserver entries directly to
  /etc/resolv.conf but does not configure namservers in per-interface
  configuration files.  This could be problematic because information
  received from other sources (e.g., from another interface that is
  using dhcp) could clobber the information in /etc/resolv.conf.

  Unfortunately, at least under OpenStack, the nameserver information is
  not interface-scoped so it is not *possible* to correctly configure
  the interface configuration files.

  The solution in this case is to ensure that NM will not attempt to
  update /etc/resolv.conf.  The simplest way of doing this is to drop a
  file into /etc/NetworkManager/conf.d containing:

[main]
dns=none

  This will prevent NetworkManager from managing /etc/resolv.conf.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1693251/+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 1691489] Re: fstab entries written by cloud-config may not be mounted

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1691489

Title:
  fstab entries written by cloud-config may not be mounted

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Won't Fix
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Confirmed

Bug description:
  === Begin SRU Template ===
  [Impact]
  There is a race condition on a re-deployment of cloud-init on Azure
  where /mnt will not get properly formatted or mounted.  This is due to
  "dirty" entries in /etc/fstab that cause a device to be busy when
  cloud-init goes to format it.  This shows itself usually as 'mkfs'
  complaining that the device is busy.  The cause is that systemd
  starts an fsck and collides with cloud-init re-formatting the disk.

  The problem can be seen other places but seemed to be most reproducible
  and originally found on Azure.

  [Test Case]
  1.) Launch a Azure vm, ideally size L32S.
  2.) Log in and verify the system properly mounted /mnt.
  3.) Re-deploy the vm through the web ui and try again.

  [Regression Potential]
  Worst case scenario, these changes unnecessarily slow down boot and
  do not fix the problem.

  [Regression]
  This SRU change caused bug 1717477.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=1f5489c258

  === End SRU Template ===

  As reported in bug 1686514, sometimes /mnt will not get mounted when
  re-delpoying or stopping-then-starting a Azure vm of L32S.  This is
  probably a more generic issue, I suspect shown due to the speed of
  disks on these systems.

  Related bugs:
   * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition 
ephemeral disks
   * bug 1717477: cloud-init generates ordering cycle via After=cloud-init in 
systemd-fsck

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1691489/+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 1675576] Re: cloud-init netplan renderer might need to delete baked in configuration

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1675576

Title:
  cloud-init netplan renderer might need to delete baked in
  configuration

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]
  Writing netplan configuration during cloud-init's local phase
  does not work properly.  This is because there is stale configuration
  from the default installed files in a Ubuntu core image.

  The change to cloud-initn was to clean those up so that it could
  invoke netplan apply.

  [Test Case]
  Unit tests were added that excercise this code, full functional
  test would run through ubuntu core.  To do this on ubuntu cloud images
  we will simulate.

  lxc-proposed-snapshot is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc init $ref $name
  $ cat > 00-snapd-config.yaml <<"EOF"
  # This is the initial network config.
  # It can be overwritten by cloud-init or console-conf.
  network:
  version: 2
  ethernets:
  all-en:
  match:
  name: "en*"
  dhcp4: true
  all-eth:
  match:
  name: "eth*"
  dhcp4: true
  EOF
  $ echo 'system_info: {network: {renderers: ["netplan"]}}' |
     lxc file push -p - $name/etc/cloud/cloud.cfg.d/99-renderers.cfg

  $ lxc file push -p 00-snapd-config.yaml $name/etc/netplan/00-snapd-config.yaml
  # xenial does not have netplan, so trick the renderer search.
  $ ( set -x; lxc file pull $name/usr/sbin/netplan - >/dev/null ||
  echo "" | lxc file push netplan $name/usr/sbin/netplan --mode=0755 )

  $ lxc start $name

  $ sleep 10
  $ lxc exec $name ls /etc/netplan/00-snapd-config.yaml
  ls: cannot access '/etc/netplan/00-snapd-config.yaml': No such file or 
directory

  $ grep removing /var/log/cloud-init.log
  2017-04-04 14:38:18,303 - netplan.py[DEBUG]: removing known config 
'/etc/netplan/00-snapd-config.yaml' and derived existing files: 
['/run/systemd/network/10-netplan-all-en.network', 
'/run/systemd/network/10-netplan-all-eth.network', 
'/run/systemd/generator/netplan.stamp']
  lxc

  # In yakkety, you can see networkd set up the links with
  # In xenial, there is no netplan, so we assume broken networking.
  $ lxc exec $name ip a
  $ lxc exec $name systemctl status systemd-networkd --no-pager --full

  [Regression Potential]
  This code could delete a users netplan config incorrectly.
  That is protected against the config being *exactly* as shown above,
  and also named exactly as above.

  === End SRU Template ===

  1. Zesty
  2. 0.7.9-68-gef18b8ac-0ubuntu1
  3. cloud-init with network configuration rendering to netplan config has 
exclusive control over networkd configuration
  4. On images with existing netplan configuration (UC16 has an 
/etc/netplan/00-snapd-config.yaml); netplan generator will parse and write out 
networkd config to /run/systemd/network/10-netplan-*
  These files may collide with network-configuration provided to cloud-init 
which has been configured to render netplan.

  cloud-init should employ a 'maybe-delete' like function in the eni
  renderer to

  a) remove /etc/netplan/00-snapd-config.yaml  # this is the only known content 
at this time
  b) remove /run/systemd/network/10-netplan*   # files generated from (a)
  c) remove /run/systemd/generator/netplan.stamp # prevents new invocations of 
netplan generate

  Once these are removed, cloud-init netplan renderer may write out
  netplan config, and invoke netplan generate successfully.

  raharper@localhost:~$ find /etc/netplan /run/systemd/network
  /etc/netplan
  /etc/netplan/00-snapd-config.yaml
  /run/systemd/network
  /run/systemd/network/10-netplan-all-en.network
  /run/systemd/network/10-netplan-all-eth.network
  raharper@localhost:~$ ls -al /run/systemd/generator/netplan.stamp
  -rw-r--r-- 1 root root 0 Mar 23 21:58 /run/systemd/generator/netplan.stamp

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675576/+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 1700091] Re: Non-free repositories enabled

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1700091

Title:
  Non-free repositories enabled

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

Bug description:
  The non-free repositories are enabled both in Debian and Ubuntu
  template files located in the templates directory
  (sources.list.ubuntu.tmpl and sources.list.debian.tmpl). They should
  not be enabled, and thus be removed from the .tmpl files. This bug has
  been reported already in the Debian distribution:
  .

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1700091/+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 1707222] Re: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1707222

Title:
  usage of /tmp during boot is not safe due to systemd-tmpfiles-clean

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  Earlier this week on Zesty on Azure I saw a cloud-init failure in its 
'mount_cb' function.
  That function esentially does:
   a.) make a tmp directory for a mount point
   b.)  mount some filesystem to that mount point
   c.) call a function
   d.) unmount the directory

  What I recall was that access to a file inside the mount point failed during 
'c'.
  This seems possible as systemd-tmpfiles-clean may be running at the same time 
as cloud-init (cloud-init.service in this example).

  
  It seems that this service basically inhibits *any* other service from using 
tmp files.
  It's ordering statements are only:

After=local-fs.target time-sync.target
Before=shutdown.target

  So while in most cases only services that run early in the boot
  process like cloud-init will be affected, any service could have its
  tmp files removed.  this service could take quite a long time to run
  if /tmp/ had been filled with lots of files in the previous boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1707222/+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 1681531] Re: DigitalOcean DS defines mutliple gateways via meta-data

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1681531

Title:
  DigitalOcean DS defines mutliple gateways via meta-data

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:
  [Impact]
  The cloud-init datasource for DigitalOcean allows for multiple gateways on 
any NIC.

  On Ubuntu 16.04, this breaks networking.service. For 17.04 and later,
  Ubuntu _replaces_ the default gateway with the second gateway on
  'ifup' after reboot.

  DigitalOcean is looking at changing the meta-data, however, this will
  result in another version of the meta-data JSON.

  [Regression Potential]

  Low. This change is scope to DigitalOcean only. DigitalOcean has
  tested this Datasource exhaustively.

  [TEST Cases]
  - provision on DigitalOcean with a private IP
  - reboot
  - confirm that a single route exists in /etc/network/interfaces

  [LOGS]

  
--
  From /var/log/cloud-init.log:

  2017-04-10 17:36:11,608 - util.py[DEBUG]: Running command ['ip', 'link', 
'set', 'ens3', 'down'] with allowed return codes [0] (shell=False, capture=True)
  2017-04-10 17:36:11,615 - util.py[DEBUG]: Running command ['ip', 'link', 
'set', 'ens3', 'name', 'eth0'] with allowed return codes [0] (shell=False, 
capture=True)
  2017-04-10 17:36:11,635 - util.py[DEBUG]: Running command ['ip', 'link', 
'set', 'ens4', 'name', 'eth1'] with allowed return codes [0] (shell=False, 
capture=True)
  2017-04-10 17:36:11,651 - util.py[DEBUG]: Running command ['ip', 'link', 
'set', 'eth0', 'up'] with allowed return codes [0] (shell=False, capture=True)
  2017-04-10 17:36:11,654 - stages.py[INFO]: Applying network configuration 
from ds bringup=False: {'version': 1, 'config': [{'name': 'eth0', 'subnets': 
[{'address': '138.197.88.85', 'netmask': '255.255.240.0', 'gateway': 
'138.197.80.1', 'type': 'static', 'control': 'auto'}, {'address': 
'2604:A880:0800:0010:::2ECE:D001/64', 'gateway': 
'2604:A880:0800:0010::::0001', 'type': 'static', 'control': 
'auto'}, {'address': '10.17.0.10', 'netmask': '255.255.0.0', 'type': 'static', 
'control': 'auto'}], 'mac_address': 'ee:90:f2:c6:dc:db', 'type': 'physical'}, 
{'name': 'eth1', 'subnets': [{'address': '10.132.92.131', 'netmask': 
'255.255.0.0', 'gateway': '10.132.0.1', 'type': 'static', 'control': 'auto'}], 
'mac_address': '1a:b6:7c:24:5e:cd', 'type': 'physical'}, {'address': 
['2001:4860:4860::8844', '2001:4860:4860::', '8.8.8.8'], 'type': 
'nameserver'}]}
  2017-04-10 17:36:11,668 - util.py[DEBUG]: Writing to 
/etc/network/interfaces.d/50-cloud-init.cfg - wb: [420] 868 bytes
  2017-04-10 17:36:11,669 - main.py[DEBUG]: [local] Exiting. datasource 
DataSourceDigitalOcean not in local mode.
  2017-04-10 17:36:11,674 - util.py[DEBUG]: Reading from /proc/uptime 
(quiet=False)

  
--
  From 'dmesg':
  Apr 10 17:36:11 ubuntu systemd[1]: Started Initial cloud-init job 
(pre-networking).
  Apr 10 17:36:12 ubuntu systemd[1]: Started LSB: AppArmor initialization.
  Apr 10 17:36:12 ubuntu systemd[1]: Reached target Network (Pre).
  Apr 10 17:36:12 ubuntu systemd[1]: Starting Raise network interfaces...
  Apr 10 17:36:13 ubuntu ifup[1099]: Waiting for DAD... Done
  Apr 10 17:36:13 ubuntu ifup[1099]: RTNETLINK answers: File exists
  Apr 10 17:36:13 ubuntu ifup[1099]: Failed to bring up eth1.

  
--
  $ sudo journalctl -xe -u networking
  Apr 10 17:36:12 ubuntu systemd[1]: Starting Raise network interfaces...
  -- Subject: Unit networking.service has begun start-up
  -- Defined-By: systemd
  -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
  --
  -- Unit networking.service has begun starting up.
  Apr 10 17:36:13 ubuntu ifup[1099]: Waiting for DAD... Done
  Apr 10 17:36:13 ubuntu ifup[1099]: RTNETLINK answers: File exists
  Apr 10 17:36:13 ubuntu ifup[1099]: Failed to bring up eth1.
  Apr 10 17:36:13 ubuntu systemd[1]: networking.service: Main process exited, 
code=exited, status=1/FAILURE
  Apr 10 17:36:13 ubuntu systemd[1]: Failed to start Raise network interfaces.
  -- Subject: Unit networking.service has failed
  -- Defined-By: systemd
  -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
  --
  -- Unit 

[Yahoo-eng-team] [Bug 1691551] Re: warnings are still printed after user touches file

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1691551

Title:
  warnings are still printed after user touches file

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

Bug description:
  === Begin SRU Template ===
  [Impact]
  Warnings are not suppressed when /var/lib/cloud/instance/warnings/.skip 
exists.

  [Test Case]
  if [ ! -f lxc-proposed-snapshot ]; then
    wget 
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/lxc-proposed-snapshot
    chmod 755 lxc-proposed-snapshot
  fi

  for release in xenial yakkety zesty; do
  ref=$release-proposed;
  echo "$release START --";
  ./lxc-proposed-snapshot --proposed --install ntp --publish $release 
$ref;
  lxc init $ref test-$release;
  lxc start test-$release;
  sleep 10
  # Create a warning
  lxc exec test-$release -- sh -c 'd=/var/lib/cloud/instance/warnings/; 
mkdir -p $d; echo "WARNING WARNING FOO" > "$d/warn-foo"'
  # Validate warning exists
  echo -n "Warning should exist on login: "
  lxc exec test-$release -- bash --login &1 | grep WARNING
  lxc exec test-$release -- touch /var/lib/cloud/instance/warnings/.skip
  echo -n "Warning should now be suppressed on login: "
  lxc exec test-$release -- bash --login &1 | grep WARNING
  echo "$release DONE --";
  done

  [Regression Potential]
  Minimal as the alternative warning suppression file works if you touch 
/root/.cloud-warnings.skip

  [Other Info]
  Upstream commit:
   
https://git.launchpad.net/cloud-init/commit/?id=66e46d8ec290737fd74f50eb8c7672d627d9b516

  === End SRU Template ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1691551/+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 1675349] Re: Dsid missing source on Finnish provider Nebula and RDO installs

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1675349

Title:
  Dsid missing source on Finnish provider Nebula and RDO installs

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] 
  When running on a Redhat RDO install (such as Finnish provider Nebula),
  instances will show a warning on ssh login or in the cloud-init.log file.

  This was by design, as we wanted to find places where ds-identify was
  not working correctly.

  [Test Case]
  1. Launch an instance on a RDO deployed cloud
  2. enable proposed, upgrade
  3. rm -Rf /var/lib/cloud /var/log/cloud*
  4. reboot
  5. ssh back in, expect to see no warning.
 
  [Regression Potential]
  regression potential is low.  The code change made here
  was just to consider either 'OpenStack Nova' or 'OpenStack Compute'
  as identifying openstack where previously only the 'Nova' string
  was considered.  This does provide a larger potential for false-positive
  in identifying a non-openstack cloud as openstack, but that should
  be seemingly small.

  [Other Info]
 
  === End SRU Template ===

  
  **
  # A new feature in cloud-init identified possible datasources for#
  # this system as:#
  #   ['Ec2', 'None']  #
  # However, the datasource used was: OpenStack#
  ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675349/+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 1717477] Re: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1717477

Title:
  cloud-init generates ordering cycle via After=cloud-init in systemd-
  fsck

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

Bug description:
  http://pad.lv/1717477
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1717477

  === Begin SRU Template ===
  [Impact]
  Cloud-init's inclusion of a systemd drop-in file
/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
  Caused a regression on systems that had entries in /etc/fstab
  that were not authored by cloud-init (specifically that did not have
  something like 'x-systemd.requires=cloud-init.service' in their
  filesystem options.

  [Test Case]
  The test can be done on any cloud that has space to put a non-root
  filesystem.

  a.) launch instance
  b.) upgrade to cloud-init to -updates pocket
  c.) create a filesystem and put it in /etc/fstab
  bdev="/dev/sdb1"
  mkdir -p /mnt
  mkfs.ext4 -F "$bdev"
  echo "$bdev /mnt auto defaults 0 2" >> /etc/fstab

  reboot
  d.) see mention of 'ordering cycle' in journal

  $ journalctl -o short-precise  | grep -i ordering.cycle
  Sep 15 14:08:48.331033 xenial-20170911-174122 systemd[1]: 
local-fs.target: Found ordering cycle on local-fs.target/start
  Sep 15 14:08:48.331097 xenial-20170911-174122 systemd[1]: 
local-fs.target: Breaking ordering cycle by deleting job mnt.mount/start
  Sep 15 14:08:48.331108 xenial-20170911-174122 systemd[1]: mnt.mount: Job 
mnt.mount/start deleted to break ordering cycle starting with 
local-fs.target/start

  e.) upgrade to proposed
  f.) reboot
  g.) expect no mention of ordering cycle as seen in 'd'
  $ journalctl -o short-precise  | grep -i ordering.cycle || echo "no 
cycles"
  no cycles

  [Regression Potential]
  This change will mean that bug 1691489 is present again.
  That bug is much less severe and affects a much smaller set of users.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=a2f8ce9c80

  === End SRU Template ===


  We're running several machines with

    cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2

  without problems.

  Just upgraded all machines to

    cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  and rebooted them all.

  All machines report ordering cycles in their dmesg, resulting in systemd 
breaking the
  loop by NOT starting some important services, e.g. mouting local filesystems:

  Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering 
cycle on networking.service/start
  Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found 
dependency on local-fs.target/start
  Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found 
dependency on home.mount/start
  Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found 
dependency on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start
  Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found 
dependency on cloud-init.service/start
  Sep 14 15:43:52.487982 noname systemd[1]: networking.service: Found 
dependency on networking.service/start
  Sep 14 15:43:52.488297 noname systemd[1]: networking.service: Breaking 
ordering cycle by deleting job local-fs.target/start
  Sep 14 15:43:52.488306 noname systemd[1]: local-fs.target: Job 
local-fs.target/start deleted to break ordering cycle starting with 
networking.service/start

  % cat /etc/fstab
  LABEL=cloudimg-rootfs /ext4   defaults,discard0 1
  LABEL=Home/homexfsdefaults,logbufs=8  0 2

  In this case /home isn't mounted as a result of systemd breaking the
  loop, resulting in services depending on /home not being started.

  1. Tell us your cloud provider

  AWS

  2. dpkg-query -W -f='${Version}' cloud-init

  0.7.9-233-ge586fe35-0ubuntu1~16.04.1

  3. Any appropriate cloud-init configuration you can provide us

  Nothing special - worked with 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 on
  all machines without hassle.

  The problem is this change:

  diff -uaNr 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf 
233/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
  --- 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
1970-01-01 01:00:00.0 +0100
  +++ 233/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
2017-07-28 22:28:47.0 +0200
  @@ -0,0 +1,2 @@
  

[Yahoo-eng-team] [Bug 1679817] Re: dual stack IPv4/IPv6 configuration via config drive broken for RHEL7

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1679817

Title:
  dual stack IPv4/IPv6 configuration via config drive broken for RHEL7

Status in cloud-init:
  Fix Released

Bug description:
  Currently, if a network interface has both IPv4 and IPv6 configuration
  information (via network_data.json), cloud-init creates separate
  aliases files for IPv4 (i.e. ifcfg-eth0:0) and IPv6 (ifcfg-eth0:1)
  network configuration information. This results in an error when
  attempting to ifup eth0:

  /etc/sysconfig/network-scripts/ifup-aliases: error in ifcfg-eth0:1:
  didn't specify device or ipaddr

  I believe this error is occurring because RHEL expects/requires an
  IPv4 address within any aliases file.

  Red Hat documentation (https://access.redhat.com/documentation/en-
  US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-
  interfaces-alias.html) seems to indicate that alias files are
  supported only for IPv4 information and even then secondary addresses
  within the primary interface file is the preferred method.

  Furthermore, it appears that multiple IPv6 addresses on the same
  interface should use the IPV6ADDR_SECONDARIES parameter in the primary
  interface file rather than using IP alias files (see here:
  https://access.redhat.com/documentation/en-
  US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-networkscripts-
  interfaces.html).

  I believe this issue can be resolved by eliminating the use of alias
  files and instead configuring IPv4 and IPv6 within the primary
  interface file (i.e. ifcfg-eth0). Here's an example:

  # Created by cloud-init on instance boot automatically, do not edit.
  #
  BOOTPROTO=static
  DEVICE=eth0
  HWADDR=fa:16:3e:b2:4b:d4
  ONBOOT=yes
  TYPE=Ethernet
  USERCTL=no
  DEFROUTE=yes
  GATEWAY=10.252.197.129
  IPADDR=10.252.197.143
  NETMASK=255.255.255.224
  IPV6ADDR=2620:160:d2ff:1c07::b
  IPV6INIT=yes
  IPV6_DEFAULTGW=2620:160:d2ff:1c07::1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1679817/+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 1691517] Re: centos7 unit tests fail due to hard coded mkfs.ext4

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1691517

Title:
  centos7 unit tests fail due to hard coded mkfs.ext4

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]
  Unit tests for cloud-init did not run successfully in a centos environment.
  This is really just failure of the unit tests.

  The fix was to no longer expect /sbin/mkfs.ext4 but to mock the
  checking.

  [Test Case]
  Test of ubuntu package in centos is non-trivial and/or not useful.
  The proposed test case is to just run the trunk tests at the
  uploaded git commit in a lxc container (the environment that originally
  found the issue).

  $ lxc launch images:centos/7 c7
  $ sleep 10; # let it boot
  $ lxc exec c7 -- /bin/sh -xe <<"EOF"
  yum install --assumeyes epel-release
  yum install --assumeyes pyserial python-argparse python-cheetah 
python-configobj python-jinja2 python-jsonpatch python-oauthlib 
python-prettytable python-requests python-six python-pip PyYAML git file 
e2fsprogs
  pip install contextlib2 httpretty mock nose pep8 unittest2
  git clone https://git.launchpad.net/cloud-init
  cd cloud-init
  git checkout 16a7302f
  nosetests tests/unittests
  EOF

  [Regression Potential]
  No runtime regression potential.
  Unit test only changes.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=951863c21

  === End SRU Template ===

  A recent merge that added a mkfs.ext4 tests has a hard coded location
  for the binary of mkfs.ext4. The result is that on centos 7, which has
  the command in a different location than Ubuntu, is a failed test:

  https://paste.ubuntu.com/24589593/

  Steps to reproduce:
  lxc launch images:centos/7 c7
  lxc exec c7 bash
  yum install --assumeyes epel-release
  yum install --assumeyes pyserial python-argparse python-cheetah 
python-configobj python-jinja2 python-jsonpatch python-oauthlib 
python-prettytable python-requests python-six python-pip PyYAML git file 
e2fsprogs
  pip install contextlib2 httpretty mock nose pep8 unittest2
  git clone https://git.launchpad.net/cloud-init
  cd cloud-init
  nosetests tests/unittests

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1691517/+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 1695318] Re: unit tests failing if no jsonschema available

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: cloud-init
   Status: In Progress => 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/1695318

Title:
  unit tests failing if no jsonschema available

Status in cloud-init:
  Fix Released

Bug description:
  With the recent merge of the validation work the unit tests are now failing 
on the centos 6 and 7 platforms. Here are the test failures:
  centos 6: https://paste.ubuntu.com/24749874/
  centos 7: https://paste.ubuntu.com/24749876/

  Steps to reproduce:
  1. lxc launch images:centos/[6|7] c[6|7]
  2. lxc exec c[6|7] bash
  3. yum install epel-release -y
  4. install dependencies
  5. git clone https://git.launchpad.net/cloud-init 
  6. cd cloud-init
  7. nosetests tests/unittests

  Expected behavior:
  Tests pass with no failures

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1695318/+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 1696295] Re: [Hype-V][Azure]cloud-init failed to create user if "/mnt/cdrom/secure" does not exist

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1696295

Title:
  [Hype-V][Azure]cloud-init failed to create user if "/mnt/cdrom/secure"
  does not exist

Status in cloud-init:
  Fix Released

Bug description:
  On Azure, cloud-init (head) fails to mount cdrom /dev/cd0 on FreeBSD
  if the directory /mnt/cdrom/secure does not exist. In fact, "mount"
  should not depends on any directory. The quick fix is to use
  "util.mount_cd" to test whether cdrom is available or not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1696295/+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 1694801] Re: sysconfig needs fix for ipv6 gateway routes

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1694801

Title:
  sysconfig needs fix for ipv6 gateway routes

Status in cloud-init:
  Fix Released

Bug description:
  Static IPV6 subnet with a ipv6 route fails to set the default IPV6
  gateway.

  With cloud-init master:

  % cat ipv6-static.yaml
  network:
  version: 1
  config:
  - type: physical
name: interface0
mac_address: "52:54:00:12:34:00"
subnets:
- type: static
  address: 2001:4800:78ff:1b:be76:4eff:fe06:96b3
  netmask: ':::::'
  routes:
- gateway: 2001:4800:78ff:1b::1
  netmask: '::'
  network: '::'

  % ./tools/net-convert.py --network-data ipv6-static.yaml \
--kind yaml --output-kind sysconfig -d target-sysconfig

  % grep -nr IPV6_DEFAULTGW target-sysconfig/; echo $?
  1

  Currently only the subnet is checked for 'ipv6' setting, however, the routes 
array may include a mix of v4 or v6 configurations, in particular, the gateway
  in a route may be ipv6, and if so, should export the value via IPV6_DEFAULTGW 
in the ifcfg- file.

  Additionally, if the route is v6, it should rendering a routes6-
  file; this is present but missing the 'dev ' scoping.

  % cat target-sysconfig/etc/sysconfig/network-scripts/route6-interface0 
  # Created by cloud-init on instance boot automatically, do not edit.
  #
  ::/0 via 2001:4800:78ff:1b::1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1694801/+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 1697815] Re: [Hyper-V][Azure]ifdown/ifup fail to run on FreeBSD

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1697815

Title:
  [Hyper-V][Azure]ifdown/ifup fail to run on FreeBSD

Status in cloud-init:
  Fix Released

Bug description:
  An error was found when cloud-init running on FreeBSD, even it does
  not impact the functionality. There is an error in /var/log/cloud-
  init.log complaining "ifdown" and "ifup" fail to run.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1697815/+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 1705147] Re: cloud-init interface renaming should apply .lower() to mac_address values to match sysfs entries

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1705147

Title:
  cloud-init interface renaming should apply .lower() to mac_address
  values to match sysfs entries

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 Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  cloud-init takes network configuration input in a variety of formats.
  It then applies that network configuration, including renaming devices
  based on their mac address and provided name.

  If the mac address provided contained upper case letters (hex values,
  so A-F) then cloud-init would fail to rename the devices and show a
  WARN message in /var/log/cloud-init.log.

  The warn message would look like:
Failed to rename devices: [nic not present] Cannot rename 
  mac=00:16:3E:FC:3D:65 to eth0, not available.

  [Test Case]
  The basic idea below is:
   a.) launch an lxd instance with proposed version of cloud-init.
   b.) inside instance, change the provided network config to use upper case
   for mac addresses.
   c.) clean the system and reboot.
   d.) check no errors in /var/log/cloud-init.log

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc launch $ref $name
  $ lxc exec $name -- /bin/bash

  
  ## inside
  % read lower < /sys/class/net/eth0/address
  % echo $lower
  00:16:3e:fc:3d:65

  % upper=$(echo "$lower" | tr '[a-z]' '[A-Z]')
  % sed -i.dist -e 's,\( *\)name: eth0,\1name: nic0\n\1mac_address: 
"'$upper'",' \
   /var/lib/cloud/seed/nocloud-net/network-config
  % ( cd /var/lib/cloud/seed/nocloud-net/ && diff -u network-config.dist 
network-config )
  --- network-config.dist 2017-08-01 20:44:48.445568094 +
  +++ network-config   2017-08-01 20:44:58.277456919 +
  @@ -1,7 +1,8 @@
   version: 1
   config:
   - type: physical
  -  name: eth0
  +  name: nic0
  +  mac_address: "00:16:3E:5D:72:AE"
 subnets:
 - type: dhcp
   control: auto

  ## clean up skipping the 'seed' directory.
  % ( cd /var/lib/cloud && for i in *; do [ "$i" = "seed" ] || rm -Rf $i; done )
  % rm -Rf /var/log/cloud-init*
  % reboot

  ## back outside, wait a bit, then

  % lxc exec $name -- /bin/bash
  % grep WARN /var/log/cloud-init.log || echo "no warnings"

  % ip addr show nic0
  90: nic0@if91:  mtu 1500 qdisc noqueue state 
UP group default qlen 1000
  link/ether 00:16:3e:5d:72:ae brd ff:ff:ff:ff:ff:ff link-netnsid 0
  inet 10.75.205.253/24 brd 10.75.205.255 scope global nic0
 valid_lft forever preferred_lft forever
  inet6 fe80::216:3eff:fe5d:72ae/64 scope link 
 valid_lft forever preferred_lft forever

  [Regression Potential]
  Regression potential here should be very low.  The fix was essentially to
  be more liberal on matching mac addresses by using '.lower()' on both values.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=c0060fe489

  lxc-proposed-snapshot is

https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  === End SRU Template ===

  
  When supplying a network config to cloud-init with MAC address values using 
Upper case letters, this will fail to match MAC address values returned from 
sysfs.  THe result is that cloud-init gives up on the renaming of the interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1705147/+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 1696176] Re: Add default routes for IPv4 and IPv6 only to ifcfg-* files and not to route-* or route6-* files in sysconfig

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1696176

Title:
  Add default routes for IPv4 and IPv6 only to ifcfg-* files and not to
  route-* or route6-* files in sysconfig

Status in cloud-init:
  Fix Released

Bug description:
  Since f38fa41317602908139aa96e930b634f65e39555 , default routes get
  added to both ifcfg-* and route-* and route6-* files. (ii) Default
  routes should only go to ifcfg-* files, otherwise the information is
  redundant. (i) Also, in dual stack networks, this redundant "feature"
  isn't working correctly, only the IPv6 route is added to both route6-*
  and ifcfg-*, but not the IPv4 route.

  (i) First of all, let me explain why only the IPv6 route was added to
  route6-* and not the IPv4 route to route-*

  sysconfig.py
  (...)
  for route in subnet.get('routes', []):
  is_ipv6 = subnet.get('ipv6')

  if _is_default_route(route):
  if (
  (subnet.get('ipv4') and
   route_cfg.has_set_default_ipv4) or
  (subnet.get('ipv6') and
   route_cfg.has_set_default_ipv6)
  ):
  raise ValueError("Duplicate declaration of default "
   "route found for interface '%s'"
   % (iface_cfg.name))
  # NOTE(harlowja): ipv6 and ipv4 default gateways
  gw_key = 'GATEWAY0'
  nm_key = 'NETMASK0'
  addr_key = 'ADDRESS0'
  (...)

  The above will obviously overwrite GATEWAY0, NETMASK0, ADDRESS0 when
  there is an IPv4 default route and an IPv6 default route.

  (ii) Now, interestingly, we don't want to add these routes to the
  route-* and route6-* files, because this would only result in
  duplicate default route declaration (we only need it in the ifcfg-*
  files, not in the route-* or route6-*).

  Which means that this can be fixed by changing indentation for the following 
lines (moving all lines marked with "+" exactly 4 characters to the right). 
This moves the route_cfg part into the "else" condition:
  ~~~
  cd /usr/lib/python2.7/site-packages/cloudinit/net
  [root@rhel-test net]# diff -u sysconfig.py.back sysconfig.py
  --- sysconfig.py.back 2017-06-06 12:39:25.857595506 -0400
  +++ sysconfig.py  2017-06-06 12:40:19.059595506 -0400
  @@ -372,11 +372,11 @@
   nm_key = 'NETMASK%s' % route_cfg.last_idx
   addr_key = 'ADDRESS%s' % route_cfg.last_idx
   route_cfg.last_idx += 1
  -for (old_key, new_key) in [('gateway', gw_key),
  -   ('netmask', nm_key),
  -   ('network', addr_key)]:
  -if old_key in route:
  -route_cfg[new_key] = route[old_key]
  +for (old_key, new_key) in [('gateway', gw_key),
  +   ('netmask', nm_key),
  +   ('network', addr_key)]:
  +if old_key in route:
  +route_cfg[new_key] = route[old_key]
   
   @classmethod
   def _render_bonding_opts(cls, iface_cfg, iface):
  ~~~

  The above means that a route will only be added to the route_cfg array
  if it is not a default route.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1696176/+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 1695333] Re: snapcraft.yaml: classic snap should not have plugs

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1695333

Title:
  snapcraft.yaml: classic snap should not have plugs

Status in cloud-init:
  Fix Released

Bug description:
  It has come to my attention when attempting to publish the cloud-init
  snap that because it is a classic snap it should not actually have any
  plugs. This is because as a classic snap it has access to the system
  by default and does not require any additional access to be specified.

  Failure text:
  confinement 'classic' not allowed with plugs/slots 
lint-snap-v2_confinement_classic_with_interfaces
  Refrence LP: #1655369

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1695333/+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 1699282] Re: cloud-init process fails to configure puppet

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1699282

Title:
  cloud-init process fails to configure puppet

Status in cloud-init:
  Fix Released

Bug description:
  At firstboot when cloud-init is initiated.
  The cloud-init process fails to configure puppet, the python script exits 
with a trace.

  1. redhat/tripleo
  2. cloud-init-0.7.9-3.el7
  3. in the attachment

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1699282/+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 1695918] Re: 'jsonschema' imported but unused

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1695918

Title:
  'jsonschema' imported but unused

Status in cloud-init:
  Fix Released

Bug description:
  From latest build tests:
  tests/unittests/test_handler/test_handler_ntp.py:20: 'jsonschema' imported 
but unused
  tests/unittests/test_handler/test_schema.py:16: 'jsonschema' imported but 
unused

  Steps to reproduce:
  # git clone master
  # cd cloud-init
  # tox -e tip-pyflakes

  The offending code in both files is:
  try:
  import jsonschema  # NOQA
  _missing_jsonschema_dep = False
  except ImportError:
  _missing_jsonschema_dep = True

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1695918/+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 1701420] Re: Created by cloud-init comment being added on every reboot to /etc/resolv.conf

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1701420

Title:
  Created by cloud-init comment being added on every reboot to
  /etc/resolv.conf

Status in cloud-init:
  Fix Released

Bug description:
  Every time I reboot a system which has its networking configured by
  cloud-init the following comment is added

  ; Created by cloud-init on instance boot automatically, do not edit.

  For example I've rebooted the system 3 times and have the following
  config

  # cat /etc/resolv.conf 
  ; Created by cloud-init on instance boot automatically, do not edit.
  ;
  ; Created by cloud-init on instance boot automatically, do not edit.
  ;
  ; Created by cloud-init on instance boot automatically, do not edit.
  ;
  nameserver 10.0.0.2
  search maas

  Using cloud-init-0.7.9+191.g0bcb95a-1.el7.centos.noarch from http
  ://copr-be.cloud.fedoraproject.org/results/@cloud-init/cloud-init-
  curtin/epel-7-x86_64

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701420/+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 1695092] Re: sysconfig only applies subnet/route config to physical interfaces

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1695092

Title:
  sysconfig only applies subnet/route config to physical interfaces

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init master

  Testing bridging configuration.  First, empty subnets break sysconfig
  rendering; this has been reported in other bugs), after that, the
  resulting ifcfg-br0 does not include the static network configuration.
  Upon closer examination the _render_interface_subnets and routes is
  only called in the _render_physical_interface code.  Instead, this
  should be called on *any* interface as we can configure subnets and
  routes on vlans or bridges, bonds, etc.

  % cat bridge.yaml
  network:
  version: 1
  config:
  - type: physical
name: eth0
mac_address: "52:54:00:12:34:00"
subnets:
- type: dhcp4
  - type: physical
name: eth1
mac_address: "52:54:00:12:34:02"
  - type: physical
name: eth2
mac_address: "52:54:00:12:34:04"
  - type: bridge
name: br0
bridge_interfaces:
  - eth1
  - eth2
params:
bridge_ageing: 250
bridge_bridgeprio: 22
bridge_fd: 1
bridge_gcint: 2
bridge_hello: 1
bridge_maxage: 10
bridge_maxwait: 0
bridge_pathcost:
  - eth1 50
  - eth2 75
bridge_portprio:
  - eth1 28
  - eth2 14
bridge_stp: 'off'
bridge_waitport:
  - 1 eth1
  - 2 eth2
subnets:
- type: static
  address: 192.168.14.2/24

  After fixing the empty subnet issue, we can see in net-convert rendering of 
ifcfg-br0 is missing
  the 192.168.14.2/24 address.

  % cat target-sysconfig/etc/sysconfig/network-scripts/ifcfg-br0 
  # Created by cloud-init on instance boot automatically, do not edit.
  #
  AGEING=250
  BOOTPROTO=none
  DEVICE=br0
  NM_CONTROLLED=no
  ONBOOT=yes
  PRIO=22
  STP=off
  TYPE=Bridge
  USERCTL=no

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1695092/+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 1704872] Re: sysconfig use subnet prefix and set DEFROUTE key

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1704872

Title:
  sysconfig use subnet prefix and set DEFROUTE key

Status in cloud-init:
  Fix Released

Bug description:
  Sysconfig network files should set DEFROUTE and IPV6_DEFROUTE if the
  key is configured.  Additionally, ipv6 routes should use the subnet
  'prefix' value instead of netmask.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1704872/+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 1702513] Re: sysconfig should render MTU values from subnets/routes including ipv6

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1702513

Title:
  sysconfig should render MTU values from subnets/routes including ipv6

Status in cloud-init:
  Fix Released

Bug description:
  Network configuration with MTU values should be rendered.  MTU values
  set under subnets, including ipv6 MTU is not being rendered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1702513/+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 1703789] Re: Disk setup example text only lists MBR as valid table_type

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1703789

Title:
  Disk setup example text only lists MBR as valid table_type

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

Bug description:
  The disk setup example in the docs mentions that only MBR table_type
  is supported, while support for GPT was introduced in 0.7.7.

  See here for disk setup example text: https://git.launchpad.net/cloud-
  init/tree/doc/examples/cloud-config-disk-setup.txt#n99

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1703789/+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 1702717] Re: test: keyid specified does not match ppa

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1702717

Title:
  test: keyid specified does not match ppa

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

Bug description:
  The keyid specified for the modules/apt_configure_sources_keyserver
  integration test does not match the repo that is imported:

  #cloud-config
apt:
  source1:
keyid: 0165013E
keyserver: keyserver.ubuntu.com
source: "deb 
http://ppa.launchpad.net/cloud-init-dev/test-archive/ubuntu $RELEASE main"

  That keyid is for the curtin developers test-archive ppa and not the
  cloud-init developer's test-archive ppa.

  Expected result:
  `apt-key list` should specify an entry for:
Launchpad PPA for cloud init development team
1FF0 D853 5EF7 E719 E5C8  1B9C 083D 06FB E4D3 04DF

  Actual result:
A curtin developers entry.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1702717/+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 1703697] Re: tests fail under python 3.6

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1703697

Title:
  tests fail under python 3.6

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

Bug description:
  Steps to reproduce:
  1. lxc launch ubuntu-daily:a a
  2. lxc exec a bash
  3. add-apt-repository ppa:canonical-foundations/python3.6-as-default -y
  4. apt-get update
  5. apt-get upgrade -y
  6. apt-get install tox
  6. git clone https://git.launchpad.net/cloud-init
  7. cd cloud-init
  8. tox

  Expected results:
  All tests pass

  Actual results:
  Numerous unittest failures, see:
  http://paste.ubuntu.com/25071344/

  There appear to be three types of errors:

  9x jsonpatch issues related: http://paste.ubuntu.com/25071366/
  2x unexpected None type: http://paste.ubuntu.com/25071385/
  1x incorrect assert/mock(?) http://paste.ubuntu.com/25071375/

  Related bugs:
   *  bug 1704024: stack trace on import with python3.6

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1703697/+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 1701417] Re: cloud-init fails to configure bonding on CentOS 7

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1701417

Title:
  cloud-init fails to configure bonding on CentOS 7

Status in cloud-init:
  Fix Released

Bug description:
  When using ppa:raharper/curtin-dev and the cloud-init-curtin yum
  repo[1] with MAAS configuring the node to use bonding networking never
  comes up causing the deployment to fail.

  cloud-init-0.7.9+191.g0bcb95a-1.el7.centos.noarch
  curtin-0.1.0~bzr535-0ubuntu1

  [1] http://copr-be.cloud.fedoraproject.org/results/@cloud-init/cloud-
  init-curtin/epel-7-x86_64

  apt:
preserve_sources_list: false
primary:
- arches:
  - default
  uri: http://archive.ubuntu.com/ubuntu
proxy: http://10.0.0.2:8000/
security:
- arches:
  - default
  uri: http://archive.ubuntu.com/ubuntu
  cloudconfig:
maas-cloud-config:
  content: "#cloud-config\ndatasource:\n  MAAS: {consumer_key: 
72gtz4EuywxY9wtaTy,\
\ metadata_url: 'http://10.0.0.2:5240/MAAS/metadata/',\ntoken_key: 
H24Erg25Cx9Q8hHJrp,\
\ token_secret: 7jC2PWsGcrxcvHNPw8yHyz2zf76DcEFS}\n"
  path: /etc/cloud/cloud.cfg.d/90_maas_cloud_config.cfg
maas-datasource:
  content: 'datasource_list: [ MAAS ]'
  path: /etc/cloud/cloud.cfg.d/90_maas_datasource.cfg
maas-ubuntu-sso:
  content: '#cloud-config

snappy: {email: lee.tra...@canonical.com}

'
  path: /etc/cloud/cloud.cfg.d/90_maas_ubuntu_sso.cfg
  debconf_selections:
maas: 'cloud-init   cloud-init/datasources  multiselect MAAS

  cloud-init   cloud-init/maas-metadata-url  string
  http://10.0.0.2:5240/MAAS/metadata/

  cloud-init   cloud-init/maas-metadata-credentials  string
  
oauth_token_key=H24Erg25Cx9Q8hHJrp_consumer_key=72gtz4EuywxY9wtaTy_token_secret=7jC2PWsGcrxcvHNPw8yHyz2zf76DcEFS

  cloud-init   cloud-init/local-cloud-config  string apt:\n  
preserve_sources_list:
  false\n  primary:\n  - arches: [default]\nuri: 
http://archive.ubuntu.com/ubuntu\n  proxy:
  http://10.0.0.2:8000/\n  security:\n  - arches: [default]\nuri: 
http://archive.ubuntu.com/ubuntu\napt_preserve_sources_list:
  true\napt_proxy: http://10.0.0.2:8000/\nmanage_etc_hosts: 
false\nmanual_cache_clean:
  true\nreporting:\n  maas: {consumer_key: 72gtz4EuywxY9wtaTy, endpoint: 
''http://10.0.0.2:5240/MAAS/metadata/status/43gt4w'',\ntoken_key:
  H24Erg25Cx9Q8hHJrp, token_secret: 7jC2PWsGcrxcvHNPw8yHyz2zf76DcEFS,\n
type:
  webhook}\nsystem_info:\n  package_mirrors:\n  - arches: [i386, amd64]\n   
 failsafe:
  {primary: ''http://archive.ubuntu.com/ubuntu'', security: 
''http://security.ubuntu.com/ubuntu''}\nsearch:\n  primary:
  [''http://archive.ubuntu.com/ubuntu'']\n  security: 
[''http://archive.ubuntu.com/ubuntu'']\n  -
  arches: [default]\nfailsafe: {primary: 
''http://ports.ubuntu.com/ubuntu-ports'',
  security: ''http://ports.ubuntu.com/ubuntu-ports''}\nsearch:\n  
primary:
  [''http://ports.ubuntu.com/ubuntu-ports'']\n  security: 
[''http://ports.ubuntu.com/ubuntu-ports'']\n

  '
  install:
log_file: /tmp/install.log
post_files:
- /tmp/install.log
  late_commands:
maas:
- wget
- --no-proxy
- http://10.0.0.2:5240/MAAS/metadata/latest/by-id/43gt4w/
- --post-data
- op=netboot_off
- -O
- /dev/null
  network:
config:
- id: ens10
  mac_address: 52:54:00:4b:11:ea
  mtu: 1500
  name: ens10
  subnets:
  - type: manual
  type: physical
- id: ens3
  mac_address: 52:54:00:aa:40:cd
  mtu: 1500
  name: ens3
  subnets:
  - type: manual
  type: physical
- bond_interfaces:
  - ens10
  - ens3
  id: bond0
  mac_address: 52:54:00:aa:40:cd
  mtu: 1500
  name: bond0
  params:
bond-downdelay: 0
bond-lacp-rate: slow
bond-miimon: 100
bond-mode: active-backup
bond-updelay: 0
bond-xmit-hash-policy: layer2
  subnets:
  - address: 10.0.0.147/24
dns_nameservers: []
gateway: 10.0.0.1
type: static
  type: bond
- address:
  - 10.0.0.2
  search:
  - maas
  type: nameserver
version: 1
  network_commands:
builtin:
- curtin
- net-meta
- custom
  reporting:
maas:
  consumer_key: 72gtz4EuywxY9wtaTy
  endpoint: http://10.0.0.2:5240/MAAS/metadata/status/43gt4w
  token_key: H24Erg25Cx9Q8hHJrp
  token_secret: 7jC2PWsGcrxcvHNPw8yHyz2zf76DcEFS
  type: webhook

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701417/+subscriptions

-- 
Mailing list: 

[Yahoo-eng-team] [Bug 1701527] Re: Exceptions in meta-mock.py need more care

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1701527

Title:
  Exceptions in meta-mock.py need more care

Status in cloud-init:
  Fix Released

Bug description:
  The tools/mock-meta.py has one error in exception handling (it excepts
  KeyError which is made for dicts instead of IndexError that is made
  for lists) and also it returns non-describing http code. I have
  attached a patch that fixes this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701527/+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 1705306] Re: Cannot set hostname on Arch Linux

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1705306

Title:
  Cannot set hostname on Arch Linux

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init fails to set the hostname on Arch Linux with the following
  error:

  [CLOUDINIT] util.py[DEBUG]: Failed to set the hostname to dev1.localdomain 
(dev1)
Traceback (most recent call last):
  File 
"/usr/lib/python2.7/site-packages/cloudinit/config/cc_set_hostname.py", line 
33, in handle
cloud.distro.set_hostname(hostname, fqdn)
  File "/usr/lib/python2.7/site-packages/cloudinit/distros/__init__.py", 
line 96, in set_hostname
self._write_hostname(writeable_hostname, self.hostname_conf_fn)
  File "/usr/lib/python2.7/site-packages/cloudinit/distros/arch.py", line 
132, in _write_hostname
util.write_file(out_fn, conf, 0o644)
  File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 1662, in 
write_file
content = encode_text(content)
  File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 97, in 
encode_text
return text.encode(encoding)
AttributeError: 'HostnameConf' object has no attribute 'encode'

  The bug is that _write_hostname passes conf instead of str(conf) to
  util.write_file (compare distros/arch.py#n122 and
  distros/debian.py#n112).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1705306/+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 1706593] Re: Archlinux Bugs

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1706593

Title:
  Archlinux Bugs

Status in cloud-init:
  Fix Released

Bug description:
  This is a copy of an existing bug report, except the patch is created
  from the latest master and by myself who has signed the Canonical
  agreement.

  Taken from: https://bugs.launchpad.net/cloud-init/+bug/1555605

  I needed to patch a few places in distros/arch.py to get cloud-init to
  work on Arch. This is with an OpenNebula-based cloud, but that
  shouldn't matter. In /etc/cloud/cloud.cfg I obviously used "arch" for
  system_info -> distro.

  I checked against current trunk version of distros/arch.py. There's 3
  issues in arch.py that this patch fixes (in order of appearance in the
  patch):

  1. The loopback device is returned as an entry by
  net_util.translate_network(), leading to it gettingprocessed to
  configure settings like IP address, netmask, etc, but these aren't
  available and leads to an exception. I simply removed the "lo" entry
  from the dictionary.

  2. The netctl command expects its profile files to be named
  /etc/netctl/. The code in arch.py leaves out the last
  separator, leading to files like /etc/netctleth0, which doesn't work

  3. The function convert_resolv_conf() can't possibly work, as it tries
  to iterate over the "list" type instead of the "settings" list.

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

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

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

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

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

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 1673818] Re: Misleading requirements for 'unpartitioned disks' for ConfigDrive in documentation

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1673818

Title:
  Misleading requirements for 'unpartitioned disks' for ConfigDrive in
  documentation

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] 
  This is a doc only change.  The related doc is not present in ubuntu
  binary packages.

  [Test Case]
  apt-get source cloud-init
  vi cloud-init*/doc/rtd/topics/datasources/configdrive.rst

  [Regression Potential] 
  None.
 
  [Other Info]
  Upstream commit:
   https://git.launchpad.net/cloud-init/commit/?id=58cc8f7521725d4f00

  === End SRU Template ===

  
  Current documentation states that:
  
http://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html#version-2

  ... a config drive: ...Must be a un-partitioned block device
  (/dev/vdb, not /dev/vdb1)...

  This is not correct.

  1. Cloud-init actually, works with ConfigDrive as partition (e.g. /dev/sda1)
  2. Ironic uses partition at the end of disk to write metadata, and it's 
absurd for baremetal provisioning to dedicate whole disk (actual SATA, SSD, 
SAS/FC drive) just to tiny metada.
  3. According to @smoser at #cloud-init IRC, " i'm pretty sure the doc is just 
wrong, ... i'm pretty sure reading current code that if the filesystem has a 
label of 'config-2', then it will work".

  I think this part of documentation should be rewritten to avoid
  confusion with Ironic workflow for ConfigDrive.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1673818/+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 1674946] Re: cloud-init fails with "Unknown network_data link type: dvs"

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1674946

Title:
  cloud-init fails with "Unknown network_data link type: dvs"

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]
  When a config drive provides network_data.json on Openstack running on
  ESXi 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.

  This is very similar to change in bug 1642679.
  Upstream Openstack Merge proposal to stop this from continually
  happening at https://review.openstack.org/#/c/400883/
  === End SRU Template ===

  When booting an OpenStack instance, cloud-init fails with:

  [   33.307325] cloud-init[445]: Cloud-init v. 0.7.9 running 'init-local' at 
Mon, 20 Mar 2017 14:42:58 +. Up 31.06 seconds.
  [   33.368434] cloud-init[445]: 2017-03-20 14:43:00,779 - util.py[WARNING]: 
failed stage init-local
  [   33.449886] cloud-init[445]: failed run of stage init-local
  [   33.490863] cloud-init[445]: 

  [   33.542214] cloud-init[445]: Traceback (most recent call last):
  [   33.585204] cloud-init[445]:   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 513, in 
status_wrapper
  [   33.654579] cloud-init[445]: ret = functor(name, args)
  [   33.696372] cloud-init[445]:   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 269, in main_init
  [   33.755593] cloud-init[445]: 
init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
  [   33.809124] cloud-init[445]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 622, in 
apply_network_config
  [   33.847161] cloud-init[445]: netcfg, src = 
self._find_networking_config()
  [   33.876562] cloud-init[445]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 609, in 
_find_networking_config
  [   33.916335] cloud-init[445]: if self.datasource and 
hasattr(self.datasource, 'network_config'):
  [   33.956207] cloud-init[445]:   File 
"/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py", 
line 147, in network_config
  [   34.008213] cloud-init[445]: self.network_json, 
known_macs=self.known_macs)
  [   34.049714] cloud-init[445]:   File 
"/usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py", line 
627, in convert_net_json
  [   34.104226] cloud-init[445]: 'Unknown network_data link type: %s' % 
link['type'])
  [   34.144219] cloud-init[445]: ValueError: Unknown network_data link type: 
dvs
  [   34.175934] cloud-init[445]: 


  I am using Neutron with the Simple DVS plugin.

  Related bugs:
   * bug 1674946: cloud-init fails with "Unknown network_data link type: dvs
   * bug 1642679: OpenStack network_config.json implementation fails on Hyper-V 
compute nodes

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1674946/+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 1675063] Re: vmware customization only writes ENI network config

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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 cloud-init.
https://bugs.launchpad.net/bugs/1675063

Title:
  vmware customization only writes ENI network config

Status in cloud-init:
  Fix Released

Bug description:
  the vmware code that configures networking currently only supports
  writing etc/network/interfaces (eni or ifupdown) format.  Additionally
  it has its own code to write that data
  (cloudinit/sources/helpers/vmware/imc/config_nic.py).

  It would be better for it to use the renderers for ENI and sysconfig,
  and then it will gain new backends as cloud-init does.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675063/+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 1367899] Re: cloud-init rsyslog config uses deprecated syntax

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1367899

Title:
  cloud-init rsyslog config uses deprecated syntax

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

Bug description:
  === Begin SRU Template ===
  [Impact]
  Warning messages in /var/log/syslog on startup:
  warning: ~ action is deprecated, consider using the 'stop' statement instead

  [Test Case]
  Startup proposed lxcs and confirm warning message no longer present

  $ name=proposed-test
  $ for release in xenial yakkety zesty; do
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc init $ref $name
  $ lxc start $name
  $ sleep 10
  $ lxc exec $name grep "warning: ~ action is deprecated, consider using the 
  'stop' statemen" /var/log/syslog
  # validate cloud-init messages are making it into syslog still
  $  lxc exec $name grep cloud-init /var/log/syslog
  $ lxc stop $name
  $ lxc delete $name

  
  [Regression Potential]
  Low. oneliner rsyslog change

  [Other Info]
  Upstream commit:

https://git.launchpad.net/~powersj/cloud-init/commit/?id=87dcf5769df4e5ce370be753b7d39f5a65cee2f2

  === End SRU Template ===

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

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

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

Title:
  cloud-init attempts to rename bonds

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]
  When booting with bonds provided in networking configuration, cloud-init
  can fail as it attempts to rename the bond device to an interface.

  [Test Case]
   * download ubuntu cloud image
   * mount image, enable proposed, update, upgrade cloud-init
   * run 'bond-rename-launch' as provided.
   * login to kvm guest as 'ubuntu:passw0rd'
   * sudo cloud-init init

  the 'cloud-init init' above would fail before in an attempt
  to rename a bond device.  It will succeed now, as it will realize
  that it does not have anything to do.

  [Regression Potential]
  Should be small. regressions would be certainly related to
  bond or vlan configurations.

  === End SRU Template ===

  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/

  Related bugs:
   * bug 1682871: cloud-init attempts to rename vlans / get_interfaces_by_mac 
does not filter vlans

To manage notifications about this bug go to:

[Yahoo-eng-team] [Bug 1674861] Re: Google Compute Engine (GCE) datasource setting to none after update

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1674861

Title:
  Google Compute Engine (GCE) datasource setting to none after update

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]
  When running on a Google Compute (GCE),
  instances may show a warning on ssh login or in the cloud-init.log file.

  This was by design, as we wanted to find places where ds-identify was
  not working correctly.

  This seems to only occur on older instances.  The original reporter
  cannot re-create  it on a new instance. The reason for the behavior
  change is that the new instances have different smbios information.
  Presumably this is because the mechanism for launching the new 
  instances has been changed to include 'Google Compute' in the Product
  Name where previously only 'Google' appeard.

  [Test Case]
  Note, you'd have to have an old instance to actually see this.
  So this is not really easy to test the fix.
  The test for no regression is easier:

  1. Launch an instance on a GCE.
  2. enable proposed, upgrade
  3. rm -Rf /var/lib/cloud /var/log/cloud*
  4. reboot
  5. ssh back in, expect to see no warning.
 
  [Regression Potential] 
  Very low.  the change was just to consider an a dmi product serial
  number with 'GoogleCloud-*' as a indication that we are running on
  Google Compute.  That would seem a very low false-positive rate.
 
  [Other Info]

  === End SRU Template ===

  
  The following message appears after login in my Google Cloud VPS:

  **
  # A new feature in cloud-init identified possible datasources for#
  # this system as:#
  #   ['None'] #
  # However, the datasource used was: GCE  #
  ##
  # In the future, cloud-init will only attempt to use datasources that#
  # are identified or specifically configured. #
  # For more information see   #
  #   https://bugs.launchpad.net/bugs/1669675  #
  ##
  # If you are seeing this message, please file a bug against  #
  # cloud-init at  #
  #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid  #
  # Make sure to include the cloud provider your instance is   #
  # running on.#
  ##
  # After you have filed a bug, you can disable this warning by launching  #
  # your instance with the cloud-config below, or putting that content #
  # into /etc/cloud/cloud.cfg.d/99-warnings.cfg#
  ##
  # #cloud-config  #
  # warnings:  #
  #   dsid_missing_source: off #
  **

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1674861/+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 1665694] Re: cc_set_passwords fails to change passwords specified as chpasswd['list'] in cloud-config

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1665694

Title:
  cc_set_passwords fails to change passwords specified as
  chpasswd['list'] in cloud-config

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:
  === Being SRU Template ===
  [Impact]
  Users of cloud-init can change passwords on a system by providing input
  to chpasswd as a string:
    #cloud-config
    chpasswd:
  list: |
    user1:password1

  Confusingly, the 'list' is actually not a list, but a multi-line string.
  The change made in this bug supports either.

  [Test Case]
  There is an integration test in cloud-init that runs though this code.
  To run that:

  $ git clone https://git.launchpad.net/cloud-init
  $ cd cloud-init

  # download the appropriate deb for cloud-init from -proposed
  $ rel=xenial
  $ pver=$(rmadison --url=ubuntu --suite=$rel-proposed cloud-init | awk '{print 
$3}')
  $ fname="cloud-init_${pver}_all.deb"
  $ wget "http://archive.ubuntu.com/ubuntu/pool/main/c/cloud-init/$fname;
  $ ln -sf $fname cloud-init_all.$rel.deb
  $ tox -e citest -- run -v -n $rel --deb=cloud-init_all.$rel.deb \
 -t tests/cloud_tests/testcases/modules/set_password_list_string.py \
 -t tests/cloud_tests/testcases/modules/set_password_list.py

  That will install the new cloud-init into a container and run
  with user data to excercise this new feature.

  
  [Regression Potential]
  Very low regression potential.  The test case shown provides both
  the previously supported path (a string) and the new path (a list).

  [Other Info]
  Upstream commit:
   https://git.launchpad.net/cloud-init/commit/?id=7f2b51054a5defe

  === End SRU Template ===

  If cloud-config contains list of user:password pairs as in example
  below

  chpasswd:
    list:
  - user1:pwd001
  - user2:pwd002

  cc_set_passwords module fails to change passwords with error:
  Feb 17 15:52:48 si-man [CLOUDINIT] stages.py[DEBUG]: Running module 
set-passwords () with 
frequency once-per-instance
  Feb 17 15:52:48 si-man [CLOUDINIT] handlers.py[DEBUG]: start: 
modules-config/config-set-passwords: running config-set-passwords with 
frequency once-per-instance
  Feb 17 15:52:48 si-man [CLOUDINIT] util.py[DEBUG]: Writing to 
/var/lib/cloud/instances/6d822e81-98a1-4b43-bed2-db8d0cf045bb/sem/config_set_passwords
 - wb: [420] 25 bytes
  Feb 17 15:52:48 si-man [CLOUDINIT] helpers.py[DEBUG]: Running 
config-set-passwords using lock ()
  Feb 17 15:52:48 si-man [CLOUDINIT] cc_set_passwords.py[DEBUG]: Changing 
password for ["['user1"]:
  Feb 17 15:52:48 si-man [CLOUDINIT] util.py[DEBUG]: Running command 
['chpasswd'] with allowed return codes [0] (shell=False, capture=True)
  Feb 17 15:52:48 si-man [CLOUDINIT] util.py[WARNING]: Failed to set passwords 
with chpasswd for ["['user1"]
  Feb 17 15:52:48 si-man [CLOUDINIT] util.py[DEBUG]: Failed to set passwords 
with chpasswd for ["['user1"]#012Traceback (most recent call last):#012  File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_set_passwords.py", line 
121, in handle#012util.subp(['chpasswd'], ch_in)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 1836, in subp#012
cmd=args)#012cloudinit.util.ProcessExecutionError: Unexpected error while 
running command.#012Command: ['chpasswd']#012Exit code: 1#012Reason: 
-#012Stdout: ''#012Stderr: "chpasswd: (user ['user1) pam_chauthtok() failed, 
error:\nAuthentication token manipulation error\nchpasswd: (line 1, user 
['user1) password not changed\n"
  Feb 17 15:52:48 si-man [CLOUDINIT] util.py[DEBUG]: Running command ['passwd', 
'--expire', "['user1"] with allowed return codes [0] (shell=False, capture=True)
  Feb 17 15:52:48 si-man [CLOUDINIT] util.py[WARNING]: Failed to set 'expire' 
for ['user1
  Feb 17 15:52:48 si-man [CLOUDINIT] util.py[DEBUG]: Failed to set 'expire' for 
['user1#012Traceback (most recent call last):#012  File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_set_passwords.py", line 
136, in handle#012util.subp(['passwd', '--expire', u])#012  File 
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 1836, in subp#012
cmd=args)#012cloudinit.util.ProcessExecutionError: Unexpected error while 
running command.#012Command: ['passwd', '--expire', "['user1"]#012Exit code: 
1#012Reason: -#012Stdout: ''#012Stderr: "passwd: user '['user1' does not 
exist\n"
  Feb 17 15:52:48 si-man [CLOUDINIT] cc_set_passwords.py[DEBUG]: 2 errors 

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

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

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

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

Status in cloud-init:
  Fix Released
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 1673411] Re: config-drive support is broken

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1673411

Title:
  config-drive support is broken

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive newton series:
  Fix Released
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in cloud-init:
  Fix Released
Status in nova-lxd:
  Fix Released
Status in nova-lxd newton series:
  Fix Released
Status in nova-lxd ocata series:
  Fix Released
Status in nova-lxd trunk series:
  Fix Released
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:
  Fix Released
Status in nova-lxd source package in Xenial:
  Invalid
Status in cloud-init source package in Yakkety:
  Fix Released
Status in nova-lxd source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in nova-lxd source package in Zesty:
  Fix Released

Bug description:
  === Begin cloud-init SRU Template ===
  [Impact]
  nova-lxd can provide data to instances in 2 ways:
   a.) metadata service
   b.) config drive

  The support for reading the config drive in cloud-init was never
  functional.  Nova-lxd has changed the way they're presenting the config
  drive to the guest.  Now they are doing so by populating a directory in
  the container /config-drive with the information.
  The change added to cloud-init was to extend support read config drive
  information from that directory.

  [Test Case]
  With a nova-lxd that contains the fix this can be fully tested
  by launching an instance with updated cloud-init and config drive
  attached.

  For cloud-init, the easiest way to demonstrate this is to
  create a lxc container and populate it with a '/config-drive'.

  lxc-proposed-snapshot is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  $ release=xenial
  $ ref=xenial-proposed
  $ name=$release-lp1673411
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc init $ref $name

  # lxc will create the 'NoCloud' seed, and the normal search
  # path looks there first, so remove it.

  $ lxc file pull $name/etc/cloud/cloud.cfg.d/90_dpkg.cfg - |
  sed 's/NoCloud, //' |
  lxc file push - $name/etc/cloud/cloud.cfg.d/90_dpkg.cfg

  ## populate a /config-drive with attached 'make-config-drive-dir'
  ## and push it to the container

  $ d=$(mktemp -d)
  $ make-config-drive-dir "$d" "$name"
  $ rm -Rf "$d"

  ## start it and look around
  $ lxc start $name
  $ sleep 10
  $ lxc exec $name cat /run/cloud-init/result.json
  {
   "v1": {
    "datasource": "DataSourceConfigDrive [net,ver=2][source=/config-drive]",
    "errors": []
   }
  }

  [Regression Potential]
  There is a potentiali false positive where a user had data in
  /config-drive and now that information is read as config drive data.

  That would require a directory tree like:
    /config-drive/openstack/2???-??-??/meta_data.json
  or
    /config-drive/openstack/latest/meta_data.json

  Which seems like a small likelyhood of non-contrived hit.

  [Other Info]
  Upstream commit:
   https://git.launchpad.net/cloud-init/commit/?id=443095f4d4b6fe

  === End cloud-init SRU Template ===

  After reviewing https://review.openstack.org/#/c/445579/ and doing
  some testing, it would appear that the config-drive support in the
  nova-lxd driver is not functional.

  cloud-init ignores the data presented in /var/lib/cloud/data and reads
  from the network accessible metadata-service.

  To test this effectively you have to have a fully offline instance
  (i.e. no metadata service access).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1673411/+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 1670052] Re: cloud-init raises an exception when it sees more than 3 nameservers

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1670052

Title:
  cloud-init raises an exception when it sees more than 3 nameservers

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] 
  When rendering sysconfig (redhat/centos) output there was a bug
  where cloud-init would error if provided with more than 3 nameservers.

  That was changed to a warning.
 
  [Test Case]
  This can't really be tested on Ubuntu, as ubuntu does not render
  sysconfig network information.
   
  [Regression Potential] 
  Low everywhere (change ValueError to a WARN) and lower on Ubuntu,
  where the code is not in the run path.
 
  [Other Info]
  Upstream commit:
   https://git.launchpad.net/cloud-init/commit/?id=657fd40f9ee692a
 
  === End SRU Template ===

  When running in an environment that provides more than 3 nameservers,
  cloud-init will raise a ValueError exception:

    Mar 04 18:03:01 localhost.localdomain cloud-init[901]: ValueError:
  Adding '8.8.8.8' would go beyond the '3' maximum name servers

  While that is a legitimate complaint, raising an exception seems like
  the wrong response, because this results in *no* nameserver
  configuration, which can have a substantial operational impact on the
  system.  Cloud-init should probably just log a warning in this case,
  and ignore any nameservers received after the first three.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1670052/+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 1088611] Re: using random hostnames to detect dns proxies allows for false positives

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** 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/1088611

Title:
  using random hostnames to detect dns proxies allows for false
  positives

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 Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  Prior to this fix, cloud-init attempts to detect dns redirection by doing
  dns queries for a random hostname and two invalid hostnames.  Then, if
  the result returned for the input value was the same as the response for
  the invalid query cloud-init would assume that result was also invalid.

  The change was to replace the random string with
__cloud_init_expected_not_found__
  This is a valid hostname and resolution will use the 'search' path in
  resolv.conf where the other invalid domain names would not.

  [Test Case]
  The test case for this consists of excercising the the 'is_resolvable_url'
  method in cloudinit.util and watching dns queries.  To do this, see the
  following steps:
  a.) start an lxc container
 $ release=xenial
 $ name=$release-1088611
 $ lxc launch ubuntu-daily:$release $name
  b.) start a dnsmasq server
 $ ./run-dnsmasq lxdbr0
 ... 
 === listening on 10.75.205.2/24 ===

 # run-dnsmasq is attached and at
 #  
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bugs/lp-1088611/run-dnsmasq

  c.) point /etc/resolv.conf at your server ip
 $ lxc exec $name -- sh -c 'exec >/etc/resolv.conf;
 echo nameserver 10.75.205.2; echo search foo;'

  d.) perform query via is_resolvable_url watch dnsmasq output, expect
  to see the random query.
 $ lxc exec $name -- python3 -c 'import sys;
  from cloudinit.util import is_resolvable_url; 
  print(is_resolvable_url(sys.argv[1]))' http://ubuntu.com

  e.) upgrade to -proposed version
  f.) perform query via is_resolvable_url, expect to *not* see random query.

  [Regression Potential]
  Immediate regression seems unlikely.  Effectively the change in cloud-init
  code path was simply to change a dns lookup attempt from rand() to a defined
  string.

  We chose a random string initially to make it difficult for a dns server to
  circumvent cloud-init's attempt to identify dns redirection.  The regression
  path really then seems to involve a dns redirection service specifically
  provding a response for '__cloud_init_expected_not_found__' that differs
  from does-not-exist.example.com.  Cloud-init could then be tricked into
  believing that a apt mirror was valid where it previously would have
  identified the dns redirection.  The failure would be seen as errors
  in package installation or 'apt-get update'.

  [Other Info]
  Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=42a7b34a12

  Original upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=1bb67be5bd

  === End SRU Template ===

  The fix that's been applied for bug #974509 checks for the presence of
  a redirector by looking of three hostnames, and treating as invalid
  any results pointing to a matching address:

   - does-not-exist.example.com.
   - example.invalid.
   - a random, unqualified 32-character alphanumeric hostname.

  The last of these carries a small but non-zero risk of colliding with
  a real hostname, and there's a small but non-zero risk that this host
  points to the same address as something we care about.  If possible,
  it would be better to not include this random-host lookup in the
  algorithm, as somewhere, some day, chances are there will eventually
  be a collision, causing an incomprehensible and unreproducible failure
  for a user.

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