[Yahoo-eng-team] [Bug 1795786] [NEW] glance-cache-manage need to be removed from documentation?

[Abhishek Kekane]

Public bug reported:

When I try to run glance-cache-manage command it returns following
error.

glance-cache-manage --help
Traceback (most recent call last):
  File "/usr/local/bin/glance-cache-manage", line 6, in 
from glance.cmd.cache_manage import main
ImportError: No module named 'glance.cmd.cache_manage'

This command is removed from the code base during v1 removal [1] but
still present in documentation.

[1]
https://review.openstack.org/#/c/532503/10/glance/cmd/cache_manage.py

** Affects: glance
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1795786

Title:
  glance-cache-manage need to be removed from documentation?

Status in Glance:
  New

Bug description:
  When I try to run glance-cache-manage command it returns following
  error.

  glance-cache-manage --help
  Traceback (most recent call last):
File "/usr/local/bin/glance-cache-manage", line 6, in 
  from glance.cmd.cache_manage import main
  ImportError: No module named 'glance.cmd.cache_manage'

  This command is removed from the code base during v1 removal [1] but
  still present in documentation.

  [1]
  https://review.openstack.org/#/c/532503/10/glance/cmd/cache_manage.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1795786/+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 1795482] Re: Deleting network namespaces sometimes fails in check/gate queue with ENOENT

[OpenStack Infra]

Reviewed:  https://review.openstack.org/607009
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=00de8f9a9e36bbca6ef7f0c17c2e6f74a144a358
Submitter: Zuul
Branch:master

commit 00de8f9a9e36bbca6ef7f0c17c2e6f74a144a358
Author: Brian Haley 
Date:   Mon Oct 1 13:49:32 2018 -0400

Do not fail deleting namespace if it does not exist

Note: this is a squash of two changes since they are
dependent on each other, and are currently blocking
the gate queue.

Sometimes cleanup methods are failing in the check and
gate queues trying to delete non-existing namespaces.
Since they could have been deleted asynchronously, don't
raise if the failure is "No such file or directory" since
the system is in the intended state.

Cleaned-up the DHCP agent to longer check for existence
first, and the tests to longer mock-out the namespace
exists check.

Fix test_legacy_router_lifecycle failures

Multi-path routes returned via the pyroute2 library have
their outgoing interfaces in the 'multipath' dictionary
element, not in the route dictionary.  In that case return
all the multipath routes correctly.

Change-Id: I5415cb3a88ff2640a19598a1fcb2278388815343
Closes-bug: #1795482
Closes-bug: #1795548


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1795482

Title:
  Deleting network namespaces sometimes fails in check/gate queue with
  ENOENT

Status in neutron:
  Fix Released

Bug description:
  I have seen the fullstack tests sometimes fail, complaining that the
  namespace doesn't exist.  An example is here:

  http://logs.openstack.org/79/604179/1/check/neutron-fullstack-
  python36/9b41cd5/logs/testr_results.html.gz

  End of stack trace for reference:

   File "/opt/stack/new/neutron/neutron/tests/fullstack/resources/process.py", 
line 354, in clean_dhcp_namespaces
  ip_lib.delete_network_namespace(namespace)
File "/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 1103, in 
delete_network_namespace
  privileged.remove_netns(namespace, **kwargs)
File 
"/opt/stack/new/neutron/.tox/dsvm-fullstack-python35/lib/python3.5/site-packages/oslo_privsep/priv_context.py",
 line 207, in _wrap
  return self.channel.remote_call(name, args, kwargs)
File 
"/opt/stack/new/neutron/.tox/dsvm-fullstack-python35/lib/python3.5/site-packages/oslo_privsep/daemon.py",
 line 202, in remote_call
  raise exc_type(*result[2])
  FileNotFoundError: [Errno 2] No such file or directory

  While some callers check for RuntimeError, none check for this OSError
  errno.ENOENT case.

  In this case, I don't believe we should be returning an error at all,
  since an asynchronous event could have deleted the namespace, and
  since it's no longer there we are in the desired state.

  This will help with some of the recent issues we've had getting code
  merged.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1795482/+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 1795548] Re: neutron.tests.functional.agent.l3.test_legacy_router.L3AgentTestCase.test_legacy_router_lifecycle* fail

[OpenStack Infra]

Reviewed:  https://review.openstack.org/607009
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=00de8f9a9e36bbca6ef7f0c17c2e6f74a144a358
Submitter: Zuul
Branch:master

commit 00de8f9a9e36bbca6ef7f0c17c2e6f74a144a358
Author: Brian Haley 
Date:   Mon Oct 1 13:49:32 2018 -0400

Do not fail deleting namespace if it does not exist

Note: this is a squash of two changes since they are
dependent on each other, and are currently blocking
the gate queue.

Sometimes cleanup methods are failing in the check and
gate queues trying to delete non-existing namespaces.
Since they could have been deleted asynchronously, don't
raise if the failure is "No such file or directory" since
the system is in the intended state.

Cleaned-up the DHCP agent to longer check for existence
first, and the tests to longer mock-out the namespace
exists check.

Fix test_legacy_router_lifecycle failures

Multi-path routes returned via the pyroute2 library have
their outgoing interfaces in the 'multipath' dictionary
element, not in the route dictionary.  In that case return
all the multipath routes correctly.

Change-Id: I5415cb3a88ff2640a19598a1fcb2278388815343
Closes-bug: #1795482
Closes-bug: #1795548


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1795548

Title:
  
neutron.tests.functional.agent.l3.test_legacy_router.L3AgentTestCase.test_legacy_router_lifecycle*
  fail

Status in neutron:
  Fix Released

Bug description:
  I keep seeing these two tests fail:

  http://logs.openstack.org/05/606205/2/check/neutron-
  functional/66c9475/logs/testr_results.html.gz

  Example stack trace:

  Traceback (most recent call last):
File "neutron/tests/base.py", line 137, in func
  return f(self, *args, **kwargs)
File "neutron/tests/functional/agent/l3/test_legacy_router.py", line 85, in 
test_legacy_router_lifecycle
  self._router_lifecycle(enable_ha=False, dual_stack=True)
File "neutron/tests/functional/agent/l3/framework.py", line 302, in 
_router_lifecycle
  self._assert_onlink_subnet_routes(router, ip_versions)
File "neutron/tests/functional/agent/l3/framework.py", line 526, in 
_assert_onlink_subnet_routes
  namespace=ns_name)
File "neutron/agent/linux/ip_lib.py", line 1030, in get_routing_table
  return list(privileged.get_routing_table(ip_version, namespace))
File 
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_privsep/priv_context.py",
 line 207, in _wrap
  return self.channel.remote_call(name, args, kwargs)
File 
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_privsep/daemon.py",
 line 202, in remote_call
  raise exc_type(*result[2])
  KeyError

  I think the problem is that in the privsep get_routing_table code, one
  of the IPv6 routes does not have an integer in the route['oif']
  element, it is None, raising the KeyError.

  For example, here is a list of IPv6 routes on my local system:

  --> ip -6 r
  2601:18f:700:c12d::/64 dev enp0s31f6  proto ra  metric 100  pref medium
  fe80::/64 dev enp0s31f6  proto kernel  metric 256  pref medium
  fe80::/64 dev tun0  proto kernel  metric 256  pref medium
  default via fe80::9ade:d0ff:fe25:7710 dev enp0s31f6  proto static  metric 100 
 pref medium

  But a little test program I wrote shows iproute2 returns no 'oif':

  dst: fe80::/64
  gateway: None
  oif: None
  Traceback (most recent call last):
File "", line 1, in 
File "./getroute.py", line 78, in foo
  routes = list(get_routing_table(6))
File "./getroute.py", line 50, in get_routing_table
  print 'interface: %s' % ipdb_interfaces[route['oif']]['ifname']
  KeyError: None

  Digging further, since there are two routes to fe80::/64, it's
  returned differently from pyroute2:

  {'metrics': {}, 'dst_len': 64, 'family': 10, 'proto': 2, 'tos': 0,
  'dst': 'fe80::/64', 'pref': '00', 'ipdb_priority': 0, 'priority': 256,
  'flags': 0, 'encap': {}, 'src_len': 0, 'table': 254, 'multipath':
  ({'oif': 2, 'family': 10}, {'oif': 6, 'dst_len': 64, 'family': 10,
  'proto': 2, 'tos': 0, 'pref': '00', 'priority': 256, 'flags': 0,
  'encap': {}, 'src_len': 0, 'table': 254, 'type': 1, 'scope': 0}),
  'type': 1, 'scope': 0, 'ipdb_scope': 'system'}

  So it looks like we need to parse this 'multipath' element, but there
  are two items in the list, so we have to parse them both.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1795548/+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 1778771] Re: Backups panel is visible even if enable_backup is False

[Launchpad Bug Tracker]

This bug was fixed in the package horizon - 3:14.0.0-0ubuntu4

---
horizon (3:14.0.0-0ubuntu4) cosmic; urgency=medium

  * d/p/add-enabled-check-in-backups-panel.patch: Cherry-picked from
https://review.openstack.org/#/c/605715 to ensure Volume Backups panel
is disabled if enable_backup is False (LP: #1778771).

 -- Corey Bryant   Mon, 01 Oct 2018 15:04:31
-0400

** Changed in: horizon (Ubuntu Cosmic)
   Status: Fix Committed => Fix Released

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

Title:
  Backups panel is visible even if enable_backup is False

Status in OpenStack openstack-dashboard charm:
  In Progress
Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in Ubuntu Cloud Archive rocky series:
  Fix Committed
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in horizon package in Ubuntu:
  Fix Released
Status in horizon source package in Bionic:
  Triaged
Status in horizon source package in Cosmic:
  Fix Released

Bug description:
  Hi,

  Volumes - Backup panel is visible even if OPENSTACK_CINDER_FEATURES =
  {'enable_backup': False} in local_settings.py

  Meanwhile setting enable_backup to false removes an option to create
  backup of a volume in the volume drop-down options. But panel with
  backups itself stays visible for both admins and users.

  As a work-around I use the following customization script:
  import horizon
  from django.conf import settings
  if not getattr(settings, 'OPENSTACK_CINDER_FEATURES', 
{}).get('enable_backup', False):
  project = horizon.get_dashboard("project")
  backup = project.get_panel("backups")
  project.unregister(backup.__class__)

  And for permanent fix I see the following decision. In 
openstack_dashboard/dashboards/project/backups/panel.py make the following 
changes:
  ...
  +L16: from django.conf import settings
  ...
  +L21: if not getattr(settings, 'OPENSTACK_CINDER_FEATURES', 
{}).get('enable_backup', False):
  +L22: return False
  ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1778771/+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 1794552] Re: Flaskification broke ECP

[OpenStack Infra]

Reviewed:  https://review.openstack.org/606195
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=1efecc92c09d5f691fac1e9373ff123b549ced39
Submitter: Zuul
Branch:master

commit 1efecc92c09d5f691fac1e9373ff123b549ced39
Author: Morgan Fainberg 
Date:   Fri Sep 28 13:08:37 2018 -0700

Properly replace flask view args in links

When the API Prefix is used in a Flask API, it is possible the flask
view argument specification will bleed through to the self link instead
of a properly formated url.

The add_self_reference_links mechanism in keystone.server.flask.common
now substitutes out the self link to the {} substitution and applies
a .format() utilizing the view args to the URI in the self link.

Change-Id: Ic5c89c285ed964de7411b273567bb97fcf43da06
closes-bug: #1794552


** Changed in: keystone
   Status: In Progress => Fix Released

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

Title:
  Flaskification broke ECP

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  THe Federation itegration (not voting) tests for Python35 are failing.

  
   ==
  2018-09-26 06:26:21.371093 | primary | Failed 1 tests - output below:
  2018-09-26 06:26:21.371172 | primary | ==
  2018-09-26 06:26:21.371200 | primary |
  2018-09-26 06:26:21.371360 | primary | 
keystone_tempest_plugin.tests.scenario.test_federated_authentication.TestSaml2EcpFederatedAuthentication.test_request_scoped_token
  2018-09-26 06:26:21.371521 | primary | 
--
  2018-09-26 06:26:21.371538 | primary |
  2018-09-26 06:26:21.371576 | primary | Captured traceback:
  2018-09-26 06:26:21.371614 | primary | ~~~
  2018-09-26 06:26:21.371675 | primary | b'Traceback (most recent call 
last):'
  2018-09-26 06:26:21.371900 | primary | b'  File 
"/opt/stack/new/tempest/.tox/tempest/lib/python3.5/site-packages/keystone_tempest_plugin/tests/scenario/test_federated_authentication.py",
 line 176, in test_request_scoped_token'
  2018-09-26 06:26:21.371979 | primary | b"
project_id=projects[0]['id'], token=token_id)"
  2018-09-26 06:26:21.372155 | primary | b'  File 
"/opt/stack/new/tempest/tempest/lib/services/identity/v3/token_client.py", line 
140, in auth'
  2018-09-26 06:26:21.372357 | primary | b'resp, body = 
self.post(self.auth_url, body=body)'
  2018-09-26 06:26:21.372573 | primary | b'  File 
"/opt/stack/new/tempest/tempest/lib/common/rest_client.py", line 279, in post'
  2018-09-26 06:26:21.372724 | primary | b"return self.request('POST', 
url, extra_headers, headers, body, chunked)"
  2018-09-26 06:26:21.372881 | primary | b'  File 
"/opt/stack/new/tempest/tempest/lib/services/identity/v3/token_client.py", line 
172, in request'
  2018-09-26 06:26:21.372961 | primary | b"'Unexpected status code 
{0}'.format(resp.status))"
  2018-09-26 06:26:21.373034 | primary | 
b'tempest.lib.exceptions.IdentityError: Got identity error'
  2018-09-26 06:26:21.373088 | primary | b'Details: Unexpected status code 
500'
  2018-09-26 06:26:21.373108 | primary | b''


  Looking in the logs for Keystone show an improper string replacement:

  /OS-FEDERATION/identity_providers//protocols

  See below

  
  2018-09-26 06:26:16.800826 | primary | b'Body: b\'{"protocol": 
{"links": {"self": 
"http://149.202.181.254/identity/v3/OS-FEDERATION/identity_providers//protocols/mapped",
 "identity_provider": "http://149.202.181.254/identity/v3/testshib"}, 
"mapping_id": "608508b0cd09476289b2be05bcca98e3", "id": "mapped"}}\\n\''
  2018-09-26 06:26:16.801021 | primary | b'2018-09-26 06:26:16,423 30292 
INFO [tempest.lib.common.rest_client] Request 
(TestSaml2EcpFederatedAuthentication:test_request_scoped_token): 500 POST 
http://149.202.181.254/identity/v3/auth/tokens'
  2018-09-26 06:26:16.801187 | primary | b"2018-09-26 06:26:16,424 30292 
DEBUG[tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 
'application/json', 'Accept': 'application/json'}"
  2018-09-26 06:26:16.801241 | primary | b'Body: '
  2018-09-26 06:26:16.801530 | primary | b"Response - Headers: 
{'connection': 'close', 'content-type': 'application/json', 'server': 
'Apache/2.4.18 (Ubuntu)', 'date': 'Wed, 26 Sep 2018 06:26:16 GMT', 
'x-openstack-request-id': 'req-2185af52-06fa-41c3-80eb-de3d5e667380', 
'content-location': 'http://149.202.181.254/identity/v3/auth/tokens', 
'content-length': '143', 'vary': 'X-Auth-Token', 'status': '500'}"
  2018-09-26 06:26:16.801855 | primary | b'Body: b\'{"error": 
{"message": "An unexpected error prevented the server from 

[Yahoo-eng-team] [Bug 1795078] Re: "OsloDBDeprecationWarning: EngineFacade is deprecated; please use oslo_db.sqlalchemy.enginefacade" warnings emitted numerous times during py3 unit tests

[OpenStack Infra]

Reviewed:  https://review.openstack.org/606213
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=020651ad3d14066af34dc5d1d96cec7c6ffe5cd9
Submitter: Zuul
Branch:master

commit 020651ad3d14066af34dc5d1d96cec7c6ffe5cd9
Author: melanie witt 
Date:   Fri Sep 28 22:07:42 2018 +

Replace usage of get_legacy_facade() with get_engine()

We've been seeing warnings emitted to the python 3 unit tests:

  OsloDBDeprecationWarning: EngineFacade is deprecated; please use
  oslo_db.sqlalchemy.enginefacade

which stem from our use of the get_legacy_facade() oslo.db method.

This replaces the get_legacy_facade() usage with the get_engine()
method from the transaction context manager.

Closes-Bug: #1795078

Change-Id: If1e355d6174f15a1880e97115a2cf3f9f4be837e


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  "OsloDBDeprecationWarning: EngineFacade is deprecated; please use
  oslo_db.sqlalchemy.enginefacade" warnings emitted numerous times
  during py3 unit tests

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Seen in the openstack-tox-py35 [1]:

  2018-09-26 17:20:32.001487 | ubuntu-xenial | 
/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/oslo_db/sqlalchemy/enginefacade.py:350:
 OsloDBDeprecationWarning: EngineFacade is deprecated; please use 
oslo_db.sqlalchemy.enginefacade
  2018-09-26 17:20:32.001833 | ubuntu-xenial |   self._legacy_facade = 
LegacyEngineFacade(None, _factory=self)

  and openstack-tox-py36 jobs:

  2018-09-28 11:39:03.066777 | ubuntu-bionic | 
b'/home/zuul/src/git.openstack.org/openstack/nova/.tox/py36/lib/python3.6/site-packages/oslo_db/sqlalchemy/enginefacade.py:350:
 OsloDBDeprecationWarning: EngineFacade is deprecated; please use 
oslo_db.sqlalchemy.enginefacade'
  2018-09-28 11:39:03.066944 | ubuntu-bionic | b'  self._legacy_facade = 
LegacyEngineFacade(None, _factory=self)'

  [1] 
http://logs.openstack.org/97/410297/44/gate/openstack-tox-py35/9d96763/job-output.txt#_2018-09-26_17_14_52_089548
  [2] 
http://logs.openstack.org/16/270116/18/check/openstack-tox-py36/56e7491/job-output.txt.gz#_2018-09-28_11_39_03_066777

  I think this issue stems from our use of the get_legacy_facade()
  method in the DB API, so we need to update to use the get_engine()
  method from the transaction context manager class instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1795078/+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 1795747] [NEW] libvirtError: unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' when try to creat

[Eduardo Francis Batista]

Public bug reported:

Description
===

Error occurs when an instance with two volumes (created from SCSI image). From 
nova-compute.log, the following information related to volume attachment 
(address has no bus, target and unit informations):
 
  
  
  
  8fc346e1-fdf4-420a-b6cd-5ee97e97a5b8
  


  
  
  
  7f3b3f37-8449-4fc1-9d8d-0ba691aeacfb
  


But when instance is created with only one volume and second volume is attached 
later (with openstack volume attach .. command), it's configured differently:

  
  
  
  
  20fb8417-3ece-46f0-affb-d80800a885dd
  
  


  
  
  
  
  2d087117-bc51-48ae-9c4d-00950deeb617
  
  


Steps to reproduce
==

1 - Using an admin openstack account, create a cirros image with scsi
properties:

wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
openstack image create "cirros_scsi" \
  --file cirros-0.3.5-x86_64-disk.img \
  --disk-format qcow2 --container-format bare \
  --property hw_disk_bus=scsi \
  --property hw_scsi_controller=virtio-scsi \
  --public

2 - Create two volumes (volume-backed image) using cirros_scsi image:
openstack volume create --size 1 volume-0 --image cirros_scsi
openstack volume create --size 1 volume-1 --image cirros_scsi

3 - Create an instance using two volumes (error scenario):
v1id=`openstack volume show volume-0 | grep " id " | awk '{print $4}'` && echo 
$v1id
v2id=`openstack volume show volume-1 | grep " id " | awk '{print $4}'` && echo 
$v2id
nova boot --flavor m1.nano \
   --block-device source=volume,id=$v1id,shutdown=preserve,bootindex=0 \
   --block-device source=volume,id=$v2id,shutdown=preserve,bootindex=1 \
   --nic net-id=77669d98-2bc2-4a48-aa6f-7184ec99698c \
   --key mykey instance01

nova boot --flavor $flavor_id \
   --block-device source=volume,id=$v1id,shutdown=preserve,bootindex=0 \
   --block-device source=volume,id=$v2id,shutdown=preserve,bootindex=1 \
   --nic net-id= \
   --key  instance01

4 - Check instance
openstack server list
openstack volume list

Expected result
===
Instance should be created normally;

Actual result
=
(openstack) server list
+--+++--+---+-+
| ID   | Name   | Status | Networks | Image 
| Flavor  |
+--+++--+---+-+
| 6717d471-2092-48c8-8a4f-463ff8afc5bb | instance01 | ERROR  |  |   
| m1.nano |
+--+++--+---+-+

root@cldsrv02 ~]# openstack server show instance01 -f shell | grep fault
fault="{u'message': u'Exceeded maximum number of retries. Exhausted all hosts 
available for retrying build failures for instance 
6717d471-2092-48c8-8a4f-463ff8afc5bb.', u'code': 500, u'details': u'  File 
"/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 580, in 
build_instances\nraise exception.MaxRetriesExceeded(reason=msg)\n', 
u'created': u'2018-10-02T21:24:23Z'}"

Error reported in /var/log/nova/nova-compute.log:
lugin='linux_bridge',port_profile=,preserve_on_delete=False,vif_name='tap7946d21b-8f')
2018-10-02 17:24:09.694 17390 ERROR nova.virt.libvirt.guest 
[req-6105a653-1bdd-4812-83a5-2f68bf3e4b7a f04ef8cc6c7c46f782488ff162dcdef2 
bf7678e543da4c4a9703a0196efda6e9 - default default] Error defining a guest with 
XML: 
  6717d471-2092-48c8-8a4f-463ff8afc5bb
  instance-0008
  65536
  1
  
http://openstack.org/xmlns/libvirt/nova/1.0;>
  
  instance01
  2018-10-02 21:24:07
  
64
1
0
0
1
  
  
admin
admin
  

  
  

  RDO
  OpenStack Compute
  17.0.5-1.el7
  1235d097-6a37-4c00-a5e5-33ccae494775
  6717d471-2092-48c8-8a4f-463ff8afc5bb
  Virtual Machine

  
  
hvm


  
  


  
  
1024
  
  
  

  
  

  
  
  
  0ce95aac-3205-4aa3-830b-c65113f0c9f7
  


  
  
  
  08e55f7d-78e8-4e5a-bdfc-2f7ebcd0ee27
  


  
  
  
  
  


  




  


  

  

: libvirtError: unsupported configuration: Found duplicate drive address for 
disk with target name 'sda' controller='0' bus='0' target='0' unit='0'

2018-10-02 17:24:14.189 17390 ERROR nova.compute.manager 
[req-6105a653-1bdd-4812-83a5-2f68bf3e4b7a f04ef8cc6c7c46f782488ff162dcdef2 
bf7678e543da4c4a9703a0196efda6e9 - default default] [instance: 
6717d471-2092-48c8-8a4f-463ff8afc5bb] Instance failed to spawn: libvirtError: 
unsupported configuration: Found duplicate drive address for disk with target 
name 'sda' controller='0' bus='0' target='0' unit='0'
2018-10-02 17:24:14.189 17390 ERROR nova.compute.manager [instance: 

[Yahoo-eng-team] [Bug 1768547] Re: OpenNebula DataSource adds null gateway6 to netplan config

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1768547

Title:
  OpenNebula DataSource adds null gateway6 to netplan config

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

Bug description:
  Hello,

  In Ubuntu 18.04 with cloud-init 18.2-14-g6d48d265-0ubuntu1, the OpenNebula 
data source generates an invalid netplan yaml file if the IPv6 gateway is not 
defined in context.sh:
  network:
  ethernets:
  eth0:
  addresses:
  - 10.22.33.44/22
  gateway4: 10.22.33.1
  gateway6: null
  match:
  macaddress: 02:00:00:00:aa:bb
  nameservers:
  addresses:
  - 10.22.22.22
  - 10.33.33.33
  version: 2

  Netplan will not apply this config:
  # netplan try
  Error in network definition //etc/netplan/50-cloud-init.yaml line 11 column 
22: invalid IPv6 address 'null'

  This is due to a typo in DataSourceOpenNebula.py, attached is a patch
  which fixes it.

  Cheers,
  Corey Melanson

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1768547/+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 1766538] Re: network customization with cloud-init does not work on Ubuntu18.04 Beta2 Server

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1766538

Title:
  network customization with cloud-init does not work on Ubuntu18.04
  Beta2 Server

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

Bug description:
  This issue does NOT exist on Ubuntu18.04 Beta2 Desktop, it only
  reproduces on Ubuntu18.04 Beta2 Server

  Ubuntu18.04 Beta2 Server is installed on a VMware VM.

  VMware customization Config File was copied to /var/run/vmware-imc/cust.cfg 
correctly.
  Check cloud-init.log, it parsed the cust.cfg, but VM network is not 
customized correctly according to cust.cfg.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1766538/+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 1727876] Re: Document in RTD that cloud-init users shouldn't write to /tmp due races with systemd LP:1707222

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1727876

Title:
  Document in RTD that cloud-init users shouldn't write to /tmp due
  races with systemd LP:1707222

Status in cloud-init:
  Fix Released

Bug description:
  Since cloud-init races with systemd cleanup of /tmp per LP: #1707222. We need 
to change doc examples which mention this issue when writing things to /tmp.
We should also add a note or special consideration to cloud-init RTD about this 
case where pertinent so that users don't go down this route.
  affects cloud-init 17.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1727876/+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 1778737] Re: salt-minion test needs fixing

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1778737

Title:
  salt-minion test needs fixing

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init-integration-lxd-b test 200 failed.
  Looking at the console log at [1] shows
boot instance encountered error: ssh: after 120s instance is not reachable
  at 2018-06-26 11:23:47,693 which was indeed 120 seconds after starting the
  salt minion test.

  The summary of the failure is just that salt failed to restart due to dns
  lookup problems of a host 'salt'.

  The corresponding cloud-init log [2] progresses well until

2018-06-26 11:22:16,726 - util.py[DEBUG]: Running command ['service', 
'salt-minion', 'restart'] with allowed return codes [0] (shell=False, 
capture=False)
2018-06-26 11:23:47,032 - handlers.py[DEBUG]: finish: 
modules-final/config-salt-minion: SUCCESS: config-salt-minion ran successfully

  So 'service salt-minion restart' took ~ 90 seconds.
   $ journalctl --file=system.journal --unit=salt-minion.service | pastebinit
   http://paste.ubuntu.com/p/jjkrs3nhYF/

  Lines of most interest there are 3 times:
Jun 26 07:22:17 [1241]: [ERROR   ] DNS lookup or connection check of 'salt' 
failed.
Jun 26 07:22:17 [1241]: [ERROR   ] Master hostname: 'salt' not found or not 
responsive. Retrying in 30 seconds

  [1] 
https://jenkins.ubuntu.com/server/job/cloud-init-integration-lxd-b/200/consoleFull
  [2] 
https://jenkins.ubuntu.com/server/job/cloud-init-integration-lxd-b/200/artifact/cloud-init/results/lxd/bionic/modules/salt_minion/cloud-init.log

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1778737/+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 1781094] Re: cloud.cfg.tmpl should not include "ssh_deletekeys: 0"

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1781094

Title:
  cloud.cfg.tmpl should not include "ssh_deletekeys: 0"

Status in cloud-init:
  Fix Released

Bug description:
  It seems that cloud-init inherited from Fedora the inclusion of
  "ssh_deletekeys: 0" in cloud.cfg.tmpl (commit 41d46bfb85).  This is
  risky in orchestration environments where an instance might be used as
  a master or template, and cloned from without other tools removing SSH
  host keys.  We believe that line should be removed from cloud.cfg.tmpl
  to reduce the risk of it being used in such environments.

  CVE-2018-10896 has been assigned [1].  On the Fedora bug [2] we are
  looking into history.

  1: https://access.redhat.com/security/cve/cve-2018-10896
  2: https://bugzilla.redhat.com/show_bug.cgi?id=1598832

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1781094/+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 1780481] Re: ubuntu/centos/debian: get_linux_distro has different behavior than platform.dist

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1780481

Title:
  ubuntu/centos/debian: get_linux_distro has different behavior than
  platform.dist

Status in cloud-init:
  Fix Released

Bug description:
  Recently cloudinit added get_linux_distro to replace platform.dist() 
functionality.
  The behavior returned a tuple on ubuntu that doens't match the platform.dist 
module.

  python3 -c 'from platform import dist; from cloudinit.util import 
get_linux_distro; print(dist()); print(get_linux_distro())'
  ('Ubuntu', '16.04', 'xenial')
  ('ubuntu', '16.04', 'x86_64')


  This breaks ntp configuration in cloud-init on xenial, which checks
  (_name, _version, codename) = util.system_info()['dist']
  if codename == "xenial" and not util.system_is_snappy():
  ...

  
  Also CentOS 7 behavior:
  [root@c71 ~]# python -c 'from platform import dist; from cloudinit.util 
import get_linux_distro; print(dist()); print(get_linux_distro())'
  ('centos', '7.5.1804', 'Core')
  ('centos', '7', 'x86_64')

  Debian stretch:
  root@debStretch:~# python -c 'from platform import dist; 
print(dist());'('debian', '9.4', '')

  
  openSuse 42.3:
  sles42:~ # python3 -c 'from platform import dist; print(dist());'
  ('SuSE', '42.3', 'x86_64')

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1780481/+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 1682064] Re: cloud-init should support config bond mac address

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1682064

Title:
  cloud-init should support config bond mac address

Status in cloud-init:
  Fix Released

Bug description:
  In OpenStack ocata, Ironic support portgroup which meaning bond for
  cloudinit. In case of using ironic through nova, the MAC address for
  bonded NICs of the bare metal server is populated by neutron for the
  VIF’s address representing this portgroup. If the MAC address can not
  be configured, the bare metal server will not be able to get ip via
  DHCP

  References: 
  
http://specs.openstack.org/openstack/ironic-specs/specs/approved/ironic-ml2-integration.html
  
https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1682064/+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 1784699] Re: cloud-init not setting mac address for bond or bridge in bionic

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1784699

Title:
  cloud-init not setting mac address for bond or bridge in bionic

Status in cloud-init:
  Fix Released

Bug description:
  When deploying bionic, cloud-init doesn't set the mac address for the
  bond or bridge interface, which causes issues when there's
  expectations between MAC/IP mappings.

  For example, in Bionic:

  curtin config sent (/etc/cloud/cloud.cfg.d/50-curtin-networking.cfg): 
http://paste.ubuntu.com/p/25GnQXQVhn/
  neplan config written to netplan (/etc/netplan/50-cloud-init.cfg): 
http://paste.ubuntu.com/p/XGQRzjGTDm/

  The result is that each interface have a different MAC address from
  those told in the configuration:

  ip addr sh: http://paste.ubuntu.com/p/25GnQXQVhn/

  This results in inconsistency which was configured and intended by the
  user, vs what it was actually written.

  For example, in Xenial, the issue above doesn't exist and the result
  is as expected:

  curtin config: http://paste.ubuntu.com/p/DmFvryXdwm/
  e/n/i config: http://paste.ubuntu.com/p/fsXYpmMzCb/
  ip addr sh: http://paste.ubuntu.com/p/wXXSTNfwHK/

  Also note that in my configuration, I kept the same mac addresses for
  bridges/bond as the physical interfaces, but if I were to randomize
  those or choose other ones, the behavior is the same.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1784699/+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 1792799] Re: Host environment bleeds into test for mirror access testing

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1792799

Title:
  Host environment bleeds into test for mirror access testing

Status in cloud-init:
  Fix Released

Bug description:
  FAIL: 
tests.unittests.test_handler.test_handler_apt_source_v3.TestAptSourceConfig.test_apt_v3_mirror_search_dns
  --
  Traceback (most recent call last):
File 
"/work/rjschwei/devel/cloud-init/tests/unittests/test_handler/test_handler_apt_source_v3.py",
 line 988, in test_apt_v3_mirror_search_dns
  mockse.assert_has_calls(calls)
File "/usr/lib64/python3.6/unittest/mock.py", line 846, in assert_has_calls
  ) from cause
  AssertionError: Calls not found.
  Expected: [call(None),
   call(['http://ubuntu-mirror.localdomain/ubuntu', 
'http://ubuntu-mirror/ubuntu']),
   call(None),
   call(['http://ubuntu-security-mirror.localdomain/ubuntu', 
'http://ubuntu-security-mirror/ubuntu'])]
  Actual: [call(None),
   call(['http://ubuntu-mirror.suse.de/ubuntu', 
'http://ubuntu-mirror.localdomain/ubuntu', 'http://ubuntu-mirror/ubuntu']),
   call(None),
   call(['http://ubuntu-security-mirror.suse.de/ubuntu', 
'http://ubuntu-security-mirror.localdomain/ubuntu', 
'http://ubuntu-security-mirror/ubuntu'])]
   >> begin captured logging << 
  tests.unittests.test_handler.test_handler_apt_configure_sources_list_v3: 
DEBUG: got primary mirror: http://mocked/foo
  tests.unittests.test_handler.test_handler_apt_configure_sources_list_v3: 
DEBUG: got security mirror: http://mocked/foo
  tests.unittests.test_handler.test_handler_apt_configure_sources_list_v3: 
DEBUG: got primary mirror: http://mocked/foo
  tests.unittests.test_handler.test_handler_apt_configure_sources_list_v3: 
DEBUG: got security mirror: http://mocked/foo
  cloudinit.util: DEBUG: Reading from /tmp/tmpsdcw1kdi/etc/hosts (quiet=False)
  cloudinit.util: DEBUG: Reading from /tmp/tmpsdcw1kdi/etc/hosts (quiet=False)
  tests.unittests.test_handler.test_handler_apt_configure_sources_list_v3: 
DEBUG: got primary mirror: phit
  cloudinit.util: DEBUG: Reading from /tmp/tmpsdcw1kdi/etc/hosts (quiet=False)
  cloudinit.util: DEBUG: Reading from /tmp/tmpsdcw1kdi/etc/hosts (quiet=False)
  tests.unittests.test_handler.test_handler_apt_configure_sources_list_v3: 
DEBUG: got security mirror: shit

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1792799/+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 1781229] Re: copr builds broken

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1781229

Title:
  copr builds broken

Status in cloud-init:
  Fix Released

Bug description:
  The last successful copr build was  18.3+7.g802c1d51-1.el7 
   18.3+9.g2e62cb8a-1.el7  is currently failing for
  
https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/build/775930/

  epel-6-i386 
  epel-6-x86_64
  fedora-rawhide-i386
  fedora-rawhide-x86_64
  fedora-rawhide-ppc64le

  The rawhide errors look to all be a result of no 'python':
  + /usr/bin/python setup.py build
  BUILDSTDERR: /var/tmp/rpm-tmp.OtzNu9: line 31: /usr/bin/python: No such file 
or directory

  
https://fedoraproject.org/wiki/Packaging:Python#Requires_and_BuildRequires_with_standardized_names
  might be useful for figuring out how to do that the right way.

  The epel issues seem to be related to get_linux_distro.
  It fails with stack trace like (cleaned up the output):

  | RuntimeError: Failed running ['/usr/bin/python', './tools/render-cloudcfg', 
'systemd/cloud-init.service.tmpl', 'RENDERED_TEMPDan8FYU/cloud-init.service'] 
[rc=1] (, Traceback (most recent call last):
  |   File "./tools/render-cloudcfg", line 44, in 
  | main()
  |   File "./tools/render-cloudcfg", line 19, in main
  | platform = util.system_info()
  |   File 
"/builddir/build/BUILD/cloud-init-18.3-9-g2e62cb8a/cloudinit/util.py", line 
627, in system_info
  | 'dist': get_linux_distro()
  |   File 
"/builddir/build/BUILD/cloud-init-18.3-9-g2e62cb8a/cloudinit/util.py", line 
597, in get_linux_distro
  | os_release.get('VERSION'))
  |   File "/usr/lib/python2.6/re.py", line 137, in match
  | return _compile(pattern, flags).match(string)
  | TypeError: expected string or buffer
  |

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1781229/+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 1784685] Re: Oracle: cloud-init openstack local detection too strict for oracle cloud

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1784685

Title:
  Oracle: cloud-init openstack local detection too strict for oracle
  cloud

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

Bug description:
  === Begin SRU Template ===
  [Impact]
  Cloud-init should detect OpenStack datasource on any OracleCloud instance.
  Per the bug, it was falling through the DataSourceNone after upgrade to 18.3.9
  and a system reboot.

  [Test Case]
  # Deploy an Oracle cloud bionic instance and validate upgrade/reboot path

  cat > setup_proposed.sh &1 | egrep 'cloud-init';
     ssh ubuntu@$vm -- sudo cloud-init clean --logs --reboot;
     echo "After clean reboot, upgrade 18.3.9 should detect OpenStackLocal 
datasource"
     ssh-keygen -f ".ssh/known_hosts" -R $vm;
     ssh ubuntu@$vm -- cloud-init status --long;
     ssh ubuntu@$vm -- cloud-init --version;
  done

  [Regression Potential]
  This fixes a critical issue in datasource detection on Oracle platforms only.
  This should not regress any other platforms and is only a minor code path 
change
  to include Oracle's DMI chassis asset tag as a valid OpenStack datasource 
type.

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

  === End SRU Template ===

  === Original Description ===

  cloud-init 18.3 cannot detect OpenStack datasource on Oracle cloud
  across reboots.

  18.2 properly detects DataSourceOpenstack, but 18.3 added a
  detect_openstack helper function which fails to detect openstack
  datasource from the environment or DMI data matching a limited set of
  conditions:

    - DMI system-product_name in ['OpenStack Nova', 'OpenStack Compute']
    OracleCloud product-name is 'Standard PC (i440FX + PIIX, 1996)'
    - DMI chassis_asset_tag in ['OpenTelekomCloud']
   Oracle's chassis asset tag is 'OracleCloud.com'

    - proc/1/environ:product_name == 'OpenStack Nova'
     Oracle's /proc/1/environ has no product_name key:
  $ sudo cat /proc/1/environ
  
HOME=/init=/sbin/initrecovery=TERM=linuxdrop_caps=BOOT_IMAGE=/boot/vmlinuz-4.15.0-29-genericPATH=/sbin:/usr/sbin:/bin:/usr/binPWD=/rootmnt=/root

  We need a more permissive detect_openstack function to detect Oracle
  during cloud-init's get_data() method.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1784685/+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 1784713] Re: cloud-init profile.d files use bash-specific builtin "local"

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1784713

Title:
  cloud-init profile.d files use bash-specific builtin "local"

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

Bug description:
  /etc/profile, which is read by the Bourne-like shells (including ksh),
  runs the scripts in /etc/profile.d.  The scripts from the cloud-init
  package Z99-cloudinit-warnings.sh and Z99-cloud-locale-test.sh
  use the bash-builtin "local" which is not recognized by ksh resulting
  in these errors at login:

  /etc/profile[23]: .[141]: local: not found [No such file or directory]
  /etc/profile[23]: .[142]: local: not found [No such file or directory]
  /etc/profile[23]: .[143]: local: not found [No such file or directory]
  /etc/profile[23]: .[178]: local: not found [No such file or directory]
  /etc/profile[23]: .[179]: local: not found [No such file or directory]

  $ grep -n local\  Z99*
  Z99-cloudinit-warnings.sh:7:local warning="" 
idir="/var/lib/cloud/instance" n=0
  Z99-cloudinit-warnings.sh:8:local warndir="$idir/warnings"
  Z99-cloudinit-warnings.sh:9:local ufile="$HOME/.cloud-warnings.skip" 
sfile="$warndir/.skip"
  Z99-cloud-locale-test.sh:14:local bad_names="" bad_lcs="" key="" val="" 
var="" vars="" bad_kv=""
  Z99-cloud-locale-test.sh:15:local w1 w2 w3 w4 remain
  Z99-cloud-locale-test.sh:56:local bad invalid="" to_gen="" 
sfile="/usr/share/i18n/SUPPORTED"
  Z99-cloud-locale-test.sh:57:local pkgs=""
  Z99-cloud-locale-test.sh:70:local pkgs=""

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cloud-init 18.2-27-g6ef92c98-0ubuntu1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CloudName: Other
  Date: Tue Jul 31 20:04:30 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/ksh
  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/1784713/+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 1792415] Re: WARNINGs and failures in log on OVH public cloud

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1792415

Title:
  WARNINGs and failures in log on OVH public cloud

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

Bug description:
  Part of  "make OVH work right" was brought up by Tobias in
   https://code.launchpad.net/~tobijk/cloud-init/+git/cloud-init/+merge/354752

  After that, though we still see some warnings in the logs that is
  attached.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: cloud-init 18.3-39-g757247f9-0ubuntu1 [modified: 
usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py]
  ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
  Uname: Linux 4.18.0-7-generic x86_64
  ApportVersion: 2.20.10-0ubuntu9
  Architecture: amd64
  CloudName: Other
  Date: Thu Sep 13 16:37:09 2018
  Ec2AMI: ami-00014f37
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: s1-2
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: cloud-init
  UpgradeStatus: No upgrade log present (probably fresh install)
  cloud-init-log-warnings:
   2018-09-13 16:34:54,017 - util.py[WARNING]: Getting data from  failed
   cloudinit.util.ProcessExecutionError: Unexpected error while running command.
   Stderr: Error: Nexthop has invalid gateway.
   2018-09-13 16:34:56,266 - openstack.py[DEBUG]: Failed reading optional path 
http://169.254.169.254/openstack/latest/user_data due to: 404 Client Error: Not 
Found for url: http://169.254.169.254/openstack/latest/user_data
  user_data.txt:

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1792415/+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 1791781] Re: instance-data.json not persisted across reboot.

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1791781

Title:
  instance-data.json not persisted across reboot.

Status in cloud-init:
  Fix Released

Bug description:
  cloud-init v18.3 /run/cloud-init/instance-data.json does not persist
  across reboot.

  Affects: Xenial series or later

  
  Any attempt by services/consumers to re-use instance data after a machine 
reboots will fail.

  To reproduce:

  
  $ lxc launch ubuntu-daily:xenial test-xenial
  Creating test-xenial
  Starting test-xenial

  $ lxc exec test-xenial cat 
/ruc/cloud-init/instance-data.json/cloud-init/instance-data.json
  {
   "base64-encoded-keys": [
"ds/vendor-data",
  ...

  $ lxc exec test-xenial reboot
  $ lxc exec test-xenial cat /ruc/cloud-init/instance-data.json

  cat: /run/cloud-init/instance-data.json: No such file or directory


  Note: cloud-init only writes instnace-data.json when processing meta-
  data on the 1st boot via DataSource.get_data call. We either need to
  persist this data somewhere else, or write it again per boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1791781/+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 1787459] Re: datasource.sys_cfg gets different values in local stage and after.

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1787459

Title:
  datasource.sys_cfg gets different values in local stage and after.

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

Bug description:
  When a datasource is instantiated it is passed in Init.cfg as the 'sys_cfg'.
  But then when 'distro' property is referenced, it has the side effect
  of:
  system_config = self._extract_cfg('system')

  if self.datasource is not NULL_DATA_SOURCE:
  self.datasource.distro = self._distro
  self.datasource.sys_cfg = system_config

  
  Here we see the problem demonstrated.

  root@c1:~# cat show-syscfg-keys
  #!/usr/bin/python3
  from cloudinit.stages import _pkl_load;
  print(_pkl_load("/var/lib/cloud/instance/obj.pkl").sys_cfg.keys())

  root@c1:~# cloud-init clean --logs
  root@c1:~# cloud-init init --local
  Cloud-init v. 18.3-18-g3cee0bf8-0ubuntu1 running 'init-local' at Thu, 16 Aug 
2018 18:08:00 +. Up 574.00 seconds.

  root@c1:~# python3 show-syscfg-keys
  dict_keys(['datasource_list', '_log', 'log_cfgs', 'output', 'users', 
'disable_root', 'preserve_hostname', 'cloud_init_modules', 
'cloud_config_modules', 'cloud_final_modules', 'def_log_file', 
'syslog_fix_perms', 'vendor_data'])

  root@c1:~#
  root@c1:~#
  root@c1:~# cloud-init init >/dev/null 2>&1
  Cloud-init v. 18.3-18-g3cee0bf8-0ubuntu1 running 'init' at Thu, 16 Aug 2018 
18:08:11 +. Up 585.00 seconds.
  ...

  root@c1:~# python3 show-syscfg-keys
  dict_keys(['default_user', 'ntp_client', 'paths', 'package_mirrors', 
'ssh_svcname', 'network'])

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: cloud-init 18.3-18-g3cee0bf8-0ubuntu1
  ProcVersionSignature: Ubuntu 4.17.0-6.7-generic 4.17.9
  Uname: Linux 4.17.0-6-generic x86_64
  ApportVersion: 2.20.10-0ubuntu7
  Architecture: amd64
  CloudName: LXD
  Date: Thu Aug 16 18:02:03 2018
  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/1787459/+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 1792454] Re: Network configuration broken for some distributions with OpenNebula, EC2, Azure

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1792454

Title:
  Network configuration broken for some distributions with OpenNebula,
  EC2, Azure

Status in cloud-init:
  Fix Released

Bug description:
  The DataSources Azure, EC2 and OpenNebula providing the network
  configuration in the v2 format.

  Distributions that make use of `net_util.translate_network` are not
  working with v2 network configurations.

  These distributions are:

  - Arch
  - FreeBSD
  - Gentoo
  - OpenSUSE
  - RHEL

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1792454/+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 1792157] Re: cloud-init uses openstack latest version due to decoding bug

[Scott Moser]

This bug is believed to be fixed in cloud-init in version 18.4. 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/1792157

Title:
  cloud-init uses openstack latest version due to decoding bug

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

Bug description:
  Line like this in the log shows the issue:
  2018-09-12 10:36:25,462 - openstack.py[DEBUG]: Selected version 'latest' from 
[b'2012-08-10', b'2013-04-04', b'2013-10-17', b'2015-10-15', b'2016-06-30', 
b'2016-10-06', b'latest']

  
  we're looking for a string in a list of bytes.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: cloud-init 18.3-38-gd47d404e-0ubuntu1
  ProcVersionSignature: Ubuntu 4.17.0-9.10-generic 4.17.17
  Uname: Linux 4.17.0-9-generic x86_64
  ApportVersion: 2.20.10-0ubuntu9
  Architecture: amd64
  CloudName: OpenStack
  Date: Wed Sep 12 14:15:16 2018
  Ec2AMI: ami-0131
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  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/1792157/+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 1795741] Re: Release 18.4

[Scott Moser]

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

Title:
  Release 18.4

Status in cloud-init:
  Fix Released

Bug description:
  == Release Notes ==
  Cloud-init 18.4 is now available.

  The 18.4 release:
   * Spanned just over 3 months.
   * Had 17 contributors from 13 domains.
   * Fixed 18 bugs.

  Highlights:
   * Add datasource Oracle Compute Infrastructure (OCI).
   * SmartOS: Support for re-reading metadata and re-applying on each boot 
[Mike Gerdts]
   * Scaleway: Add network configuration to the DataSource [Louis Bouchard]
   * Azure: allow azure to generate network configuration from IMDS per boot.
   * Support access to platform meta-data in cloud-config and user-data via 
jinja rendering. (LP: #1791781)

  
  == ChangeLog ==
   - add rtd example docs about new standardized keys
   - use ds._crawled_metadata instance attribute if set when writing
     instance-data.json
   - ec2: update crawled metadata. add standardized keys
   - tests: allow skipping an entire cloud_test without running.
   - tests: disable lxd tests on cosmic
   - cii-tests: use unittest2.SkipTest in ntp_chrony due to new deps
   - lxd: adjust to snap installed lxd.
   - docs: surface experimental doc in instance-data.json
   - tests: fix ec2 integration tests. process meta_data instead of meta-data
   - Add support for Infiniband network interfaces (IPoIB). [Mark Goddard]
   - cli: add cloud-init query subcommand to query instance metadata
   - tools/tox-venv: update for new features.
   - pylint: ignore warning assignment-from-no-return for _write_network
   - stages: Fix bug causing datasource to have incorrect sys_cfg.
     (LP: #1787459)
   - Remove dead-code _write_network distro implementations.
   - net_util: ensure static configs have netmask in translate_network result
     [Thomas Berger] (LP: #1792454)
   - Fall back to root:root on syslog permissions if other options fail.
     [Robert Schweikert]
   - tests: Add mock for util.get_hostname. [Robert Schweikert] (LP: #1792799)
   - ds-identify: doc string cleanup.
   - OpenStack: Support setting mac address on bond.
     [Fabian Wiesel] (LP: #1682064)
   - bash_completion/cloud-init: fix shell syntax error.
   - EphemeralIPv4Network: Be more explicit when adding default route.
     (LP: #1792415)
   - OpenStack: support reading of newer versions of metdata.
   - OpenStack: fix bug causing 'latest' version to be used from network.
     (LP: #1792157)
   - user-data: jinja template to render instance-data.json in cloud-config
     (LP: #1791781)
   - config: disable ssh access to a configured user account
   - tests: print failed testname instead of docstring upon failure
   - tests: Disallow use of util.subp except for where needed.
   - sysconfig: refactor sysconfig to accept distro specific templates paths
   - Add unit tests for config/cc_ssh.py [Francis Ginther]
   - Fix the built-in cloudinit/tests/helpers:skipIf
   - read-version: enhance error message [Joshua Powers]
   - hyperv_reporting_handler: simplify threaded publisher
   - VMWare: Fix a network config bug in vm with static IPv4 and no gateway.
     [Pengpeng Sun] (LP: #1766538)
   - logging: Add logging config type hyperv for reporting via Azure KVP
     [Andy Liu]
   - tests: disable other snap test as well [Joshua Powers]
   - tests: disable snap, fix write_files binary [Joshua Powers]
   - Add datasource Oracle Compute Infrastructure (OCI).
   - azure: allow azure to generate network configuration from IMDS per boot.
   - Scaleway: Add network configuration to the DataSource [Louis Bouchard]
   - docs: Fix example cloud-init analyze command to match output.
     [Wesley Gao]
   - netplan: Correctly render macaddress on a bonds and bridges when
     provided. (LP: #1784699)
   - tools: Add 'net-convert' subcommand command to 'cloud-init devel'.
   - redhat: remove ssh keys on new instance. (LP: #1781094)
   - Use typeset or local in profile.d scripts. (LP: #1784713)
   - OpenNebula: Fix null gateway6 [Akihiko Ota] (LP: #1768547)
   - oracle: fix detect_openstack to report True on OracleCloud.com DMI data
     (LP: #1784685)
   - tests: improve LXDInstance trying to workaround or catch bug.
   - update_metadata re-config on every boot comments and tests not quite
     right [Mike Gerdts]
   - tests: Collect build_info from system if available.
   - pylint: Fix pylint warnings reported in pylint 2.0.0.
   - get_linux_distro: add support for rhel via redhat-release.
   - get_linux_distro: add support for centos6 and rawhide flavors of redhat
     (LP: #1781229)
   - tools: add '--debug' to tools/net-convert.py
   - tests: bump the version of paramiko to 2.4.1.
   - docs: note in rtd about avoiding /tmp when writing files (LP: #1727876)
   - ubuntu,centos,debian: get_linux_distro to align with platform.dist
     (LP: 

[Yahoo-eng-team] [Bug 1795741] [NEW] Release 18.4

[Scott Moser]

Public bug reported:

== Release Notes ==
Cloud-init 18.4 is now available.

The 18.4 release:
 * Spanned just over 3 months.
 * Had 17 contributors from 13 domains.
 * Fixed 18 bugs.


== ChangeLog ==
 - add rtd example docs about new standardized keys
 - use ds._crawled_metadata instance attribute if set when writing
   instance-data.json
 - ec2: update crawled metadata. add standardized keys
 - tests: allow skipping an entire cloud_test without running.
 - tests: disable lxd tests on cosmic
 - cii-tests: use unittest2.SkipTest in ntp_chrony due to new deps
 - lxd: adjust to snap installed lxd.
 - docs: surface experimental doc in instance-data.json
 - tests: fix ec2 integration tests. process meta_data instead of meta-data
 - Add support for Infiniband network interfaces (IPoIB). [Mark Goddard]
 - cli: add cloud-init query subcommand to query instance metadata
 - tools/tox-venv: update for new features.
 - pylint: ignore warning assignment-from-no-return for _write_network
 - stages: Fix bug causing datasource to have incorrect sys_cfg.
   (LP: #1787459)
 - Remove dead-code _write_network distro implementations.
 - net_util: ensure static configs have netmask in translate_network result
   [Thomas Berger] (LP: #1792454)
 - Fall back to root:root on syslog permissions if other options fail.
   [Robert Schweikert]
 - tests: Add mock for util.get_hostname. [Robert Schweikert] (LP: #1792799)
 - ds-identify: doc string cleanup.
 - OpenStack: Support setting mac address on bond.
   [Fabian Wiesel] (LP: #1682064)
 - bash_completion/cloud-init: fix shell syntax error.
 - EphemeralIPv4Network: Be more explicit when adding default route.
   (LP: #1792415)
 - OpenStack: support reading of newer versions of metdata.
 - OpenStack: fix bug causing 'latest' version to be used from network.
   (LP: #1792157)
 - user-data: jinja template to render instance-data.json in cloud-config
   (LP: #1791781)
 - config: disable ssh access to a configured user account
 - tests: print failed testname instead of docstring upon failure
 - tests: Disallow use of util.subp except for where needed.
 - sysconfig: refactor sysconfig to accept distro specific templates paths
 - Add unit tests for config/cc_ssh.py [Francis Ginther]
 - Fix the built-in cloudinit/tests/helpers:skipIf
 - read-version: enhance error message [Joshua Powers]
 - hyperv_reporting_handler: simplify threaded publisher
 - VMWare: Fix a network config bug in vm with static IPv4 and no gateway.
   [Pengpeng Sun] (LP: #1766538)
 - logging: Add logging config type hyperv for reporting via Azure KVP
   [Andy Liu]
 - tests: disable other snap test as well [Joshua Powers]
 - tests: disable snap, fix write_files binary [Joshua Powers]
 - Add datasource Oracle Compute Infrastructure (OCI).
 - azure: allow azure to generate network configuration from IMDS per boot.
 - Scaleway: Add network configuration to the DataSource [Louis Bouchard]
 - docs: Fix example cloud-init analyze command to match output.
   [Wesley Gao]
 - netplan: Correctly render macaddress on a bonds and bridges when
   provided. (LP: #1784699)
 - tools: Add 'net-convert' subcommand command to 'cloud-init devel'.
 - redhat: remove ssh keys on new instance. (LP: #1781094)
 - Use typeset or local in profile.d scripts. (LP: #1784713)
 - OpenNebula: Fix null gateway6 [Akihiko Ota] (LP: #1768547)
 - oracle: fix detect_openstack to report True on OracleCloud.com DMI data
   (LP: #1784685)
 - tests: improve LXDInstance trying to workaround or catch bug.
 - update_metadata re-config on every boot comments and tests not quite
   right [Mike Gerdts]
 - tests: Collect build_info from system if available.
 - pylint: Fix pylint warnings reported in pylint 2.0.0.
 - get_linux_distro: add support for rhel via redhat-release.
 - get_linux_distro: add support for centos6 and rawhide flavors of redhat
   (LP: #1781229)
 - tools: add '--debug' to tools/net-convert.py
 - tests: bump the version of paramiko to 2.4.1.
 - docs: note in rtd about avoiding /tmp when writing files (LP: #1727876)
 - ubuntu,centos,debian: get_linux_distro to align with platform.dist
   (LP: #1780481)
 - Fix boothook docs on environment variable name (INSTANCE_I ->
   INSTANCE_ID) [Marc Tamsky]
 - update_metadata: a datasource can support network re-config every boot
 - tests: drop salt-minion integration test (LP: #1778737)
 - Retry on failed import of gpg receive keys.
 - tools: Fix run-container when neither source or binary package requested.
 - docs: Fix a small spelling error. [Oz N Tiram]
 - tox: use simplestreams from git repository rather than bzr.

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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1795741

Title:
  Release 18.4

Status in cloud-init:
  New

Bug description:
  == Release Notes ==
  Cloud-init 18.4 is now available.

  The 18.4 release:
   * Spanned 

[Yahoo-eng-team] [Bug 1761140] Re: [SRU] dpkg eror processing package nova-compute

[Corey Bryant]

This bug was fixed in the package nova - 2:13.1.4-0ubuntu4.3~cloud0
---

 nova (2:13.1.4-0ubuntu4.3~cloud0) trusty-mitaka; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 nova (2:13.1.4-0ubuntu4.3) xenial; urgency=medium
 .
   * d/control: Drop circular dependencies. nova-compute depends on
 nova-compute-* packages. nova-compute-* packages shouldn't depend
 on nova-compute. nova-compute-* should however depend on nova-common.
 (LP: #1761140).


** Changed in: cloud-archive/mitaka
   Status: Fix Committed => Fix Released

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

Title:
  [SRU] dpkg eror processing package nova-compute

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Released
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in Ubuntu Cloud Archive pike series:
  Fix Released
Status in Ubuntu Cloud Archive queens series:
  Fix Committed
Status in Ubuntu Cloud Archive rocky series:
  Fix Released
Status in OpenStack Compute (nova):
  Invalid
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Xenial:
  Fix Released
Status in nova source package in Bionic:
  Fix Released
Status in nova source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

  Hello!
  I've encountered the bug while installing Nova on compute nodes:

  ...
  Setting up qemu-system-x86 (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up qemu-kvm (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up qemu-utils (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up python-keystone (2:13.0.0-0ubuntu1~cloud0) ...
  Processing triggers for initramfs-tools (0.122ubuntu8.11) ...
  update-initramfs: Generating /boot/initrd.img-4.4.0-116-generic
  Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ...
  adduser: The user `nova' does not exist.
  dpkg: error processing package nova-compute-libvirt (--configure):
   subprocess installed post-installation script returned error exit status 1
  dpkg: dependency problems prevent configuration of nova-compute-kvm:
   nova-compute-kvm depends on nova-compute-libvirt (= 
2:17.0.1-0ubuntu1~cloud0); however:
    Package nova-compute-libvirt is not configured yet.

  dpkg: error processing package nova-compute-kvm (--configure):
   dependency problems - leaving unconfigured
  Setting up python-os-brick (2.3.0-0ubuntu1~cloud0) ...
  No apport report written because the error message indicates its a followup 
error from a previous failure.
  Setting up python-nova (2:17.0.1-0ubuntu1~cloud0) ...
  Setting up nova-common (2:17.0.1-0ubuntu1~cloud0) ...
  Setting up nova-compute (2:17.0.1-0ubuntu1~cloud0) ...
  Processing triggers for libc-bin (2.23-0ubuntu10) ...
  Processing triggers for systemd (229-4ubuntu21.2) ...
  Processing triggers for ureadahead (0.100.0-19) ...
  Processing triggers for dbus (1.10.6-1ubuntu3.3) ...
  Errors were encountered while processing:
   nova-compute-libvirt
   nova-compute-kvm
  ...

  Installation failed when executing 'post-installation script'.
  After some investigation I've found out that if I've create 'nova' user 
BEFORE running package installation, it's will be succeded.

  [Test Case]

  Steps to reproduce
  --
  1. Prepare the node for installing nova-compute packages
  2. Run 'apt-get install nova-compute'

  Expected result
  --
  Nova-compute installed successfully without errors

  Actual result
  --
  Installation failed with dpkg error

  Workaround
  --
  1. Create system user: add to /etc/passwd
     nova:x:64060:64060::/var/lib/nova:/bin/false
  2. Create system group: add to /etc/group
     nova:x:64060:
  3. Run 'apt-get install nova-compute'

  My Environment
  --
  Ubuntu 16.04.4 LTS, 4.4.0-116-generic
  Openstack Queens Release
  Nova 17.0.1-0ubuntu1

  [Regression Potential]
  Should be very low. This is a very minor dependency chain to prevent a 
dependency circular loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1761140/+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 1761140] Re: [SRU] dpkg eror processing package nova-compute

[Launchpad Bug Tracker]

This bug was fixed in the package nova - 2:13.1.4-0ubuntu4.3

---
nova (2:13.1.4-0ubuntu4.3) xenial; urgency=medium

  * d/control: Drop circular dependencies. nova-compute depends on
nova-compute-* packages. nova-compute-* packages shouldn't depend
on nova-compute. nova-compute-* should however depend on nova-common.
(LP: #1761140).

 -- Corey Bryant   Wed, 27 Jun 2018 10:57:19
-0400

** Changed in: nova (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

** Changed in: nova (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

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

Title:
  [SRU] dpkg eror processing package nova-compute

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Released
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in Ubuntu Cloud Archive pike series:
  Fix Released
Status in Ubuntu Cloud Archive queens series:
  Fix Committed
Status in Ubuntu Cloud Archive rocky series:
  Fix Released
Status in OpenStack Compute (nova):
  Invalid
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Xenial:
  Fix Released
Status in nova source package in Bionic:
  Fix Released
Status in nova source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

  Hello!
  I've encountered the bug while installing Nova on compute nodes:

  ...
  Setting up qemu-system-x86 (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up qemu-kvm (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up qemu-utils (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up python-keystone (2:13.0.0-0ubuntu1~cloud0) ...
  Processing triggers for initramfs-tools (0.122ubuntu8.11) ...
  update-initramfs: Generating /boot/initrd.img-4.4.0-116-generic
  Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ...
  adduser: The user `nova' does not exist.
  dpkg: error processing package nova-compute-libvirt (--configure):
   subprocess installed post-installation script returned error exit status 1
  dpkg: dependency problems prevent configuration of nova-compute-kvm:
   nova-compute-kvm depends on nova-compute-libvirt (= 
2:17.0.1-0ubuntu1~cloud0); however:
    Package nova-compute-libvirt is not configured yet.

  dpkg: error processing package nova-compute-kvm (--configure):
   dependency problems - leaving unconfigured
  Setting up python-os-brick (2.3.0-0ubuntu1~cloud0) ...
  No apport report written because the error message indicates its a followup 
error from a previous failure.
  Setting up python-nova (2:17.0.1-0ubuntu1~cloud0) ...
  Setting up nova-common (2:17.0.1-0ubuntu1~cloud0) ...
  Setting up nova-compute (2:17.0.1-0ubuntu1~cloud0) ...
  Processing triggers for libc-bin (2.23-0ubuntu10) ...
  Processing triggers for systemd (229-4ubuntu21.2) ...
  Processing triggers for ureadahead (0.100.0-19) ...
  Processing triggers for dbus (1.10.6-1ubuntu3.3) ...
  Errors were encountered while processing:
   nova-compute-libvirt
   nova-compute-kvm
  ...

  Installation failed when executing 'post-installation script'.
  After some investigation I've found out that if I've create 'nova' user 
BEFORE running package installation, it's will be succeded.

  [Test Case]

  Steps to reproduce
  --
  1. Prepare the node for installing nova-compute packages
  2. Run 'apt-get install nova-compute'

  Expected result
  --
  Nova-compute installed successfully without errors

  Actual result
  --
  Installation failed with dpkg error

  Workaround
  --
  1. Create system user: add to /etc/passwd
     nova:x:64060:64060::/var/lib/nova:/bin/false
  2. Create system group: add to /etc/group
     nova:x:64060:
  3. Run 'apt-get install nova-compute'

  My Environment
  --
  Ubuntu 16.04.4 LTS, 4.4.0-116-generic
  Openstack Queens Release
  Nova 17.0.1-0ubuntu1

  [Regression Potential]
  Should be very low. This is a very minor dependency chain to prevent a 
dependency circular loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1761140/+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 1783654] Re: DVR process flow not installed on physical bridge for shared tenant network

[Corey Bryant]

** Also affects: neutron (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: neutron (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: neutron (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: neutron (Ubuntu Cosmic)
   Importance: Undecided => High

** Changed in: neutron (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: neutron (Ubuntu Cosmic)
   Status: New => Triaged

** Also affects: cloud-archive/pike
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/rocky
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/queens
   Importance: Undecided
   Status: New

** Changed in: cloud-archive/pike
   Status: New => Triaged

** Changed in: cloud-archive/queens
   Status: New => Triaged

** Changed in: cloud-archive/rocky
   Status: New => Triaged

** Changed in: cloud-archive/queens
   Importance: Undecided => High

** Changed in: cloud-archive/pike
   Importance: Undecided => High

** Changed in: cloud-archive/rocky
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1783654

Title:
  DVR process flow not installed on physical bridge for shared tenant
  network

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in Ubuntu Cloud Archive rocky series:
  Triaged
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Triaged
Status in neutron source package in Bionic:
  Triaged
Status in neutron source package in Cosmic:
  Triaged

Bug description:
  Seems like collateral from
  https://bugs.launchpad.net/neutron/+bug/1751396

  In DVR, the distributed gateway port's IP and MAC are shared in the
  qrouter across all hosts.

  The dvr_process_flow on the physical bridge (which replaces the shared
  router_distributed MAC address with the unique per-host MAC when its
  the source), is missing, and so is the drop rule which instructs the
  bridge to drop all traffic destined for the shared distributed MAC.

  Because of this, we are seeing the router MAC on the network
  infrastructure, causing it on flap on br-int on every compute host:

  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
 11 4  fa:16:3e:42:a2:ec1
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
 11 4  fa:16:3e:42:a2:ec2
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
  1 4  fa:16:3e:42:a2:ec0
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
 11 4  fa:16:3e:42:a2:ec0
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
 11 4  fa:16:3e:42:a2:ec0
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
  1 4  fa:16:3e:42:a2:ec0
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
  1 4  fa:16:3e:42:a2:ec0
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
  1 4  fa:16:3e:42:a2:ec0
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
  1 4  fa:16:3e:42:a2:ec1
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
 11 4  fa:16:3e:42:a2:ec0
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
 11 4  fa:16:3e:42:a2:ec0
  root@milhouse:~# ovs-appctl fdb/show br-int | grep fa:16:3e:42:a2:ec
 11 4  fa:16:3e:42:a2:ec0

  
  Where port 1 is phy-br-vlan, connecting to the physical bridge, and port 11 
is the correct local qr-interface. Because these dvr flows are missing on 
br-vlan, pkts w/ source mac ingress into the host and br-int learns it upstream.

  
  The symptom is when pinging a VM's floating IP, we see occasional packet loss 
(10-30%), and sometimes the responses are sent upstream by br-int instead of 
the qrouter, so the ICMP replies come with fixed IP of the replier since no 
NAT'ing took place, and on the tenant network rather than external network.

  When I force net_shared_only to False here, the problem goes away:
  
https://github.com/openstack/neutron/blob/stable/pike/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L436

  It should we noted we *ONLY* need to do this on our dvr_snat host. The
  dvr process's are missing on every compute host. But if we shut
  qrouter on the snat host, FIP functionality works and DVR mac stops
  flapping on others. Or if we apply fix only to snat host, it works.
  Perhaps there is something on SNAT node that is unique

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : 

[Yahoo-eng-team] [Bug 1751396] Re: DVR: Inter Tenant Traffic between two networks and connected through a shared network not reachable with DVR routers

[Corey Bryant]

Marking Artful as invalid since it is EOL.

** Changed in: neutron (Ubuntu Artful)
   Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1751396

Title:
  DVR: Inter Tenant Traffic between two networks and connected through a
  shared network not reachable with DVR routers

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in Ubuntu Cloud Archive rocky series:
  Triaged
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Triaged
Status in neutron source package in Artful:
  Invalid
Status in neutron source package in Bionic:
  Triaged
Status in neutron source package in Cosmic:
  Triaged

Bug description:
  Inter Tenant Traffic between Two Tenants on two different private
  networks connected through a common shared network (created by Admin)
  is not route able through DVR routers

  Steps to reproduce it:

  (NOTE: No external, just shared network)
  This is only reproducable in Multinode scenario. ( 1 Controller - 2 compute ).
  Make sure that the two VMs are isolated in two different computes.

  openstack network create --share shared_net

  openstack subnet create shared_net_sn --network shared_net --subnet-
  range 172.168.10.0/24

  
  openstack network create net_A
  openstack subnet create net_A_sn --network net_A --subnet-range 10.1.0.0/24

  
  openstack network create net_B
  openstack subnet create net_B_sn --network net_B --subnet-range 10.2.0.0/24

  
  openstack router create router_A

  openstack port create --network=shared_net --fixed-ip 
subnet=shared_net_sn,ip-address=172.168.10.20 port_router_A_shared_net
  openstack router add port router_A port_router_A_shared_net
  openstack router add subnet router_A net_A_sn

  openstack router create router_B
  openstack port create --network=shared_net --fixed-ip 
subnet=shared_net_sn,ip-address=172.168.10.30 port_router_B_shared_net
  openstack router add port router_B port_router_B_shared_net
  openstack router add subnet router_B net_B_sn

  openstack server create server_A --flavor m1.tiny --image cirros --nic 
net-id=net_A
  openstack server create server_B --flavor m1.tiny --image cirros --nic 
net-id=net_B

  Add static routes to the router.
  openstack router set router_A --route 
destination=10.1.0.0/24,gateway=172.168.10.20
  openstack router set router_B --route 
destination=10.2.0.0/24,gateway=172.168.10.30
  ```

  Ping from one instance to the other times out

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1751396/+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 1795716] [NEW] neutron-openvswitch-agent deletes existing other_config and thus breaks undercloud's MAC address assignment in tripleo

[Andreas Karis]

Public bug reported:

https://github.com/openstack/neutron/commit/1f8378e0ac4b8c3fc4670144e6efc51940d796ad
 was supposed to change other-config:mac-table-size to set a higher value of 
mac-table-size
option can be set for bridge. Instead, it overwrites the entire other-config 
array and thus interferes with tripleo's undercloud settings where 
other-config:hwaddr is a requirement.

neutron-openvswitch-agent thus resets the MAC address to a random value
although it should be fixed to the underlying interface's MAC>

The original bridge configuration is:
~~~
ov[root@undercloud-7 ~]# ovs-vsctl list-bridge br-ctlplane
ovs-vsctl: unknown command 'list-bridge'; use --help for help
[root@undercloud-7 ~]# ovs-vsctl list bridge br-ctlplane
_uuid   : d56235c5-4933-4334-b33b-be2134c5
auto_attach : []
controller  : []
datapath_id : "525400ec14c2"
datapath_type   : ""
datapath_version: ""
external_ids: {bridge-id=br-ctlplane}
fail_mode   : standalone
flood_vlans : []
flow_tables : {}
ipfix   : []
mcast_snooping_enable: false
mirrors : []
name: br-ctlplane
netflow : []
other_config: {hwaddr="52:54:00:ec:14:c2"}
ports   : [054cde3c-0e02-497d-ac25-be8e6992f708, 
fcbfcff7-d6b8-4bce-824d-085a681663cf]
protocols   : []
rstp_enable : false
rstp_status : {}
sflow   : []
status  : {}
stp_enable  : false
~~~

The new version of neutron-openvswitch-agent sets this:
~~~
2018-10-02 12:31:43.032 3949 DEBUG neutron.agent.ovsdb.impl_idl [-] Running txn 
command(idx=1): DbSetCommand(table=Bridge, col_values=(('other_config', 
{'mac-table-size': '5'}),), record=br-ctlplane) do_commit 
/usr/lib/python2.7/site-packages/neutron/agent/ovsdb/impl_idl.py:98
~~~

Which removes the hwaddr:
~~~
[root@undercloud-7 ~]# ovs-vsctl list bridge br-ctlplane
_uuid   : 334f1314-e024-4c0e-ad6f-acddaa43bb40
auto_attach : []
controller  : [505d73e7-4049-44b8-862c-e19e556bc051]
datapath_id : "16134f330e4c"
datapath_type   : system
datapath_version: ""
external_ids: {bridge-id=br-ctlplane}
fail_mode   : secure
flood_vlans : []
flow_tables : {}
ipfix   : []
mcast_snooping_enable: false
mirrors : []
name: br-ctlplane
netflow : []
other_config: {mac-table-size="5"}
ports   : [18c205e9-c869-4c0b-a24a-18e249cf4f3e, 
90ab6c75-f108-4716-a328-9c26ba7b1a75]
protocols   : ["OpenFlow10", "OpenFlow13"]
rstp_enable : false
rstp_status : {}
sflow   : []
status  : {}
stp_enable  : false
~~~

When it should run something similar to this manual command:
~~~
[root@undercloud-7 ~]# ovs-vsctl set bridge br-ctlplane 
other-config:mac-table-size=5
[root@undercloud-7 ~]# ovs-vsctl list bridge br-ctlplane
_uuid   : d56235c5-4933-4334-b33b-be2134c5
auto_attach : []
controller  : []
datapath_id : "525400ec14c2"
datapath_type   : ""
datapath_version: ""
external_ids: {bridge-id=br-ctlplane}
fail_mode   : standalone
flood_vlans : []
flow_tables : {}
ipfix   : []
mcast_snooping_enable: false
mirrors : []
name: br-ctlplane
netflow : []
other_config: {hwaddr="52:54:00:ec:14:c2", mac-table-size="5"}
ports   : [054cde3c-0e02-497d-ac25-be8e6992f708, 
fcbfcff7-d6b8-4bce-824d-085a681663cf]
protocols   : []
rstp_enable : false
rstp_status : {}
sflow   : []
status  : {}
stp_enable  : false
[root@undercloud-7 ~]# 
[root@undercloud-7 ~]# ip link ls dev br-ctlplane
14: br-ctlplane:  mtu 1500 qdisc noqueue state 
UNKNOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:ec:14:c2 brd ff:ff:ff:ff:ff:ff
~~~

The neutron OVS agent issue can be reproduced manually:
~~~
[root@undercloud-7 ~]# ovs-vsctl set bridge br-ctlplane 
other-config='{mac-table-size=5}'
[root@undercloud-7 ~]# ovs-vsctl list bridge br-ctlplane | grep other
other_config: {mac-table-size="5"}
[root@undercloud-7 ~]# ip link ls dev br-ctlplane
14: br-ctlplane:  mtu 1500 qdisc noqueue state 
UNKNOWN mode DEFAULT group default qlen 1000
link/ether c6:35:62:d5:34:43 brd ff:ff:ff:ff:ff:ff
[root@undercloud-7 ~]# 
~~~

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1795716

Title:
  neutron-openvswitch-agent deletes existing other_config and thus
  breaks undercloud's MAC address assignment in tripleo

Status in neutron:
  New

Bug description:
  

[Yahoo-eng-team] [Bug 1607313] Re: Inconsistency in data stored in libvirt.xml file

[Corey Bryant]

Marking as Fix Released for Ubuntu Ocata as it has nova 15.1.3.

** Changed in: cloud-archive/ocata
   Status: Fix Committed => Fix Released

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

Title:
  Inconsistency in data stored in libvirt.xml file

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Incomplete
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Xenial:
  Incomplete

Bug description:
  Operations involved : 
  nova migrate
  nova evacuate
  nova live-migration

  The above mentioned operations on instances lead to creation of a new
  instance on a new compute host. It has been observed that the 'owner'
  information in the libvirt.xml file is populated with the
  username/projectname(tenantname) of the user performing any of the
  above operations.

  For instance,

  There's an instance 'ins-1' in project/tenant 'pro-1' owned by user 'user01' 
launched on compute host 'compute-101'.
  Now, an admin user named 'osadmin' from project 'admin', performs operation 
  `nova live-migration asdfghi123xyz compute-102`  
  * AD-123 (ID if ins-1)

  This leads to a live migration of ins-1 from compute-101 to compute-102.
  Now, the file /var/lib/nova/instances/asdfghi123xyz/libvirt.xml in 
compute-102 will have 

  
  osadmin
  admin
  

  which ideally should be,

  
  user01
  pro-1
  
   

  This inconsistency is seen in all the operations mentioned, i.e. evacuate, 
migrate, live-
  migration.

  
  Related commands : 
  nova live-migration SERVER HOST_NAME
  nova evacuate EVACUATED_SERVER_NAME HOST_B
  nova migrate VM_ID

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1607313/+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 1643444] Re: TenantUsagesTestJSON.test_list_usage_all_tenants 500 from Db layer

[Matt Riedemann]

** No longer affects: nova/ocata

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

Title:
  TenantUsagesTestJSON.test_list_usage_all_tenants 500 from Db layer

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Committed

Bug description:
  I have a newton setup with 3 api(controller) node.

  TenantUsagesTestJSON.test_list_usage_all_tenants failed once , the
  failure looks similar to one described in the already fixed in
  https://bugs.launchpad.net/nova/+bug/1487570 , but it is different api
  call so it can have similar issue.

  Likely you have an old list of ids, and trying to fetch more info
  about an already deleted instance.

  
  The tempest exception:

  
  2016-11-20 00:07:18,606 27600 INFO [tempest.lib.common.rest_client] 
Request (TenantUsagesTestJSON:test_list_usage_all_tenants): 500 GET 
http://[2620:52:0:13b8:5054:ff:fe3e:4]:8774/v2.1/os-simple-tenant-usage?detailed=1=2016-11-19T00%3A07%3A17.645313=2016-11-21T00%3A07%3A17.645313
 0.134s
  2016-11-20 00:07:18,607 27600 DEBUG[tempest.lib.common.rest_client] 
Request - Headers: {'Content-Type': 'application/json', 'Accept': 
'application/json', 'X-Auth-Token': ''}
  Body: None
  Response - Headers: {'status': '500', 'content-length': '205', 
'content-location': 
'http://[2620:52:0:13b8:5054:ff:fe3e:4]:8774/v2.1/os-simple-tenant-usage?detailed=1=2016-11-19T00%3A07%3A17.645313=2016-11-21T00%3A07%3A17.645313',
 'x-compute-request-id': 'req-3ff84c48-b03e-4f23-8f33-227719a0ced4', 'vary': 
'X-OpenStack-Nova-API-Version', 'openstack-api-version': 'compute 2.1', 
'connection': 'close', 'x-openstack-nova-api-version': '2.1', 'date': 'Sun, 20 
Nov 2016 05:07:18 GMT', 'content-type': 'application/json; charset=UTF-8'}
  Body: {"computeFault": {"message": "Unexpected API Error. Please 
report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if 
possible.\n", "code": 500}}
File 
"/home/stack/tempest-dir/tempest/api/compute/admin/test_simple_tenant_usage.py",
 line 73, in test_list_usage_all_tenants
  start=self.start, end=self.end, detailed="1")['tenant_usages'][0]
File 
"/home/stack/tempest-dir/tempest/api/compute/admin/test_simple_tenant_usage.py",
 line 63, in call_until_valid
  self.assertEqual(test_utils.call_until_true(is_valid, duration, 1),
File "/home/stack/tempest-dir/tempest/lib/common/utils/test_utils.py", line 
103, in call_until_true
  if func():
File 
"/home/stack/tempest-dir/tempest/api/compute/admin/test_simple_tenant_usage.py",
 line 59, in is_valid
  self.resp = func(*args, **kwargs)
File 
"/home/stack/tempest-dir/tempest/lib/services/compute/tenant_usages_client.py", 
line 37, in list_tenant_usages
  resp, body = self.get(url)
File "/home/stack/tempest-dir/tempest/lib/common/rest_client.py", line 291, 
in get
  return self.request('GET', url, extra_headers, headers)
File 
"/home/stack/tempest-dir/tempest/lib/services/compute/base_compute_client.py", 
line 48, in request
  method, url, extra_headers, headers, body, chunked)
File "/home/stack/tempest-dir/tempest/lib/common/rest_client.py", line 664, 
in request
  self._error_checker(resp, resp_body)
File "/home/stack/tempest-dir/tempest/lib/common/rest_client.py", line 827, 
in _error_checker
  message=message)
  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.
  


  The related nova api log (node-2):
  2016-11-20 05:07:18.476 111884 DEBUG nova.api.openstack.wsgi 
[req-3ff84c48-b03e-4f23-8f33-227719a0ced4 d4852c5eaf2645e2aab0c7485939395a 
998c56750d4a4056853829f088ce2be9 - default default] Calling method '>' _process_stack 
/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:636
  2016-11-20 05:07:18.507 111884 DEBUG nova.objects.instance 
[req-3ff84c48-b03e-4f23-8f33-227719a0ced4 d4852c5eaf2645e2aab0c7485939395a 
998c56750d4a4056853829f088ce2be9 - default default] Lazy-loading 'flavor' on 
Instance uuid 5f3a04c2-ab22-4378-9512-bfd4f9fb0a52 obj_load_attr 
/usr/lib/python2.7/site-packages/nova/objects/instance.py:1013
  2016-11-20 05:07:18.556 111884 DEBUG nova.objects.instance 
[req-3ff84c48-b03e-4f23-8f33-227719a0ced4 d4852c5eaf2645e2aab0c7485939395a 
998c56750d4a4056853829f088ce2be9 - default default] Lazy-loading 'flavor' on 
Instance uuid 5f3a04c2-ab22-4378-9512-bfd4f9fb0a52 obj_load_attr 
/usr/lib/python2.7/site-packages/nova/objects/instance.py:1013
  2016-11-20 05:07:18.597 111884 ERROR nova.api.openstack.extensions 
[req-3ff84c48-b03e-4f23-8f33-227719a0ced4 d4852c5eaf2645e2aab0c7485939395a 
998c56750d4a4056853829f088ce2be9 - default default] Unexpected exception in API 
method
  2016-11-20 05:07:18.597 111884 ERROR 

[Yahoo-eng-team] [Bug 1644248] Re: Nova incorrectly tracks live migration progress

[Matt Riedemann]

** Changed in: nova
   Status: Confirmed => Fix Released

** No longer affects: nova/ocata

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

Title:
  Nova incorrectly tracks live migration progress

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Nova while monitoring live migration progress bases on what libvirt
  reports under data_remaining property

  
https://github.com/openstack/nova/blob/54482fde22742bc852414c58552fe64ea59d61d5/nova/virt/libvirt/driver.py#L6189-L6193

  However, data_remaining does not reflect any valuable information that
  nova can use to track live migration progress. It's just an
  information how many data needs to be transferred in current iteration
  to finish current iteration and check whether VM can be switched to
  destination, nothing more.

  As an example let's assume we have VM with 4 GBs of memory. In the
  very fist iteration libvirt will report that there is still 4GB of
  data to be transferred. During the first iteration this number will go
  down to 0 bytes (or almost 0) and this will end the first iteration.
  Let's say that during the first iteration VM has dirtied 3 GBs of
  memory. At the beginning of subsequent iteration QEMU will calculate
  number of dirty pages * page size and libvirt will report 3 GBs of
  data to be transferred in the second iteration. However, during second
  iteration data_remaining will again go down to zero at the end of
  second iteration.

  Given that nova makes snapshot of all those information once every 0.5
  second and that data remaining reported by libvirt reflects only data
  remaining in particular iteration, we can't say whether LM is
  progressing or not. Therefore live migration progress timeout does not
  make sense as nova can take a snapshot from libvirt in the first
  iteration that will say that there is only 150 MB to be transferred to
  destination and very likely in every subsequent iteration nova will
  not take a snapshot with less amount of data to be transferred and
  will think that LM is not progressing.

  This affects all releases starting from Liberty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1644248/+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 1739318] Re: RequestSpec online data migration context does not contain project_id

[Matt Riedemann]

I've closed this bug since the immediate issue is fixed. In order to
remove the workaround during move operations from change
I34b1d99a9d0d2aca80f094a79ec1656abaf762dc we'd have to add an online
data migration, but that could be done later separately from this bug.

** Changed in: nova
   Status: In Progress => Fix Released

** Changed in: nova/newton
   Status: In Progress => Fix Released

** Changed in: nova/ocata
   Status: In Progress => Fix Released

** Changed in: nova/pike
   Status: In Progress => Fix Released

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

Title:
  RequestSpec online data migration context does not contain project_id

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Fix Released
Status in OpenStack Compute (nova) pike series:
  Fix Released

Bug description:
  The online data migration generates a context in order to be able to
  execute migrations:

  https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L747

  However, this context does not contain a `project_id` when running
  this via CLI.

  https://github.com/openstack/nova/blob/master/nova/context.py#L279-L290

  During the creation of RequestSpec's for old instances, the context
  which contains no `project_id`.

  
https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L611-L622

  This means that a RequestSpec gets created with `project_id` set to
  `null`.  During the day-to-day operations, things work okay, however,
  when attempting to do a live migration, the `project_id` is set to
  `null` when trying to claim resources which the placement API refuses.

  https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L791

  This will give errors as such:

  
   
400 Bad Request
   
   
400 Bad Request
The server could not comply with the request since it is either malformed 
or otherwise incorrect.
  JSON does not validate: None is not of type 'string'

  Failed validating 'type' in schema['properties']['project_id']:
  {'maxLength': 255, 'minLength': 1, 'type': 'string'}

  On instance['project_id']:
  None

  
   
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1739318/+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 1607313] Re: Inconsistency in data stored in libvirt.xml file

[Matt Riedemann]

** Changed in: nova/ocata
   Status: In Progress => Fix Released

** Changed in: nova/ocata
 Assignee: (unassigned) => György Szombathelyi (gyurco)

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

Title:
  Inconsistency in data stored in libvirt.xml file

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Incomplete
Status in Ubuntu Cloud Archive ocata series:
  Fix Committed
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Xenial:
  Incomplete

Bug description:
  Operations involved : 
  nova migrate
  nova evacuate
  nova live-migration

  The above mentioned operations on instances lead to creation of a new
  instance on a new compute host. It has been observed that the 'owner'
  information in the libvirt.xml file is populated with the
  username/projectname(tenantname) of the user performing any of the
  above operations.

  For instance,

  There's an instance 'ins-1' in project/tenant 'pro-1' owned by user 'user01' 
launched on compute host 'compute-101'.
  Now, an admin user named 'osadmin' from project 'admin', performs operation 
  `nova live-migration asdfghi123xyz compute-102`  
  * AD-123 (ID if ins-1)

  This leads to a live migration of ins-1 from compute-101 to compute-102.
  Now, the file /var/lib/nova/instances/asdfghi123xyz/libvirt.xml in 
compute-102 will have 

  
  osadmin
  admin
  

  which ideally should be,

  
  user01
  pro-1
  
   

  This inconsistency is seen in all the operations mentioned, i.e. evacuate, 
migrate, live-
  migration.

  
  Related commands : 
  nova live-migration SERVER HOST_NAME
  nova evacuate EVACUATED_SERVER_NAME HOST_B
  nova migrate VM_ID

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1607313/+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 1794767] Re: Horizon exposes url in Swift error message

[OpenStack Infra]

Reviewed:  https://review.openstack.org/605731
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=4d6a1b327a033b5252317a9e35b664f2155cc2a2
Submitter: Zuul
Branch:master

commit 4d6a1b327a033b5252317a9e35b664f2155cc2a2
Author: BubaVV 
Date:   Thu Sep 27 16:58:58 2018 +0300

Hide Swift network info in Horizon error message

In case of error Swift API return some details about unsuccessful
request, i.e. internal IP, full object pass, etc. This response is not
processed by Horizon and presented to user as-is, which is potentially
insecure. Proposed patch adds error processing striping network location
from error message

Change-Id: Ieef9669a1be3ed7bbc685a457eb1fe86b34c3c7e
Closes-bug: #1794767


** Changed in: horizon
   Status: In Progress => Fix Released

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

Title:
  Horizon exposes url in Swift error message

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Horizon can be made to expose internal data structures from HTTP
  requests, this a security hazard.

  See for example:

  GET /api/swift/containers/test01s/metadata/nonexistantFile.txt HTTP/1.1
  Host: example.com
  ...

  Response:

  HTTP/1.1 404 Not Found
  Date: Tue, 11 Sep 2018 19:30:11 GMT
  Server: Apache/2.4.18 (Ubuntu)
  Content-Length: 98
  Vary: Accept-Language,Cookie
  X-Frame-Options: SAMEORIGIN
  Content-Language: en
  Content-Type: application/json

  "Object HEAD failed:
  http://123.456.789.012:8080/swift/v1/test01s/nonexistantFile.txt 404
  Not Found"

  -

  Note, the Object Store endpoint configured on the /project/api_access
  page as "http://example.com:8080/swift/v1;, so exposing the internal
  url is incorrect.

  It should return smth like:
  "Object HEAD failed: 
http://example.com:8080/swift/v1/test01s/nonexistantFile.txt 404 Not Found" , 
or just hide url at all

  To reproduce:
  1. Log into Horizon with Firefox
  2. Open up Web Developer Tools
  3. Navigate to Project -> Object Store -> Containers
  4. pick a GET from the Network tab in developer tool that is for 
/api/swift/containers, copy it as cUrl and append 
"test01s/metadata/nonexistantFile.txt" onto the end of the URL.

  Note you need to do this quickly otherwise the auth token will expire. If 
that happens just refresh page and edit request quickly.
  5. Observe url present in response

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1794767/+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 1404867] Re: Volume remains in-use status, if instance booted from volume is deleted in error state

[Matt Riedemann]

** No longer affects: nova/ocata

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

Title:
  Volume remains in-use status, if instance booted from volume is
  deleted in error state

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) pike series:
  Fix Committed
Status in OpenStack Compute (nova) queens series:
  Fix Committed

Bug description:
  If the instance is booted from volume and goes in to error state due to some 
reason.
  Volume from which instance is booted, remains in-use state even the instance 
is deleted.
  IMO, volume should be detached so that it can be used to boot other instance.

  Steps to reproduce:

  1. Log in to Horizon, create a new volume.
  2. Create an Instance using newly created volume.
  3. Verify instance is in active state.
  $ source devstack/openrc demo demo
  $ nova list
  
+--+--+++-+--+
  | ID   | Name | Status | Task State | Power 
State | Networks |
  
+--+--+++-+--+
  | dae3a13b-6aa8-4794-93cd-5ab7bf90f604 | nova | ACTIVE | -  | Running 
| private=10.0.0.3 |
  
+--+--+++-+--+

  Note:
  Use shelve-unshelve api to see the instance goes into error state.
  unshelving volumed back instance does not work and sets instance state to 
error state (ref: https://bugs.launchpad.net/nova/+bug/1404801)

  4. Shelve the instance
  $ nova shelve 

  5. Verify the status is SHELVED_OFFLOADED.
  $ nova list
  
+--+--+---++-+--+
  | ID   | Name | Status| Task 
State | Power State | Networks |
  
+--+--+---++-+--+
  | dae3a13b-6aa8-4794-93cd-5ab7bf90f604 | nova | SHELVED_OFFLOADED | - 
 | Shutdown| private=10.0.0.3 |
  
+--+--+---++-+--+

  6. Unshelve the instance.
  $ nova unshelve 

  5. Verify the instance is in Error state.
  $ nova list
  
+--+--+---++-+--+
  | ID   | Name | Status| Task 
State | Power State | Networks |
  
+--+--+---++-+--+
  | dae3a13b-6aa8-4794-93cd-5ab7bf90f604 | nova | Error | 
unshelving | Spawning| private=10.0.0.3 |
  
+--+--+---++-+--+

  6. Delete the instance using Horizon.

  7. Verify that volume still in in-use state
  $ cinder list
  
+--++--+--+-+--+--+
  |  ID  | Status | Name | Size | Volume Type | 
Bootable | Attached to  |
  
+--++--+--+-+--+--+
  | 4aeefd25-10aa-42c2-9a2d-1c89a95b4d4f | in-use | test |  1   | lvmdriver-1 | 
  true   | 8f7bdc24-1891-4bbb-8f0c-732b9cbecae7 |
  
+--++--+--+-+--+--+

  8. In Horizon, volume "Attached To" information is displayed as
  "Attached to None on /dev/vda".

  9. User is not able to delete this volume, or attached it to another
  instance as it is still in use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1404867/+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 1408527] Re: Delete instance without block_device_mapping record in database after schedule error

[Matt Riedemann]

** No longer affects: nova/ocata

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

Title:
  Delete instance without block_device_mapping record in database after
  schedule error

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) pike series:
  Fix Committed
Status in OpenStack Compute (nova) queens series:
  Fix Committed

Bug description:
  When a instance with cinder volume is failed to be scheduled to a host, its 
status becomes error.
  Now I delete it successfully, but in block_device_mapping table of nova 
database, the volume information of the instance is still kept, and not deleted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1408527/+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 1795631] [NEW] DBAPIError

[Christoph Manns]

Public bug reported:

Hiho,
we recently discovered that our neutron server are throwing exception upon 
various DB operations.


2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
[req-1eacbfed-9560-4fba-b1fa-bfcf0136d504 - - - - -] DBAPIError exception 
wrapped from (pymysql.err.InternalError) (1305, u'SAVEPOINT sa_savepoint_28 
does not exist') [SQL: u'ROLLBACK TO SAVEPOINT sa_savepoint_28'] (Background on 
this error at: http://sqlalche.me/e/2j85): InternalError: (1305, u'SAVEPOINT 
sa_savepoint_28 does not exist')
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters Traceback 
(most recent call last):
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1193, in 
_execute_context
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters context)
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 507, in 
do_execute
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
cursor.execute(statement, parameters)
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/site-packages/pymysql/cursors.py", line 170, in execute
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters result = 
self._query(query)
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/site-packages/pymysql/cursors.py", line 328, in _query
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
conn.query(q)
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/site-packages/pymysql/connections.py", line 893, in query
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
self._affected_rows = self._read_query_result(unbuffered=unbuffered)
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1103, in 
_read_query_result
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
result.read()
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1396, in read
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
first_packet = self.connection._read_packet()
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1059, in 
_read_packet
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
packet.check_error()
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/site-packages/pymysql/connections.py", line 384, in 
check_error
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
err.raise_mysql_exception(self._data)
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/site-packages/pymysql/err.py", line 109, in 
raise_mysql_exception
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters raise 
errorclass(errno, errval)
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters 
InternalError: (1305, u'SAVEPOINT sa_savepoint_28 does not exist')
2018-10-02 13:32:45.384 6479 ERROR oslo_db.sqlalchemy.exc_filters



LATEST DETECTED DEADLOCK

2018-10-02 13:32:45 7f2c88915700
*** (1) TRANSACTION:
TRANSACTION 221633832, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1184, 3 row lock(s), undo log entries 2
MySQL thread id 35685062, OS thread handle 0x7f2c993bc700, query id 528303451 
$hostname $ip neutron updating
UPDATE standardattributes SET revision_number=6, updated_at='2018-10-02 
11:32:45' WHERE standardattributes.id = 291182 AND 
standardattributes.revision_number = 5
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 401 page no 17 n bits 368 index `PRIMARY` of table 
`neutron`.`standardattributes` trx id 221633832 lock_mode X locks rec but not 
gap waiting
*** (2) TRANSACTION:
TRANSACTION 221633901, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1
MySQL thread id 35700724, OS thread handle 0x7f2c88915700, query id 528303621 
$hostname $ip neutron updating
UPDATE standardattributes SET revision_number=7, updated_at='2018-10-02 
11:32:45' WHERE standardattributes.id = 291212 AND 
standardattributes.revision_number = 6
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 401 page no 17 n bits 368 index `PRIMARY` of table 
`neutron`.`standardattributes` trx id 221633901 lock_mode X locks rec but not 
gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 401 page no 17 n bits 368 index `PRIMARY` of table 

[Yahoo-eng-team] [Bug 1795628] [NEW] cloud-init clean does not remove /etc/network/interfaces.d/50-cloud-init.cfg

[Sirio Balmelli]

Public bug reported:

`cloud-init clean` does not remove `/etc/network/interfaces.d/50-cloud-
init.cfg`

How to reproduce:

1. ubuntu 16.04.5

2. install a static cloud-init config containing network v2
e.g.

```
network:
  version: 2
  ethernets:
eth0:
  addresses:
- "192.168.0.1"
```

3. Install a *new* cloud-init config which disables network
(this is because cloud-init network v2, among other bugs *ignores* the `metric` 
directive - but that is not this bug):

```
network:
  config: disabled
```

4. Run `cloud-init clean && cloud-init init`

5. The file `/etc/network/interfaces.d/50-cloud-init.cfg` is still there

6. Manually remove `/etc/network/interfaces.d/50-cloud-init.cfg` and run
clean+init again ... it is not recreated.

This means that /etc/network/interfaces.d/50-cloud-init.cfg created
under cloud-init is *not* deleted when running `cloud-init clean` == bug
== unexpected behavior.

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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1795628

Title:
  cloud-init clean does not remove /etc/network/interfaces.d/50-cloud-
  init.cfg

Status in cloud-init:
  New

Bug description:
  `cloud-init clean` does not remove `/etc/network/interfaces.d/50
  -cloud-init.cfg`

  How to reproduce:

  1. ubuntu 16.04.5

  2. install a static cloud-init config containing network v2
  e.g.

  ```
  network:
version: 2
ethernets:
  eth0:
addresses:
  - "192.168.0.1"
  ```

  3. Install a *new* cloud-init config which disables network
  (this is because cloud-init network v2, among other bugs *ignores* the 
`metric` directive - but that is not this bug):

  ```
  network:
config: disabled
  ```

  4. Run `cloud-init clean && cloud-init init`

  5. The file `/etc/network/interfaces.d/50-cloud-init.cfg` is still
  there

  6. Manually remove `/etc/network/interfaces.d/50-cloud-init.cfg` and
  run clean+init again ... it is not recreated.

  This means that /etc/network/interfaces.d/50-cloud-init.cfg created
  under cloud-init is *not* deleted when running `cloud-init clean` ==
  bug == unexpected behavior.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1795628/+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 1792472] Re: neutron_tempest_plugin: test_floatingip_port_details occasionally fails

[OpenStack Infra]

Reviewed:  https://review.openstack.org/602694
Committed: 
https://git.openstack.org/cgit/openstack/neutron-tempest-plugin/commit/?id=af347da20f17dbbafb59bc1c0bc39101e9a612e1
Submitter: Zuul
Branch:master

commit af347da20f17dbbafb59bc1c0bc39101e9a612e1
Author: Brian Haley 
Date:   Fri Sep 14 11:24:00 2018 -0600

Wait for floating IP to be DOWN before checking port details

Occasionally test_floatingip_port_details() fails, showing
the floating IP attached port status as 'BUILD'.  Wait for the
status to transition to 'DOWN' before checking other port details,
similar as is done to the fixed IP port's device_id value.

Changed afffected method to use constants for port status as well.

Change-Id: I862115b37c97d5a3cad082d8cd4e7b855ef3f88b
Closes-bug: #1792472


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1792472

Title:
  neutron_tempest_plugin: test_floatingip_port_details occasionally
  fails

Status in neutron:
  Fix Released

Bug description:
  
neutron_tempest_plugin.scenario.test_floatingip.FloatingIPPortDetailsTest.test_floatingip_port_details
  occasionally fails in the check queue.  An example:

  http://logs.openstack.org/97/602097/2/check/neutron-tempest-plugin-
  scenario-linuxbridge/849d93e/testr_results.html.gz

  Traceback (most recent call last):
File 
"/opt/stack/neutron-tempest-plugin/neutron_tempest_plugin/scenario/test_floatingip.py",
 line 249, in test_floatingip_port_details
  fip, port, status='DOWN', device_id='', device_owner='')
File 
"/opt/stack/neutron-tempest-plugin/neutron_tempest_plugin/scenario/test_floatingip.py",
 line 259, in _check_port_details
  self.assertEqual(status, port_details['status'])
File 
"/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 411, in assertEqual
  self.assertThat(observed, matcher, message)
File 
"/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 498, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: 'DOWN' != u'BUILD'

  The strange thing is that BUILD is not a valid state for a floating
  IP, only ACTIVE, DOWN and ERROR are.

  I believe this is due to this test using the compute API to get the
  floating IP state, it should instead use the neutron API if possible,
  for example get_floatingip(), so that a valid object is returned.
  I'll investigate changing the code.

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