[Yahoo-eng-team] [Bug 1696309] [NEW] net-ip-availability-list not support filter by project id
Public bug reported: List network ip availability filtered by project id not supported. $ neutron net-ip-availability-list --project-id 6d0a93fb8cfc4c2f84e3936d95a17bad neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. +--+--+--+---+--+ | network_id | tenant_id| network_name | total_ips | used_ips | +--+--+--+---+--+ | 34bed001-306a-4b1c-a441-c9f6bf95b361 | b76ff5120e234f11a7e7a35a5b60277e | private-net | 253 |2 | | 4ebdcf94-6ec9-498c-a2c6-b7746aaf09f5 | c04b15f261854c13bff01610313e7b99 | dvr-net | 253 |4 | | e374af03-4461-4316-bf8c-d95f5ed8526c | 274428ff074a4b639809fb28a52c2621 | private-net | 253 |5 | | bd1aa0a3-fe2f-42b1-b4e0-6405d4609279 | ed343dbff2384a07bf5871f0cac018f5 | private-net | 253 |2 | | 3a4a15f6-5eb3-4f4e-acf5-940131030e9f | c04b15f261854c13bff01610313e7b99 | ceph-net | 253 |7 | | 9cd01eb4-906a-4c68-b705-0520bfe1b1e6 | 6d0a93fb8cfc4c2f84e3936d95a17bad | net12| 253 |1 | ** Affects: neutron Importance: Undecided Assignee: Dongcan Ye (hellochosen) Status: New ** Changed in: neutron Assignee: (unassigned) => Dongcan Ye (hellochosen) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1696309 Title: net-ip-availability-list not support filter by project id Status in neutron: New Bug description: List network ip availability filtered by project id not supported. $ neutron net-ip-availability-list --project-id 6d0a93fb8cfc4c2f84e3936d95a17bad neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. +--+--+--+---+--+ | network_id | tenant_id| network_name | total_ips | used_ips | +--+--+--+---+--+ | 34bed001-306a-4b1c-a441-c9f6bf95b361 | b76ff5120e234f11a7e7a35a5b60277e | private-net | 253 |2 | | 4ebdcf94-6ec9-498c-a2c6-b7746aaf09f5 | c04b15f261854c13bff01610313e7b99 | dvr-net | 253 |4 | | e374af03-4461-4316-bf8c-d95f5ed8526c | 274428ff074a4b639809fb28a52c2621 | private-net | 253 |5 | | bd1aa0a3-fe2f-42b1-b4e0-6405d4609279 | ed343dbff2384a07bf5871f0cac018f5 | private-net | 253 |2 | | 3a4a15f6-5eb3-4f4e-acf5-940131030e9f | c04b15f261854c13bff01610313e7b99 | ceph-net | 253 |7 | | 9cd01eb4-906a-4c68-b705-0520bfe1b1e6 | 6d0a93fb8cfc4c2f84e3936d95a17bad | net12| 253 |1 | To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1696309/+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 1696308] [NEW] list revoked tokens API returns 500 InternalServerError
Public bug reported:
list revoked tokens API returns 500 InternalServerError
The documentation [1] says that the API should return list of expired PKI
tokens, signed by the cryptographic message syntax (CMS) but
I am using token format as UUID.
[1] https://developer.openstack.org/api-ref/identity/v3/?expanded=list-
revoked-tokens-detail#list-revoked-tokens
Sample program:
1 from keystoneauth1.identity import v3
2 from keystoneauth1 import session
3 from keystoneclient.v3 import client
4 auth = v3.Password(auth_url='http:///identity/v3',
5user_id=,
6password=,
7project_id=)
8 sess = session.Session(auth=auth)
9 keystone = client.Client(session=sess)
10
11 a = keystone.tokens.get_revoked()
The API which is getting used is below:
GET http:///identity/v3/auth/tokens/OS-PKI/revoked
Curl command:
$ curl -g -i -X GET http://10.232.48.201/identity/v3/auth/tokens/OS-PKI/revoked
-H "X-Auth-Token: eb8fc9de9d154c6daa6b26a14d7c4e0f"
HTTP/1.1 500 Internal Server Error
Date: Wed, 07 Jun 2017 05:51:14 GMT
Server: Apache/2.4.18 (Ubuntu)
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 143
x-openstack-request-id: req-a6517dc2-08ac-4d62-8d21-c3405159e1f3
Connection: close
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request.", "code": 500, "title": "Internal Server
Error"}}
command prompt traceback:
Traceback (most recent call last):
File "3_keystoneclient_program.py", line 12, in
a = keystone.tokens.get_revoked()
File "/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line
101, in inner
return wrapped(*args, **kwargs)
File "/opt/stack/python-keystoneclient/keystoneclient/v3/tokens.py", line 62,
in get_revoked
resp, body = self._client.get(path)
File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line
223, in get
return self.request(url, 'GET', **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line
382, in request
resp = super(LegacyJsonAdapter, self).request(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line
148, in request
return self.session.request(url, method, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/positional/__init__.py", line
101, in inner
return wrapped(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line
655, in request
raise exceptions.from_response(resp, method, url)
keystoneauth1.exceptions.http.InternalServerError: An unexpected error
prevented the server from fulfilling your request. (HTTP 500) (Request-ID:
req-7004583f-3556-4b38-877a-b7669b3df3f8)
Keystone logs:
2017-06-07 11:07:13.262 DEBUG keystone.middleware.auth
[req-78ad2fdd-6a2d-4489-96c0
-98c7373b3eb2 None None] Authenticating user token from (pid=9498)
process_request
/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py:40
1
2017-06-07 11:07:13.270 DEBUG keystone.middleware.auth
[req-44f7294f-8430-48d3-b9a6
-4f531544c893 None None] RBAC: auth_context: {'is_delegated_auth': False,
'access_t
oken_id': None, 'user_id': u'3ad182b5723d4e88b97ea7a52bf50cea', 'roles':
[u'admin']
, 'user_domain_id': u'default', 'consumer_id': None, 'trustee_id': None,
'is_domain
': False, 'is_admin_project': True, 'trustor_id': None, 'token': , 'project_id': u'c76af8728a56496fb67c6ace6e78657d', 'trust_id': None,
'projec
t_domain_id': u'default'} from (pid=9498) fill_context
/opt/stack/keystone/keystone
/middleware/auth.py:239
2017-06-07 11:07:13.271 INFO keystone.common.wsgi
[req-44f7294f-8430-48d3-b9a6-4f53
1544c893 None None] GET
http://10.232.48.201/identity/v3/auth/tokens/OS-PKI/revoked
2017-06-07 11:07:13.271 DEBUG keystone.common.authorization
[req-44f7294f-8430-48d3
-b9a6-4f531544c893 None None] RBAC: Authorizing identity:revocation_list() from
(pi
d=9498) _build_policy_check_credentials
/opt/stack/keystone/keystone/common/authori
zation.py:136
2017-06-07 11:07:13.272 DEBUG keystone.policy.backends.rules
[req-44f7294f-8430-48d
3-b9a6-4f531544c893 None None] enforce identity:revocation_list:
{'is_delegated_aut
h': False, 'access_token_id': None, 'user_id':
u'3ad182b5723d4e88b97ea7a52bf50cea',
'roles': [u'admin'], 'user_domain_id': u'default', 'consumer_id': None,
'trustee_i
d': None, 'is_domain': False, 'is_admin_project': True, 'trustor_id': None,
'token'
: , 'project_id':
u'c76af8728a56496fb67c6ace6e78657d', 'trust_id': None, 'project_domain_id':
u'default'} from (pid=9498) enforce
/opt/stack/keystone/keystone/policy/backends/rules.py:33
2017-06-07 11:07:13.274 DEBUG keystone.common.authorization
[req-44f7294f-8430-48d3-b9a6-4f531544c893 None None] RBAC: Authorization
granted from (pid=9498) check_policy
/opt/stack/keystone/keystone/common/authorization.py:240
Wed Jun 7 09:49:23 2017 - SIGPIPE: writing to a closed pipe/socket/fd
(pro
[Yahoo-eng-team] [Bug 1320029] Re: GRE segmentation issue drops packets over 1438 bytes long
[Expired for Ubuntu because there has been no activity for 60 days.] ** Changed in: ubuntu Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1320029 Title: GRE segmentation issue drops packets over 1438 bytes long Status in neutron: Expired Status in Ubuntu: Expired Bug description: OpenStack Icehouse release running on ubuntu 14.04 using GRE tunnels, packets over 1438 bytes long are dropped and not segmented. This causes many issues, not least of which is you cannot inject an ssh key into an ubuntu 14.04 guest using the metadata service. I have attached tcpdump to the tap interface, the br-int bridge, the br-tun bridge, and I can see a small packet traverse the path all the way to the physical interface leaving the compute node. When I attempt to send a packet of 1439 bytes, it enters the br-int bridge, but never leaves. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1320029/+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 1320029] Re: GRE segmentation issue drops packets over 1438 bytes long
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1320029 Title: GRE segmentation issue drops packets over 1438 bytes long Status in neutron: Expired Status in Ubuntu: Expired Bug description: OpenStack Icehouse release running on ubuntu 14.04 using GRE tunnels, packets over 1438 bytes long are dropped and not segmented. This causes many issues, not least of which is you cannot inject an ssh key into an ubuntu 14.04 guest using the metadata service. I have attached tcpdump to the tap interface, the br-int bridge, the br-tun bridge, and I can see a small packet traverse the path all the way to the physical interface leaving the compute node. When I attempt to send a packet of 1439 bytes, it enters the br-int bridge, but never leaves. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1320029/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1696295] [NEW] [Hype-V][Azure]cloud-init failed to create user if "/mnt/cdrom/secure" does not exist
Public bug reported: On Azure, cloud-init (head) fails to mount cdrom /dev/cd0 on FreeBSD if the directory /mnt/cdrom/secure does not exist. In fact, "mount" should not depends on any directory. The quick fix is to use "util.mount_cd" to test whether cdrom is available or not. ** 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/1696295 Title: [Hype-V][Azure]cloud-init failed to create user if "/mnt/cdrom/secure" does not exist Status in cloud-init: New Bug description: On Azure, cloud-init (head) fails to mount cdrom /dev/cd0 on FreeBSD if the directory /mnt/cdrom/secure does not exist. In fact, "mount" should not depends on any directory. The quick fix is to use "util.mount_cd" to test whether cdrom is available or not. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1696295/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1696267] Re: Functional test test_sync_standard_traits intermittently fails
Reviewed: https://review.openstack.org/471508 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=11f4b627459cb68b199ad4f2f1738f07f27627bc Submitter: Jenkins Branch:master commit 11f4b627459cb68b199ad4f2f1738f07f27627bc Author: Chris Dent Date: Tue Jun 6 22:47:49 2017 + Reset the _TRAITS_SYNCED global in Traits tests The global is reset before and after tests because we don't know what other tests might have been messing with it (without even knowing) in this process. We want to start from a clean slate and leave the slate clean. Change-Id: I42b9a7973ec5c4f42578779dc6ad59274212113f Closes-Bug: #1696267 ** 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/1696267 Title: Functional test test_sync_standard_traits intermittently fails Status in OpenStack Compute (nova): Fix Released Bug description: http://logs.openstack.org/98/471498/1/check/gate-nova-tox-functional- ubuntu-xenial/c84dfef/console.html#_2017-06-06_22_23_07_594859 2017-06-06 22:23:07.594859 | nova.tests.functional.db.test_resource_provider.ResourceProviderTraitTestCase.test_sync_standard_traits 2017-06-06 22:23:07.594888 | --- 2017-06-06 22:23:07.594894 | 2017-06-06 22:23:07.594904 | Captured traceback: 2017-06-06 22:23:07.594917 | ~~~ 2017-06-06 22:23:07.594934 | Traceback (most recent call last): 2017-06-06 22:23:07.594965 | File "nova/tests/functional/db/test_resource_provider.py", line 1768, in test_sync_standard_traits 2017-06-06 22:23:07.594988 | self.assertEqual(set(std_traits), set(all_traits)) 2017-06-06 22:23:07.595032 | File "/home/jenkins/workspace/gate-nova-tox-functional-ubuntu-xenial/.tox/functional/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual 2017-06-06 22:23:07.595053 | self.assertThat(observed, matcher, message) 2017-06-06 22:23:07.595095 | File "/home/jenkins/workspace/gate-nova-tox-functional-ubuntu-xenial/.tox/functional/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat 2017-06-06 22:23:07.595107 | raise mismatch_error 2017-06-06 22:23:07.595122 | testtools.matchers._impl.MismatchError: !=: 2017-06-06 22:23:07.595136 | reference = set(['HW_CPU_X86_3DNOW', 2017-06-06 22:23:07.595147 | 'HW_CPU_X86_ABM', 2017-06-06 22:23:07.595158 | 'HW_CPU_X86_AESNI', 2017-06-06 22:23:07.595169 | 'HW_CPU_X86_ASF', 2017-06-06 22:23:07.595198 | 'HW_CPU_X86_AVX', 2017-06-06 22:23:07.595211 | 'HW_CPU_X86_AVX2', 2017-06-06 22:23:07.595223 | 'HW_CPU_X86_AVX512BW', 2017-06-06 22:23:07.595234 | 'HW_CPU_X86_AVX512CD', 2017-06-06 22:23:07.595250 | 'HW_CPU_X86_AVX512DQ', 2017-06-06 22:23:07.595262 | 'HW_CPU_X86_AVX512ER', 2017-06-06 22:23:07.595274 | 'HW_CPU_X86_AVX512F', 2017-06-06 22:23:07.595286 | 'HW_CPU_X86_AVX512PF', 2017-06-06 22:23:07.595297 | 'HW_CPU_X86_AVX512VL', 2017-06-06 22:23:07.595308 | 'HW_CPU_X86_BMI', 2017-06-06 22:23:07.595319 | 'HW_CPU_X86_BMI2', 2017-06-06 22:23:07.595331 | 'HW_CPU_X86_CLMUL', 2017-06-06 22:23:07.595342 | 'HW_CPU_X86_F16C', 2017-06-06 22:23:07.595353 | 'HW_CPU_X86_FMA3', 2017-06-06 22:23:07.595364 | 'HW_CPU_X86_FMA4', 2017-06-06 22:23:07.595375 | 'HW_CPU_X86_MMX', 2017-06-06 22:23:07.595385 | 'HW_CPU_X86_MPX', 2017-06-06 22:23:07.595416 | 'HW_CPU_X86_SGX', 2017-06-06 22:23:07.595430 | 'HW_CPU_X86_SHA', 2017-06-06 22:23:07.595441 | 'HW_CPU_X86_SSE', 2017-06-06 22:23:07.595458 | 'HW_CPU_X86_SSE2', 2017-06-06 22:23:07.595469 | 'HW_CPU_X86_SSE3', 2017-06-06 22:23:07.595482 | 'HW_CPU_X86_SSE41', 2017-06-06 22:23:07.595494 | 'HW_CPU_X86_SSE42', 2017-06-06 22:23:07.595505 | 'HW_CPU_X86_SSE4A', 2017-06-06 22:23:07.595516 | 'HW_CPU_X86_SSSE3', 2017-06-06 22:23:07.595532 | 'HW_CPU_X86_SVM', 2017-06-06 22:23:07.595544 | 'HW_CPU_X86_TBM', 2017-06-06 22:23:07.59 | 'HW_CPU_X86_TSX', 2017-06-06 22:23:07.595566 | 'HW_CPU_X86_VMX', 2017-06-06 22:23:07.595576 | 'HW_CPU_X86_XOP', 2017-06-06 22:23:07.595588 | 'HW_NIC_ACCEL_DEFLATE', 2017-06-06 22:23:07.595600 | 'HW_NIC_ACCEL_DIFFIEH', 2017-06-06 22:23:07.595612 | 'HW_NIC_ACCEL_ECC', 2017-06-06 22:23:07.595623 | 'HW_NIC_ACCEL_IPSEC', 2017-06-06 22:23:07.595634 | 'HW_NIC_ACCEL_LZS', 2017-06-06 22:23:07.595646 | 'HW_
[Yahoo-eng-team] [Bug 1649852] Re: Concurrent calls to DELETE os-floating-ips can raise uncaught neutronclient.common.exceptions.NotFound
Reviewed: https://review.openstack.org/410815
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=d99197aece6451013d1de1f08c1af16832ee0e7e
Submitter: Jenkins
Branch:master
commit d99197aece6451013d1de1f08c1af16832ee0e7e
Author: Guillaume Espanel
Date: Wed Dec 14 15:29:02 2016 +0100
Catch neutronclient.NotFound on floating deletion
In some cases, trying to delete a floating IP multiple times in a short
delay can trigger an exception beacause the floating ip deletion
operation is not atomic. If neutronclient's call to delete fails with a
NotFound error, we raise a 404 error to nova's client instead of a 500.
Change-Id: I49ea7e52073148457e794d641ed17d4ef58616f8
Co-Authored-By: Stephen Finucane
Closes-Bug: #1649852
** Changed in: nova
Status: In Progress => Fix Released
** Changed in: nova/ocata
Status: Confirmed => In Progress
** Changed in: nova/ocata
Assignee: (unassigned) => Matt Riedemann (mriedem)
--
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/1649852
Title:
Concurrent calls to DELETE os-floating-ips can raise uncaught
neutronclient.common.exceptions.NotFound
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) ocata series:
In Progress
Bug description:
Description
Concurrent calls to DELETE os-floating-ips/floating-ip-id can cause
neutronclient to raise
a neutronclient.common.exceptions.NotFound exception uncaught by Nova which
in turn returns
a 500 Error.
Steps to reproduce
===
Tested on a mitaka devstack :
- source openrc
- run this humble script :
FIP_ID=`nova floating-ip-create | grep public | awk '{print($2)}'`
TENANT_ID=`keystone token-get | grep " tenant_id " | awk '{print($4)}'`
TOKEN_ID=`keystone token-get | grep " id " | awk '{print($4)}'`
curl -g -i -X DELETE
http://127.0.0.1:8774/v2.1/$TENANT_ID/os-floating-ips/$FIP_ID -H "User-Agent:
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN_ID"&
curl -g -i -X DELETE
http://127.0.0.1:8774/v2.1/$TENANT_ID/os-floating-ips/$FIP_ID -H "User-Agent:
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN_ID"&
curl -g -i -X DELETE
http://127.0.0.1:8774/v2.1/$TENANT_ID/os-floating-ips/$FIP_ID -H "User-Agent:
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN_ID"&
curl -g -i -X DELETE
http://127.0.0.1:8774/v2.1/$TENANT_ID/os-floating-ips/$FIP_ID -H "User-Agent:
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN_ID"
Expected result
First call to go trough should return a 202, and all other calls
should probably return 404 or 409 if deletion is in progress but not
500.
Actual result
==
Some calls to DELETE get a 500 Error response.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1649852/+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 1696267] [NEW] Functional test test_sync_standard_traits intermittently fails
Public bug reported: http://logs.openstack.org/98/471498/1/check/gate-nova-tox-functional- ubuntu-xenial/c84dfef/console.html#_2017-06-06_22_23_07_594859 2017-06-06 22:23:07.594859 | nova.tests.functional.db.test_resource_provider.ResourceProviderTraitTestCase.test_sync_standard_traits 2017-06-06 22:23:07.594888 | --- 2017-06-06 22:23:07.594894 | 2017-06-06 22:23:07.594904 | Captured traceback: 2017-06-06 22:23:07.594917 | ~~~ 2017-06-06 22:23:07.594934 | Traceback (most recent call last): 2017-06-06 22:23:07.594965 | File "nova/tests/functional/db/test_resource_provider.py", line 1768, in test_sync_standard_traits 2017-06-06 22:23:07.594988 | self.assertEqual(set(std_traits), set(all_traits)) 2017-06-06 22:23:07.595032 | File "/home/jenkins/workspace/gate-nova-tox-functional-ubuntu-xenial/.tox/functional/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual 2017-06-06 22:23:07.595053 | self.assertThat(observed, matcher, message) 2017-06-06 22:23:07.595095 | File "/home/jenkins/workspace/gate-nova-tox-functional-ubuntu-xenial/.tox/functional/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat 2017-06-06 22:23:07.595107 | raise mismatch_error 2017-06-06 22:23:07.595122 | testtools.matchers._impl.MismatchError: !=: 2017-06-06 22:23:07.595136 | reference = set(['HW_CPU_X86_3DNOW', 2017-06-06 22:23:07.595147 | 'HW_CPU_X86_ABM', 2017-06-06 22:23:07.595158 | 'HW_CPU_X86_AESNI', 2017-06-06 22:23:07.595169 | 'HW_CPU_X86_ASF', 2017-06-06 22:23:07.595198 | 'HW_CPU_X86_AVX', 2017-06-06 22:23:07.595211 | 'HW_CPU_X86_AVX2', 2017-06-06 22:23:07.595223 | 'HW_CPU_X86_AVX512BW', 2017-06-06 22:23:07.595234 | 'HW_CPU_X86_AVX512CD', 2017-06-06 22:23:07.595250 | 'HW_CPU_X86_AVX512DQ', 2017-06-06 22:23:07.595262 | 'HW_CPU_X86_AVX512ER', 2017-06-06 22:23:07.595274 | 'HW_CPU_X86_AVX512F', 2017-06-06 22:23:07.595286 | 'HW_CPU_X86_AVX512PF', 2017-06-06 22:23:07.595297 | 'HW_CPU_X86_AVX512VL', 2017-06-06 22:23:07.595308 | 'HW_CPU_X86_BMI', 2017-06-06 22:23:07.595319 | 'HW_CPU_X86_BMI2', 2017-06-06 22:23:07.595331 | 'HW_CPU_X86_CLMUL', 2017-06-06 22:23:07.595342 | 'HW_CPU_X86_F16C', 2017-06-06 22:23:07.595353 | 'HW_CPU_X86_FMA3', 2017-06-06 22:23:07.595364 | 'HW_CPU_X86_FMA4', 2017-06-06 22:23:07.595375 | 'HW_CPU_X86_MMX', 2017-06-06 22:23:07.595385 | 'HW_CPU_X86_MPX', 2017-06-06 22:23:07.595416 | 'HW_CPU_X86_SGX', 2017-06-06 22:23:07.595430 | 'HW_CPU_X86_SHA', 2017-06-06 22:23:07.595441 | 'HW_CPU_X86_SSE', 2017-06-06 22:23:07.595458 | 'HW_CPU_X86_SSE2', 2017-06-06 22:23:07.595469 | 'HW_CPU_X86_SSE3', 2017-06-06 22:23:07.595482 | 'HW_CPU_X86_SSE41', 2017-06-06 22:23:07.595494 | 'HW_CPU_X86_SSE42', 2017-06-06 22:23:07.595505 | 'HW_CPU_X86_SSE4A', 2017-06-06 22:23:07.595516 | 'HW_CPU_X86_SSSE3', 2017-06-06 22:23:07.595532 | 'HW_CPU_X86_SVM', 2017-06-06 22:23:07.595544 | 'HW_CPU_X86_TBM', 2017-06-06 22:23:07.59 | 'HW_CPU_X86_TSX', 2017-06-06 22:23:07.595566 | 'HW_CPU_X86_VMX', 2017-06-06 22:23:07.595576 | 'HW_CPU_X86_XOP', 2017-06-06 22:23:07.595588 | 'HW_NIC_ACCEL_DEFLATE', 2017-06-06 22:23:07.595600 | 'HW_NIC_ACCEL_DIFFIEH', 2017-06-06 22:23:07.595612 | 'HW_NIC_ACCEL_ECC', 2017-06-06 22:23:07.595623 | 'HW_NIC_ACCEL_IPSEC', 2017-06-06 22:23:07.595634 | 'HW_NIC_ACCEL_LZS', 2017-06-06 22:23:07.595646 | 'HW_NIC_ACCEL_RSA', 2017-06-06 22:23:07.595657 | 'HW_NIC_ACCEL_SSL', 2017-06-06 22:23:07.595668 | 'HW_NIC_ACCEL_TLS', 2017-06-06 22:23:07.595679 | 'HW_NIC_DCB_ETS', 2017-06-06 22:23:07.595689 | 'HW_NIC_DCB_PFC', 2017-06-06 22:23:07.595700 | 'HW_NIC_DCB_QCN', 2017-06-06 22:23:07.595712 | 'HW_NIC_MULTIQUEUE', 2017-06-06 22:23:07.595723 | 'HW_NIC_OFFLOAD_FDF', 2017-06-06 22:23:07.595735 | 'HW_NIC_OFFLOAD_GENEVE', 2017-06-06 22:23:07.595747 | 'HW_NIC_OFFLOAD_GRE', 2017-06-06 22:23:07.595759 | 'HW_NIC_OFFLOAD_GRO', 2017-06-06 22:23:07.595770 | 'HW_NIC_OFFLOAD_GSO', 2017-06-06 22:23:07.595782 | 'HW_NIC_OFFLOAD_L2CRC', 2017-06-06 22:23:07.595794 | 'HW_NIC_OFFLOAD_LRO', 2017-06-06 22:23:07.595808 | 'HW_NIC_OFFLOAD_LSO', 2017-06-06 22:23:07.595820 | 'HW_NIC_OFFLOAD_QINQ', 2017-06-06 22:23:07.595832 | 'HW_NIC_OFFLOAD_RDMA', 2017-06-06 22:23:07.595845 | 'HW_NIC_OFFLOAD_RXHASH', 2017-06-06 22:23:07.595858 | 'HW_NIC_OFFLOAD_RXVLAN', 2017-06-06 22:23:07.595869 | 'HW_NIC_OFFLOAD_SCS', 2017-06-
[Yahoo-eng-team] [Bug 1696001] Re: nova-manage cell_v2 map_cell0 can create invalid connection URL
** Changed in: nova Importance: Medium => High ** Also affects: nova/newton Importance: Undecided Status: New ** Also affects: nova/ocata Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1696001 Title: nova-manage cell_v2 map_cell0 can create invalid connection URL Status in OpenStack Compute (nova): Confirmed Status in OpenStack Compute (nova) newton series: New Status in OpenStack Compute (nova) ocata series: New Bug description: Description === nova-manage cell_v2 map_cell0 will automatically generate a database connection url from the existing connection configuration setting. However, if the connection has query parameters like a charset defined, it will generate an invalid URL. Steps to reproduce == Set the following in the nova.conf: [database] connection = mysql+pymysql://nova:passw...@db.example.com/nova?charset=utf8 Run: nova-manage cell_v2 map_cell0 Excepted result === Cell0 is mapped to mysql+pymysql://nova:passw...@db.example.com/nova_cell0?charset=utf8 Actual Result = Cell0 is mapped to mysql+pymysql://nova:passw...@db.example.com/nova?charset=utf8nova_cell0 Subsequent API calls may fail because of this with exceptions like: 2017-06-05 20:54:20.343 2197 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 660, in __init__ 2017-06-05 20:54:20.343 2197 ERROR nova.api.openstack.extensions self.encoding = charset_by_name(self.charset).encoding 2017-06-05 20:54:20.343 2197 ERROR nova.api.openstack.extensions AttributeError: 'NoneType' object has no attribute 'encoding' because utf8nova_cell0 is not a valid encoding. Environment: OpenStack Ocata, # dpkg -l | grep nova-common ii nova-common 2:15.0.5-1~u16.04+mcp5 all OpenStack Compute - common files To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1696001/+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 1696043] Re: os-hypervisors api can not list the uuid of the specified VMM
Thanks for your bug report. Unforutunatly, it doesn't really correspond
to a notion of either a regression or a technical issue, but rather a
missing feature.
We have a specific process for approving feature requests thru Launchpad
Blueprints and what we call 'specs', ie. formalized textual RFEs
describing the problem description and the proposal.
FWIW, what you're asking for is actually already approved for our Pike
timeframe :
https://blueprints.launchpad.net/nova/+spec/service-hyper-uuid-in-api
http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/service-hyper-uuid-in-api.html
I'd suggest you helping by at least reviewing the current series where
some patches have already merged
https://review.openstack.org/#/q/topic:bp/service-hyper-uuid-in-api,n,z
** Changed in: nova
Status: New => Invalid
** Changed in: nova
Importance: Undecided => Wishlist
--
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/1696043
Title:
os-hypervisors api can not list the uuid of the specified VMM
Status in OpenStack Compute (nova):
Invalid
Bug description:
os-hypervisors api just cann't list the host's uuid.
we could find uuid field in nova.compute.
created_at: 2017-05-17 05:50:51
updated_at: 2017-05-27 07:45:30
deleted_at: NULL
id: 2
service_id: NULL
vcpus: 2
memory_mb: 3791
local_gb: 98
vcpus_used: 0
memory_mb_used: 512
local_gb_used: 0
hypervisor_type: QEMU
hypervisor_version: 2003000
cpu_info: {"vendor": "Intel", "model": "Westmere", "arch":
"x86_64", "features": ["pge", "avx", "clflush", "sep", "syscall", "vme", "msr",
"fsgsbase", "xsave", "vmx", "erms", "cmov", "smep", "pcid", "pat", "lm", "tsc",
"nx", "fxsr", "sse4.1", "pae", "sse4.2", "pclmuldq", "fma", "mmx", "osxsave",
"cx8", "mce", "de", "rdtscp", "ht", "pse", "lahf_lm", "popcnt", "mca",
"pdpe1gb", "apic", "sse", "f16c", "ds", "invtsc", "pni", "aes", "sse2", "ss",
"hypervisor", "ssse3", "fpu", "cx16", "pse36", "mtrr", "movbe", "rdrand",
"x2apic"], "topology": {"cores": 2, "cells": 1, "threads": 1, "sockets": 1}}
disk_available_least: 82
free_ram_mb: 3279
free_disk_gb: 98
current_workload: 0
running_vms: 0
hypervisor_hostname: compute
deleted: 0
host_ip: 192.168.2.101
supported_instances: [["i686", "qemu", "hvm"], ["i686", "kvm", "hvm"],
["x86_64", "qemu", "hvm"], ["x86_64", "kvm", "hvm"]]
pci_stats: {"nova_object.version": "1.1", "nova_object.changes":
["objects"], "nova_object.name": "PciDevicePoolList", "nova_object.data":
{"objects": []}, "nova_object.namespace": "nova"}
metrics: []
extra_resources: NULL
stats: {}
numa_topology: {"nova_object.version": "1.2", "nova_object.changes":
["cells"], "nova_object.name": "NUMATopology", "nova_object.data": {"cells":
[{"nova_object.version": "1.2", "nova_object.changes": ["cpu_usage",
"memory_usage", "cpuset", "mempages", "pinned_cpus", "memory", "siblings",
"id"], "nova_object.name": "NUMACell", "nova_object.data": {"cpu_usage": 0,
"memory_usage": 0, "cpuset": [0, 1], "pinned_cpus": [], "siblings": [],
"memory": 4095, "mempages": [{"nova_object.version": "1.1",
"nova_object.changes": ["total", "used", "reserved", "size_kb"],
"nova_object.name": "NUMAPagesTopology", "nova_object.data": {"used": 0,
"total": 1048462, "reserved": 0, "size_kb": 4}, "nova_object.namespace":
"nova"}, {"nova_object.version": "1.1", "nova_object.changes": ["total",
"used", "reserved", "size_kb"], "nova_object.name": "NUMAPagesTopology",
"nova_object.data": {"used": 0, "total": 0, "reserved": 0, "size_kb": 2048},
"nova_object.namespace": "nova"}, {"nova_object.version": "1.1",
"nova_object.changes": ["total", "used", "reserved", "size_kb"],
"nova_object.name": "NUMAPagesTopology", "nova_object.data": {"used": 0,
"total": 0, "reserved": 0, "size_kb": 1048576}, "nova_object.namespace":
"nova"}], "id": 0}, "nova_object.namespace": "nova"}]},
"nova_object.namespace": "nova"}
host: compute
ram_allocation_ratio: 0
cpu_allocation_ratio: 0
uuid: cbf2b233-3645-45e3-a7f5-588857035531
disk_allocation_ratio: 0
but the List Hypervisors Details api in
https://developer.openstack.org/api-ref/compute/ couldn't list the uuid.
Here is the code of nova/api/openstack/compute/hypervisors.py
60 for field in ('vcpus', 'memory_mb', 'local_gb', 'vcpus_used',
61 'memory_mb_used', 'local_gb_used',
62 'hypervisor_type', 'hypervisor_version',
63 'free_ram_mb', 'free_disk_gb',
'current_workload',
64
[Yahoo-eng-team] [Bug 1694371] Re: Timeout while waiting for network-vif-plugged event during server rebuild
** Changed in: nova Status: New => Confirmed ** Changed in: heat Status: New => 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/1694371 Title: Timeout while waiting for network-vif-plugged event during server rebuild Status in heat: Invalid Status in neutron: New Status in OpenStack Compute (nova): Confirmed Bug description: It seems like the server is going to ERROR state during rebuild. traceback: 2017-05-28 04:34:37.767757 | 2017-05-28 04:34:37.767 | Captured traceback: 2017-05-28 04:34:37.768828 | 2017-05-28 04:34:37.768 | ~~~ 2017-05-28 04:34:37.770099 | 2017-05-28 04:34:37.769 | b'Traceback (most recent call last):' 2017-05-28 04:34:37.771108 | 2017-05-28 04:34:37.770 | b' File "/opt/stack/new/heat/heat_integrationtests/functional/test_snapshot_restore.py", line 74, in test_stack_snapshot_restore' 2017-05-28 04:34:37.772364 | 2017-05-28 04:34:37.772 | b' self.stack_restore(stack_identifier, snapshot_id)' 2017-05-28 04:34:37.773407 | 2017-05-28 04:34:37.773 | b' File "/opt/stack/new/heat/heat_integrationtests/common/test.py", line 626, in stack_restore' 2017-05-28 04:34:37.774541 | 2017-05-28 04:34:37.774 | b' self._wait_for_stack_status(stack_id, wait_for_status)' 2017-05-28 04:34:37.775568 | 2017-05-28 04:34:37.775 | b' File "/opt/stack/new/heat/heat_integrationtests/common/test.py", line 357, in _wait_for_stack_status' 2017-05-28 04:34:37.776642 | 2017-05-28 04:34:37.776 | b' fail_regexp):' 2017-05-28 04:34:37.778354 | 2017-05-28 04:34:37.778 | b' File "/opt/stack/new/heat/heat_integrationtests/common/test.py", line 321, in _verify_status' 2017-05-28 04:34:37.779448 | 2017-05-28 04:34:37.779 | b' stack_status_reason=stack.stack_status_reason)' 2017-05-28 04:34:37.780644 | 2017-05-28 04:34:37.780 | b"heat_integrationtests.common.exceptions.StackBuildErrorException: Stack StackSnapshotRestoreTest-1374582671/7fb8f800-1545-4e34-a6fa-3e2adbf4443a is in RESTORE_FAILED status due to 'Error: resources.my_server: Rebuilding server failed, status 'ERROR''" 2017-05-28 04:34:37.782119 | 2017-05-28 04:34:37.781 | b'' Noticed at: http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm- functional-convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/console.html#_2017-05-28_04_34_37_753094 Looks like a nova issue from the below traceback. http://logs.openstack.org/16/462216/16/check/gate-heat-dsvm- functional-convg-mysql-lbaasv2-py35-ubuntu- xenial/17c2da9/logs/screen-n-cpu.txt.gz?level=ERROR#_May_28_04_14_49_044455 May 28 04:14:49.042877 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] File "/opt/stack/new/nova/nova/compute/manager.py", line 6758, in _error_out_instance_on_exception May 28 04:14:49.042955 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] yield May 28 04:14:49.043027 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] File "/opt/stack/new/nova/nova/compute/manager.py", line 2814, in rebuild_instance May 28 04:14:49.043100 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] bdms, recreate, on_shared_storage, preserve_ephemeral) May 28 04:14:49.043197 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] File "/opt/stack/new/nova/nova/compute/manager.py", line 2855, in _do_rebuild_instance_with_claim May 28 04:14:49.043299 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] self._do_rebuild_instance(*args, **kwargs) May 28 04:14:49.043384 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] File "/opt/stack/new/nova/nova/compute/manager.py", line 2977, in _do_rebuild_instance May 28 04:14:49.043458 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] self._rebuild_default_impl(**kwargs) May 28 04:14:49.043534 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b970-4ced-968c-a1c4ead5b282] File "/opt/stack/new/nova/nova/compute/manager.py", line 2714, in _rebuild_default_impl May 28 04:14:49.043611 ubuntu-xenial-osic-cloud1-s3700-9024798 nova-compute[26709]: ERROR nova.compute.manager [instance: 45105d34-b97
[Yahoo-eng-team] [Bug 1696221] [NEW] Unnecessary instance lazy-loads during rebuild
Public bug reported:
The rebuild code in the compute manager also handles evacuate. Rebuild
is rebuild on the same host, no migration. Evacuate is rebuild the
instance on another host, and has a migration context.
This code:
https://github.com/openstack/nova/blob/e01ae75d52900d96355dfcb39ef9b136f0c0d5c4/nova/compute/manager.py#L2718
Is using the mutated_migration_context() context manager which lazy-
loads numa_topology, pci_requests and pci_devices and then, since
self.migration_context isn't set on the instance, yields as a noop.
Seen here:
http://logs.openstack.org/82/471082/1/gate/gate-novaclient-dsvm-
functional-neutron-ubuntu-
xenial/796acb7/logs/screen-n-cpu.txt.gz#_Jun_06_13_14_02_547424
Jun 06 13:14:02.547424 ubuntu-xenial-infracloud-chocolate-9158824
nova-compute[20994]: DEBUG nova.objects.instance [None
req-5b3770c1-d332-4875-8933-97de8a9890b4 admin admin] Lazy-loading
'pci_requests' on Instance uuid 573258a4-9416-4e13-a765-7c90683f3526
{{(pid=20994) obj_load_attr /opt/stack/new/nova/nova/objects/instance.py:1038}}
Jun 06 13:14:02.562243 ubuntu-xenial-infracloud-chocolate-9158824
nova-compute[20994]: DEBUG nova.objects.instance [None
req-5b3770c1-d332-4875-8933-97de8a9890b4 admin admin] Lazy-loading
'pci_devices' on Instance uuid 573258a4-9416-4e13-a765-7c90683f3526
{{(pid=20994) obj_load_attr /opt/stack/new/nova/nova/objects/instance.py:1038}}
Jun 06 13:14:02.577132 ubuntu-xenial-infracloud-chocolate-9158824
nova-compute[20994]: DEBUG nova.objects.instance [None
req-5b3770c1-d332-4875-8933-97de8a9890b4 admin admin] Lazy-loading
'migration_context' on Instance uuid 573258a4-9416-4e13-a765-7c90683f3526
{{(pid=20994) obj_load_attr /opt/stack/new/nova/nova/objects/instance.py:1038}}
Jun 06 13:14:02.590554 ubuntu-xenial-infracloud-chocolate-9158824
nova-compute[20994]: DEBUG nova.objects.instance [None
req-5b3770c1-d332-4875-8933-97de8a9890b4 admin admin] [instance:
573258a4-9416-4e13-a765-7c90683f3526] Trying to apply a migration context that
does not seem to be set for this instance {{(pid=20994) apply_migration_context
/opt/stack/new/nova/nova/objects/instance.py:977}}
This is wasteful as each lazy-loaded field is a round trip to the
database via conductor to set the field. If self.migration_context isn't
set, mutated_migration_context() should just yield and return.
** Affects: nova
Importance: Undecided
Status: Triaged
** Tags: rebuild
--
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/1696221
Title:
Unnecessary instance lazy-loads during rebuild
Status in OpenStack Compute (nova):
Triaged
Bug description:
The rebuild code in the compute manager also handles evacuate. Rebuild
is rebuild on the same host, no migration. Evacuate is rebuild the
instance on another host, and has a migration context.
This code:
https://github.com/openstack/nova/blob/e01ae75d52900d96355dfcb39ef9b136f0c0d5c4/nova/compute/manager.py#L2718
Is using the mutated_migration_context() context manager which lazy-
loads numa_topology, pci_requests and pci_devices and then, since
self.migration_context isn't set on the instance, yields as a noop.
Seen here:
http://logs.openstack.org/82/471082/1/gate/gate-novaclient-dsvm-
functional-neutron-ubuntu-
xenial/796acb7/logs/screen-n-cpu.txt.gz#_Jun_06_13_14_02_547424
Jun 06 13:14:02.547424 ubuntu-xenial-infracloud-chocolate-9158824
nova-compute[20994]: DEBUG nova.objects.instance [None
req-5b3770c1-d332-4875-8933-97de8a9890b4 admin admin] Lazy-loading
'pci_requests' on Instance uuid 573258a4-9416-4e13-a765-7c90683f3526
{{(pid=20994) obj_load_attr /opt/stack/new/nova/nova/objects/instance.py:1038}}
Jun 06 13:14:02.562243 ubuntu-xenial-infracloud-chocolate-9158824
nova-compute[20994]: DEBUG nova.objects.instance [None
req-5b3770c1-d332-4875-8933-97de8a9890b4 admin admin] Lazy-loading
'pci_devices' on Instance uuid 573258a4-9416-4e13-a765-7c90683f3526
{{(pid=20994) obj_load_attr /opt/stack/new/nova/nova/objects/instance.py:1038}}
Jun 06 13:14:02.577132 ubuntu-xenial-infracloud-chocolate-9158824
nova-compute[20994]: DEBUG nova.objects.instance [None
req-5b3770c1-d332-4875-8933-97de8a9890b4 admin admin] Lazy-loading
'migration_context' on Instance uuid 573258a4-9416-4e13-a765-7c90683f3526
{{(pid=20994) obj_load_attr /opt/stack/new/nova/nova/objects/instance.py:1038}}
Jun 06 13:14:02.590554 ubuntu-xenial-infracloud-chocolate-9158824
nova-compute[20994]: DEBUG nova.objects.instance [None
req-5b3770c1-d332-4875-8933-97de8a9890b4 admin admin] [instance:
573258a4-9416-4e13-a765-7c90683f3526] Trying to apply a migration context that
does not seem to be set for this instance {{(pid=20994) apply_migration_context
/opt/stack/new/nova/nova/objects/instance.py:977}}
This is wasteful as each lazy-loaded field is a round trip to the
database via conductor to set the field.
[Yahoo-eng-team] [Bug 1691195] Re: Can't live-migrate after "round-trip" volume-upate
Reviewed: https://review.openstack.org/465205
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=a8a4a8ea7b8e6c85273ddb02d34d6af1740b183f
Submitter: Jenkins
Branch:master
commit a8a4a8ea7b8e6c85273ddb02d34d6af1740b183f
Author: Artom Lifshitz
Date: Wed May 17 00:22:34 2017 +
Use VIR_DOMAIN_BLOCK_REBASE_COPY_DEV when rebasing
Previously, in swap_volume, the VIR_DOMAIN_BLOCK_REBASE_COPY_DEV flag
was not passed to virDomainBlockRebase. In the case of iSCSI-backed
disks, this caused the XML to change from
to . This was a problem because
/dev/iscsi/lun is not a regular file. This patch passes the
VIR_DOMAIN_BLOCK_REBASE_COPY_DEV flag to virDomainBlockRebase, causing
the correct to be generated upon
volume-update.
Change-Id: I868a0dae0baf8cded9c7c5807ea63ffc5eec0c5e
Closes-bug: 1691195
** 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/1691195
Title:
Can't live-migrate after "round-trip" volume-upate
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) newton series:
In Progress
Status in OpenStack Compute (nova) ocata series:
In Progress
Bug description:
Description
===
If an instance has had an attached volume volume-updated twice in a
"round-trip" - ie, volume-update $vol1 $vol2, then volume-update $vol2
$vol1 - it cannot be live-migrated.
Steps to reproduce
==
1. Create two iscsi volumes.
# cinder create --name test_vol1 --volume-type iscsi 1
# cinder create --name test_vol2 --volume-type iscsi 1
(--volume-type iscsi isn't mandatory - in my devstack environment there
is no iscsi volume-type, but that doesn't stop me from reproducing this
bug)
2. Boot an instance.
# nova boot --flavor 1 --image $imageid --nic net-id=$netid testvm1
3. Attach one iscsi volume to testvm1.
# nova volume-attach testvm1 $test_vol1
4. Do volume-update to swap volume to 2nd one. (1st time volume-update)
# nova volume-update testvm1 $test_vol1 $test_vol2
5. Do volume-update again to swap volume back to the 1st one. (2nd time
volume-update)
# nova volume-update testvm1 $test_vol2 $test_vol1
6. Live migrate instance to other compute node.
# nova live-migration testvm1
Expected result
===
Live migration succeeds.
Actual result
=
Live migration fails with:
Apr 27 10:32:14 multi9h-3 nova-compute: File "/usr/lib64/python2.7
/site-packages/libvirt.py", line 1939, in migrateToURI3
Apr 27 10:32:14 multi9h-3 nova-compute: if ret == -1: raise
libvirtError ('virDomainMigrateToURI3() failed', dom=self)
Apr 27 10:32:14 multi9h-3 nova-compute: libvirtError: missing source
information for device vdb
Environment
===
This has been originally reported [1] in Red Hat OSP 9 (Mitaka) and is
reproducible on devstack master as well.
Additional information
==
There are two things going on here.
1. When performing the volume-update, the libvirt driver calls
virDomainBlockRebase without the VIR_DOMAIN_BLOCK_REBASE_COPY_DEV flag
[2], meaning the device XML changes from to
. This is a problem because /dev/iscsi/lun
isn't a regular file, and causes the above error, except you need the
"round-trip" volume-update to trigger it. Why? Because:
2. The serial number isn't updated when doing volume-update, and
there's a bit of live-migration code [3] that checks for serial
numbers before updating the XML. If the serial numbers don't match,
the XML isn't updated, and libvirt doesn't notice that /dev/iscsi/lun
isn't a file.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1446446
[2] http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainBlockRebase
[3]
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/migration.py#L158
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1691195/+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 1696006] Re: Libvirt fails to detach network interface with Linux bridge
*** This bug is a duplicate of bug 1696125 *** https://bugs.launchpad.net/bugs/1696125 ** No longer affects: neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1696006 Title: Libvirt fails to detach network interface with Linux bridge Status in OpenStack Compute (nova): New Bug description: We are seeing a spike of failures in job gate-tempest-dsvm-neutron- linuxbridge-ubuntu-xenial, test tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic. As of this writing, there are 48 instances of this failure in Kibana: http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Failed%20to%20delete%20resource%5C%22%20AND%20message:%5C%22within%20the%20required%20time%20%5C%22%20AND%20message:%5C%22TestNetworkBasicOps:_run_cleanups%5C%22%20AND%20tags:%5C%22console%5C%22&from=7d I analyzed several cases and all seem to be the same. Compute manager calls libvirt to detach the interface and gets a failure (in this example, tap tap05567d09-b3 is being detached), so it raises an InterfaceDetachFailed exception: http://paste.openstack.org/show/611347/ The code involved is here: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5224 Since the exception is raised, the call to Neutron to delete the port is never executed: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5227. Since the tempest test was setup to wait for the port deletion to ascertain success of the interface removal (https://github.com/openstack/tempest/blob/master/tempest/scenario/test_network_basic_ops.py#L253) a timeout occurs and the test / job fails. It is worth noting that the Linuxbridge agent actually detected the removal of the interface: http://paste.openstack.org/show/611346/. Please note that tap05567d09-b3 shows up in the removed set of the changes detected by the agent It is also worth noting that this failure starts to show up in Kibana on 5/31/2017 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1696006/+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 1696098] Re: Race in deleting ports during Tempest Runs
*** This bug is a duplicate of bug 1696125 ***
https://bugs.launchpad.net/bugs/1696125
** This bug is no longer a duplicate of bug 1696006
Libvirt fails to detach network interface with Linux bridge
** This bug has been marked a duplicate of bug 1696125
Detach interface failed - Unable to detach from guest transient domain (pike)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1696098
Title:
Race in deleting ports during Tempest Runs
Status in neutron:
Confirmed
Bug description:
This is similar to https://bugs.launchpad.net/tempest/+bug/1357055
which is closed (and honestly would be confusing to make this the same
bug).
When trying to tear down subnets, they sometimes fail because the port
still exists. However there is no indication that the port delete
failed.
2017-06-05 18:38:20.846777 | Captured traceback-1:
2017-06-05 18:38:20.846795 | ~
2017-06-05 18:38:20.846817 | Traceback (most recent call last):
2017-06-05 18:38:20.846853 | File
"tempest/lib/common/utils/test_utils.py", line 84, in
call_and_ignore_notfound_exc
2017-06-05 18:38:20.846890 | return func(*args, **kwargs)
2017-06-05 18:38:20.846926 | File
"tempest/lib/services/network/subnets_client.py", line 52, in delete_subnet
2017-06-05 18:38:20.846949 | return self.delete_resource(uri)
2017-06-05 18:38:20.846981 | File
"tempest/lib/services/network/base.py", line 41, in delete_resource
2017-06-05 18:38:20.847004 | resp, body = self.delete(req_uri)
2017-06-05 18:38:20.847034 | File "tempest/lib/common/rest_client.py",
line 301, in delete
2017-06-05 18:38:20.847064 | return self.request('DELETE', url,
extra_headers, headers, body)
2017-06-05 18:38:20.847094 | File "tempest/lib/common/rest_client.py",
line 659, in request
2017-06-05 18:38:20.847117 | self._error_checker(resp, resp_body)
2017-06-05 18:38:20.847149 | File "tempest/lib/common/rest_client.py",
line 780, in _error_checker
2017-06-05 18:38:20.847175 | raise exceptions.Conflict(resp_body,
resp=resp)
2017-06-05 18:38:20.847208 | tempest.lib.exceptions.Conflict: An object
with that identifier already exists
2017-06-05 18:38:20.847274 | Details: {u'detail': u'', u'message':
u'Unable to complete operation on subnet 276de24c-4560-47f5-9feb-2964314d7814:
One or more ports have an IP allocation from this subnet.', u'type':
u'SubnetInUse'}
http://logs.openstack.org/53/469253/1/gate/gate-tempest-dsvm-neutron-
linuxbridge-ubuntu-
xenial/64416cc/console.html#_2017-06-05_18_38_20_847274
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1696098/+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 1694772] Re: test_keepalived_multiple_sighups_does_not_forfeit_mastership fails because of "AttributeError: 'module' object has no attribute 'LINUX_DEV_LEN'"
** 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/1694772 Title: test_keepalived_multiple_sighups_does_not_forfeit_mastership fails because of "AttributeError: 'module' object has no attribute 'LINUX_DEV_LEN'" Status in neutron: Fix Released Bug description: http://logs.openstack.org/82/465182/1/check/gate-neutron-dsvm- fullstack-ubuntu-xenial/a0a5ab4/logs/dsvm-fullstack- logs/TestHAL3Agent.test_keepalived_multiple_sighups_does_not_forfeit_mastership/neutron-l3-agent --2017-05-31--17-35-57-322793.txt.gz?level=TRACE 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info [req-2ccd326a-186e-4c00-85cc-17ed633b93dc - - - - -] 'module' object has no attribute 'LINUX_DEV_LEN' 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info Traceback (most recent call last): 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/common/utils.py", line 287, in call 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info return func(*args, **kwargs) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 1094, in process 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info self.process_external(agent) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 869, in process_external 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info self._process_external_gateway(ex_gw_port, agent.pd) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/agent/l3/router_info.py", line 750, in _process_external_gateway 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info interface_name = self.get_external_device_name(ex_gw_port_id) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info File "/opt/stack/new/neutron/neutron/tests/common/agents/l3_agent.py", line 96, in get_external_device_name 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info [:iptables_firewall.LINUX_DEV_LEN]) 2017-05-31 17:36:06.311 32260 ERROR neutron.agent.l3.router_info AttributeError: 'module' object has no attribute 'LINUX_DEV_LEN' This is probably Newton only. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694772/+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 1693353] Re: resource provider links list shows 'traits' in all microversions and should not
Reviewed: https://review.openstack.org/468923 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=72960a33e094f74de76f23d75dbaaae07332fa6f Submitter: Jenkins Branch:master commit 72960a33e094f74de76f23d75dbaaae07332fa6f Author: Chris Dent Date: Mon May 29 16:38:59 2017 + [placement] adjust resource provider links by microversion The resource provider representation includes links to other related resources. Those links should vary depending on microversion as some of the related resources did not show up until a later microversion. This change makes it so 'aggregates' show up at microverison 1.1 and beyond and traits in microversion 1.6 and beyond. A new gabbit has been added, resource-provider-links which exercises this. Only the single resource provider representation is tested because the same code is used for single and collection representations. Change-Id: Ife64922ee91a775fabdcf718e6eb0e0c7ddfde7a Closes-Bug: #1693353 ** 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/1693353 Title: resource provider links list shows 'traits' in all microversions and should not Status in OpenStack Compute (nova): Fix Released Bug description: When listing single or multiple resource providers, the JSON response includes a list of 'links' with each provider. These link to 'inventories', 'aggregates', 'usages' and 'traits'. Since 'traits' only showed up in microversion 1.6 the link to them should only be presented if the microversion is 1.6 or above. The change to fix this is in the '_serialize_links' method in nova.api.openstack.placement.handlers.resource_provider. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1693353/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1696176] [NEW] Add default routes for IPv4 and IPv6 only to ifcfg-* files and not to route-* or route6-* files in sysconfig
Public bug reported:
Since f38fa41317602908139aa96e930b634f65e39555 , default routes get
added to both ifcfg-* and route-* and route6-* files. (ii) Default
routes should only go to ifcfg-* files, otherwise the information is
redundant. (i) Also, in dual stack networks, this redundant "feature"
isn't working correctly, only the IPv6 route is added to both route6-*
and ifcfg-*, but not the IPv4 route.
(i) First of all, let me explain why only the IPv6 route was added to
route6-* and not the IPv4 route to route-*
sysconfig.py
(...)
for route in subnet.get('routes', []):
is_ipv6 = subnet.get('ipv6')
if _is_default_route(route):
if (
(subnet.get('ipv4') and
route_cfg.has_set_default_ipv4) or
(subnet.get('ipv6') and
route_cfg.has_set_default_ipv6)
):
raise ValueError("Duplicate declaration of default "
"route found for interface '%s'"
% (iface_cfg.name))
# NOTE(harlowja): ipv6 and ipv4 default gateways
gw_key = 'GATEWAY0'
nm_key = 'NETMASK0'
addr_key = 'ADDRESS0'
(...)
The above will obviously overwrite GATEWAY0, NETMASK0, ADDRESS0 when
there is an IPv4 default route and an IPv6 default route.
(ii) Now, interestingly, we don't want to add these routes to the
route-* and route6-* files, because this would only result in duplicate
default route declaration (we only need it in the ifcfg-* files, not in
the route-* or route6-*).
Which means that this can be fixed by changing indentation for the following
lines (moving all lines marked with "+" exactly 4 characters to the right).
This moves the route_cfg part into the "else" condition:
~~~
cd /usr/lib/python2.7/site-packages/cloudinit/net
[root@rhel-test net]# diff -u sysconfig.py.back sysconfig.py
--- sysconfig.py.back 2017-06-06 12:39:25.857595506 -0400
+++ sysconfig.py2017-06-06 12:40:19.059595506 -0400
@@ -372,11 +372,11 @@
nm_key = 'NETMASK%s' % route_cfg.last_idx
addr_key = 'ADDRESS%s' % route_cfg.last_idx
route_cfg.last_idx += 1
-for (old_key, new_key) in [('gateway', gw_key),
- ('netmask', nm_key),
- ('network', addr_key)]:
-if old_key in route:
-route_cfg[new_key] = route[old_key]
+for (old_key, new_key) in [('gateway', gw_key),
+ ('netmask', nm_key),
+ ('network', addr_key)]:
+if old_key in route:
+route_cfg[new_key] = route[old_key]
@classmethod
def _render_bonding_opts(cls, iface_cfg, iface):
~~~
The above means that a route will only be added to the route_cfg array
if it is not a default route.
** 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/1696176
Title:
Add default routes for IPv4 and IPv6 only to ifcfg-* files and not to
route-* or route6-* files in sysconfig
Status in cloud-init:
New
Bug description:
Since f38fa41317602908139aa96e930b634f65e39555 , default routes get
added to both ifcfg-* and route-* and route6-* files. (ii) Default
routes should only go to ifcfg-* files, otherwise the information is
redundant. (i) Also, in dual stack networks, this redundant "feature"
isn't working correctly, only the IPv6 route is added to both route6-*
and ifcfg-*, but not the IPv4 route.
(i) First of all, let me explain why only the IPv6 route was added to
route6-* and not the IPv4 route to route-*
sysconfig.py
(...)
for route in subnet.get('routes', []):
is_ipv6 = subnet.get('ipv6')
if _is_default_route(route):
if (
(subnet.get('ipv4') and
route_cfg.has_set_default_ipv4) or
(subnet.get('ipv6') and
route_cfg.has_set_default_ipv6)
):
raise ValueError("Duplicate declaration of default "
"route found for interface '%s'"
% (iface_cfg.name))
# NOTE(harlowja): ipv6 and ipv4 default gateways
gw_key = 'GATEWAY0'
nm_key = 'NETMASK0'
addr_key = 'ADDRESS0'
(...)
The above will obviously overwrite GAT
[Yahoo-eng-team] [Bug 1685185] Re: disconnect_volume not called when rebase failures are encountered during swap_volume
** Changed in: nova
Importance: Undecided => Medium
** Also affects: nova/newton
Importance: Undecided
Status: New
** Also affects: nova/ocata
Importance: Undecided
Status: New
** Changed in: nova/newton
Status: New => In Progress
** Changed in: nova/ocata
Status: New => In Progress
** Changed in: nova/newton
Importance: Undecided => Medium
** Changed in: nova/ocata
Importance: Undecided => Medium
** Changed in: nova/newton
Assignee: (unassigned) => Lee Yarwood (lyarwood)
** Changed in: nova/ocata
Assignee: (unassigned) => Lee Yarwood (lyarwood)
--
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/1685185
Title:
disconnect_volume not called when rebase failures are encountered
during swap_volume
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) newton series:
In Progress
Status in OpenStack Compute (nova) ocata series:
In Progress
Bug description:
Description
===
At present disconnect_volume is not called when rebase failures are
encountered during swap_volume. This results in the new volume
remaining connected to the compute host prior to terminate_connection
then being called. This can in turn lead to left over devices
remaining on the compute host for some volume backends such as
LVM/iSCSI.
Steps to reproduce
==
Downstream, the easiest way to reproduce this is via
https://bugzilla.redhat.com/show_bug.cgi?id=1401755 :
# sudo setenforce 1
# nova update-volume ${instance_uuid} \
${attached_NFS_volume_id} \
${unattached_iSCSI_volume_id}
Upstream, I've been unable to get devstack to even work correctly with
SELinux in enforcing mode so I've been unable to reproduce the
rollback this way.
Expected result
===
New volume disconnected from compute host.
Actual result
=
New volume remains connected to compute host.
Environment
===
1. Exact version of OpenStack you are running. See the following
list for all releases: http://docs.openstack.org/releases/
N/A
2. Which hypervisor did you use?
(For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
What's the version of that?
Libvirt + KVM
2. Which storage type did you use?
(For example: Ceph, LVM, GPFS, ...)
What's the version of that?
NFS + LVM/iSCSI
3. Which networking type did you use?
(For example: nova-network, Neutron with OpenVSwitch, ...)
N/A
Logs & Configs
==
Example Newton trace :
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher
[req-f31f6110-e880-41e8-be1a-2c41ea7fd9ce 75fbc7a6db34480091d2a53e2e20b695
62e53e5e804e49a9890928a5a4846f60 - - -] Exception during message handling:
internal error: unable to execute QEMU command 'drive-mirror': Could not open
'/dev/disk/by-id/dm-uuid-mpath-360014053aac4f90daef4d76baa773169': Permission
denied
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher Traceback
(most recent call last):
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 138,
in _dispatch_and_reply
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher
incoming.message))
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 183,
in _dispatch
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher return
self._do_dispatch(endpoint, method, ctxt, args)
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 127,
in _do_dispatch
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher result =
func(ctxt, **new_args)
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/site-packages/nova/exception.py", line 110, in wrapped
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher payload)
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher
self.force_reraise()
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher
six.reraise(self.type_, self.value, self.tb)
2017-04-12 09:37:53.744 3077 ERROR oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/site-packages/nova/exception.py", line 89, in wrapped
2017-
[Yahoo-eng-team] [Bug 1696152] [NEW] nova notifications use nova-api as binary name instead of nova-osapi_compute
Public bug reported: There are multiple places in nova where the binary of the nova api service is referred as 'nova-api'[1] but in fact the correct name of that binary is 'nova-osapi_compute' [2] [1]https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=binary%3Dnova-api&type= [2]https://github.com/openstack/nova/blob/a818049554f61316930c7122bb0831b6372fadc0/api-guide/source/general_info.rst ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1696152 Title: nova notifications use nova-api as binary name instead of nova- osapi_compute Status in OpenStack Compute (nova): New Bug description: There are multiple places in nova where the binary of the nova api service is referred as 'nova-api'[1] but in fact the correct name of that binary is 'nova-osapi_compute' [2] [1]https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=binary%3Dnova-api&type= [2]https://github.com/openstack/nova/blob/a818049554f61316930c7122bb0831b6372fadc0/api-guide/source/general_info.rst To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1696152/+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 1696006] Re: Libvirt fails to detach network interface with Linux bridge
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Importance: Undecided => Critical -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1696006 Title: Libvirt fails to detach network interface with Linux bridge Status in neutron: New Status in OpenStack Compute (nova): New Bug description: We are seeing a spike of failures in job gate-tempest-dsvm-neutron- linuxbridge-ubuntu-xenial, test tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic. As of this writing, there are 48 instances of this failure in Kibana: http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Failed%20to%20delete%20resource%5C%22%20AND%20message:%5C%22within%20the%20required%20time%20%5C%22%20AND%20message:%5C%22TestNetworkBasicOps:_run_cleanups%5C%22%20AND%20tags:%5C%22console%5C%22&from=7d I analyzed several cases and all seem to be the same. Compute manager calls libvirt to detach the interface and gets a failure (in this example, tap tap05567d09-b3 is being detached), so it raises an InterfaceDetachFailed exception: http://paste.openstack.org/show/611347/ The code involved is here: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5224 Since the exception is raised, the call to Neutron to delete the port is never executed: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5227. Since the tempest test was setup to wait for the port deletion to ascertain success of the interface removal (https://github.com/openstack/tempest/blob/master/tempest/scenario/test_network_basic_ops.py#L253) a timeout occurs and the test / job fails. It is worth noting that the Linuxbridge agent actually detected the removal of the interface: http://paste.openstack.org/show/611346/. Please note that tap05567d09-b3 shows up in the removed set of the changes detected by the agent It is also worth noting that this failure starts to show up in Kibana on 5/31/2017 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1696006/+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 1669844] Re: Host failure shortly after image download can result in data corruption
Reviewed: https://review.openstack.org/443230 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=1301368bf2352eddcc664202d7f159f523f681e2 Submitter: Jenkins Branch:master commit 1301368bf2352eddcc664202d7f159f523f681e2 Author: Matthew Booth Date: Wed Mar 8 16:38:49 2017 + Ensure image conversion flushes output data to disk qemu-img convert defaults to cache=none, which means that when it completes the output data may still only be in the host kernel's cache rather than on persistent storage. A host crash at this point will leave a file with the correct metadata (name, size, ownership, permissions), but no contents. This will prevent qcow2 instances on that compute host which use that image from restarting, and requires manual intervention from an operator to fix. See also change Id9905a87, which fixes this issue for downloads without a conversion. Closes-Bug: #1669844 Change-Id: I33bd99b0752111ff7057f9bd40e58dcde77c7d95 ** 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/1669844 Title: Host failure shortly after image download can result in data corruption Status in OpenStack Compute (nova): Fix Released Bug description: GlanceImageServiceV2.download() ensures its downloaded file is closed before releasing for use by an external qemu process, but it doesn't do an fdatasync(). This means that the downloaded file may be temporarily in the host kernel's cache rather than on disk, which means there is a short window in which a host crash will lose the contents of the backing file, despite it being in use by a running instance. Disclaimer: I'm not personally able to reproduce this, but it looks sane and our QE team is reliably hitting it. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1669844/+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 1664465] Re: check instance exist before check in cell
Reviewed: https://review.openstack.org/433470 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=4ac27e815c48d1ff89218bd62fef49ab238f2764 Submitter: Jenkins Branch:master commit 4ac27e815c48d1ff89218bd62fef49ab238f2764 Author: jichenjc Date: Mon Jan 23 23:11:39 2017 +0800 Check instance existing before check in mapping The instance might be not exist during checking so we provide a incorrect info to admin, this patch check instance exist before check in mapping. Closes-Bug: 1664465 Change-Id: I21a7d1effaadcbda4cfbd0a0465b984ebb484f24 ** 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/1664465 Title: check instance exist before check in cell Status in OpenStack Compute (nova): Fix Released Bug description: we should check whether instance exist before saying (upgrade is incomplete) as the instance itself doesn't exist (I removed 'e' on purpose) stack@ubuntu1604:/opt/stack/nova$ nova-manage cell_v2 verify_instance --uuid 0e7a7e72-3d75-46af-86a9-3ccf7b97699e /usr/local/lib/python2.7/dist-packages/pymysql/cursors.py:166: Warning: (3090, u"Changing sql mode 'NO_AUTO_CREATE_USER' is deprecated. It will be removed in a future release.") result = self._query(query) Instance 0e7a7e72-3d75-46af-86a9-3ccf7b97699e is in cell: None (85980b20-6ca3-451f-a873-af4a5ba3809f) stack@ubuntu1604:/opt/stack/nova$ nova-manage cell_v2 verify_instance --uuid 0e7a7e72-3d75-46af-86a9-3ccf7b97699 /usr/local/lib/python2.7/dist-packages/pymysql/cursors.py:166: Warning: (3090, u"Changing sql mode 'NO_AUTO_CREATE_USER' is deprecated. It will be removed in a future release.") result = self._query(query) Instance 0e7a7e72-3d75-46af-86a9-3ccf7b97699 is not mapped to a cell (upgrade is incomplete) stack@ubuntu1604:/opt/stack/nova$ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1664465/+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 1696135] Re: kali console (onecloudhosting) crashes
solved ** Changed in: nova Status: New => 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/1696135 Title: kali console (onecloudhosting) crashes Status in OpenStack Compute (nova): Fix Released Bug description: VPS Security Distros Kali Linux 2017.1 Latest Configurable Options VM Image Kali Linux 2017.1 x64 IP Addresses 1 Backups Files Limit 0 Disk 50 [GB] RAM 4096 [MB] VCPUs 2 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1696135/+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 1696135] [NEW] kali console (onecloudhosting) crashes
Public bug reported: VPS Security Distros Kali Linux 2017.1 Latest Configurable Options VM Image Kali Linux 2017.1 x64 IP Addresses 1 Backups Files Limit 0 Disk 50 [GB] RAM 4096 [MB] VCPUs 2 ** Affects: nova Importance: Undecided Status: 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/1696135 Title: kali console (onecloudhosting) crashes Status in OpenStack Compute (nova): Fix Released Bug description: VPS Security Distros Kali Linux 2017.1 Latest Configurable Options VM Image Kali Linux 2017.1 x64 IP Addresses 1 Backups Files Limit 0 Disk 50 [GB] RAM 4096 [MB] VCPUs 2 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1696135/+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 1649852] Re: Concurrent calls to DELETE os-floating-ips can raise uncaught neutronclient.common.exceptions.NotFound
** Changed in: nova
Assignee: Matt Riedemann (mriedem) => Guillaume Espanel (guillaume-espanel)
** Changed in: nova
Importance: Undecided => Medium
** Also affects: nova/ocata
Importance: Undecided
Status: New
** Changed in: nova/ocata
Status: New => Confirmed
** Changed in: nova/ocata
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1649852
Title:
Concurrent calls to DELETE os-floating-ips can raise uncaught
neutronclient.common.exceptions.NotFound
Status in OpenStack Compute (nova):
In Progress
Status in OpenStack Compute (nova) ocata series:
Confirmed
Bug description:
Description
Concurrent calls to DELETE os-floating-ips/floating-ip-id can cause
neutronclient to raise
a neutronclient.common.exceptions.NotFound exception uncaught by Nova which
in turn returns
a 500 Error.
Steps to reproduce
===
Tested on a mitaka devstack :
- source openrc
- run this humble script :
FIP_ID=`nova floating-ip-create | grep public | awk '{print($2)}'`
TENANT_ID=`keystone token-get | grep " tenant_id " | awk '{print($4)}'`
TOKEN_ID=`keystone token-get | grep " id " | awk '{print($4)}'`
curl -g -i -X DELETE
http://127.0.0.1:8774/v2.1/$TENANT_ID/os-floating-ips/$FIP_ID -H "User-Agent:
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN_ID"&
curl -g -i -X DELETE
http://127.0.0.1:8774/v2.1/$TENANT_ID/os-floating-ips/$FIP_ID -H "User-Agent:
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN_ID"&
curl -g -i -X DELETE
http://127.0.0.1:8774/v2.1/$TENANT_ID/os-floating-ips/$FIP_ID -H "User-Agent:
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN_ID"&
curl -g -i -X DELETE
http://127.0.0.1:8774/v2.1/$TENANT_ID/os-floating-ips/$FIP_ID -H "User-Agent:
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: $TOKEN_ID"
Expected result
First call to go trough should return a 202, and all other calls
should probably return 404 or 409 if deletion is in progress but not
500.
Actual result
==
Some calls to DELETE get a 500 Error response.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1649852/+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 1696094] Re: CI: ovb-ha promotion job fails with 504 gateway timeout
** Also 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/1696094
Title:
CI: ovb-ha promotion job fails with 504 gateway timeout
Status in neutron:
New
Status in tripleo:
Triaged
Bug description:
http://logs.openstack.org/15/359215/106/experimental-tripleo/gate-
tripleo-ci-centos-7-ovb-
ha/2ea94ab/console.html#_2017-06-05_23_52_38_539282
2017-06-05 23:50:34.148537 |
+---+--+
2017-06-05 23:50:35.545475 | neutron CLI is deprecated and will be removed in
the future. Use openstack CLI instead.
2017-06-05 23:52:38.539282 | 504 Gateway Time-out
2017-06-05 23:52:38.539408 | The server didn't respond in time.
2017-06-05 23:52:38.539437 |
It happens on where subnet creation should be.
I see in logs ovs-vsctl failure, but not sure it's not red herring.
http://logs.openstack.org/15/359215/106/experimental-tripleo/gate-
tripleo-ci-centos-7-ovb-ha/2ea94ab/logs/controller-1-tripleo-
ci-b-bar/var/log/messages
Jun 5 23:48:22 localhost ovs-vsctl: ovs|1|vsctl|INFO|Called as
/bin/ovs-vsctl --timeout=5 --id=@manager -- create Manager
"target=\"ptcp:6640:127.0.0.1\"" -- add Open_vSwitch . manager_options @manager
Jun 5 23:48:22 localhost ovs-vsctl: ovs|2|db_ctl_base|ERR|transaction
error: {"details":"Transaction causes multiple rows in \"Manager\" table to
have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\".
First row, with UUID 7e2b866a-40d5-4f9c-9e08-0be3bb34b199, existed in the
database before this transaction and was not modified by the transaction.
Second row, with UUID 49488cff-271a-457a-b1e7-e6ca3da6f069, was inserted by
this transaction.","error":"constraint violation"}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1696094/+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 1696125] [NEW] Detach interface failed - Unable to detach from guest transient domain (pike)
Public bug reported: Seeing this in Tempest runs on master (pike): http://logs.openstack.org/24/471024/2/check/gate-tempest-dsvm-neutron- linuxbridge-ubuntu- xenial/6b98d38/logs/screen-n-cpu.txt.gz?level=TRACE#_Jun_06_02_16_02_855503 Jun 06 02:16:02.855503 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: WARNING nova.compute.manager [None req-b4a50024-a2fd-4279-b284-340d2074f1c1 tempest-TestNetworkBasicOps-1479445685 tempest-TestNetworkBasicOps-1479445685] [instance: 2668bcb9-b13d-4b5b-8ee5-edbdee3b15a8] Detach interface failed, port_id=3843caa3-ab04-45f1-94d8-f330390e40fe, reason: Device detach failed for fa:16:3e:ab:e3:3f: Unable to detach from guest transient domain.: DeviceDetachFailed: Device detach failed for fa:16:3e:ab:e3:3f: Unable to detach from guest transient domain. Jun 06 02:16:02.884007 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server [None req-b4a50024-a2fd-4279-b284-340d2074f1c1 tempest-TestNetworkBasicOps-1479445685 tempest-TestNetworkBasicOps-1479445685] Exception during message handling: InterfaceDetachFailed: Failed to detach network adapter device from 2668bcb9-b13d-4b5b-8ee5-edbdee3b15a8 Jun 06 02:16:02.884180 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server Traceback (most recent call last): Jun 06 02:16:02.884286 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 157, in _process_incoming Jun 06 02:16:02.884395 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) Jun 06 02:16:02.884538 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 213, in dispatch Jun 06 02:16:02.884669 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) Jun 06 02:16:02.884777 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 183, in _do_dispatch Jun 06 02:16:02.884869 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) Jun 06 02:16:02.884968 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/opt/stack/new/nova/nova/exception_wrapper.py", line 77, in wrapped Jun 06 02:16:02.885069 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server function_name, call_dict, binary) Jun 06 02:16:02.885171 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ Jun 06 02:16:02.885272 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server self.force_reraise() Jun 06 02:16:02.885367 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise Jun 06 02:16:02.885461 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) Jun 06 02:16:02.885554 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/opt/stack/new/nova/nova/exception_wrapper.py", line 68, in wrapped Jun 06 02:16:02.885649 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server return f(self, context, *args, **kw) Jun 06 02:16:02.885755 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/opt/stack/new/nova/nova/compute/manager.py", line 214, in decorated_function Jun 06 02:16:02.885856 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server kwargs['instance'], e, sys.exc_info()) Jun 06 02:16:02.885950 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ Jun 06 02:16:02.886053 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server self.force_reraise() Jun 06 02:16:02.886143 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise Jun 06 02:16:02.886232 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) Jun 06 02:16:02.886322 ubuntu-xenial-ovh-bhs1-9149075 nova-compute[24118]: ERROR oslo_messaging.rpc.server File "/opt/stack/new/nova/nova/co
[Yahoo-eng-team] [Bug 1696111] [NEW] Keystone confuses users when creating a trust when there's a roles name conflict
Public bug reported: Due to code [1] Keystone produces a confusing message when: * We're using python-openstackclient * We're creating a trust with a role name that exists in more that one domain. "role %s is not defined" suggests that there isn't a role like that. What actually happens, Keystone cannot decide which role is the user's choice. python-openstackclient automatically converts role ids to role names when sending a POST request, so specifying roles using an id doesn't help at all. [1] https://github.com/openstack/keystone/blob/03319d1/keystone/trust/controllers.py#L90-L94 ** Affects: keystone Importance: Undecided Status: New ** Affects: python-openstackclient Importance: Undecided Status: New ** Also affects: python-openstackclient Importance: Undecided Status: New -- 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/1696111 Title: Keystone confuses users when creating a trust when there's a roles name conflict Status in OpenStack Identity (keystone): New Status in python-openstackclient: New Bug description: Due to code [1] Keystone produces a confusing message when: * We're using python-openstackclient * We're creating a trust with a role name that exists in more that one domain. "role %s is not defined" suggests that there isn't a role like that. What actually happens, Keystone cannot decide which role is the user's choice. python-openstackclient automatically converts role ids to role names when sending a POST request, so specifying roles using an id doesn't help at all. [1] https://github.com/openstack/keystone/blob/03319d1/keystone/trust/controllers.py#L90-L94 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1696111/+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 1696104] [NEW] iptables without ipset are not being restored after reboot
Public bug reported: After deleting all VMs from compute node there are related to ipset entries left in /etc/iptables/rules.v4. So after restarting this node not all of the entries would be restored. Steps to reproduce: 1. Create VM 2. Delete VM 3. Check number of entries in iptables-save 4. Reboot compute node 5. Check number of entries in iptables-save or run `iptables-restore < /etc/iptables/rules.v4` Expected output: Not all entries are restored Actual output: # iptables-restore < /etc/iptables/rules.v4 iptables-restore v1.4.21: Set NIPv4d6056099-2723-45ac-bf56- doesn't exist. Error occurred at line: 161 Try `iptables-restore -h' or 'iptables-restore --help' for more information. Version: Openstack Mitaka ** 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/1696104 Title: iptables without ipset are not being restored after reboot Status in neutron: New Bug description: After deleting all VMs from compute node there are related to ipset entries left in /etc/iptables/rules.v4. So after restarting this node not all of the entries would be restored. Steps to reproduce: 1. Create VM 2. Delete VM 3. Check number of entries in iptables-save 4. Reboot compute node 5. Check number of entries in iptables-save or run `iptables-restore < /etc/iptables/rules.v4` Expected output: Not all entries are restored Actual output: # iptables-restore < /etc/iptables/rules.v4 iptables-restore v1.4.21: Set NIPv4d6056099-2723-45ac-bf56- doesn't exist. Error occurred at line: 161 Try `iptables-restore -h' or 'iptables-restore --help' for more information. Version: Openstack Mitaka To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1696104/+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 1696098] [NEW] Race in deleting ports during Tempest Runs
Public bug reported:
This is similar to https://bugs.launchpad.net/tempest/+bug/1357055 which
is closed (and honestly would be confusing to make this the same bug).
When trying to tear down subnets, they sometimes fail because the port
still exists. However there is no indication that the port delete
failed.
2017-06-05 18:38:20.846777 | Captured traceback-1:
2017-06-05 18:38:20.846795 | ~
2017-06-05 18:38:20.846817 | Traceback (most recent call last):
2017-06-05 18:38:20.846853 | File
"tempest/lib/common/utils/test_utils.py", line 84, in
call_and_ignore_notfound_exc
2017-06-05 18:38:20.846890 | return func(*args, **kwargs)
2017-06-05 18:38:20.846926 | File
"tempest/lib/services/network/subnets_client.py", line 52, in delete_subnet
2017-06-05 18:38:20.846949 | return self.delete_resource(uri)
2017-06-05 18:38:20.846981 | File "tempest/lib/services/network/base.py",
line 41, in delete_resource
2017-06-05 18:38:20.847004 | resp, body = self.delete(req_uri)
2017-06-05 18:38:20.847034 | File "tempest/lib/common/rest_client.py",
line 301, in delete
2017-06-05 18:38:20.847064 | return self.request('DELETE', url,
extra_headers, headers, body)
2017-06-05 18:38:20.847094 | File "tempest/lib/common/rest_client.py",
line 659, in request
2017-06-05 18:38:20.847117 | self._error_checker(resp, resp_body)
2017-06-05 18:38:20.847149 | File "tempest/lib/common/rest_client.py",
line 780, in _error_checker
2017-06-05 18:38:20.847175 | raise exceptions.Conflict(resp_body,
resp=resp)
2017-06-05 18:38:20.847208 | tempest.lib.exceptions.Conflict: An object
with that identifier already exists
2017-06-05 18:38:20.847274 | Details: {u'detail': u'', u'message': u'Unable
to complete operation on subnet 276de24c-4560-47f5-9feb-2964314d7814: One or
more ports have an IP allocation from this subnet.', u'type': u'SubnetInUse'}
http://logs.openstack.org/53/469253/1/gate/gate-tempest-dsvm-neutron-
linuxbridge-ubuntu-
xenial/64416cc/console.html#_2017-06-05_18_38_20_847274
** 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/1696098
Title:
Race in deleting ports during Tempest Runs
Status in neutron:
New
Bug description:
This is similar to https://bugs.launchpad.net/tempest/+bug/1357055
which is closed (and honestly would be confusing to make this the same
bug).
When trying to tear down subnets, they sometimes fail because the port
still exists. However there is no indication that the port delete
failed.
2017-06-05 18:38:20.846777 | Captured traceback-1:
2017-06-05 18:38:20.846795 | ~
2017-06-05 18:38:20.846817 | Traceback (most recent call last):
2017-06-05 18:38:20.846853 | File
"tempest/lib/common/utils/test_utils.py", line 84, in
call_and_ignore_notfound_exc
2017-06-05 18:38:20.846890 | return func(*args, **kwargs)
2017-06-05 18:38:20.846926 | File
"tempest/lib/services/network/subnets_client.py", line 52, in delete_subnet
2017-06-05 18:38:20.846949 | return self.delete_resource(uri)
2017-06-05 18:38:20.846981 | File
"tempest/lib/services/network/base.py", line 41, in delete_resource
2017-06-05 18:38:20.847004 | resp, body = self.delete(req_uri)
2017-06-05 18:38:20.847034 | File "tempest/lib/common/rest_client.py",
line 301, in delete
2017-06-05 18:38:20.847064 | return self.request('DELETE', url,
extra_headers, headers, body)
2017-06-05 18:38:20.847094 | File "tempest/lib/common/rest_client.py",
line 659, in request
2017-06-05 18:38:20.847117 | self._error_checker(resp, resp_body)
2017-06-05 18:38:20.847149 | File "tempest/lib/common/rest_client.py",
line 780, in _error_checker
2017-06-05 18:38:20.847175 | raise exceptions.Conflict(resp_body,
resp=resp)
2017-06-05 18:38:20.847208 | tempest.lib.exceptions.Conflict: An object
with that identifier already exists
2017-06-05 18:38:20.847274 | Details: {u'detail': u'', u'message':
u'Unable to complete operation on subnet 276de24c-4560-47f5-9feb-2964314d7814:
One or more ports have an IP allocation from this subnet.', u'type':
u'SubnetInUse'}
http://logs.openstack.org/53/469253/1/gate/gate-tempest-dsvm-neutron-
linuxbridge-ubuntu-
xenial/64416cc/console.html#_2017-06-05_18_38_20_847274
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1696098/+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 1696093] [NEW] When update a firewall, we should update the iptables firstly, and then clear the conntrack record, just like the function create_firewall(). Otherwise, the contra
Public bug reported: environment: devstack master When update a firewall, we should update the iptables firstly, and then clear the conntrack record, just like the function create_firewall(). Otherwise, the contrack record could be reproduced. We can trigger the firewall_update action by: 1.#neutron firewall-update f1 --no-routers 2.vm ping external ip address all the time 3.#neutron firewall-update f1 --router demo-router We can found that vm still can ping external ip address successfully. ** Affects: neutron Importance: Undecided Assignee: wujun (wujun) Status: New ** Tags: fwaas ** Changed in: neutron Assignee: (unassigned) => wujun (wujun) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1696093 Title: When update a firewall, we should update the iptables firstly, and then clear the conntrack record, just like the function create_firewall(). Otherwise, the contrack record could be reproduced. Status in neutron: New Bug description: environment: devstack master When update a firewall, we should update the iptables firstly, and then clear the conntrack record, just like the function create_firewall(). Otherwise, the contrack record could be reproduced. We can trigger the firewall_update action by: 1.#neutron firewall-update f1 --no-routers 2.vm ping external ip address all the time 3.#neutron firewall-update f1 --router demo-router We can found that vm still can ping external ip address successfully. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1696093/+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 1695533] Re: Incorrect URL in XML used by libvirt to launch instance
I don't think that this is a valid bug, as the XML namespace URI is usually not a "real" URI. In Wikipedia you will also find: "[...] the namespace specification does not require nor suggest that the namespace URI be used to retrieve information. [...]" https://en.wikipedia.org/wiki/XML_namespace FWIW: The XML metadata in the domain XML got introduced with commit https://github.com/openstack/nova/commit/bf02f13 The blueprint is this: http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/libvirt-driver-domain-metadata.html ** Changed in: nova Status: New => Invalid -- 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/1695533 Title: Incorrect URL in XML used by libvirt to launch instance Status in OpenStack Compute (nova): Invalid Bug description: I launched an instance using Devstack running on QEMU hypervisor. I dumped the XML of VM to see what things are getting configured and found a URL in the XML. The URL points to a page which no longer exists on the openstack.org website. I guess this URL gets embedded in each VM's XML. Though it does nothing (maybe pointing to the syntax used to define XML), and I am interested in this URL. I have filed this bug so that the URL can be corrected or can be removed from the XML. Attached is the full dumpxml. Here is a snippet of it: http://openstack.org/xmlns/libvirt/nova/1.0";> ttt Steps to reproduce: 1. Launch an instance 2. Goto compute node where the instance is running. 3. Do "virsh dumpxml " 4. Check the URL in dumped output. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1695533/+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 1693670] Re: Fix doc generation for Python3
Reviewed: https://review.openstack.org/470673 Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=ef21b5798901243ec2eed4ba8af871029c33532d Submitter: Jenkins Branch:master commit ef21b5798901243ec2eed4ba8af871029c33532d Author: Vu Cong Tuan Date: Sun Jun 4 12:27:34 2017 +0700 Fix html_last_updated_fmt for Python3 html_last_updated_fmt option is interpreted as a byte string in python3, causing Sphinx build to break. This patch makes it utf-8 string. Change-Id: I261fc5fecad14dd1e9c37877388bc91d8a18b26d Closes-Bug:#1693670 ** Changed in: neutron Status: Confirmed => 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/1693670 Title: Fix doc generation for Python3 Status in neutron: Fix Released Status in tacker: Fix Released Status in zaqar: Fix Released Bug description: Fix the Sphinx html_last_updated_fmt for Python3. The html_last_updated_fmt option is interpeted as a byte string in python3, causing Sphinx build to break. This patch makes it utf-8 string. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1693670/+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 1696082] [NEW] 'nova.exception.NeutronAdminCredentialConfigurationInvalid
Public bug reported: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-b31a490e-9a16-4e60-87c8-98266a9bb4c4) [root@controller ~(keystone_fulladmin)]$ dpkg -l | grep nova ii nova-api 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute - API frontend ii nova-common 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-conductor 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute - conductor service ii nova-consoleauth 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute - Console Authenticator ii nova-doc 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute - documentation ii nova-novncproxy 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute - NoVNC proxy ii nova-placement-api 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute - placement API frontend ii nova-scheduler 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute - virtual machine scheduler ii python-nova 2:15.0.2-0ubuntu1~cloud0 all OpenStack Compute Python libraries ii python-novaclient2:7.1.0-0ubuntu1~cloud0 all client library for OpenStack Compute API - Python 2.7 2017-06-06 14:20:46.952 6587 ERROR nova.network.neutronv2.api [req-b31a490e-9a16-4e60-87c8-98266a9bb4c4 ebdda307ceb44f4c8984f9c2a0e7b839 96b226f6aa2f4d32b361ad0fa3eec46c - default default] Neutron client was not able to generate a valid admin token, please verify Neutron admin credential located in nova.conf 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions [req-b31a490e-9a16-4e60-87c8-98266a9bb4c4 ebdda307ceb44f4c8984f9c2a0e7b839 96b226f6aa2f4d32b361ad0fa3eec46c - default default] Unexpected exception in API method 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py", line 338, in wrapped 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, in wrapper 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, in wrapper 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, in wrapper 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, in wrapper 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, in wrapper 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, in wrapper 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/servers.py", line 642, in create 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions **create_kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/hooks.py", line 154, in inner 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions rv = f(*args, **kwargs) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 1613, in create 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions check_server_group_quota=check_server_group_quota) 2017-06-06 14:20:46.952 6587 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist
[Yahoo-eng-team] [Bug 1696076] [NEW] tempest plugin needs an update for identity v3
Public bug reported: some tests are disabled for identity v3 only deployment after [1]. [1] I8fffc50fd45e43f34ca591416924bcf29626b21f ** 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/1696076 Title: tempest plugin needs an update for identity v3 Status in neutron: New Bug description: some tests are disabled for identity v3 only deployment after [1]. [1] I8fffc50fd45e43f34ca591416924bcf29626b21f To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1696076/+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
