[Yahoo-eng-team] [Bug 1733783] [NEW] some links are invalid in the spec file
Public bug reported: The old link is invalid, we can't access any more. so fix it ** Affects: neutron Importance: Undecided Assignee: zhangyanxian (zhang-yanxian) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => zhangyanxian (zhang-yanxian) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733783 Title: some links are invalid in the spec file Status in neutron: In Progress Bug description: The old link is invalid, we can't access any more. so fix it To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733783/+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 1733757] [NEW] Remove deprecated neutron.common.utils.ensure_dir
Public bug reported: ensure_dir implementation has been moved from neutron.agent.linux.utils and will be deprecated for removal in version Ocata. ensure_tree(path, 0o755) from oslo_utils.fileutils can be used instead. ** Affects: neutron Importance: Undecided Assignee: Chenghui Yu (chenghuiyu) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Chenghui Yu (chenghuiyu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733757 Title: Remove deprecated neutron.common.utils.ensure_dir Status in neutron: In Progress Bug description: ensure_dir implementation has been moved from neutron.agent.linux.utils and will be deprecated for removal in version Ocata. ensure_tree(path, 0o755) from oslo_utils.fileutils can be used instead. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733757/+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 1733754] [NEW] 500 error if OS-TRUST:trust is not a dict when authenticate
Public bug reported:
env: master branch
when user try to issue a token with OS-TRUST:trust if OS-TRUST:trust is not a
dict, keystone will raise 500 error:
SZX1000339032 devstack@keystone.service[12272]: ERROR keystone.common.wsgi
Traceback (most recent call last):
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/common/wsgi.py", line
228, in __call__
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi LOG.warning(
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/controllers.py",
line 114, in authenticate_for_token
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi auth_info = core.AuthInfo.create(auth=auth)
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/core.py", line
142, in create
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi auth_info._validate_and_normalize_auth_data(scope_only)
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/core.py", line
295, in _validate_and_normalize_auth_data
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi self._validate_and_normalize_scope_data()
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/core.py", line
255, in _validate_and_normalize_scope_dat
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi self.auth['scope']['OS-TRUST:trust'])
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/core.py", line
224, in _lookup_trust
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi trust_id = trust_info.get('id')
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi AttributeError: 'str' object has no attribute 'get'
Keystone should add OS-TRUST:trust into the schema check as well.
** Affects: keystone
Importance: Undecided
Assignee: wangxiyuan (wangxiyuan)
Status: New
** Changed in: keystone
Assignee: (unassigned) => wangxiyuan (wangxiyuan)
--
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/1733754
Title:
500 error if OS-TRUST:trust is not a dict when authenticate
Status in OpenStack Identity (keystone):
New
Bug description:
env: master branch
when user try to issue a token with OS-TRUST:trust if OS-TRUST:trust is not a
dict, keystone will raise 500 error:
SZX1000339032 devstack@keystone.service[12272]: ERROR keystone.common.wsgi
Traceback (most recent call last):
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/common/wsgi.py", line
228, in __call__
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi LOG.warning(
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/controllers.py",
line 114, in authenticate_for_token
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi auth_info = core.AuthInfo.create(auth=auth)
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/core.py", line
142, in create
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi auth_info._validate_and_normalize_auth_data(scope_only)
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/core.py", line
295, in _validate_and_normalize_auth_data
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi self._validate_and_normalize_scope_data()
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/core.py", line
255, in _validate_and_normalize_scope_dat
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi self.auth['scope']['OS-TRUST:trust'])
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/core.py", line
224, in _lookup_trust
Nov 07 16:46:18 SZX1000339032 devstack@keystone.service[12272]: ERROR
keystone.common.wsgi tru
[Yahoo-eng-team] [Bug 1733746] [NEW] Failed to get flavors(raise 500) with a domain scope(without project_id).
Public bug reported:
Description
===
Failed to get flavors(raise a 500 error) with a domain scope
or unscope token(without project_id).
https://docs.openstack.org/keystone/pike/admin/identity-tokens.html
#domain-scoped-tokens
Steps to reproduce
==
1. Get a unscope token or domain token.
TOKEN=`curl -i -X POST http://10.76.6.31/identity/v3/auth/tokens -H "Accept:
application/json" -H "Content-Type: application/json" -d
'{"auth":{"identity":{"methods":["password"],"password":{"user":{"domain":{"name":"default"},"name":"admin","password":"xxx"}'
| grep X-Subject-Token | awk '{ print $2 }’`
2. Get flavors.
curl -g -i -X GET http://10.76.6.31/compute/v2.1/flavors/detail -H
"OpenStack-API-Version: compute 2.53" -H "User-Agent: python-novaclient" -H
"Accept: application/json" -H "X-OpenStack-Nova-API-Version: 2.53" -H
"X-Auth-Token: $TOKEN"
Expected result
===
Get flavors back.
Actual result
=
HTTP/1.1 500 Internal Server Error
Date: Fri, 17 Nov 2017 09:22:38 GMT
Server: Apache/2.4.18 (Ubuntu)
OpenStack-API-Version: compute 2.53
X-OpenStack-Nova-API-Version: 2.53
Vary: OpenStack-API-Version,X-OpenStack-Nova-API-Version
Content-Type: application/json; charset=UTF-8
Content-Length: 193
x-openstack-request-id: req-f77858f8-dd77-4dcd-825a-aec012cabcfc
x-compute-request-id: req-f77858f8-dd77-4dcd-825a-aec012cabcfc
Connection: close
{"computeFault": {"message": "Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n", "code": 500}}
Logs & Configs
==
2017-11-19 20:19:03.567 9606 INFO sqlalchemy.engine.base.Engine
[req-c1765f1e-786a-4457-9c45-2f8c3897722b - admin] ROLLBACK
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions
[req-c1765f1e-786a-4457-9c45-2f8c3897722b - admin] Unexpected exception in API
method: TypeError: 'in ' requires string as left operand, not NoneType
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions Traceback
(most recent call last):
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions File
"/opt/stack/nova/nova/api/openstack/extensions.py", line 336, in wrapped
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions return
f(*args, **kwargs)
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions File
"/opt/stack/nova/nova/api/openstack/compute/flavors.py", line 48, in detail
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions return
self._view_builder.detail(req, limited_flavors)
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions File
"/opt/stack/nova/nova/api/openstack/compute/views/flavors.py", line 61, in
detail
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions return
self._list_view(self.show, request, flavors, coll_name)
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions File
"/opt/stack/nova/nova/api/openstack/compute/views/flavors.py", line 74, in
_list_view
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions
flavor_list = [func(request, flavor)["flavor"] for flavor in flavors]
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions File
"/opt/stack/nova/nova/api/openstack/compute/views/flavors.py", line 47, in show
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions
self._collection_name),
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions File
"/opt/stack/nova/nova/api/openstack/common.py", line 390, in _get_links
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions "href":
self._get_href_link(request, identifier, collection_name),
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions File
"/opt/stack/nova/nova/api/openstack/common.py", line 413, in _get_href_link
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions
self._get_project_id(request),
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions File
"/opt/stack/nova/nova/api/openstack/common.py", line 383, in _get_project_id
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions if
project_id in request.url:#project_id and project_id in request.url:
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions TypeError: 'in
' requires string as left operand, not NoneType
2017-11-19 20:19:03.571 9606 ERROR nova.api.openstack.extensions
2017-11-19 20:19:03.598 9606 INFO nova.api.openstack.wsgi
[req-c1765f1e-786a-4457-9c45-2f8c3897722b - admin] HTTP exception thrown:
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and
attach the Nova API log if possible.
2017-11-19 20:19:03.600 9606 DEBUG nova.api.openstack.wsgi
[req-c1765f1e-786a-4457-9c45-2f8c3897722b - admin] Returning 500 to user:
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and
attach the Nova API log if possible.
__call__
/opt/stack/nova/nova/api/openstack/wsgi.py:1029
2017-11-19 20:
[Yahoo-eng-team] [Bug 1733747] [NEW] No way to find out which instances are using a security group
Public bug reported: I'm trying to figure out which instances are using a specific security group but it doesn't look possible via the API (unless I'm missing something). The only way to do this is by looking in the database and doing some sql on the securitygroupportbindings table. Is there another way? ** 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/1733747 Title: No way to find out which instances are using a security group Status in neutron: New Bug description: I'm trying to figure out which instances are using a specific security group but it doesn't look possible via the API (unless I'm missing something). The only way to do this is by looking in the database and doing some sql on the securitygroupportbindings table. Is there another way? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733747/+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 1733736] [NEW] reclaim_instance_interval
Public bug reported: Description When set reclaim_instance_interval > 0, and we delete an instance which boot from volume with delete_on_termination set as true. After reclaim_instance_interval time pass, all volumes boot instance will with state: attached and in-use, but attached instances was deleted. Steps to reproduce 1. set reclaim_instance_interval = 60 2. create a bootable volume 3. boot instance with created bootable volume 4. delete instance, and wait 60 seconds Expected result Previous test bootable volume was deleted after reclaim_instance_interval seconds. Actual result Previous test bootable volume was in state attached and in-use, attached with deleted instance. ** Affects: nova Importance: Undecided Assignee: Li Xipeng (lixipeng) Status: In Progress ** Description changed: Description - === When set reclaim_instance_interval > 0, and we delete an instance which boot from volume with delete_on_termination set as true. After reclaim_instance_interval time pass, all volumes boot instance will with state: attached and in-use, but attached instances was deleted. Steps to reproduce - == 1. set reclaim_instance_interval = 60 2. create a bootable volume 3. boot instance with created bootable volume 4. delete instance, and wait 60 seconds - Expected result - === Previous test bootable volume was deleted after reclaim_instance_interval seconds. - Actual result - = Previous test bootable volume was in state attached and in-use, attached with deleted instance. ** Changed in: nova Assignee: (unassigned) => Li Xipeng (lixipeng) -- 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/1733736 Title: reclaim_instance_interval Status in OpenStack Compute (nova): In Progress Bug description: Description When set reclaim_instance_interval > 0, and we delete an instance which boot from volume with delete_on_termination set as true. After reclaim_instance_interval time pass, all volumes boot instance will with state: attached and in-use, but attached instances was deleted. Steps to reproduce 1. set reclaim_instance_interval = 60 2. create a bootable volume 3. boot instance with created bootable volume 4. delete instance, and wait 60 seconds Expected result Previous test bootable volume was deleted after reclaim_instance_interval seconds. Actual result Previous test bootable volume was in state attached and in-use, attached with deleted instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1733736/+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 1706719] Re: Account is locked out and cannot have password updated.
** Changed in: keystone
Status: New => Invalid
--
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/1706719
Title:
Account is locked out and cannot have password updated.
Status in OpenStack Identity (keystone):
Invalid
Status in tempest:
New
Bug description:
We are seeing this in tempest testing. In some tempest runs the test
to change the user password fails because the account is locked out.
Example traceback can be found at
http://logs.openstack.org/21/485221/2/gate/gate-tempest-dsvm-neutron-
full-ubuntu-xenial/4ecd651/console.html#_2017-07-20_01_14_10_769485
and is pasted here so that log expiry doesn't delete it under us:
2017-07-20 01:14:10.769485 |
tempest.api.identity.v3.test_users.IdentityV3UsersTest.test_user_update_own_password[id-ad71bd23-12ad-426b-bb8b-195d2b635f27]
2017-07-20 01:14:10.769531 |
-
2017-07-20 01:14:10.769545 |
2017-07-20 01:14:10.769562 | Captured traceback:
2017-07-20 01:14:10.769580 | ~~~
2017-07-20 01:14:10.769602 | Traceback (most recent call last):
2017-07-20 01:14:10.769639 | File
"tempest/api/identity/v3/test_users.py", line 89, in
test_user_update_own_password
2017-07-20 01:14:10.769672 |
self._update_password(original_password=old_pass, password=new_pass)
2017-07-20 01:14:10.769707 | File
"tempest/api/identity/v3/test_users.py", line 42, in _update_password
2017-07-20 01:14:10.769732 | original_password=original_password)
2017-07-20 01:14:10.769769 | File
"tempest/lib/services/identity/v3/users_client.py", line 60, in
update_user_password
2017-07-20 01:14:10.769801 | resp, _ = self.post('users/%s/password'
% user_id, update_user)
2017-07-20 01:14:10.769831 | File "tempest/lib/common/rest_client.py",
line 270, in post
2017-07-20 01:14:10.769864 | return self.request('POST', url,
extra_headers, headers, body, chunked)
2017-07-20 01:14:10.769895 | File "tempest/lib/common/rest_client.py",
line 659, in request
2017-07-20 01:14:10.769919 | self._error_checker(resp, resp_body)
2017-07-20 01:14:10.769951 | File "tempest/lib/common/rest_client.py",
line 755, in _error_checker
2017-07-20 01:14:10.769979 | raise exceptions.Unauthorized(resp_body,
resp=resp)
2017-07-20 01:14:10.770005 | tempest.lib.exceptions.Unauthorized:
Unauthorized
2017-07-20 01:14:10.770054 | Details: {u'code': 401, u'title':
u'Unauthorized', u'message': u'The account is locked for user:
b99de038ad484b1fb4d65aebefd4464d.'}
2017-07-20 01:14:10.770068 |
2017-07-20 01:14:10.770081 |
2017-07-20 01:14:10.770099 | Captured pythonlogging:
2017-07-20 01:14:10.770118 | ~~~
2017-07-20 01:14:10.770193 | 2017-07-20 00:54:16,576 23533 INFO
[tempest.lib.common.rest_client] Request
(IdentityV3UsersTest:test_user_update_own_password): 401 POST
https://198.72.124.157/identity/v3/users/b99de038ad484b1fb4d65aebefd4464d/password
0.049s
2017-07-20 01:14:10.770284 | 2017-07-20 00:54:16,576 23533 DEBUG
[tempest.lib.common.rest_client] Request - Headers: {'Content-Type':
'application/json', 'X-Auth-Token': '', 'Accept': 'application/json'}
2017-07-20 01:14:10.770331 | Body: {"user": {"password":
"M8*qsS56SFEo%s4", "original_password": "T4+DR4vL577eGl_"}}
2017-07-20 01:14:10.770475 | Response - Headers: {u'content-type':
'application/json', u'date': 'Thu, 20 Jul 2017 00:54:16 GMT', u'vary':
'X-Auth-Token', u'server': 'Apache/2.4.18 (Ubuntu)', u'connection': 'close',
u'x-openstack-request-id': 'req-20995818-e4f4-4aaa-bdc1-d91c145ca562',
u'www-authenticate': 'Keystone uri="https://198.72.124.157/identity";',
u'content-length': '129', 'status': '401', 'content-location':
'https://198.72.124.157/identity/v3/users/b99de038ad484b1fb4d65aebefd4464d/password'}
2017-07-20 01:14:10.770528 | Body: {"error": {"message": "The
account is locked for user: b99de038ad484b1fb4d65aebefd4464d.", "code": 401,
"title": "Unauthorized"}}
2017-07-20 01:14:10.770599 | 2017-07-20 00:54:16,614 23533 INFO
[tempest.lib.common.rest_client] Request (IdentityV3UsersTest:_run_cleanups):
401 POST
https://198.72.124.157/identity/v3/users/b99de038ad484b1fb4d65aebefd4464d/password
0.036s
2017-07-20 01:14:10.770669 | 2017-07-20 00:54:16,614 23533 DEBUG
[tempest.lib.common.rest_client] Request - Headers: {'Content-Type':
'application/json', 'X-Auth-Token': '', 'Accept': 'application/json'}
2017-07-20 01:14:10.770709 | Body: {"user": {"password":
"H1!w*#WDyqGDBod", "original_password": "M8*qsS56SFEo%s4"}}
2017-07-20 01:14:10.770857 | Response - Headers: {u'content-type':
'applic
[Yahoo-eng-team] [Bug 1705958] Re: Flavor Access tab doesn't show updated data
Reviewed: https://review.openstack.org/486473 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=221d1a25a483894a523cc82c9f3f54d025896586 Submitter: Zuul Branch:master commit 221d1a25a483894a523cc82c9f3f54d025896586 Author: Ying Zuo Date: Sun Jul 23 19:25:05 2017 -0700 Show updated data on Flavor Access tab Memoization for api flavor_access_list should be limited to request so the updated data is shown after it's modified. Closes-bug: #1705958 Change-Id: Icf6716854502c2462569e12f00414950c915ca9b ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1705958 Title: Flavor Access tab doesn't show updated data Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Steps to reproduce: 1. Go to admin/flavors panel 2. Click Edit Flavor or Modify Access action 3. On the Flavor Access tab, add or remove a project from the access list 4. A success message is shown then check the Flavor Access tab. Expect to see the updated access list but it's not. I confirmed the access list was actually modified with CLI so the problem is that the Flavor Access tab doesn't show the updated information. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1705958/+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 1731948] Re: Wrong OVO classes registered in some cases
Added oslo.versionedobjects to the list of affected projects so that it allows to use custom registries for consuming projects. ** Also affects: oslo.versionedobjects Importance: Undecided Status: New ** Changed in: oslo.versionedobjects Importance: Undecided => Wishlist ** Tags added: gate-failure unittest ** Changed in: neutron Importance: Medium => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1731948 Title: Wrong OVO classes registered in some cases Status in neutron: In Progress Status in oslo.versionedobjects: New Bug description: When patch https://review.openstack.org/#/c/321001 was merged some UT in projects like networking-midonet started failing. It is reported on https://bugs.launchpad.net/networking-midonet/+bug/1731623 It looks that reason of this problem is that wrong OVO classes are registered in case when e.g. 2 different projects uses same names of OVO objects. I checked it little bit and it looks that neutron.objects.subnet.Subnet has got registered os_vif.objects.route.Route object instead of neutron.objects.subnet.Route, see my logs from one exampled test: http://paste.openstack.org/show/626170/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1731948/+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 1615076] Re: Keystone server does not define "enabled" attribute for Region but mentions in v3 regions.py
Adding python-keystoneclient to this bug report so that we can get a
release that doesn't assume `enabled` attributes for regions. Keeping
this open for keystone so that we can make sure we're not documenting
it, officially or in code comments.
** Also affects: python-keystoneclient
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/1615076
Title:
Keystone server does not define "enabled" attribute for Region but
mentions in v3 regions.py
Status in OpenStack Identity (keystone):
Confirmed
Status in python-keystoneclient:
New
Bug description:
The bug was discovered while writing the region functional tests [1].
The create() and update() calls [2] in regions.py mention the
"enabled" attribute, but the specs [3] don't mention it and the code
[4] doesn't support it. We don't check for "enabled" in the region
schema either [5].
So, it's being stored as an extra attribute and it even works if one
passes {'enabled': 'WHATEVER'}
[1] https://review.openstack.org/#/c/339158/
[2]
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/regions.py
[3]
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#regions-v3-regions
[4]
https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L33-L49
[5]
https://github.com/openstack/keystone/blob/master/keystone/catalog/schema.py#L17-L43
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1615076/+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 1719492] Re: admin_token_auth not found
*** This bug is a duplicate of bug 1716797 *** https://bugs.launchpad.net/bugs/1716797 ** This bug has been marked a duplicate of bug 1716797 Verify operation in keystone: step 1 has already been done -- 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/1719492 Title: admin_token_auth not found Status in OpenStack Identity (keystone): Invalid Bug description: in the /etc/keystone/keystone-paste.ini ,the admin_token_auth is not found.rmemove it plaese. This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 12.0.0.0rc3.dev2 on 2017-08-26 22:01 SHA: 5a9aeefff06678d790d167b6dac752677f02edf9 Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-verify-ubuntu.rst URL: https://docs.openstack.org/keystone/pike/install/keystone-verify-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1719492/+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 1573766] Re: Enable the paste filter HTTPProxyToWSGI by default
** Also affects: nova (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: nova (Ubuntu Xenial) Status: New => Triaged ** Changed in: nova (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: nova (Ubuntu) Status: New => Invalid ** Also affects: cloud-archive/mitaka Importance: Undecided Status: New ** Changed in: cloud-archive Status: New => Invalid ** Changed in: cloud-archive/mitaka Status: New => Triaged ** Changed in: cloud-archive/mitaka 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/1573766 Title: Enable the paste filter HTTPProxyToWSGI by default Status in OpenStack nova-cloud-controller charm: Triaged Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive mitaka series: Triaged Status in OpenStack Compute (nova): Fix Released Status in nova package in Ubuntu: Invalid Status in nova source package in Xenial: Triaged Bug description: [Impact] Getting http link instead of https even if https setting is set. [Test case] 1. deploy openstack ( with keystone charm option use-https, https-service-endpoints) 2. create instance 3. nova --debug list - check the result if https links are there. [Regression Potential] nova pkg will be affected by this patch. However, this patch modifies only api-paste.ini by adding http_proxy_to_wsgi. To accept this patch, nova service need to be restarted. Tested no vms are affected this patch, but APIs or daemons are temporarily. [Others] related commits ( which are already in comments ) https://git.openstack.org/cgit/openstack/nova/commit/?id=b609a3b32ee8e68cef7e66fabff07ca8ad6d4649 https://git.openstack.org/cgit/openstack/nova/commit/?id=6051f30a7e61c32833667d3079744b2d4fd1ce7c [Original Description] oslo middleware provides a paste filter that sets the correct proxy scheme and host. This is needed for the TLS proxy case. Without this then enabling the TLS proxy in devstack will fail configuring tempest because 'nova flavor-list' returns a http scheme in Location in a redirect it returns. I've proposed a temporary workaround in devstack using: +iniset $NOVA_API_PASTE_INI filter:ssl_header_handler past e.filter_factory oslo_middleware.http_proxy_to_wsgi:HTTPProxyToWSGI.factory +iniset $NOVA_API_PASTE_INI composite:openstack_compute_ap i_v21 keystone "ssl_header_handler cors compute_req_id faultwrap sizelimit autht oken keystonecontext osapi_compute_app_v21" But this isn't a long-term solution because two copies of the default paste filters will need to be maintained. See https://review.openstack.org/#/c/301172 To manage notifications about this bug go to: https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1573766/+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 1733570] Re: horizon accesses the internet during the build
Reviewed: https://review.openstack.org/521827 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=5cac0c4b34f29afa385bdf2d560dacd8754214aa Submitter: Zuul Branch:master commit 5cac0c4b34f29afa385bdf2d560dacd8754214aa Author: Akihiro Motoki Date: Tue Nov 21 11:57:43 2017 + pull_catalog: avoid internet access during module loading pull_catalog command accesses Zanata OpenStack site during loaded. Python unit tests tries to load modules when starting tests. This commit moves the logic to access to the Zanata OpenStack site to inside the command class to avoid this. Change-Id: Ibcb56f941003815340b2b7486ef0e1392c8ac540 Closes-Bug: #1733570 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1733570 Title: horizon accesses the internet during the build Status in OpenStack Dashboard (Horizon): Fix Released Bug description: horizon accesses the internet during the build https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882266 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1733570/+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 1678056] Re: RequestSpec records are never deleted when destroying an instance
Reviewed: https://review.openstack.org/515034 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=32fd58813f8247641a6b574b5f01528b29d48b76 Submitter: Zuul Branch:master commit 32fd58813f8247641a6b574b5f01528b29d48b76 Author: Surya Seetharaman Date: Wed Oct 25 13:43:43 2017 +0200 cleanup mapping/reqspec after archive instance This patch aims at deleting the records of the archived instances from the instance_mappings and request_specs tables in the API database immediately following their archival from instances to shadow_instances table. So upon running the 'nova-manage db archive_deleted_rows' command the records of the archived instances will be automatically removed from the instance_mappings and request_specs tables as well. A warning has also been added to fix the issue of 'nova-manage verify_instance' returning a valid instance mapping even after the instance is deleted. The patch also adds InstanceMappingList.destory_bulk() and RequestSpec.destroy_bulk() methods for ease of bulk deletion of records. Change-Id: I483701a55576c245d091ff086b32081b392f746e Closes-Bug: #1724621 Closes-Bug: #1678056 ** 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/1678056 Title: RequestSpec records are never deleted when destroying an instance Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: New Status in OpenStack Compute (nova) ocata series: New Bug description: When an instance is created, Nova adds a record in the API DB 'request_specs' table by providing the user request. That's used by the scheduler for knowing the boot request, also when the instance is moved afterwards. That said, when destroying the instance, we don't delete the related RequestSpec record. Of course, operators could run a script for deleting them by checking the instance UUIDs, but it would be better if when an instance is hard-deleted (ie. when operators don't use [DEFAULT]/reclaim_instance_interval for restoring deleted instances), we could then delete the RequestSpec too. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1678056/+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 1724621] Re: nova-manage cell_v2 verify_instance returns a valid instance mapping even after the instance is deleted/archived
Reviewed: https://review.openstack.org/515034 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=32fd58813f8247641a6b574b5f01528b29d48b76 Submitter: Zuul Branch:master commit 32fd58813f8247641a6b574b5f01528b29d48b76 Author: Surya Seetharaman Date: Wed Oct 25 13:43:43 2017 +0200 cleanup mapping/reqspec after archive instance This patch aims at deleting the records of the archived instances from the instance_mappings and request_specs tables in the API database immediately following their archival from instances to shadow_instances table. So upon running the 'nova-manage db archive_deleted_rows' command the records of the archived instances will be automatically removed from the instance_mappings and request_specs tables as well. A warning has also been added to fix the issue of 'nova-manage verify_instance' returning a valid instance mapping even after the instance is deleted. The patch also adds InstanceMappingList.destory_bulk() and RequestSpec.destroy_bulk() methods for ease of bulk deletion of records. Change-Id: I483701a55576c245d091ff086b32081b392f746e Closes-Bug: #1724621 Closes-Bug: #1678056 ** 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/1724621 Title: nova-manage cell_v2 verify_instance returns a valid instance mapping even after the instance is deleted/archived Status in OpenStack Compute (nova): Fix Released Bug description: Although nova-manage cell_v2 verify_instance is used to check if the provided instance is correctly mapped to a cell or not, this should not be returning a valid mapping message if the instance itself is deleted. It should return an error message saying 'The instance does not exist'. Steps to reproduce : 1. Create an instance : -> nova boot --image 831bb8a0-9305-4cd7-b985-cbdadfb5d3db --flavor m1.nano test -> nova list +--++++-+-+ | ID | Name | Status | Task State | Power State | Networks| +--++++-+-+ | aec6eb34-6aaf-4883-8285-348d40fdac87 | test | ACTIVE | - | Running | public=2001:db8::4, 172.24.4.9 | +--++++-+-+ 2. Delete the instance : -> nova delete test Request to delete server test has been accepted. -> nova list +--++++-+-+ | ID | Name | Status | Task State | Power State | Networks| +--++++-+-+ +--++++-+-+ 3. Verify Instance : -> nova-manage cell_v2 verify_instance --uuid aec6eb34-6aaf-4883-8285-348d40fdac87 Instance aec6eb34-6aaf-4883-8285-348d40fdac87 is in cell: cell5 (c5ccba5d-1a45-4739-a5dd-d665a1b19301) Basically the message that we get is misleading for a deleted instance. This is because verify_instance queries the instance_mappings table which maintains a mapping of the deleted instances as well. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1724621/+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 1714417] Re: Error "Unable to retrieve the Absolute Limits" appeared in browser console when creating a volume from an image.
Reviewed: https://review.openstack.org/499897 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=de37fc1024a2e02cb9ec0f29a6dbd218474072df Submitter: Zuul Branch:master commit de37fc1024a2e02cb9ec0f29a6dbd218474072df Author: zhangdebo1987 Date: Fri Sep 1 13:32:00 2017 +0800 NaNJSONEncoder should be used in api "cinder/tenantabsolutelimits" In api "cinder/tenantabsolutelimits", result maybe contains Infinity values, but Infinity values are not supported by JSON standard, so NaNJSONEncoder is needed here. Change-Id: I750637e3214ad46a8b29e1ad565870cdcb827fe1 Closes-bug: #1714417 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1714417 Title: Error "Unable to retrieve the Absolute Limits" appeared in browser console when creating a volume from an image. Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Open the modal from for creating a volume from an image, an error message appeared : "Unable to retrieve the Absolute Limits". I saw an error in browser console : "SyntaxError: Unexpected token I in JSON at position 76". Note that this happens only for a project with unlimited Cinder quotas. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1714417/+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 1682114] Re: Missing include template in admin migrate host page
Reviewed: https://review.openstack.org/456216 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=f713bfb82b13a56e628cfdff05e9f01256d7213a Submitter: Zuul Branch:master commit f713bfb82b13a56e628cfdff05e9f01256d7213a Author: wei.ying Date: Wed Apr 12 21:07:47 2017 +0800 Add missing include template in admin migrate host form If migrate host action missing "ajax-modal", it will can not find "_migrate_host.html" Change-Id: Ide8db6dd4b1a46565eefdaf3d08470f450ee3a83 Closes-bug: #1682114 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1682114 Title: Missing include template in admin migrate host page Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Env: devstack master branch Path:openstack_dashboard/dashboards/admin/hypervisors/templates/hypervisors/compute/migrate_host.html not include "_migrate_host.html" To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1682114/+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 1402915] Re: Error: Unable to retrieve attachment information
Reviewed: https://review.openstack.org/143815 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=f22fe2dce31a2d2fe158979f351e9bb4415eaa8c Submitter: Zuul Branch:master commit f22fe2dce31a2d2fe158979f351e9bb4415eaa8c Author: Trung Trinh Date: Thu Dec 25 00:45:10 2014 +1400 Display attachment's server_id when name is no longer available This scenario occurs when the associated VM instance with the volume is not found by whatever underlying reasons. Change-Id: I15831e2377fe504c667babe5ea00ac09808d296f Closes-Bug: #1402915 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1402915 Title: Error: Unable to retrieve attachment information Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Version: stable/juno Bug description: In the view of "Volumes", provided that some volume whose status is "in-use" or it is being attached to a VM. If the associated VM is deleted, this will trigger the detaching of the volume. If the volume detaching process is failed by whatever reason, then the volume becomes attached to an already-deleted VM. If now, we try retrieving the volume info with Horizon dashboard then we will get the error of "Unable to retrieve attachment information". Proposal: Such an error has to be disabled and the info of the field "Attached To" should be set to None or left blank as if the volume were not attached to the VM. Furthermore, the field "Status" should be set back to blank To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1402915/+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 1733515] Re: use_journal option not available in ocata
** Changed in: nova Status: New => Invalid ** Changed in: openstack-manuals Status: New => In Progress ** Changed in: openstack-manuals Assignee: (unassigned) => Petr Kovar (pmkovar) -- 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/1733515 Title: use_journal option not available in ocata Status in OpenStack Compute (nova): Invalid Status in openstack-manuals: In Progress Bug description: The config documentation for Nova Ocata lists the "use_journal" option[1], however that option was added to oslo.log only for the Pike cycle[2] in oslo.log==3.24.0. It isn't available e.g. in Ubuntu Ocata UCA with python-oslo.log=3.20.1-0ubuntu1~cloud0. [1] https://docs.openstack.org/ocata/config-reference/compute/config-options.html [2] https://docs.openstack.org/releasenotes/oslo.log/pike.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1733515/+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 1723006] [NEW] "Create OpenStack client environment scripts" cannot be accessed
You have been subscribed to a public bug: On the Install document for "Keystone Installation Tutorial for Ubuntu", "Create OpenStack client environment scripts" cannot be accessed (your 404 message and "Warning: Major rework in progress" appeared), so I cannot proceed to further installation since it is not clear if the further installation can be processed without the process. ** Affects: keystone Importance: Undecided Status: Incomplete -- "Create OpenStack client environment scripts" cannot be accessed https://bugs.launchpad.net/bugs/1723006 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). -- 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 1723006] Re: "Create OpenStack client environment scripts" cannot be accessed
I'm also able to access https://docs.openstack.org/keystone/pike/install /keystone-openrc-ubuntu.html. Moving to the correct component. ** Project changed: openstack-manuals => keystone -- 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/1723006 Title: "Create OpenStack client environment scripts" cannot be accessed Status in OpenStack Identity (keystone): Incomplete Bug description: On the Install document for "Keystone Installation Tutorial for Ubuntu", "Create OpenStack client environment scripts" cannot be accessed (your 404 message and "Warning: Major rework in progress" appeared), so I cannot proceed to further installation since it is not clear if the further installation can be processed without the process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1723006/+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 1732522] Re: [2.3] Ephemeral boot environment does not renew DHCP leases
** Changed in: maas Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1732522 Title: [2.3] Ephemeral boot environment does not renew DHCP leases Status in cloud-init: New Status in MAAS: Fix Released Status in cloud-initramfs-tools package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: I started commissioning+hardware testing on a machine, and while the machine was testing (for 2hrs+) i noticed that the IP address had disappeared. The machine has the MAC of 00:25:90:4c:e7:9e and IP of 192.168.0.211 from the dynamic range. Checking the MAAS server, I noticed that the IP/MAC was in the ARP table: andreserl@maas:/var/lib/maas/dhcp$ arp -a | grep 211 192-168-9-211.maas (192.168.9.211) at 00:25:90:4c:e7:9e [ether] on bond-lan Checking the leases file has the following: http://pastebin.ubuntu.com/25969442/ Then I checked a couple areas of MAAS: - Device discovery, the machine wasn't there. - Subnet details page, the machine wasn't there (e.g. as observed) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1732522/+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 1733649] [NEW] fullstack neutron.tests.fullstack.test_qos.TestDscpMarkingQoSOvs.test_dscp_marking_packets(openflow-native) failure
Public bug reported: Fullstack neutron.tests.fullstack.test_qos.TestDscpMarkingQoSOvs.test_dscp_marking_packets (openflow-native) fails sometimes like on: http://logs.openstack.org/71/520371/7/check/legacy-neutron-dsvm- fullstack/ad585a2/logs/testr_results.html.gz In neutron-server logs there are errors like: http://logs.openstack.org/71/520371/7/check/legacy-neutron-dsvm-fullstack/ad585a2/logs/dsvm-fullstack-logs/TestDscpMarkingQoSOvs.test_dscp_marking_packets_openflow-native_/neutron-server--2017-11-20--22-12-38-673206.txt.gz?level=TRACE in such case. ** Affects: neutron Importance: High Assignee: Slawek Kaplonski (slaweq) Status: Confirmed ** Tags: fullstack gate-failure qos -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1733649 Title: fullstack neutron.tests.fullstack.test_qos.TestDscpMarkingQoSOvs.test_dscp_marking_packets (openflow-native) failure Status in neutron: Confirmed Bug description: Fullstack neutron.tests.fullstack.test_qos.TestDscpMarkingQoSOvs.test_dscp_marking_packets (openflow-native) fails sometimes like on: http://logs.openstack.org/71/520371/7/check/legacy-neutron-dsvm- fullstack/ad585a2/logs/testr_results.html.gz In neutron-server logs there are errors like: http://logs.openstack.org/71/520371/7/check/legacy-neutron-dsvm-fullstack/ad585a2/logs/dsvm-fullstack-logs/TestDscpMarkingQoSOvs.test_dscp_marking_packets_openflow-native_/neutron-server--2017-11-20--22-12-38-673206.txt.gz?level=TRACE in such case. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733649/+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 1673531] Re: fullstack test_controller_timeout_does_not_break_connectivity_sigkill(GRE and l2pop, openflow-native_ovsdb-cli) failure
Still fails: http://logs.openstack.org/71/520371/7/check/legacy-neutron- dsvm-fullstack/ad585a2/logs/testr_results.html.gz ** Changed in: neutron Status: Fix Released => Confirmed ** Changed in: neutron Importance: Undecided => High ** Changed in: neutron Assignee: (unassigned) => Ihar Hrachyshka (ihar-hrachyshka) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1673531 Title: fullstack test_controller_timeout_does_not_break_connectivity_sigkill(GRE and l2pop,openflow-native_ovsdb-cli) failure Status in neutron: Confirmed Bug description: Logs for failure: http://logs.openstack.org/98/446598/1/check/gate- neutron-dsvm-fullstack-ubuntu-xenial/2e0f93e/logs/dsvm-fullstack- logs/TestOvsConnectivitySameNetworkOnOvsBridgeControllerStop .test_controller_timeout_does_not_break_connectivity_sigkill_GRE-and- l2pop,openflow-native_ovsdb-cli_/ logstash query: http://logstash.openstack.org/#dashboard/file/logstash.json?query=messge%3A%5C%22in%20test_controller_timeout_does_not_break_connectivity_sigkill%5C%22%20AND%20tags%3Aconsole%20AND%20build_name %3Agate-neutron-dsvm-fullstack-ubuntu-xenial To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1673531/+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 1733642] [NEW] AttributeError: 'NoneType' object has no attribute 'get_token'
Public bug reported: Someone reported this in nova IRC: http://paste.openstack.org/show/626966/ They were doing a snapshot of an instance with an NFS-backed volume and using the nova service user configuration in the [service_user] section of nova.conf, however, it looks like their configuration was incomplete which resulted in this: Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver [req-3278cb0b-5c22-4874-905c-7f19ef735188 req-9e15496a-ae04-49ad-adbd-dd65b1bc9aaf admin admin] Failed to send updated snapshot status to volume service.: AttributeError: 'NoneType' object has no attribute 'get_token' Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver Traceback (most recent call last): Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1952, in _volume_snapshot_update_status Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver status) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/volume/cinder.py", line 241, in wrapper Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver res = method(self, ctx, *args, **kwargs) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/volume/cinder.py", line 291, in wrapper Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver res = method(self, ctx, snapshot_id, *args, **kwargs) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/opt/stack/nova/nova/volume/cinder.py", line 540, in update_snapshot_status Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver 'progress': '90%'} Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/cinderclient/v3/volume_snapshots.py", line 166, in update_snapshot_status Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver base.getid(snapshot), update_dict) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/cinderclient/v3/volume_snapshots.py", line 161, in _action Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver resp, body = self.api.client.post(url, body=body) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/cinderclient/client.py", line 202, in post Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver return self._cs_request(url, 'POST', **kwargs) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/cinderclient/client.py", line 190, in _cs_request Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver return self.request(url, method, **kwargs) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/cinderclient/client.py", line 173, in request Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver **kwargs) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 463, in request Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver resp = super(LegacyJsonAdapter, self).request(*args, **kwargs) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 189, in request Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver return self.session.request(url, method, **kwargs) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line 573, in request Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver auth_headers = self.get_auth_headers(auth) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line 900, in get_auth_headers Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.driver return auth.get_headers(self, **kwargs) Nov 21 19:06:50 openstack-VirtualBox nova-compute[10751]: ERROR nova.virt.libvirt.dri
[Yahoo-eng-team] [Bug 1733630] [NEW] placement: Version discovery URI should not require authentication
Public bug reported:
The placement API GET / returns the version document:
{
"versions": [
{
"min_version": "1.0",
"max_version": "1.10",
"id": "v1.0"
}
]
}
However, it requires authentication:
# curl http://9.1.2.3/placement/
{"error": {"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
It shouldn't. Right now I can't find the doc that says so, but Monty
confirms:
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-
nova.2017-11-21.log.html#t2017-11-21T15:35:08
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
** Tags removed: pla
** Tags added: placement
--
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/1733630
Title:
placement: Version discovery URI should not require authentication
Status in OpenStack Compute (nova):
New
Bug description:
The placement API GET / returns the version document:
{
"versions": [
{
"min_version": "1.0",
"max_version": "1.10",
"id": "v1.0"
}
]
}
However, it requires authentication:
# curl http://9.1.2.3/placement/
{"error": {"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
It shouldn't. Right now I can't find the doc that says so, but Monty
confirms:
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-
nova.2017-11-21.log.html#t2017-11-21T15:35:08
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1733630/+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 1718747] Re: Unable to delete domain with users in it
** Changed in: keystone/newton
Status: Confirmed => Won't Fix
--
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/1718747
Title:
Unable to delete domain with users in it
Status in OpenStack Identity (keystone):
In Progress
Status in OpenStack Identity (keystone) newton series:
Won't Fix
Status in OpenStack Identity (keystone) ocata series:
Confirmed
Status in OpenStack Identity (keystone) pike series:
Confirmed
Bug description:
Attempting to delete a domain which contains users and projects may
yield an UnexpectedError similiar to this
Sep 21 19:37:17 vagrant-openSUSE-Leap devstack@keystone.service[23894]: DEBUG
keystone.common.sql.core [None req-707ec264-b10c-4079-94bb-2af01db58aab None
None] Conflict project: (pymysql.err.IntegrityError) (1451, u'Cannot delete or
update a parent row: a foreign key constraint fails (`keystone`.`user`,
CONSTRAINT `user_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `project`
(`id`))') [SQL: u'DELETE FROM project WHERE project.id = %(id)s'] [parameters:
{'id': u'63d2d5446e364f00b3181bf49c62c5b8'}] {{(pid=23897) wrapper
/opt/stack/keystone/keystone/common/sql/core.py:550}}
Sep 21 19:37:17 vagrant-openSUSE-Leap devstack@keystone.service[23894]:
WARNING keystone.common.wsgi [None req-707ec264-b10c-4079-94bb-2af01db58aab
None None] An unexpected error prevented the server from fulfilling your
request.: UnexpectedError: An unexpected error prevented the server from
fulfilling your request.
Steps to reproduce:
1. Install devstack
2. create a domain 'foo'
openstack domain create foo
3. create a user in domain 'foo'
openstack user create --password equifax --domain foo foo_user
4. create a project in domain 'foo'
openstack project create --domain foo foo_project
5. enable domain user 'foo_user' access to project 'foo_project'
openstack role add --user foo_user --project foo_project admin
6. now disable domain 'foo'
openstack domain set --disable foo
7. attempt to delete domain 'foo' will yield an expected error
mentioned above
openstack domain delete foo
This was introduced in:
https://github.com/openstack/keystone/commit/2bd88d30e1d2873470af7f40db45a99e07e12ce6
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1718747/+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 1709801] Re: Domain scope auth fails when use endpoint filter
** Changed in: keystone/newton Status: In Progress => Won't Fix -- 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/1709801 Title: Domain scope auth fails when use endpoint filter Status in OpenStack Identity (keystone): Invalid Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: New Bug description: When use endpoint_filter.sql catalog driver in Newton and authenticate with domain scope, we fail to receive endpoints. Should be all endpoints instead. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1709801/+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 1733609] Re: LBaaS namespace missing default route in IPv6 only network
I'm going to change the component to neutron-lbaas since this doesn't
seem to be caused by code in neutron proper. Looking at the lbaas code
quickly, it looks like this file:
drivers/haproxy/namespace_driver.py
Needs changes similar to what was done in:
https://review.openstack.org/#/c/461887/8/neutron/agent/linux/dhcp.py
And there could be other places as well.
** Tags added: lbaas
** Project changed: neutron => octavia
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1733609
Title:
LBaaS namespace missing default route in IPv6 only network
Status in octavia:
New
Bug description:
Description:
When creating a LBaaS loadbalancer on an IPv6 only subnet (associated with a
provider network with direct internet connectivity) the resulting namespace has
no default route, even though the subnet has a gateway defined.
When doing the same with an IPv4 only network the namespace gets an
appropriate default route.
When manually injecting the default route into the namespace it starts
working immediately.
Expected Result: IPv6 only subnets also get a default route, if the
underlying subnet has one defined (gateway_ip).
Reference: Bug#1709115 mentions the same problem. A fix for the qdhcp
namespace was committed but the LBaaS side was never addressed or
answered.
Versions: ocata using Kolla from stable/ocata branch
Example output (IP Addresses sanitized):
Loadbalancer IPv4 (works as intended):
(neutron) subnet-show internet-subnet01
+---+-+
| Field | Value |
+---+-+
| allocation_pools | {"start": "XXX.XX.130.40", "end": "XXX.XX.130.240"} |
| cidr | XXX.XX.130.0/24 |
| created_at| 2017-11-03T08:17:14Z|
| description | |
| dns_nameservers | 8.8.4.4 |
| | 8.8.8.8 |
| enable_dhcp | True|
| gateway_ip| XXX.XX.130.1|
| host_routes | |
| id| c68b03d8-8e6e-48ee-a7bc-fcd7e6d03f8a|
| ip_version| 4 |
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | internet-subnet01 |
| network_id| 86ccc9d0-9495-4167-b515-68012781ded0|
| project_id| 84fb831d59cc471cb686b27e56915c8a|
| revision_number | 3 |
| service_types | |
| subnetpool_id | |
| tags | |
| tenant_id | 84fb831d59cc471cb686b27e56915c8a|
| updated_at| 2017-11-20T15:15:36Z|
+---+-+
(neutron) lbaas-loadbalancer-create --name test-lb internet-subnet01
Created a new loadbalancer:
+-+--+
| Field | Value|
+-+--+
| admin_state_up | True |
| description | |
| id | f90eff87-de07-4fce-84ee-15ec6243a07b |
| listeners | |
| name| test-lb |
| operating_status| OFFLINE |
| pools | |
| provider| haproxy |
| provisioning_status | PENDING_CREATE |
| tenant_id | 8af62d3343204fc1abfad779ebad815c |
| vip_address | XXX.XX.130.41|
| vip_port_id | 98206b7b-603b-4064-b671-d15f5cf8c056 |
| vip_subnet_id | c68b03d8-8e6e-48ee-a7bc-fcd7e6d03f8a |
+-+--+
(neutron) lbaas-listener-create --name test-lb-http --loadbalancer test-lb
--protocol HTTP --protocol-port
[Yahoo-eng-team] [Bug 1724686] Re: authentication code hangs when there are three or more admin keystone endpoints
It sounds like the client is having a hard time dealing with that
specific data set. I'm not sure if the keystone service itself can do
anything about that.
Adding python-keystoneclient to this bug report until we figure out
exactly what's going on.
** Also affects: python-keystoneclient
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/1724686
Title:
authentication code hangs when there are three or more admin keystone
endpoints
Status in OpenStack Identity (keystone):
New
Status in python-keystoneclient:
New
Bug description:
I'm running stable/pike devstack, and I was playing around with what
happens when there are many endpoints in multiple regions, and I
stumbled over a scenario where the keystone authentication code hangs.
My original endpoint list looked like this:
ubuntu@devstack:/opt/stack/devstack$ openstack endpoint list
+--+---+--+-+-+---+--+
| ID | Region| Service Name | Service Type
| Enabled | Interface | URL |
+--+---+--+-+-+---+--+
| 0a9979ebfdbf48ce91ccf4e2dd952c1a | RegionOne | kingbird |
synchronization | True| internal | http://127.0.0.1:8118/v1.0
|
| 11d5507afe2a4eddb4f030695699114f | RegionOne | placement| placement
| True| public| http://128.224.186.226/placement |
| 1e42cf139398405188755b7e00aecb4d | RegionOne | keystone | identity
| True| admin | http://128.224.186.226/identity |
| 2daf99edecae4afba88bb58233595481 | RegionOne | glance | image
| True| public| http://128.224.186.226/image |
| 2ece52e8bbb34d47b9bd5611f5959385 | RegionOne | kingbird |
synchronization | True| admin | http://127.0.0.1:8118/v1.0
|
| 4835a089666a4b03bd2f499457ade6c2 | RegionOne | kingbird |
synchronization | True| public| http://127.0.0.1:8118/v1.0
|
| 78e9fbc0a47642268eda3e3576920f37 | RegionOne | nova | compute
| True| public| http://128.224.186.226/compute/v2.1 |
| 96a1e503dc0e4520a190b01f6a0cf79c | RegionOne | keystone | identity
| True| public| http://128.224.186.226/identity |
| a1887dbc8c5e4af5b4a6dc5ce224b8ff | RegionOne | cinderv2 | volumev2
| True| public| http://128.224.186.226/volume/v2/$(project_id)s |
| b7d5938141694a4c87adaed5105ea3ab | RegionOne | cinder | volume
| True| public| http://128.224.186.226/volume/v1/$(project_id)s |
| bb169382cbea4715964e4652acd48070 | RegionOne | nova_legacy |
compute_legacy | True| public|
http://128.224.186.226/compute/v2/$(project_id)s |
| e01c8d8e08874d61b9411045a99d4860 | RegionOne | neutron | network
| True| public| http://128.224.186.226:9696/ |
| f94c96ed474249a29a6c0a1bb2b2e500 | RegionOne | cinderv3 | volumev3
| True| public| http://128.224.186.226/volume/v3/$(project_id)s |
+--+---+--+-+-+---+--+
I was able to successfully run the following python code:
from keystoneauth1 import loading
from keystoneauth1 import loading
from keystoneauth1 import session
from keystoneclient.v3 import client
loader = loading.get_plugin_loader("password")
auth =
loader.load_from_options(username='admin',password='secret',project_name='admin',auth_url='http://128.224.186.226/identity')
sess = session.Session(auth=auth)
keystone = client.Client(session=sess)
keystone.services.list()
I then duplicated all of the endpoints in a new region "region2", and
was able to run the python code. When I duplicated all the endpoints
again in a new region "region3" (for a total of 39 endpoints) the
python code hung at the final line.
Removing all the "region3" endpoints allowed the python code to work
again.
During all of this the command "openstack endpoint list" worked fine.
Further testing seems to indicate that it is the third "admin"
keystone endpoint that is causing the problem. I can add multiple
"public" keystone endpoints, but three or more "admin" keystone
endpoints cause the python code to hang.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1724686/+subscriptions
--
Mailin
[Yahoo-eng-team] [Bug 1733030] Re: GET /resource_providers?member_of misdocumented for lists
Reviewed: https://review.openstack.org/521216
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=ed51eee6c3f7a158afe3c622ea6d1a28a22e9f6e
Submitter: Zuul
Branch:master
commit ed51eee6c3f7a158afe3c622ea6d1a28a22e9f6e
Author: Eric Fried
Date: Fri Nov 17 20:02:40 2017 -0600
placement: Document `in:` prefix for ?member_of=
The documentation for the member_of query parameter for GET
/resource_providers [1] claims that it accepts a "comma-separated list
of strings representing aggregate uuids". But it turns out the code [2]
is expecting a single UUID unless the prefix 'in:' is specified.
This change set updates the documentation accordingly.
[1] https://developer.openstack.org/api-ref/placement/#resource-providers
[2]
https://github.com/openstack/nova/blob/57728836f25e9201ddec1e7790b552cfa840d572/nova/api/openstack/placement/handlers/resource_provider.py#L229-L233
Change-Id: I2ec46d767ded5be02cfc73136f2d217f1347662a
Closes-Bug: #1733030
** 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/1733030
Title:
GET /resource_providers?member_of misdocumented for lists
Status in OpenStack Compute (nova):
Fix Released
Bug description:
The documentation for the member_of query parameter for GET
/resource_providers [1] claims that it accepts a "comma-separated list
of strings representing aggregate uuids". But attempting this with
more than one aggregate UUID results in a 400 error claiming:
Invalid uuid value: 1ceb128e-a714-4e4a-8eec-0d0a45c7039a,4a10858c-
253e-4df5-8ada-c5dbe5744462,7cb20f93-8789-434f-bbe4-76ea1d485c32
Turns out the code [2] is expecting a single UUID unless the prefix
'in:' is specified.
I see three possible solutions:
a) Remove the prefix check or make it accepted but ignored. Don't
tell anyone. After all, nobody could have been using it unless they
had read the source code.
b) Document the in: prefix.
c) Publish a new placement microversion X with the prefix check
removed. Document the in: prefix as being required up to microversion
X-1 and forbidden (or perhaps ignored?) at microversion X and beyond.
Personally, I think the prefix is superfluous and would rather see it
removed. And the code change is trivial - one_uuid.split(',') will
happily return [one_uuid] if there's no commas in there. Surely we
don't need a new microversion if we make it accepted but ignored??
[1] https://developer.openstack.org/api-ref/placement/#resource-providers
[2]
https://github.com/openstack/nova/blob/57728836f25e9201ddec1e7790b552cfa840d572/nova/api/openstack/placement/handlers/resource_provider.py#L229-L233
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1733030/+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 1733609] [NEW] LBaaS namespace missing default route in IPv6 only network
Public bug reported:
Description:
When creating a LBaaS loadbalancer on an IPv6 only subnet (associated with a
provider network with direct internet connectivity) the resulting namespace has
no default route, even though the subnet has a gateway defined.
When doing the same with an IPv4 only network the namespace gets an appropriate
default route.
When manually injecting the default route into the namespace it starts working
immediately.
Expected Result: IPv6 only subnets also get a default route, if the
underlying subnet has one defined (gateway_ip).
Reference: Bug#1709115 mentions the same problem. A fix for the qdhcp
namespace was committed but the LBaaS side was never addressed or
answered.
Versions: ocata using Kolla from stable/ocata branch
Example output (IP Addresses sanitized):
Loadbalancer IPv4 (works as intended):
(neutron) subnet-show internet-subnet01
+---+-+
| Field | Value |
+---+-+
| allocation_pools | {"start": "XXX.XX.130.40", "end": "XXX.XX.130.240"} |
| cidr | XXX.XX.130.0/24 |
| created_at| 2017-11-03T08:17:14Z|
| description | |
| dns_nameservers | 8.8.4.4 |
| | 8.8.8.8 |
| enable_dhcp | True|
| gateway_ip| XXX.XX.130.1|
| host_routes | |
| id| c68b03d8-8e6e-48ee-a7bc-fcd7e6d03f8a|
| ip_version| 4 |
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | internet-subnet01 |
| network_id| 86ccc9d0-9495-4167-b515-68012781ded0|
| project_id| 84fb831d59cc471cb686b27e56915c8a|
| revision_number | 3 |
| service_types | |
| subnetpool_id | |
| tags | |
| tenant_id | 84fb831d59cc471cb686b27e56915c8a|
| updated_at| 2017-11-20T15:15:36Z|
+---+-+
(neutron) lbaas-loadbalancer-create --name test-lb internet-subnet01
Created a new loadbalancer:
+-+--+
| Field | Value|
+-+--+
| admin_state_up | True |
| description | |
| id | f90eff87-de07-4fce-84ee-15ec6243a07b |
| listeners | |
| name| test-lb |
| operating_status| OFFLINE |
| pools | |
| provider| haproxy |
| provisioning_status | PENDING_CREATE |
| tenant_id | 8af62d3343204fc1abfad779ebad815c |
| vip_address | XXX.XX.130.41|
| vip_port_id | 98206b7b-603b-4064-b671-d15f5cf8c056 |
| vip_subnet_id | c68b03d8-8e6e-48ee-a7bc-fcd7e6d03f8a |
+-+--+
(neutron) lbaas-listener-create --name test-lb-http --loadbalancer test-lb
--protocol HTTP --protocol-port 80
Created a new listener:
+---++
| Field | Value |
+---++
| admin_state_up| True |
| connection_limit | -1 |
| default_pool_id ||
| default_tls_container_ref ||
| description ||
| id| 2b2f5a5b-fd34-4090-ab0e-57c73efd6a24 |
| loadbalancers | {"id": "f90eff87-de07-4fce-84ee-15ec6243a07b"}
[Yahoo-eng-team] [Bug 1380701] Re: create project validates quota usage against the current project
** Also affects: horizon (Ubuntu) Importance: Undecided Status: New ** No longer affects: horizon (Ubuntu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1380701 Title: create project validates quota usage against the current project Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) juno series: Fix Released Bug description: When creating a new project under Admin->Identity->Create project, it seems that validation for quota values provided by the new project are validated against the usage of the current project. I've verified this behavior for volumes, instances, and virtual CPUs. To see the problem. * create 5 instances in the current project * create a new project (Admin->Identity->Create project) and on the Quotas tab, set the new projects Instance quota to 4. On create this message will be displayed: Quota value(s) cannot be less than the current usage value(s): 5 Instances used There is no reason the *current* usage should be compared to a *new* project. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1380701/+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 1627106] Re: TimeoutException while executing tests adding bridge using OVSDB native
Fixes backported to all stable branches. ** 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/1627106 Title: TimeoutException while executing tests adding bridge using OVSDB native Status in neutron: Fix Released Status in ovsdbapp: Fix Released Bug description: http://logs.openstack.org/91/366291/12/check/gate-neutron-dsvm- functional-ubuntu-trusty/a23c816/testr_results.html.gz Traceback (most recent call last): File "neutron/tests/base.py", line 125, in func return f(self, *args, **kwargs) File "neutron/tests/functional/agent/ovsdb/test_impl_idl.py", line 62, in test_post_commit_vswitchd_completed_no_failures self._add_br_and_test() File "neutron/tests/functional/agent/ovsdb/test_impl_idl.py", line 56, in _add_br_and_test self._add_br() File "neutron/tests/functional/agent/ovsdb/test_impl_idl.py", line 52, in _add_br tr.add(ovsdb.add_br(self.brname)) File "neutron/agent/ovsdb/api.py", line 76, in __exit__ self.result = self.commit() File "neutron/agent/ovsdb/impl_idl.py", line 72, in commit 'timeout': self.timeout}) neutron.agent.ovsdb.api.TimeoutException: Commands [AddBridgeCommand(name=test-br6925d8e2, datapath_type=None, may_exist=True)] exceeded timeout 10 seconds I suspect this one may hit us because we finally made timeout working with Icd745514adc14730b9179fa7a6dd5c115f5e87a5. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1627106/+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 1535254] Re: illustration of 'notify_on_state_change' are different from implementation
Reviewed: https://review.openstack.org/516264 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=e86604fb6579e2333ab9ab5a6926ef84d201152a Submitter: Zuul Branch:master commit e86604fb6579e2333ab9ab5a6926ef84d201152a Author: Balazs Gibizer Date: Mon Oct 30 12:59:12 2017 +0100 Document the real behavior of notify_on_state_change The documentation of the notify_on_state_change config param was incomplete and misleading. The code is untouched since 2012 so the document is updated to reflect the current behavior. Change-Id: I51d0deffc4f42ff2722a8d21aa6b8c8008c62723 Closes-Bug: #1535254 ** 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/1535254 Title: illustration of 'notify_on_state_change' are different from implementation Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: Confirmed Status in OpenStack Compute (nova) pike series: Confirmed Bug description: I'm using liberty to get notifications from nova. And I found a problem with 'notify_on_state_change'. In the configuration doc, 'notify_on_state_change' means that "If set, send compute.instance.update notifications on instance state changes." Valid values are None, 'vm_state' and 'vm_and_task_state'. However, in current implementation, if it's set to 'vm_state', compute.instance.update notifications will be sent for all the state changes and it will be a special state change notification when the vm state changes. So as to 'vm_and_task_state'. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1535254/+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 1733580] [NEW] Duplicated logs with default logging config
Public bug reported:
There are duplicated logs records in cloud-init logs with default
logging configuration.
Default logging configuration is used (via tee)
output: { all: "| tee -a /var/log/cloudinit/cloudinit.log" }
In the attached cloudinit.log duplicated logs starts from line 314:
WARN: no logging configured! (tried 0 configs)
Setting up basic logging...
2017-06-19 13:56:05,438 - util.py[DEBUG]: Writing to
/var/lib/cloud/instance/obj.pkl - wb: [256] 20235 bytes
2017-06-19 13:56:05,438 - util.py[DEBUG]: Writing to
/var/lib/cloud/instance/obj.pkl - wb: [256] 20235 bytes
2017-06-19 13:56:05,439 - main.py[DEBUG]: used datasource 'DataSourceOpenStack
[net,ver=2]' from 'OpenStack' was in di_report's list: ['OpenStack', 'None']
2017-06-19 13:56:05,439 - main.py[DEBUG]: used datasource 'DataSourceOpenStack
[net,ver=2]' from 'OpenStack' was in di_report's list: ['OpenStack', 'None']
Release:
#lsb_release -rd
Description:Ubuntu 16.04.2 LTS
Release:16.04
Package version:
#apt-cache policy cloud-init
cloud-init:
Installed: 0.7.9-113-g513e99e0-0ubuntu1~16.04.1
Candidate: 0.7.9-113-g513e99e0-0ubuntu1~16.04.1
Version table:
*** 0.7.9-113-g513e99e0-0ubuntu1~16.04.1 500
500 http://nova.clouds.archive.ubuntu.com/ubuntu xenial-updates/main
amd64 Packages
100 /var/lib/dpkg/status
0.7.7~bzr1212-0ubuntu1 500
500 http://nova.clouds.archive.ubuntu.com/ubuntu xenial/main amd64
Packages
What you expected to happen: No duplicated logs with default logging
config
What happened instead: Duplicated log records with default logging
** Affects: cloud-init
Importance: Undecided
Status: New
** Attachment added: "cloudinit.log"
https://bugs.launchpad.net/bugs/1733580/+attachment/5012177/+files/cloudinit.log
--
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/1733580
Title:
Duplicated logs with default logging config
Status in cloud-init:
New
Bug description:
There are duplicated logs records in cloud-init logs with default
logging configuration.
Default logging configuration is used (via tee)
output: { all: "| tee -a /var/log/cloudinit/cloudinit.log" }
In the attached cloudinit.log duplicated logs starts from line 314:
WARN: no logging configured! (tried 0 configs)
Setting up basic logging...
2017-06-19 13:56:05,438 - util.py[DEBUG]: Writing to
/var/lib/cloud/instance/obj.pkl - wb: [256] 20235 bytes
2017-06-19 13:56:05,438 - util.py[DEBUG]: Writing to
/var/lib/cloud/instance/obj.pkl - wb: [256] 20235 bytes
2017-06-19 13:56:05,439 - main.py[DEBUG]: used datasource
'DataSourceOpenStack [net,ver=2]' from 'OpenStack' was in di_report's list:
['OpenStack', 'None']
2017-06-19 13:56:05,439 - main.py[DEBUG]: used datasource
'DataSourceOpenStack [net,ver=2]' from 'OpenStack' was in di_report's list:
['OpenStack', 'None']
Release:
#lsb_release -rd
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Package version:
#apt-cache policy cloud-init
cloud-init:
Installed: 0.7.9-113-g513e99e0-0ubuntu1~16.04.1
Candidate: 0.7.9-113-g513e99e0-0ubuntu1~16.04.1
Version table:
*** 0.7.9-113-g513e99e0-0ubuntu1~16.04.1 500
500 http://nova.clouds.archive.ubuntu.com/ubuntu xenial-updates/main
amd64 Packages
100 /var/lib/dpkg/status
0.7.7~bzr1212-0ubuntu1 500
500 http://nova.clouds.archive.ubuntu.com/ubuntu xenial/main amd64
Packages
What you expected to happen: No duplicated logs with default logging
config
What happened instead: Duplicated log records with default logging
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1733580/+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 1733570] [NEW] horizon accesses the internet during the build
Public bug reported: horizon accesses the internet during the build https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882266 ** Affects: horizon Importance: High Assignee: Akihiro Motoki (amotoki) Status: New ** Tags: pike-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1733570 Title: horizon accesses the internet during the build Status in OpenStack Dashboard (Horizon): New Bug description: horizon accesses the internet during the build https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882266 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1733570/+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 1691119] Re: testtools.run neutron.tests.tempest.scenario.test_floatingip.FloatingIpSameNetwork.test_east_west
The test uses scenario, you can't simply run a single test, you need to run the whole class. ** Changed in: neutron Status: New => Opinion ** Changed in: neutron Status: Opinion => 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/1691119 Title: testtools.run neutron.tests.tempest.scenario.test_floatingip.FloatingIpSameNetwork.test_east_west Status in neutron: Invalid Bug description: We believe that each test should not depend on other tests. python -m testtools.run neutron.tests.tempest.scenario.test_floatingip Ran 4 tests in 139.164s OK python -m testtools.run neutron.tests.tempest.scenario.test_floatingip.FloatingIpSameNetwork.test_east_west == ERROR: neutron.tests.tempest.scenario.test_floatingip.FloatingIpSameNetwork.test_east_west[id-05c4e3b3-7319-4052-90ad-e8916436c23b] -- Empty attachments: pythonlogging:'' Traceback (most recent call last): File "/home/centos/tempest-upstream/neutron/neutron/tests/tempest/scenario/test_floatingip.py", line 125, in test_east_west self._test_east_west() File "/home/centos/tempest-upstream/neutron/neutron/tests/tempest/scenario/test_floatingip.py", line 100, in _test_east_west if self.dest_has_fip: AttributeError: 'FloatingIpSameNetwork' object has no attribute 'dest_has_fip' Ran 1 test in 57.370s FAILED (failures=1) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1691119/+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 1733551] [NEW] Stage call returns 500 internal server error when image does not exists
Public bug reported: If user tries to stage data to unexisting image then it fails with 500 internal server error. Ideally it should return 404 HTTNotFound error to the user. Steps to reproduce: 1. Run image-stage with any random id command $ glance image-stage abcd --file Output: 500 Internal Server Error: The server has either erred or is incapable of performing the requested operation. (HTTP 500) Glance API logs: Nov 21 10:12:29 devstack devstack@g-api.service[19195]: pdict['tenant'] = self.tenant Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data [None req-99abd47d-7c74-43ad-a92e-abf01d97f4c4 admin admin] Failed to stage image data due to internal error: ImageNotFound: No image found with ID abcd Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data Traceback (most recent call last): Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/api/v2/image_data.py", line 298, in stage Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data image = image_repo.get(image_id) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/api/authorization.py", line 107, in get Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data image = self.image_repo.get(image_id) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/domain/proxy.py", line 86, in get Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data return self.helper.proxy(self.base.get(item_id)) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/api/policy.py", line 105, in get Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data image = super(ImageRepoProxy, self).get(image_id) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/domain/proxy.py", line 86, in get Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data return self.helper.proxy(self.base.get(item_id)) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/domain/proxy.py", line 86, in get Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data return self.helper.proxy(self.base.get(item_id)) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/domain/proxy.py", line 86, in get Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data return self.helper.proxy(self.base.get(item_id)) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/db/__init__.py", line 89, in get Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data raise exception.ImageNotFound(msg) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data ImageNotFound: No image found with ID abcd Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data ** Affects: glance Importance: Undecided Assignee: Abhishek Kekane (abhishek-kekane) Status: New ** Changed in: glance Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane) ** Description changed: If user tries to stage data to unexisting image then it fails with 500 internal server error. Ideally it should return 404 HTTNotFound error to the user. Steps to reproduce: 1. Run image-stage with any random id command -$ glance image-stage abcd1234 --file + $ glance image-stage abcd --file Output: 500 Internal Server Error: The server has either erred or is incapable of performing the requested operation. (HTTP 500) Glance API logs: Nov 21 10:12:29 devstack devstack@g-api.service[19195]: pdict['tenant'] = self.tenant Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data [None req-99abd47d-7c74-43ad-a92e-abf01d97f4c4 admin admin] Failed to stage image data due to internal error: ImageNotFound: No image found with ID abcd Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data Traceback (most recent call last): Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data File "/opt/stack/glance/glance/api/v2/image_data.py", line 298, in stage Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.image_data image = image_repo.get(image_id) Nov 21 10:12:29 devstack devstack@g-api.service[19195]: ERROR glance.api.v2.im
[Yahoo-eng-team] [Bug 1573766] Re: Enable the paste filter HTTPProxyToWSGI by default
** Also affects: cloud-archive 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/1573766 Title: Enable the paste filter HTTPProxyToWSGI by default Status in OpenStack nova-cloud-controller charm: New Status in Ubuntu Cloud Archive: New Status in OpenStack Compute (nova): Fix Released Status in nova package in Ubuntu: New Bug description: [Impact] Getting http link instead of https even if https setting is set. [Test case] 1. deploy openstack ( with keystone charm option use-https, https-service-endpoints) 2. create instance 3. nova --debug list - check the result if https links are there. [Regression Potential] nova pkg will be affected by this patch. However, this patch modifies only api-paste.ini by adding http_proxy_to_wsgi. To accept this patch, nova service need to be restarted. Tested no vms are affected this patch, but APIs or daemons are temporarily. [Others] related commits ( which are already in comments ) https://git.openstack.org/cgit/openstack/nova/commit/?id=b609a3b32ee8e68cef7e66fabff07ca8ad6d4649 https://git.openstack.org/cgit/openstack/nova/commit/?id=6051f30a7e61c32833667d3079744b2d4fd1ce7c [Original Description] oslo middleware provides a paste filter that sets the correct proxy scheme and host. This is needed for the TLS proxy case. Without this then enabling the TLS proxy in devstack will fail configuring tempest because 'nova flavor-list' returns a http scheme in Location in a redirect it returns. I've proposed a temporary workaround in devstack using: +iniset $NOVA_API_PASTE_INI filter:ssl_header_handler past e.filter_factory oslo_middleware.http_proxy_to_wsgi:HTTPProxyToWSGI.factory +iniset $NOVA_API_PASTE_INI composite:openstack_compute_ap i_v21 keystone "ssl_header_handler cors compute_req_id faultwrap sizelimit autht oken keystonecontext osapi_compute_app_v21" But this isn't a long-term solution because two copies of the default paste filters will need to be maintained. See https://review.openstack.org/#/c/301172 To manage notifications about this bug go to: https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1573766/+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 1733522] [NEW] openvswitch will delete vhost-user-client socket file if vhostuser_socket_dir=/var/run/openvswitch
Public bug reported: I used ocata version neutron and ovs-dpdk with vhost-user-client mode. When I restart ovs, I found the vhost-user-client socket file disappear and 'vhuc' interface link_state is down。 The vhostuser_socket_dir in /etc/neutron/plugins/ml2/openvswitch_agent.ini was set as default value: /var/run/openvswitch. And I found ovs would recreate this directory. As a result, the socket file would be deleted. So I think the default value of vhostuser_socket_dir is not appropriate. ** Affects: neutron Importance: Undecided Status: New ** Description changed: I used ocata version neutron and ovs-dpdk with vhost-user-client mode. When I restart ovs, I found the vhost-user-client socket file disappear and 'vhuc' interface link_state is down。 - The vhostuser_socket_dir is set as default value: /var/run/openvswitch. And I found ovs would recreate this directory. As a result, the socket file would be deleted. So I think the default value of vhostuser_socket_dir is not appropriate. + The vhostuser_socket_dir was set as default value: /var/run/openvswitch. And I found ovs would recreate this directory. As a result, the socket file would be deleted. So I think the default value of vhostuser_socket_dir is not appropriate. ** Description changed: I used ocata version neutron and ovs-dpdk with vhost-user-client mode. When I restart ovs, I found the vhost-user-client socket file disappear and 'vhuc' interface link_state is down。 - The vhostuser_socket_dir was set as default value: /var/run/openvswitch. And I found ovs would recreate this directory. As a result, the socket file would be deleted. So I think the default value of vhostuser_socket_dir is not appropriate. + The vhostuser_socket_dir in /etc/neutron/plugins/ml2/openvswitch_agent.ini was set as default value: /var/run/openvswitch. And I found ovs would recreate this directory. As a result, the socket file would be deleted. So I think the default value of vhostuser_socket_dir is not appropriate. ** Project changed: fuel-plugin-contrail => 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/1733522 Title: openvswitch will delete vhost-user-client socket file if vhostuser_socket_dir=/var/run/openvswitch Status in neutron: New Bug description: I used ocata version neutron and ovs-dpdk with vhost-user-client mode. When I restart ovs, I found the vhost-user-client socket file disappear and 'vhuc' interface link_state is down。 The vhostuser_socket_dir in /etc/neutron/plugins/ml2/openvswitch_agent.ini was set as default value: /var/run/openvswitch. And I found ovs would recreate this directory. As a result, the socket file would be deleted. So I think the default value of vhostuser_socket_dir is not appropriate. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1733522/+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 1733522] [NEW] openvswitch will delete vhost-user-client socket file if vhostuser_socket_dir=/var/run/openvswitch
You have been subscribed to a public bug: I used ocata version neutron and ovs-dpdk with vhost-user-client mode. When I restart ovs, I found the vhost-user-client socket file disappear and 'vhuc' interface link_state is down。 The vhostuser_socket_dir in /etc/neutron/plugins/ml2/openvswitch_agent.ini was set as default value: /var/run/openvswitch. And I found ovs would recreate this directory. As a result, the socket file would be deleted. So I think the default value of vhostuser_socket_dir is not appropriate. ** Affects: neutron Importance: Undecided Status: New -- openvswitch will delete vhost-user-client socket file if vhostuser_socket_dir=/var/run/openvswitch https://bugs.launchpad.net/bugs/1733522 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. -- 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 1733515] Re: use_journal option not available in ocata
** Also affects: openstack-manuals 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/1733515 Title: use_journal option not available in ocata Status in OpenStack Compute (nova): New Status in openstack-manuals: New Bug description: The config documentation for Nova Ocata lists the "use_journal" option[1], however that option was added to oslo.log only for the Pike cycle[2] in oslo.log==3.24.0. It isn't available e.g. in Ubuntu Ocata UCA with python-oslo.log=3.20.1-0ubuntu1~cloud0. [1] https://docs.openstack.org/ocata/config-reference/compute/config-options.html [2] https://docs.openstack.org/releasenotes/oslo.log/pike.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1733515/+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 1733515] [NEW] use_journal option not available in ocata
Public bug reported: The config documentation for Nova Ocata lists the "use_journal" option[1], however that option was added to oslo.log only for the Pike cycle[2] in oslo.log==3.24.0. It isn't available e.g. in Ubuntu Ocata UCA with python-oslo.log=3.20.1-0ubuntu1~cloud0. [1] https://docs.openstack.org/ocata/config-reference/compute/config-options.html [2] https://docs.openstack.org/releasenotes/oslo.log/pike.html ** 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/1733515 Title: use_journal option not available in ocata Status in OpenStack Compute (nova): New Bug description: The config documentation for Nova Ocata lists the "use_journal" option[1], however that option was added to oslo.log only for the Pike cycle[2] in oslo.log==3.24.0. It isn't available e.g. in Ubuntu Ocata UCA with python-oslo.log=3.20.1-0ubuntu1~cloud0. [1] https://docs.openstack.org/ocata/config-reference/compute/config-options.html [2] https://docs.openstack.org/releasenotes/oslo.log/pike.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1733515/+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 1733512] [NEW] Stage call returns 500 internal server error when image is in saving state
Public bug reported: If image upload (/file call) is in progress image is in saving state at that time. If user tries to make a /stage call on same image then it returns 500 internal server error as Image transition from saving to uploading is not allowed. Ideally it should return 409 HTTConflict error to the user. Steps to reproduce: 1. Create image $ glance image-create --container-format ami --disk-format ami --name cirros_image 2. Upload data to image $ glance image-upload --file 3. Ensure image is in saving state and run image-stage command $ glance image-stage --file Output: 500 Internal Server Error: The server has either erred or is incapable of performing the requested operation. (HTTP 500) Glance API logs: Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi [None req-f8f2ccf6-88af-4104-aa02-8077bf2670a2 admin admin] Caught error: Image status transition from saving to uploading is not allowed: InvalidImageStatusTransition: Image status transition from saving to uploading is not allowed Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi Traceback (most recent call last): Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/common/wsgi.py", line 1222, in __call__ Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi request, **action_args) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/common/wsgi.py", line 1261, in dispatch Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi return method(*args, **kwargs) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/common/utils.py", line 363, in wrapped Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi return func(self, req, *args, **kwargs) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/api/v2/image_data.py", line 344, in stage Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi self._restore(image_repo, image) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi self.force_reraise() Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi six.reraise(self.type_, self.value, self.tb) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/api/v2/image_data.py", line 300, in stage Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi image.status = 'uploading' Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/domain/proxy.py", line 23, in set_attr Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi return setattr(getattr(self, target), attr, value) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/domain/proxy.py", line 23, in set_attr Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi return setattr(getattr(self, target), attr, value) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/domain/proxy.py", line 23, in set_attr Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi return setattr(getattr(self, target), attr, value) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/domain/proxy.py", line 23, in set_attr Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi return setattr(getattr(self, target), attr, value) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/domain/proxy.py", line 23, in set_attr Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi return setattr(getattr(self, target), attr, value) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/glance/domain/proxy.py", line 23, in set_attr Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi return setattr(getattr(self, target), attr, value) Nov 21 07:28:46 devstack devstack@g-api.service[12621]: ERROR glance.common.wsgi File "/opt/stack/glance/g
