[Yahoo-eng-team] [Bug 2049398] [NEW] [Tempest] neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net "Created
Public bug reported:
Hi,
We got BadRequest error in the following test. I think, net =
self._create_network(external=False) should be change net =
self._create_network(external=True). Can you check this test?
Test:
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net
Error:
==
Failed 1 tests - output below:
==
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net[id-d54decee-4203-4ced-91a2-ea42ca63e154]
Captured traceback:
~~~
Traceback (most recent call last):
File
"/etc/tempest/neutron-tempest-plugin/neutron_tempest_plugin/api/admin/test_external_network_extension.py",
line 231, in test_delete_policies_while_tenant_attached_to_net
self.client2.create_router(
File
"/etc/tempest/neutron-tempest-plugin/neutron_tempest_plugin/services/network/json/network_client.py",
line 365, in create_router
resp, body = self.post(uri, body)
File
"/opt/venv/tempest/lib/python3.8/site-packages/tempest/lib/common/rest_client.py",
line 300, in post
return self.request('POST', url, extra_headers, headers, body, chunked)
File
"/opt/venv/tempest/lib/python3.8/site-packages/tempest/lib/common/rest_client.py",
line 742, in request
self._error_checker(resp, resp_body)
File
"/opt/venv/tempest/lib/python3.8/site-packages/tempest/lib/common/rest_client.py",
line 857, in _error_checker
raise exceptions.BadRequest(resp_body, resp=resp)
tempest.lib.exceptions.BadRequest: Bad request
Details: {'type': 'BadRequest', 'message': 'Bad router request: Network
4ee07f67-3595-4061-9f5f-f516a7eae9e6 is not an external network.', 'detail': ''}
File:
https://github.com/openstack/neutron-tempest-plugin/blob/master/neutron_tempest_plugin/api/admin/test_external_network_extension.py
Line: 195
Openstack version: Zed
I have used admin role user in all tempest tests.
Regards,
** Affects: neutron
Importance: Undecided
Status: New
** Tags: external network neutron openstack plugin tempest test
** Summary changed:
- [Tempest]
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net
Created Network is Not an External Network
+ [Tempest]
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net
"Created Network is Not an External Network" Error
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2049398
Title:
[Tempest]
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net
"Created Network is Not an External Network" Error
Status in neutron:
New
Bug description:
Hi,
We got BadRequest error in the following test. I think, net =
self._create_network(external=False) should be change net =
self._create_network(external=True). Can you check this test?
Test:
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net
Error:
==
Failed 1 tests - output below:
==
neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON.test_delete_policies_while_tenant_attached_to_net[id-d54decee-4203-4ced-91a2-ea42ca63e154]
Captured traceback:
~~~
Traceback (most recent call last):
File
"/etc/tempest/neutron-tempest-plugin/neutron_tempest_plugin/api/admin/test_external_network_extension.py",
line 231, in test_delete_policies_while_tenant_attached_to_net
self.client2.create_router(
File
"/etc/tempest/neutron-tempest-plugin/neutron_tempest_plugin/services/network/json/network_client.py",
line 365, in create_router
resp, body = self.post(uri, body)
File
"/opt/venv/tempest/lib/python3.8/site-packages/tempest/lib/common/rest_client.py",
line 300, in post
return self.request('POST', url, extra_headers, headers, body, chunked)
File
"/opt/venv/tempest/lib/python3.8/site-packages/tempest/lib/common/rest_client.py",
line 742, in request
self._error_checker(resp, resp_body)
File
"/opt/venv/tempest
[Yahoo-eng-team] [Bug 2049121] Re: Boot one VM with two GPU(in same numa)by pci passthrough cannot have GPUDirect P2P capability
Please reopen the bug report by changing the status back to new if you think it's related to Nova. ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2049121 Title: Boot one VM with two GPU(in same numa)by pci passthrough cannot have GPUDirect P2P capability Status in OpenStack Compute (nova): Invalid Bug description: Hi, I have two GPU cards, all of them was connect with one same numa CPU socket as below link info: https://paste.opendev.org/show/b7Qi8qCnbLVxO2W0JdQw/ I can boot one nova instance successfully with the two GPU cards by PCI Passthrough way. but in the booted instances, use deviceQuery method would get the below message: Peer access from NVIDIA RTX 6000(GPU0) -> NVIDIA RTX 6000(GPU1): NO Peer access from NVIDIA RTX 6000(GPU1) -> NVIDIA RTX 6000(GPU0): NO The expected return should be as below： Peer access from NVIDIA RTX 6000(GPU0) -> NVIDIA RTX 6000(GPU1): YES Peer access from NVIDIA RTX 6000(GPU1) -> NVIDIA RTX 6000(GPU0): YES so that the memory can be shared between the two GPUs. I'm running Openstack Xena release in Intel Xeon Gold 5220R CPU To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2049121/+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 2036423] Re: subnet's gateway ip can be unset while attached to router
Reviewed: https://review.opendev.org/c/openstack/neutron/+/904713
Committed:
https://opendev.org/openstack/neutron/commit/f9e40971e94e4fd239fcf7537b0f1200fbd4ee0f
Submitter: "Zuul (22348)"
Branch:master
commit f9e40971e94e4fd239fcf7537b0f1200fbd4ee0f
Author: Rodolfo Alonso Hernandez
Date: Sun Jan 14 10:20:12 2024 +
Forbid the subnet gateway IP deletion if a router interface is attached
When a router interface is created, the corresponding subnet gateway IP
is tested first [1]. If the subnet has no gateway IP, the router
interface cannot be created. This IP will be assigned to this port.
The Neutron API also prevents from modifying the subnet gateway IP
if assigned to a router interface [2]. However the API is not
preventing the subnet gateway IP deletion. This patch is adding
this check.
This patch is being tested in the neutron-tempest-plugin [3].
[1]https://github.com/openstack/neutron/blob/de58c1b99523104a471420ef0468147f13c9e98d/neutron/db/l3_db.py#L902-L904
[2]https://github.com/openstack/neutron/blob/de58c1b99523104a471420ef0468147f13c9e98d/neutron/db/db_base_plugin_v2.py#L715
[3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904710
Closes-Bug: #2036423
Change-Id: I4c7b399a3a052749abdb88fb50be628ee91b63a0
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2036423
Title:
subnet's gateway ip can be unset while attached to router
Status in neutron:
Fix Released
Bug description:
Hello
There's a weird issue with a subnet's gateway ip when it's attached to
a router.
Normally, when you try to attach a subnet to a router, this subnet
needs to have a gateway ip set. Otherwise the attachment will fail.
So we expect the subnet attached to a router to always have a gateway
ip - this is used for creating the router interface after all.
However, when you attach a subnet with a gateway ip to a router and
then attempt to unset this gateway ip... you can do that. There's no
error, there's no connectivity lost, nothing is deleted. The router
interface is still listed under "router show", the port exists, the
connectivity is still working fine, as if nothing happened. But when
you "subnet show", you can see the gateway ip is None.
This will result in error logs whenever the code tries to process
certain things related to the router. Restarting the L3 agent will
result in these errors, for example.
file: neutron/db/dvr_mac_db.py
method: get_subnet_for_dvr()
LOG.error("Could not retrieve gateway port "
"for subnet %s", subnet_info)
file: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py
method: _bind_centralized_snat_port_on_dvr_subnet()
LOG.warning("DVR: Unable to retrieve subnet information "
"for subnet_id %s. The subnet or the gateway "
"may have already been deleted", subnet_uuid)
A user shouldn't be allowed to unset the gateway ip from a subnet
that's already attached to a router. If they can't add a gateway-less
subnet to a router, they shouldn't be allowed to unset it after the
fact as well.
Tested on Stein and quickly checked if the behaviour still exists on
Master.
To reproduce:
- Create a router
openstack router create r1
- Create a network with a subnet with gateway ip set (default behaviour)
openstack network create n1
openstack subnet create --subnet-range --network n1 s1
- Add subnet to the router
openstack router add subnet r1 s1
- Unset the gateway ip from the subnet
openstack subnet set --gateway None s1
The gateway ip on the subnet will be listed as None, the router will
still have the interface existing, the port will stil exist, all
connectivity will remain intact, certain actions and agent restarts
will trigger error logs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2036423/+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 2049121] Re: Boot one VM with two GPU(in same numa)by pci passthrough cannot have GPUDirect P2P capability
yes, I think it's related to Nova, reopen this bug, thanks ** Changed in: nova Status: Invalid => 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/2049121 Title: Boot one VM with two GPU(in same numa)by pci passthrough cannot have GPUDirect P2P capability Status in OpenStack Compute (nova): New Bug description: Hi, I have two GPU cards, all of them was connect with one same numa CPU socket as below link info: https://paste.opendev.org/show/b7Qi8qCnbLVxO2W0JdQw/ I can boot one nova instance successfully with the two GPU cards by PCI Passthrough way. but in the booted instances, use deviceQuery method would get the below message: Peer access from NVIDIA RTX 6000(GPU0) -> NVIDIA RTX 6000(GPU1): NO Peer access from NVIDIA RTX 6000(GPU1) -> NVIDIA RTX 6000(GPU0): NO The expected return should be as below： Peer access from NVIDIA RTX 6000(GPU0) -> NVIDIA RTX 6000(GPU1): YES Peer access from NVIDIA RTX 6000(GPU1) -> NVIDIA RTX 6000(GPU0): YES so that the memory can be shared between the two GPUs. I'm running Openstack Xena release in Intel Xeon Gold 5220R CPU To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2049121/+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 2049444] [NEW] mintupdate newest kernel in /boot/vmlinuz-6.5.0-14-generic wont' boot
Public bug reported: I booted a new kernel from /@/boot/vmlinuz-6.5.0-14-generic in grub.cfg: see below for what took 30 secs to cycle from: [1] ata1.00: configured for UDMA/133 snip [31] ata1.00: configured for UDMA/100 snip [61] ata1.00: configured for UDMA/66 snip [91] ata1.00: configured for PIO4 DOWN to PIO0. THEN I POWERED OFF Then in grub I chose 6.2.0-37-generic recovery (2nd choice): this is a successful boot by using a older kernel. My dmesg reads info about a boot that measures sda3 speed: [1.754905] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [1.758397] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out [1.758491] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out [1.758816] ata1.00: ACPI cmd 00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04) [1.761007] ata1.00: ATA-8: WDC WD3200BEKT-75PVMT0, 01.01A01, max UDMA/133 [1.762103] ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 32), AA [1.765817] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out [1.765908] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out [1.766265] ata1.00: ACPI cmd 00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04) [1.768698] ata1.00: configured for UDMA/133 ** Affects: nova Importance: Undecided Status: New ** Tags: 6.5.0-14-generic kernel mint21.3 ** Attachment added: "my dmesg" https://bugs.launchpad.net/bugs/2049444/+attachment/5739740/+files/dmesg.txt -- 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/2049444 Title: mintupdate newest kernel in /boot/vmlinuz-6.5.0-14-generic wont' boot Status in OpenStack Compute (nova): New Bug description: I booted a new kernel from /@/boot/vmlinuz-6.5.0-14-generic in grub.cfg: see below for what took 30 secs to cycle from: [1] ata1.00: configured for UDMA/133 snip [31] ata1.00: configured for UDMA/100 snip [61] ata1.00: configured for UDMA/66 snip [91] ata1.00: configured for PIO4 DOWN to PIO0. THEN I POWERED OFF Then in grub I chose 6.2.0-37-generic recovery (2nd choice): this is a successful boot by using a older kernel. My dmesg reads info about a boot that measures sda3 speed: [1.754905] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [1.758397] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out [1.758491] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out [1.758816] ata1.00: ACPI cmd 00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04) [1.761007] ata1.00: ATA-8: WDC WD3200BEKT-75PVMT0, 01.01A01, max UDMA/133 [1.762103] ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 32), AA [1.765817] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out [1.765908] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out [1.766265] ata1.00: ACPI cmd 00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04) [1.768698] ata1.00: configured for UDMA/133 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2049444/+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 2049444] Re: mintupdate newest kernel in /boot/vmlinuz-6.5.0-14-generic wont' boot
** Project changed: nova => ubuntu -- 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/2049444 Title: mintupdate newest kernel in /boot/vmlinuz-6.5.0-14-generic wont' boot Status in Ubuntu: New Bug description: I booted a new kernel from /@/boot/vmlinuz-6.5.0-14-generic in grub.cfg: see below for what took 30 secs to cycle from: [1] ata1.00: configured for UDMA/133 snip [31] ata1.00: configured for UDMA/100 snip [61] ata1.00: configured for UDMA/66 snip [91] ata1.00: configured for PIO4 DOWN to PIO0. THEN I POWERED OFF Then in grub I chose 6.2.0-37-generic recovery (2nd choice): this is a successful boot by using a older kernel. My dmesg reads info about a boot that measures sda3 speed: [1.754905] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [1.758397] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out [1.758491] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out [1.758816] ata1.00: ACPI cmd 00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04) [1.761007] ata1.00: ATA-8: WDC WD3200BEKT-75PVMT0, 01.01A01, max UDMA/133 [1.762103] ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 32), AA [1.765817] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out [1.765908] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out [1.766265] ata1.00: ACPI cmd 00/00:00:00:00:00:a0(NOP) rejected by device (Stat=0x51 Err=0x04) [1.768698] ata1.00: configured for UDMA/133 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2049444/+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
