[Yahoo-eng-team] [Bug 1877229] [NEW] Nova host aggregate cannot sync to placement
Public bug reported: Description === We are using the nova stein version. When adding/removing host from aggregate, nova should sync the host aggregate to placement resource provider aggregate as well. But from our test, it is not working. Steps to reproduce == 1. Check a specific compute node resource provider aggregate 2. Create a new host aggregate and add the compute node into the aggregate 3. Check the compute node resource provider aggregate again to see if the additional aggreate is added (We got the similar error when removing host from an existing aggregate) Expected result === An additional resource provider aggregate for the compute node Actual result = No change. Logs & Configs == from nova-api: May 07 09:54:06 nova-api nova-api[26742]: 2020-05-07 09:54:06.364 26742 WARNING nova.compute.api [req-b4542212-7a5c-4d81-b602-4702634015b8 c0645ff94b864d3d84c438d9855f9cea 9427903ca1544f0795ba4117d55ed9b2 - default default] Failed to associate cc2 with a placement aggregate: No such resource provider cc2.. This may be corrected after running nova- manage placement sync_aggregates.: nova.exception.ResourceProviderNotFound: No such resource provider cc2. Note: cc2 is the hostname but the name of the resource provider is fqdn(with domain). I think that is reason why the resource provider cannot be found. ** 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/1877229 Title: Nova host aggregate cannot sync to placement Status in OpenStack Compute (nova): New Bug description: Description === We are using the nova stein version. When adding/removing host from aggregate, nova should sync the host aggregate to placement resource provider aggregate as well. But from our test, it is not working. Steps to reproduce == 1. Check a specific compute node resource provider aggregate 2. Create a new host aggregate and add the compute node into the aggregate 3. Check the compute node resource provider aggregate again to see if the additional aggreate is added (We got the similar error when removing host from an existing aggregate) Expected result === An additional resource provider aggregate for the compute node Actual result = No change. Logs & Configs == from nova-api: May 07 09:54:06 nova-api nova-api[26742]: 2020-05-07 09:54:06.364 26742 WARNING nova.compute.api [req-b4542212-7a5c- 4d81-b602-4702634015b8 c0645ff94b864d3d84c438d9855f9cea 9427903ca1544f0795ba4117d55ed9b2 - default default] Failed to associate cc2 with a placement aggregate: No such resource provider cc2.. This may be corrected after running nova-manage placement sync_aggregates.: nova.exception.ResourceProviderNotFound: No such resource provider cc2. Note: cc2 is the hostname but the name of the resource provider is fqdn(with domain). I think that is reason why the resource provider cannot be found. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1877229/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1873290] Re: OAuth1 request token authorize silently ignores roles parameter
Reviewed: https://review.opendev.org/725885
Committed:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=6c73690f779a42a5c62914b6bc37f0ac2f41a3e3
Submitter: Zuul
Branch:master
commit 6c73690f779a42a5c62914b6bc37f0ac2f41a3e3
Author: Colleen Murphy
Date: Thu Apr 16 20:35:46 2020 -0700
Ensure OAuth1 authorized roles are respected
Without this patch, when an OAuth1 request token is authorized with a
limited set of roles, the roles for the access token are ignored when
the user uses it to request a keystone token. This means that user of an
access token can use it to escallate their role assignments beyond what
was authorized by the creator. This patch fixes the issue by ensuring
the token model accounts for an OAuth1-scoped token and correctly
populating the roles for it.
Change-Id: I02f9836fbd4d7e629653977fc341476cfd89859e
Closes-bug: #1873290
** Changed in: keystone
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1873290
Title:
OAuth1 request token authorize silently ignores roles parameter
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Security Advisory:
Fix Released
Bug description:
Sorry for using "trustor" and "trustee" terms in OAuth1 context, but
these terms clearly describe users positions.
OpenStack CLI explicitly requires an OAuth1 "trustor" to specify a
role for an OAuth1 Access Token:
$ openstack request token authorize
usage: openstack request token authorize [-h]
[-f {json,shell,table,value,yaml}]
[-c COLUMN] [--noindent]
[--prefix PREFIX]
[--max-width ] [--fit-width]
[--print-empty] --request-key
--role
openstack request token authorize: error: the following arguments are
required: --request-key, --role
However a specified role is silently ignored and OAuth1 token gets all
OAuth1 "trustor" roles.
https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/os_oauth1.py#L287
As an OAuth1 "trustor" I expect the "trustee" to have only accepted
roles.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1873290/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1872755] Re: ec2 credential "trust_id" can be updated to null
I've set our advisory task to Won't Fix on this one, as no advisory is
required with the fix for bug 1872735 effectively preventing the path to
exploitation.
** Tags added: security
** Information type changed from Public Security to Public
** Changed in: ossa
Status: Incomplete => 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/1872755
Title:
ec2 credential "trust_id" can be updated to null
Status in OpenStack Identity (keystone):
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Similar to https://bugs.launchpad.net/keystone/+bug/1872733 and
https://bugs.launchpad.net/keystone/+bug/1872753. If ec2 credentials
were created within a trust_id scope, it is still possible to set
these credentials' "trust_id" to "null" using:
curl -X PATCH
https://keystone/v3/credentials/3c2b3265350c6da3a18a143fbe975ca4a8ed88a6f8c6dacc2494a5c1287ba66f
-H 'Accept: application/json' -H 'Content-Type: application/json' -H
"X-Auth-Token: ***" -d'{
"credential": {
"blob": "{\"access\": \"ffe6fc21b47c4d87befc95ad070c3b7a\", \"secret\":
\"530196cd097e4a7ca9df7258aa89ff0e\", \"trust_id\": null}"
}
}'
Note "null" in blob.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1872755/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1877195] [NEW] [ovn] neutron devstack needs to support openflow15
Public bug reported: OVN has been changed to use OF15 see [1] Because of that, devstack configuration scripts must be updated to stop using the hard coded Openflow13 protocol. Still, we should make this backwards compatible so it remains working on potentially older versions of OVN. The error you observe in this situation looks like this: tail -F /opt/stack/logs/ovs-vswitchd.log 2020-05-06T21:04:31.488Z|00482|vconn|WARN|unix#341: version negotiation failed (we support version 0x04, peer support s version 0x06) To work around this issue on devstack, set the protocol and restart vswitchd service: systemctl restart devstack@ovs-vswitchd.service https://github.com/ovn- org/ovn/commit/6ec0b82038052866533f12823fe410308b3e457a ** Affects: neutron Importance: Undecided Assignee: Flavio Fernandes (ffernand) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Flavio Fernandes (ffernand) ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1877195 Title: [ovn] neutron devstack needs to support openflow15 Status in neutron: In Progress Bug description: OVN has been changed to use OF15 see [1] Because of that, devstack configuration scripts must be updated to stop using the hard coded Openflow13 protocol. Still, we should make this backwards compatible so it remains working on potentially older versions of OVN. The error you observe in this situation looks like this: tail -F /opt/stack/logs/ovs-vswitchd.log 2020-05-06T21:04:31.488Z|00482|vconn|WARN|unix#341: version negotiation failed (we support version 0x04, peer support s version 0x06) To work around this issue on devstack, set the protocol and restart vswitchd service: systemctl restart devstack@ovs-vswitchd.service https://github.com/ovn- org/ovn/commit/6ec0b82038052866533f12823fe410308b3e457a To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1877195/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1877189] [NEW] nova.task_log database records are never deleted
Public bug reported: nova.task_log database records are related to the server usage audit log API [1] which is dependent on the [DEFAULT]/instance_usage_audit config option being set to True (it defaults to False). Enablement of the config option causes nova-compute to emit notifications which are consumed by OpenStack Telemetry. When the config option is enabled, records will be periodically created in the nova.task_log table. And there is no cleanup of the records in nova. I started a ML thread about the server usage audit log API awhile back [2] and the conclusion was that deprecating or removing the API isn't practical as there are systems in the wild still using it, so the best action to take for now is to create a nova-manage command for cleaning up old nova.task_log records. I brought up the proposal in a nova meeting [3] and in the nova channel [4] and the consensus was to treat it as a Wishlist bug so that it can be backported upstream. So this is a bug for the work to add a new 'nova-manage db purge_task_log' command that offers a --before option. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-09-06.log.html#t2019-09-06T14:19:50 [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009245.html [3] http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-10-17-14.00.log.html#l-306 [4] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-10-17.log.html#t2019-10-17T14:54:39 ** Affects: nova Importance: Wishlist Assignee: melanie witt (melwitt) Status: Confirmed ** Tags: nova-manage ** Changed in: nova Importance: Undecided => Wishlist ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1877189 Title: nova.task_log database records are never deleted Status in OpenStack Compute (nova): Confirmed Bug description: nova.task_log database records are related to the server usage audit log API [1] which is dependent on the [DEFAULT]/instance_usage_audit config option being set to True (it defaults to False). Enablement of the config option causes nova-compute to emit notifications which are consumed by OpenStack Telemetry. When the config option is enabled, records will be periodically created in the nova.task_log table. And there is no cleanup of the records in nova. I started a ML thread about the server usage audit log API awhile back [2] and the conclusion was that deprecating or removing the API isn't practical as there are systems in the wild still using it, so the best action to take for now is to create a nova-manage command for cleaning up old nova.task_log records. I brought up the proposal in a nova meeting [3] and in the nova channel [4] and the consensus was to treat it as a Wishlist bug so that it can be backported upstream. So this is a bug for the work to add a new 'nova-manage db purge_task_log' command that offers a --before option. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-09-06.log.html#t2019-09-06T14:19:50 [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009245.html [3] http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-10-17-14.00.log.html#l-306 [4] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-10-17.log.html#t2019-10-17T14:54:39 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1877189/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1872735] Re: EC2 and/or credential endpoints are not protected from a scoped context
Reviewed: https://review.opendev.org/725912 Committed: https://git.openstack.org/cgit/openstack/ossa/commit/?id=2548f46b0aff357f6c953b30179b4d8e151e4236 Submitter: Zuul Branch:master commit 2548f46b0aff357f6c953b30179b4d8e151e4236 Author: Gage Hugo Date: Wed May 6 10:57:15 2020 -0500 Add OSSA-2020-004 (CVEs Pending) Change-Id: Ide28e91b184edab45d22c47661ad6bb6003dd244 Closes-Bug: #1872735 Closes-Bug: #1872733 ** Changed in: ossa Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1872735 Title: EC2 and/or credential endpoints are not protected from a scoped context Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Fix Released Bug description: Being authorized within a limited scope context, i.e. trust / oauth / application credential with a limited role, e.g. "monitoring_viewer" or "viewer", it is still possible to create EC2 credentials. User can auth against Keystone using EC2 credentials and obtain all project roles of a trust/oauth/application_credential owner. I prepared a tool to auth against keyston using ec2 credentials: https://github.com/kayrus/ec2auth * auth against keystone using trust/oauth/application_credential credentials * issue ec2 credentials: "openstack ec2 credentials create" * authenticate against keystone using ec2 credentials: "ec2auth --access 7522162ced8f4e3eb9502168ef199584 --secret c558d9401a694377a83ce910e5a5 --debug" You'll see that returned token contains all owner roles. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1872735/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1872733] Re: Keystone V3 /credentials endpoint policy logic allows to change credentials owner or target project ID
Reviewed: https://review.opendev.org/725912
Committed:
https://git.openstack.org/cgit/openstack/ossa/commit/?id=2548f46b0aff357f6c953b30179b4d8e151e4236
Submitter: Zuul
Branch:master
commit 2548f46b0aff357f6c953b30179b4d8e151e4236
Author: Gage Hugo
Date: Wed May 6 10:57:15 2020 -0500
Add OSSA-2020-004 (CVEs Pending)
Change-Id: Ide28e91b184edab45d22c47661ad6bb6003dd244
Closes-Bug: #1872735
Closes-Bug: #1872733
** Changed in: ossa
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1872733
Title:
Keystone V3 /credentials endpoint policy logic allows to change
credentials owner or target project ID
Status in OpenStack Identity (keystone):
In Progress
Status in OpenStack Security Advisory:
Fix Released
Bug description:
"_build_target_enforcement" function checks only for "credential_id":
https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/credentials.py#L38
Thus even having a '"identity:update_credential": "rule:cloud_admin or
(user_id:%(target.credential.user_id)s)"' policy doesn't prevent a
malicious user to create an EC2 credential, then change its owner and
project ID, e.g.:
curl -X PATCH
https://keystone/v3/credentials/3c2b3265350c6da3a18a143fbe975ca4a8ed88a6f8c6dacc2494a5c1287ba66f
-H 'Accept: application/json' -H 'Content-Type: application/json' -H
"X-Auth-Token: ***" -d'{
"credential": {
"project_id": "_target_project_id_",
"user_id": "_target_user_id_"
}
}'
Additionally it is possible to Create a credential with any existing
project_id, though it doesn't have a serious security issue, e.g.:
{
"credential": {
"blob": "{\"access\": \"ffe6fc21b47c4d87befc95ad070c3b7a\", \"secret\":
\"530196cd097e4a7ca9df7258aa89ff0e\", \"trust_id\": null}",
"id": "3c2b3265350c6da3a18a143fbe975ca4a8ed88a6f8c6dacc2494a5c1287ba66f",
"project_id": "_any_project_id_",
"type": "ec2",
"user_id": "_my_user_id_"
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1872733/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1873290] Re: OAuth1 request token authorize silently ignores roles parameter
Reviewed: https://review.opendev.org/725917
Committed:
https://git.openstack.org/cgit/openstack/ossa/commit/?id=3696964abeeef77b725d452b1cda8c79568d5ad0
Submitter: Zuul
Branch:master
commit 3696964abeeef77b725d452b1cda8c79568d5ad0
Author: Gage Hugo
Date: Wed May 6 11:06:58 2020 -0500
Add OSSA-2020-005 (CVE Pending)
Change-Id: I6b422cc4491d2c785565716ee4d07ca58efcdb0a
Closes-Bug: #1873290
** Changed in: ossa
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1873290
Title:
OAuth1 request token authorize silently ignores roles parameter
Status in OpenStack Identity (keystone):
In Progress
Status in OpenStack Security Advisory:
Fix Released
Bug description:
Sorry for using "trustor" and "trustee" terms in OAuth1 context, but
these terms clearly describe users positions.
OpenStack CLI explicitly requires an OAuth1 "trustor" to specify a
role for an OAuth1 Access Token:
$ openstack request token authorize
usage: openstack request token authorize [-h]
[-f {json,shell,table,value,yaml}]
[-c COLUMN] [--noindent]
[--prefix PREFIX]
[--max-width ] [--fit-width]
[--print-empty] --request-key
--role
openstack request token authorize: error: the following arguments are
required: --request-key, --role
However a specified role is silently ignored and OAuth1 token gets all
OAuth1 "trustor" roles.
https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/os_oauth1.py#L287
As an OAuth1 "trustor" I expect the "trustee" to have only accepted
roles.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1873290/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1876139] Re: Groovy cloud-images failing during growpart
This bug was fixed in the package cloud-utils - 0.31-8-g9619a1ea- 0ubuntu1 --- cloud-utils (0.31-8-g9619a1ea-0ubuntu1) groovy; urgency=medium * New upstream snapshot. - cloud-image-utils: Add depends on fdisk, drop e2fsprogs [Scott Moser] (LP: #1876139) -- Ryan Harper Tue, 05 May 2020 16:12:40 -0500 ** Changed in: cloud-utils (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1876139 Title: Groovy cloud-images failing during growpart Status in cloud-images: New Status in cloud-init: Incomplete Status in cloud-utils: Fix Committed Status in cloud-utils package in Ubuntu: Fix Released Bug description: Was running on Azure, but I expect this happens on all cloud images. We did not see our disk grow as expected on first boot. Took a look at /var/log/cloud-init and saw the following: 2020-04-30 16:04:46,837 - util.py[WARNING]: Failed growpart --dry-run for (/dev/sda, 1) 2020-04-30 16:04:46,837 - util.py[DEBUG]: Failed growpart --dry-run for (/dev/sda, 1) Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 145, in resize util.subp(["growpart", '--dry-run', diskdev, partnum]) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2084, in subp raise ProcessExecutionError(stdout=out, stderr=err, cloudinit.util.ProcessExecutionError: Unexpected error while running command. Command: ['growpart', '--dry-run', '/dev/sda', '1'] Exit code: 2 Reason: - Stdout: FAILED: sfdisk not found To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1876139/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1877146] [NEW] neutron-dynamic-plugin tempest jobs fail on stable/train branch
Public bug reported: Sample review with failure: https://review.opendev.org/#/c/725790/ https://1220c88f5f3f7dc2943f-5c9bf716eadc2e193f03b25f937f429b.ssl.cf1.rackcdn.com/725790/1/check/neutron-dynamic-routing-dsvm-tempest-api/19f9000/job-output.txt 2020-05-06 09:12:36.370490 | primary | all-plugin run-test: commands[3] | tempest run --regex '^neutron_dynamic_routing.tests.tempest.api\.' --concurrency=4 2020-05-06 09:12:40.817171 | primary | 2020-05-06 09:12:40.817256 | primary | = 2020-05-06 09:12:40.817278 | primary | Failures during discovery 2020-05-06 09:12:40.817303 | primary | = 2020-05-06 09:12:40.817322 | primary | --- import errors --- 2020-05-06 09:12:40.817342 | primary | Failed to import test module: neutron_dynamic_routing.tests.tempest.api.test_bgp_speaker_extensions 2020-05-06 09:12:40.817362 | primary | Traceback (most recent call last): 2020-05-06 09:12:40.817382 | primary | File "/usr/lib/python3.6/unittest/loader.py", line 428, in _find_test_path 2020-05-06 09:12:40.817401 | primary | module = self._get_module_from_name(name) 2020-05-06 09:12:40.817420 | primary | File "/usr/lib/python3.6/unittest/loader.py", line 369, in _get_module_from_name 2020-05-06 09:12:40.817440 | primary | __import__(name) 2020-05-06 09:12:40.817459 | primary | File "/opt/stack/new/neutron-dynamic-routing/neutron_dynamic_routing/tests/tempest/api/test_bgp_speaker_extensions.py", line 21, in 2020-05-06 09:12:40.817478 | primary | from neutron_tempest_plugin.api import base 2020-05-06 09:12:40.817498 | primary | ModuleNotFoundError: No module named 'neutron_tempest_plugin' 2020-05-06 09:12:40.817519 | primary | 2020-05-06 09:12:40.817538 | primary | Failed to import test module: neutron_dynamic_routing.tests.tempest.api.test_bgp_speaker_extensions_negative 2020-05-06 09:12:40.817557 | primary | Traceback (most recent call last): 2020-05-06 09:12:40.817575 | primary | File "/usr/lib/python3.6/unittest/loader.py", line 428, in _find_test_path 2020-05-06 09:12:40.817594 | primary | module = self._get_module_from_name(name) 2020-05-06 09:12:40.817613 | primary | File "/usr/lib/python3.6/unittest/loader.py", line 369, in _get_module_from_name 2020-05-06 09:12:40.817635 | primary | __import__(name) 2020-05-06 09:12:40.817654 | primary | File "/opt/stack/new/neutron-dynamic-routing/neutron_dynamic_routing/tests/tempest/api/test_bgp_speaker_extensions_negative.py", line 21, in 2020-05-06 09:12:40.817673 | primary | from neutron_dynamic_routing.tests.tempest.api import test_bgp_speaker_extensions as test_base # noqa 2020-05-06 09:12:40.817692 | primary | File "/opt/stack/new/neutron-dynamic-routing/neutron_dynamic_routing/tests/tempest/api/test_bgp_speaker_extensions.py", line 21, in 2020-05-06 09:12:40.817711 | primary | from neutron_tempest_plugin.api import base 2020-05-06 09:12:40.817730 | primary | ModuleNotFoundError: No module named 'neutron_tempest_plugin' 2020-05-06 09:12:40.817748 | primary | 2020-05-06 09:12:40.817767 | primary | Failed to import test module: neutron_dynamic_routing.tests.tempest.scenario.basic.test_4byte_asn 2020-05-06 09:12:40.817786 | primary | Traceback (most recent call last): 2020-05-06 09:12:40.817804 | primary | File "/usr/lib/python3.6/unittest/loader.py", line 428, in _find_test_path 2020-05-06 09:12:40.817823 | primary | module = self._get_module_from_name(name) 2020-05-06 09:12:40.817842 | primary | File "/usr/lib/python3.6/unittest/loader.py", line 369, in _get_module_from_name 2020-05-06 09:12:40.817861 | primary | __import__(name) 2020-05-06 09:12:40.817879 | primary | File "/opt/stack/new/neutron-dynamic-routing/neutron_dynamic_routing/tests/tempest/scenario/basic/test_4byte_asn.py", line 17, in 2020-05-06 09:12:40.817898 | primary | from neutron_dynamic_routing.tests.tempest.scenario import base 2020-05-06 09:12:40.817934 | primary | File "/opt/stack/new/neutron-dynamic-routing/neutron_dynamic_routing/tests/tempest/scenario/base.py", line 26, in 2020-05-06 09:12:40.817954 | primary | from neutron_tempest_plugin.api import base 2020-05-06 09:12:40.817973 | primary | ModuleNotFoundError: No module named 'neutron_tempest_plugin' 2020-05-06 09:12:40.817992 | primary | 2020-05-06 09:12:40.818011 | primary | Failed to import test module: neutron_dynamic_routing.tests.tempest.scenario.basic.test_basic 2020-05-06 09:12:40.818029 | primary | Traceback (most recent call last): 2020-05-06 09:12:40.818048 | primary | File "/usr/lib/python3.6/unittest/loader.py", line 428, in _find_test_path 2020-05-06 09:12:40.818066 | primary | module = self._get_module_from_name(name) 2020-05-06 09:12:40.818085 | primary | File "/usr/lib/python3.6/unittest/loader.py", line 369, in _get_module_from_name 2020-05-06 09:12:40.818104 | primary | __import__(name) 2020-05-06 09:12:40.818122 | primary | File "/opt/stack/new/neutron-dynamic-ro
[Yahoo-eng-team] [Bug 1700501] Re: Insecure rootwrap usage
In Manila, we've discussed migrating off of rootwrap, to privsep - and are yet to find an owner to complete that work. We'll hopefully do that soon. However, I agree this bug is wide open. We'll use a different tracker to call out the tasks to deprecate the usage of rootwrap. ** Changed in: manila Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1700501 Title: Insecure rootwrap usage Status in Cinder: New Status in OpenStack Shared File Systems Service (Manila): Invalid Status in OpenStack Compute (nova): Incomplete Status in OpenStack Security Advisory: Won't Fix Bug description: Reported by Benjamin Deuter of SUSE: Some rootwrap filters are too permissive and allow privilege escalation from service user, as explained here: https://security.openstack.org/guidelines/dg_use-oslo-rootwrap- securely.html#incorrect For example this shouldn't be authorized: sudo nova-rootwrap /etc/nova/rootwrap.conf chmod 777 /etc/shadow To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1700501/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1868033] Re: Booting instance with pci_device fails during rocky->stein live upgrade
Reviewed: https://review.opendev.org/721667
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=d3ca7356860d64555eef6f5138501cb38f50ecc8
Submitter: Zuul
Branch:master
commit d3ca7356860d64555eef6f5138501cb38f50ecc8
Author: Dan Smith
Date: Tue Apr 21 09:07:32 2020 -0700
Remove stale nested backport from InstancePCIRequests
Sometime in 2015, we removed the hard-coded obj_relationships mapping
from parent objects which facilitated semi-automated child version
backports. This was replaced by a manifest-of-versions mechanism
where the client reports all the supported objects and versions
during a backport request to conductor. The InstancePCIRequests object
isn't technically an ObjectListBase, despite acting like one, and thus
wasn't using the obj_relationships. Because of this, it was doing
its own backporting of its child object, which was not removed in
the culling of the static mechanism. Because we now no longer need to
worry about sub-object backport chaining, when version 1.2 was added,
no backport rule was added, and since the object does not call the
base class' generic routine, proper backporting of the child object
was not happening.
All we need to do is remove the override to allow the base
infrastructure to do the work.
Change-Id: Id610a24c066707de5ddc0507e7ef26c421ba366c
Closes-Bug: #1868033
** 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/1868033
Title:
Booting instance with pci_device fails during rocky->stein live
upgrade
Status in OpenStack Compute (nova):
Fix Released
Bug description:
Environment:
Stein nova-conductor having set upgrade_levels to rocky
Rocky nova-compute
Boot an instance with a flavour that has a pci_device
Error:
Failed to publish message to topic 'nova': maximum recursion depth
exceeded: RuntimeError: maximum recursion depth exceeded
Tracked this down it it continually trying to backport the
InstancePCIRequests:
It gets as arguments:
objinst={u'nova_object.version': u'1.1', u'nova_object.name':
u'InstancePCIRequests', u'nova_object.data': {u'instance_uuid':
u'08212b12-8fa8-42d9-8d3e-52ed60a64135', u'requests': [{u'nova_object.version':
u'1.3', u'nova_object.name': u'InstancePCIRequest', u'nova_object.data':
{u'count': 1, u'is_new': False, u'numa_policy': None, u'request_id': None,
u'requester_id': None, u'alias_name': u'V100-32G', u'spec': [{u'vendor_id':
u'10de', u'product_id': u'1db6'}]}, u'nova_object.namespace': u'nova'}]},
u'nova_object.namespace': u'nova'},
object_versions={u'InstancePCIRequests': '1.1', 'InstancePCIRequest':
'1.2'}
It fails because it doesn't backport the individual InstancePCIRequest inside
the InstancePCIRequests object and so keeps trying.
Error it shows is: IncompatibleObjectVersion: Version 1.3 of
InstancePCIRequest is not supported, supported version is 1.2
I have fixed this in our setup by altering obj_make_compatible to
downgrade the individual requests to version 1.2 which seems to work
and all is good
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1868033/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1863021] Re: [SRU] eventlet monkey patch results in assert len(_active) == 1 AssertionError
** Also affects: python-os-ken (Ubuntu) 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/1863021 Title: [SRU] eventlet monkey patch results in assert len(_active) == 1 AssertionError Status in Cinder: Fix Released Status in Designate: In Progress Status in Glance: Fix Released Status in OpenStack Shared File Systems Service (Manila): In Progress Status in masakari: In Progress Status in Mistral: In Progress Status in Murano: Fix Released Status in BaGPipe: In Progress Status in networking-hyperv: In Progress Status in networking-l2gw: In Progress Status in Mellanox backend integration with Neutron (networking-mlnx): In Progress Status in networking-sfc: In Progress Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo.service: Fix Released Status in senlin: In Progress Status in OpenStack Object Storage (swift): In Progress Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in barbican package in Ubuntu: Triaged Status in cinder package in Ubuntu: Fix Released Status in designate package in Ubuntu: Triaged Status in glance package in Ubuntu: Fix Released Status in heat package in Ubuntu: Triaged Status in ironic package in Ubuntu: Triaged Status in ironic-inspector package in Ubuntu: Triaged Status in magnum package in Ubuntu: Triaged Status in manila package in Ubuntu: Triaged Status in masakari package in Ubuntu: Triaged Status in mistral package in Ubuntu: Triaged Status in murano package in Ubuntu: Triaged Status in murano-agent package in Ubuntu: Triaged Status in networking-bagpipe package in Ubuntu: Triaged Status in networking-hyperv package in Ubuntu: Triaged Status in networking-l2gw package in Ubuntu: Triaged Status in networking-mlnx package in Ubuntu: Triaged Status in networking-sfc package in Ubuntu: Triaged Status in neutron package in Ubuntu: Fix Released Status in neutron-dynamic-routing package in Ubuntu: Triaged Status in nova package in Ubuntu: Fix Released Status in openstack-trove package in Ubuntu: Triaged Status in python-os-ken package in Ubuntu: New Status in python-oslo.service package in Ubuntu: Triaged Status in sahara package in Ubuntu: Triaged Status in senlin package in Ubuntu: Triaged Status in swift package in Ubuntu: Triaged Status in watcher package in Ubuntu: New Status in barbican source package in Focal: Triaged Status in cinder source package in Focal: Triaged Status in designate source package in Focal: Triaged Status in glance source package in Focal: Fix Released Status in heat source package in Focal: Triaged Status in ironic source package in Focal: Triaged Status in ironic-inspector source package in Focal: Triaged Status in magnum source package in Focal: Triaged Status in manila source package in Focal: Triaged Status in masakari source package in Focal: Triaged Status in mistral source package in Focal: Triaged Status in murano source package in Focal: Triaged Status in murano-agent source package in Focal: Triaged Status in networking-bagpipe source package in Focal: Triaged Status in networking-hyperv source package in Focal: Triaged Status in networking-l2gw source package in Focal: Triaged Status in networking-mlnx source package in Focal: Triaged Status in networking-sfc source package in Focal: Triaged Status in neutron source package in Focal: Triaged Status in neutron-dynamic-routing source package in Focal: Triaged Status in nova source package in Focal: Fix Released Status in openstack-trove source package in Focal: Triaged Status in python-os-ken source package in Focal: New Status in python-oslo.service source package in Focal: Triaged Status in sahara source package in Focal: Triaged Status in senlin source package in Focal: Triaged Status in swift source package in Focal: Triaged Status in watcher source package in Focal: New Status in barbican source package in Groovy: Triaged Status in cinder source package in Groovy: Fix Released Status in designate source package in Groovy: Triaged Status in glance source package in Groovy: Fix Released Status in heat source package in Groovy: Triaged Status in ironic source package in Groovy: Triaged Status in ironic-inspector source package in Groovy: Triaged Status in magnum source package in Groovy: Triaged Status in manila source package in Groovy: Triaged Status in masakari source package in Groovy: Triaged Status in mistral source package in Groovy: Triaged Status in murano source package in Groovy: Triaged Status in murano-agent source package in Groovy: Triaged Status in networking-bagpipe source package in Groovy: Triaged Status in networking-hyperv source package in Groovy: Triaged Status
[Yahoo-eng-team] [Bug 1871815] Re: neutron port forwarding doesn't work
** Changed in: neutron Status: New => Invalid ** Changed in: neutron Assignee: (unassigned) => Liansen Zhai (zhailiansen) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1871815 Title: neutron port forwarding doesn't work Status in neutron: Invalid Bug description: I found a bug about neutron port forwarding and Detailed operations are as follows: first,create a VPC, 1)openstack address scope create my_project_id 2)openstack network create my_network 3)openstack subnet pool create --address-scope --pool-prefix "10.0.114.0/24" 4)openstack subnet create --network --subnet-pool --subnet-range 10.0.114.0/25 5)openstack router create my_router 6)openstack router set jidd-router1 --external-gateway --enable-snat 7)openstack router add subnet second,create a vm by the network above And,config floating ip port forwarding. for example, external ip and port: 10.142.254.158, 8870; internal port: 10.0.99.29,8870 It can not reach form a external ip to 10.142.254.158 using telnet. Found that, packet is dropped in snat namespace, becase of packet is marked different labels between qg-xxx interface and sg-xxx interface. hit rules: 0 0 DROP all -- * sg-4ddcbea1-c6 0.0.0.0/0 0.0.0.0/0mark match ! 0x400/0x To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1871815/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
