[Yahoo-eng-team] [Bug 1925702] Re: The created virtual machine state is paused
[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.] ** Changed in: nova Status: Incomplete => Expired -- 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/1925702 Title: The created virtual machine state is paused Status in OpenStack Compute (nova): Expired Bug description: openstack version: train controller # openstack server create --flavor m1.nano --image cirros --nic net-id=7611f269-84ab-4759-84db-5b52def82830 --security-group default --key-name mykey selfservice-instance # The log information is too long, I put it in the attachment nova-compute # tail -f /var/log/nova/nova-compute.log nova-compute # virsh list IdName State 2 hg-vm-ceph-mds-55 running （Not managemented by openstack) 3 hg-vm-ceph-mgr-53 running （Not managemented by openstack) 4 hg-vm-ceph-deploy-140 running （Not managemented by openstack) 5 hg-vm-ceph-mon-50 running （Not managemented by openstack) 8 hg-vm-ceph-osd-57 running （Not managemented by openstack) 10hg-vm-openstack-controller-160 running （Not managemented by openstack) 17hg-vm-openstack-common-163 running 19instance-0012 paused To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1925702/+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 1933802] Re: missing global_request_id in neutron_lib context from_dict method
Why is this a bug? I looked in the entire Neutron code.
global_request_id is only used once here:
https://github.com/openstack/neutron/blob/a33588b08639bd4bb78e632eb1fb2600a96aeb44/neutron/notifiers/nova.py#L83.
And it is generated. So how is the absence of global_request_id in the
Neutron context affecting you or your deployment?
** Changed in: neutron
Status: In Progress => Opinion
** Changed in: neutron
Importance: Undecided => Low
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1933802
Title:
missing global_request_id in neutron_lib context from_dict method
Status in neutron:
Opinion
Bug description:
code:
@classmethod
def from_dict(cls, values):
return cls(user_id=values.get('user_id', values.get('user')),
¦ ¦ ¦ tenant_id=values.get('tenant_id', values.get('project_id')),
¦ ¦ ¦ is_admin=values.get('is_admin'),
¦ ¦ ¦ roles=values.get('roles'),
¦ ¦ ¦ timestamp=values.get('timestamp'),
¦ ¦ ¦ request_id=values.get('request_id'),
¦ ¦ ¦ #global_request_id=values.get('global_request_id'),
¦ ¦ ¦ tenant_name=values.get('tenant_name'),
¦ ¦ ¦ user_name=values.get('user_name'),
¦ ¦ ¦ auth_token=values.get('auth_token'))
project: neutron_lib
path: neutron_lib/context.py
please note the comment line, which should have been passed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1933802/+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 1915441] Re: Octavia amphora VMs fail to migrate (scp fails for disk.config file)
I talked with my team and maas should not be responsible for or know that other hosts need to be added to known_hosts. In fact this would probably be a security violation as that means other nodes would have privileges to login that were never meant to have access to each other. Currently nova does the key sharing between nova nodes for VM migration and I think this needs to be fixed in the charm. ** 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/1915441 Title: Octavia amphora VMs fail to migrate (scp fails for disk.config file) Status in OpenStack Compute (nova): New Bug description: Octavia Amphora VM migration fails on newly deployed Octavia install Non amphora VMs seem to migrate with any issues. The relevant error reported from nova-compute is 2021-02-11 18:46:16.194 898529 ERROR nova.compute.manager [instance: e3967a91-3f5d-45b3-9300-28f8ee936fa3] Command: scp -r HostOne.nonprod.maas:/var/lib/nova/instances/e3967a91-3f5d-45b3-9300-28f8ee936fa3/disk.config /var/lib/nova/instances/e3967a91-3f5d-45b3-9300-28f8ee936fa3 2021-02-11 18:46:16.194 898529 ERROR nova.compute.manager [instance: e3967a91-3f5d-45b3-9300-28f8ee936fa3] Exit code: 1 2021-02-11 18:46:16.194 898529 ERROR nova.compute.manager [instance: e3967a91-3f5d-45b3-9300-28f8ee936fa3] Stdout: '' 2021-02-11 18:46:16.194 898529 ERROR nova.compute.manager [instance: e3967a91-3f5d-45b3-9300-28f8ee936fa3] Stderr: 'Host key verification failed.\r\n' Steps to reproduce. One an Openstack Stein cloud with Octavia installed. Simply deploy a load balancer and try and migrate that instance to another node. VERSIONS Used dpkg -l | grep nova ii nova-common 2:19.1.0-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute 2:19.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm 2:19.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt 2:19.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support ii python3-nova 2:19.1.0-0ubuntu1~cloud0 all OpenStack Compute Python 3 libraries ii python3-novaclient2:13.0.0-0ubuntu1~cloud0 all client library for OpenStack Compute API - 3.x Work around I can login to the target machine and do this to get it to work ubuntu@HostTwo:~$ sudo -u nova scp -r HostOne.pnp.maas:/var/lib/nova/instances/7c92fefb-61a7-41e0-a224-eb52a6a24f12/disk.config test.config The authenticity of host 'cmooschstupOne.pnp.maas (10.55.33.148)' can't be established. ECDSA key fingerprint is SHA256:X Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'hostOne.pnp.maas,10.55.33.148' (ECDSA) to the list of known hosts. and now it works fine There is a somewhat unique execution path here. That disk.config is the meta data that would otherwise probably be served to other "regular" vms via the meta data service We do not see that scp action for vms that are not amphora on our cloud, nor do we see that file under /var/lib/nova/instances/INSTANCE for instances other then amphora. Thanks, Steven To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1915441/+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 1933626] Re: CI job testing os-ken master should use OVS backend
Reviewed: https://review.opendev.org/c/openstack/neutron/+/798058 Committed: https://opendev.org/openstack/neutron/commit/b189b0f32284ca5209a9b116953053448ca4a49b Submitter: "Zuul (22348)" Branch:master commit b189b0f32284ca5209a9b116953053448ca4a49b Author: Rodolfo Alonso Hernandez Date: Fri Jun 25 08:40:05 2021 + Use OVS backend for testing os-ken library Only OVS agent uses os-ken library, makes sense that the CI job testing it uses this backend. Closes-Bug: #1933626 Change-Id: I8b2eb11dfae5bc67ee9c3629f609e4b461e0ad7c ** 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/1933626 Title: CI job testing os-ken master should use OVS backend Status in neutron: Fix Released Bug description: CI job testing os-ken master should use OVS backend because so far only the OVS agent uses this library. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1933626/+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 1751923] Re: [SRU]_heal_instance_info_cache periodic task bases on port list from nova db, not from neutron server
Thanks Jorge. Let's patch rocky as well for upgrade purposes. ** Changed in: cloud-archive/rocky Status: Won't Fix => In Progress -- 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/1751923 Title: [SRU]_heal_instance_info_cache periodic task bases on port list from nova db, not from neutron server Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive queens series: In Progress Status in Ubuntu Cloud Archive rocky series: In Progress Status in Ubuntu Cloud Archive stein series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in nova package in Ubuntu: Fix Released Status in nova source package in Bionic: In Progress Status in nova source package in Disco: Fix Released Bug description: [Impact] * During periodic task _heal_instance_info_cache the instance_info_caches are not updated using instance port_ids taken from neutron, but from nova db. * This causes that existing VMs to loose their network interfaces after reboot. [Test Plan] * This bug is reproducible on Bionic/Queens clouds. 1) Deploy the following Juju bundle: https://paste.ubuntu.com/p/HgsqZfsDGh/ 2) Run the following script: https://paste.ubuntu.com/p/c4VDkqyR2z/ 3) If the script finishes with "Port not found" , the bug is still present. [Where problems could occur] Instances created prior to the Openstack Newton release that have more than one interface will not have associated information in the virtual_interfaces table that is required to repopulate the cache with interfaces in the same order they were attached prior. In the unlikely event that this occurs and you are using Openstack release Queen or Rocky, it will be necessary to either manually populate this table. Openstack Stein has a patch that adds support for generating this data. Since as things stand the guest will be unable to identify it's network information at all in the event the cache gets purged and given the hopefully low risk that a vm was created prior to Newton we hope the potential for this regression is very low. -- Description === During periodic task _heal_instance_info_cache the instance_info_caches are not updated using instance port_ids taken from neutron, but from nova db. Sometimes, perhaps because of some race-condition, its possible to lose some ports from instance_info_caches. Periodic task _heal_instance_info_cache should clean this up (add missing records), but in fact it's not working this way. How it looks now? = _heal_instance_info_cache during crontask: https://github.com/openstack/nova/blob/ef4000a0d326deb004843ee51d18030224c5630f/nova/compute/manager.py#L6525 is using network_api to get instance_nw_info (instance_info_caches): try: # Call to network API to get instance info.. this will # force an update to the instance's info_cache self.network_api.get_instance_nw_info(context, instance) self.network_api.get_instance_nw_info() is listed below: https://github.com/openstack/nova/blob/ef4000a0d326deb004843ee51d18030224c5630f/nova/network/neutronv2/api.py#L1377 and it uses _build_network_info_model() without networks and port_ids parameters (because we're not adding any new interface to instance): https://github.com/openstack/nova/blob/ef4000a0d326deb004843ee51d18030224c5630f/nova/network/neutronv2/api.py#L2356 Next: _gather_port_ids_and_networks() generates the list of instance networks and port_ids: networks, port_ids = self._gather_port_ids_and_networks( context, instance, networks, port_ids, client) https://github.com/openstack/nova/blob/ef4000a0d326deb004843ee51d18030224c5630f/nova/network/neutronv2/api.py#L2389-L2390 https://github.com/openstack/nova/blob/ef4000a0d326deb004843ee51d18030224c5630f/nova/network/neutronv2/api.py#L1393 As we see that _gather_port_ids_and_networks() takes the port list from DB: https://github.com/openstack/nova/blob/ef4000a0d326deb004843ee51d18030224c5630f/nova/objects/instance.py#L1173-L1176 And thats it. When we lose a port its not possible to add it again with this periodic task. The only way is to clean device_id field in neutron port object and re-attach the interface using `nova interface-attach`. When the interface is missing and there is no port configured on compute host (for example after compute reboot) - interface is not added to instance and from neutron point of view port state is DOWN. When the interface is missing in cache and we reboot hard the instance - its not added as tapinterface in xml file = we don't have the network on host. Steps to reproduce == 1. Spawn
[Yahoo-eng-team] [Bug 1933360] Re: Test (and enforcement?) for os_hidden mutability on queued images is wrong
Reviewed: https://review.opendev.org/c/openstack/glance/+/797721 Committed: https://opendev.org/openstack/glance/commit/7c1cd438a0a9fe5cababc9ff0164ce7844c98abf Submitter: "Zuul (22348)" Branch:master commit 7c1cd438a0a9fe5cababc9ff0164ce7844c98abf Author: Dan Smith Date: Wed Jun 23 10:08:07 2021 -0700 Fix broken test_update_queued_image_with_hidden This fixes the test to behave the way we expect. It was failing to do the update because it was using an image the requester did not own, and asserting the found behavior of 403. However, the intent here is to allow it to be updated. So, this uses the proper image and asserts the proper behavior. Change-Id: I71afe6a877485c8f92e67dcf32bb475c1a1a42a3 Closes-Bug: #1933360 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1933360 Title: Test (and enforcement?) for os_hidden mutability on queued images is wrong Status in Glance: Fix Released Bug description: The test glance.tests.unit.v2.test_images_resource.TestImagesController.test_update_queued_image_with_hidden seems to be looking to confirm that queued images cannot be marked as hidden. However, if that was the case, it should be checking for BadRequest (or similar) and not Forbidden. Currently it appears that the authorization "everything is immutable if not the owner" layer is what is triggering the Forbidden response. If we want to assert that os_hidden cannot be modified for queued images, we need to do that (as it does not appear to actually be enforced anywhere). In that case, the test needs to be modified to check for the proper return code as well. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1933360/+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 1931735] Re: node failed to deploy because an ephemeral network device was not found
** Changed in: cloud-init
Status: New => Opinion
--
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/1931735
Title:
node failed to deploy because an ephemeral network device was not
found
Status in cloud-init:
Opinion
Status in MAAS:
New
Bug description:
Hi,
Using MAAS snap 2.8.6-8602-g.07cdffcaa.
I just had a node failed to deploy because a network device that was
present during commissioning wasn't present anymore, making cloud-init
sad. To be precise, the node deployed properly, rebooted, and during
the post-deploy boot, cloud-init got sad with :
RuntimeError: Not all expected physical devices present:
{'be:65:46:cb:58:b7'}
(full stacktrace at https://pastebin.canonical.com/p/9Ycxwk5rRy/)
I was indeed able to find the network device with MAC address
'be:65:46:cb:58:b7', and it's an ephemeral NIC that gets created when
someone logs in the HTML5 console (this is a Gigabyte server by the
way). So someone was probably logged on the HTML5 console when the
node was commissioned.
I deleted this ephemeral device from the node in MAAS, and was then
able to deploy it properly.
These ephemeral NICs appear to have random MAC addresses. I was logged
on the HTML5 console during the boot logged above, and you can see
there's a device named "enx5a099ca01d4b" with MAC address
"5a:09:9c:a0:1d:4b" (which doesn't match a known OUI).
This is actually a cdc_ether device :
$ dmesg|grep cdc_ether
[ 29.867170] cdc_ether 1-1.3:2.0 usb0: register 'cdc_ether' at
usb-:06:00.3-1.3, CDC Ethernet Device, 5a:09:9c:a0:1d:4b
[ 29.867296] usbcore: registered new interface driver cdc_ether
[ 29.958137] cdc_ether 1-1.3:2.0 enx5a099ca01d4b: renamed from usb0
[ 205.908811] cdc_ether 1-1.3:2.0 enx5a099ca01d4b: unregister 'cdc_ether'
usb-:06:00.3-1.3, CDC Ethernet Device
(the last time is very probably when I logged off the HTML5 console,
which removes the device).
So I think :
- MAAS should ignore these devices by default
- cloud-init shouldn't die when a cdc_ether device is missing.
Thanks
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1931735/+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 1892361] Re: SRIOV instance gets type-PF interface, libvirt kvm fails
This bug was fixed in the package nova - 2:17.0.13-0ubuntu2~cloud0 --- nova (2:17.0.13-0ubuntu2~cloud0) xenial-queens; urgency=medium . * New update for the Ubuntu Cloud Archive. . nova (2:17.0.13-0ubuntu2) bionic; urgency=medium . * d/control: Update VCS paths for move to lp:~ubuntu-openstack-dev. * d/p/1892361-update-pci-stat-pools.patch: Cherry pick upstream fix for SRIOV instances (LP: #1892361). ** Changed in: cloud-archive/queens Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1892361 Title: SRIOV instance gets type-PF interface, libvirt kvm fails Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Released Status in Ubuntu Cloud Archive rocky series: Fix Released Status in Ubuntu Cloud Archive stein series: Fix Released Status in Ubuntu Cloud Archive train series: Fix Released Status in Ubuntu Cloud Archive ussuri series: Fix Released Status in Ubuntu Cloud Archive victoria series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: New Status in OpenStack Compute (nova) rocky series: New Status in OpenStack Compute (nova) stein series: Fix Committed Status in OpenStack Compute (nova) train series: Fix Released Status in OpenStack Compute (nova) ussuri series: Fix Released Status in OpenStack Compute (nova) victoria series: Fix Released Status in nova package in Ubuntu: Fix Released Status in nova source package in Bionic: Fix Released Status in nova source package in Focal: Fix Released Status in nova source package in Groovy: Fix Released Status in nova source package in Hirsute: Fix Released Bug description: When spawning an SR-IOV enabled instance on a newly deployed host, nova attempts to spawn it with an type-PF pci device. This fails with the below stack trace. After restarting neutron-sriov-agent and nova-compute services on the compute node and spawning an SR-IOV instance again, a type-VF pci device is selected, and instance spawning succeeds. Stack trace: 2020-08-20 08:29:09.558 7624 DEBUG oslo_messaging._drivers.amqpdriver [-] received reply msg_id: 6db8011e6ecd4fd0aaa53c8f89f08b1b __call__ /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:400 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [req-e3e49d07-24c6-4c62-916e-f830f70983a2 ddcfb3640535428798aa3c8545362bd4 dd99e7950a5b46b5b924ccd1720b6257 - 015e4fd7db304665ab5378caa691bb8b 015e4fd7db304665ab5378caa691bb8b] [insta nce: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Instance failed to spawn: libvirtError: unsupported configuration: Interface type hostdev is currently supported on SR-IOV Virtual Functions only 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Traceback (most recent call last): 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2274, in _build_resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] yield resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2054, in _build_and_run_instance 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] block_device_info=block_device_info) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3147, in spawn 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure=True) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5651, in _create_domain_and_network 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] self.force_reraise() 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in
[Yahoo-eng-team] [Bug 1892361] Re: SRIOV instance gets type-PF interface, libvirt kvm fails
This bug was fixed in the package nova - 2:18.3.0-0ubuntu1~cloud2 --- nova (2:18.3.0-0ubuntu1~cloud2) bionic-rocky; urgency=medium . * d/control: Update VCS paths for move to lp:~ubuntu-openstack-dev. * d/p/1892361-update-pci-stat-pools.patch: Cherry pick upstream fix for SRIOV instances (LP: #1892361). ** Changed in: cloud-archive/rocky Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1892361 Title: SRIOV instance gets type-PF interface, libvirt kvm fails Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Released Status in Ubuntu Cloud Archive rocky series: Fix Released Status in Ubuntu Cloud Archive stein series: Fix Released Status in Ubuntu Cloud Archive train series: Fix Released Status in Ubuntu Cloud Archive ussuri series: Fix Released Status in Ubuntu Cloud Archive victoria series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: New Status in OpenStack Compute (nova) rocky series: New Status in OpenStack Compute (nova) stein series: Fix Committed Status in OpenStack Compute (nova) train series: Fix Released Status in OpenStack Compute (nova) ussuri series: Fix Released Status in OpenStack Compute (nova) victoria series: Fix Released Status in nova package in Ubuntu: Fix Released Status in nova source package in Bionic: Fix Released Status in nova source package in Focal: Fix Released Status in nova source package in Groovy: Fix Released Status in nova source package in Hirsute: Fix Released Bug description: When spawning an SR-IOV enabled instance on a newly deployed host, nova attempts to spawn it with an type-PF pci device. This fails with the below stack trace. After restarting neutron-sriov-agent and nova-compute services on the compute node and spawning an SR-IOV instance again, a type-VF pci device is selected, and instance spawning succeeds. Stack trace: 2020-08-20 08:29:09.558 7624 DEBUG oslo_messaging._drivers.amqpdriver [-] received reply msg_id: 6db8011e6ecd4fd0aaa53c8f89f08b1b __call__ /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:400 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [req-e3e49d07-24c6-4c62-916e-f830f70983a2 ddcfb3640535428798aa3c8545362bd4 dd99e7950a5b46b5b924ccd1720b6257 - 015e4fd7db304665ab5378caa691bb8b 015e4fd7db304665ab5378caa691bb8b] [insta nce: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Instance failed to spawn: libvirtError: unsupported configuration: Interface type hostdev is currently supported on SR-IOV Virtual Functions only 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Traceback (most recent call last): 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2274, in _build_resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] yield resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2054, in _build_and_run_instance 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] block_device_info=block_device_info) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3147, in spawn 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure=True) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5651, in _create_domain_and_network 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] self.force_reraise() 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance:
[Yahoo-eng-team] [Bug 1892361] Re: SRIOV instance gets type-PF interface, libvirt kvm fails
This bug was fixed in the package nova - 2:19.3.2-0ubuntu1~cloud1 --- nova (2:19.3.2-0ubuntu1~cloud1) bionic-stein; urgency=medium . [ Hemanth Nakkina ] * d/p/0001-Update-pci-stat-pools-based-on-PCI-device-changes.patch: Update pci stats pools based on PCI device changes (LP: #1892361). ** Changed in: cloud-archive/stein Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1892361 Title: SRIOV instance gets type-PF interface, libvirt kvm fails Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Released Status in Ubuntu Cloud Archive rocky series: Fix Released Status in Ubuntu Cloud Archive stein series: Fix Released Status in Ubuntu Cloud Archive train series: Fix Released Status in Ubuntu Cloud Archive ussuri series: Fix Released Status in Ubuntu Cloud Archive victoria series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: New Status in OpenStack Compute (nova) rocky series: New Status in OpenStack Compute (nova) stein series: Fix Committed Status in OpenStack Compute (nova) train series: Fix Released Status in OpenStack Compute (nova) ussuri series: Fix Released Status in OpenStack Compute (nova) victoria series: Fix Released Status in nova package in Ubuntu: Fix Released Status in nova source package in Bionic: Fix Released Status in nova source package in Focal: Fix Released Status in nova source package in Groovy: Fix Released Status in nova source package in Hirsute: Fix Released Bug description: When spawning an SR-IOV enabled instance on a newly deployed host, nova attempts to spawn it with an type-PF pci device. This fails with the below stack trace. After restarting neutron-sriov-agent and nova-compute services on the compute node and spawning an SR-IOV instance again, a type-VF pci device is selected, and instance spawning succeeds. Stack trace: 2020-08-20 08:29:09.558 7624 DEBUG oslo_messaging._drivers.amqpdriver [-] received reply msg_id: 6db8011e6ecd4fd0aaa53c8f89f08b1b __call__ /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:400 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [req-e3e49d07-24c6-4c62-916e-f830f70983a2 ddcfb3640535428798aa3c8545362bd4 dd99e7950a5b46b5b924ccd1720b6257 - 015e4fd7db304665ab5378caa691bb8b 015e4fd7db304665ab5378caa691bb8b] [insta nce: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Instance failed to spawn: libvirtError: unsupported configuration: Interface type hostdev is currently supported on SR-IOV Virtual Functions only 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Traceback (most recent call last): 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2274, in _build_resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] yield resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2054, in _build_and_run_instance 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] block_device_info=block_device_info) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3147, in spawn 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure=True) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5651, in _create_domain_and_network 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] self.force_reraise() 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11]
[Yahoo-eng-team] [Bug 1933813] [NEW] OSError: Premature eof waiting for privileged process error in Ussuri release of Neutron
Public bug reported: After updating Neutron from Queens to Ussuri we started getting the errors "OSError: Premature eof waiting for privileged process" for all of neutron agents and for different operations (create network, enable/disable dhcp etc.). All errors raises inside librari oslo.privsep which was updated from version 1.27.0 to 2.1.2 [1]. This problem is floating and very difficult to debug, it is impossible to understand what exactly is happening. The problem is consistently reproduced by tempest tests in our infrastructure. Environment: Neutron Ussuri, ML2 plugin + linux-bridge + custom agent HPB. The examples of tracebacks: OSError: Premature eof waiting for privileged process File "neutron/plugins/ml2/drivers/agent/_common_agent.py", line 465, in daemon_loop sync = self.process_network_devices(device_info) File "osprofiler/profiler.py", line 160, in wrapper result = f(*args, **kwargs) File "neutron/plugins/ml2/drivers/agent/_common_agent.py", line 214, in process_network_devices resync_a = self.treat_devices_added_updated(devices_added_updated) File "osprofiler/profiler.py", line 160, in wrapper result = f(*args, **kwargs) File "neutron/plugins/ml2/drivers/agent/_common_agent.py", line 231, in treat_devices_added_updated self._process_device_if_exists(device_details) File "neutron/plugins/ml2/drivers/agent/_common_agent.py", line 258, in _process_device_if_exists device, device_details['device_owner']) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 594, in plug_interface network_segment.mtu) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 530, in add_tap_interface return False File "oslo_utils/excutils.py", line 220, in __exit__ self.force_reraise() File "oslo_utils/excutils.py", line 196, in force_reraise six.reraise(self.type_, self.value, self.tb) File "site-packages/six.py", line 702, in reraise raise value.with_traceback(tb) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 522, in add_tap_interface tap_device_name, device_owner, mtu) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 555, in _add_tap_interface mtu): File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 510, in ensure_physical_in_bridge segmentation_id) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 256, in ensure_vlan_bridge if self.ensure_bridge(bridge_name, interface): File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 458, in ensure_bridge self.update_interface_ip_details(bridge_name, interface) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 417, in update_interface_ip_details ips, gateway = self.get_interface_details(source, ip_version) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 274, in get_interface_details ip_version=ip_version) File "neutron/agent/linux/ip_lib.py", line 560, in list **kwargs) File "neutron/agent/linux/ip_lib.py", line 1367, in get_devices_with_ip devices = privileged.get_link_devices(namespace, **link_args) File "oslo_privsep/priv_context.py", line 247, in _wrap return self.channel.remote_call(name, args, kwargs) File "oslo_privsep/daemon.py", line 214, in remote_call result = self.send_recv((Message.CALL.value, name, args, kwargs)) File "oslo_privsep/comm.py", line 172, in send_recv reply = future.result() File "oslo_privsep/comm.py", line 111, in result raise self.error OSError: Premature eof waiting for privileged process File "oslo_messaging/rpc/server.py", line 165, in _process_incoming res = self.dispatcher.dispatch(message) File "oslo_messaging/rpc/dispatcher.py", line 276, in dispatch return self._do_dispatch(endpoint, method, ctxt, args) File "oslo_messaging/rpc/dispatcher.py", line 196, in _do_dispatch result = func(ctxt, **new_args) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 912, in network_delete self.agent.mgr.delete_bridge(bridge_name) File "neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 598, in delete_bridge if bridge_device.exists(): File "neutron/agent/linux/ip_lib.py", line 328, in exists return privileged.interface_exists(self.name, self.namespace) File "oslo_privsep/priv_context.py", line 247, in _wrap return self.channel.remote_call(name, args, kwargs) File "oslo_privsep/daemon.py", line 214, in remote_call result = self.send_recv((Message.CALL.value, name, args, kwargs)) File "oslo_privsep/comm.py", line 172, in send_recv reply = future.result() File "oslo_privsep/comm.py", line 111, in result raise self.error File
[Yahoo-eng-team] [Bug 1921381] Re: iSCSI: Flushing issues when multipath config has changed
** No longer affects: nova -- 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/1921381 Title: iSCSI: Flushing issues when multipath config has changed Status in OpenStack Compute (nova) wallaby series: Fix Released Status in OpenStack Compute (nova) xena series: Fix Released Status in os-brick: Fix Committed Status in os-brick queens series: Triaged Status in os-brick rocky series: Triaged Status in os-brick stein series: In Progress Status in os-brick train series: Fix Committed Status in os-brick ussuri series: In Progress Status in os-brick victoria series: Fix Committed Status in os-brick wallaby series: Fix Released Status in os-brick xena series: Fix Committed Bug description: OS-Brick disconnect_volume code assumes that the use_multipath parameter that is used to instantiate the connector has the same value than the connector that was used on the original connect_volume call. Unfortunately this is not necessarily true, because Nova can attach a volume, then its multipath configuration can be enabled or disabled, and then a detach can be issued. This leads to a series of serious issues such as: - Not flushing the single path on disconnect_volume (possible data loss) and leaving it as a leftover device on the host when Nova calls terminate-connection on Cinder. - Not flushing the multipath device (possible data loss) and leaving it as a lefover device similarly to the other case. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/wallaby/+bug/1921381/+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 1933096] Re: nova fail to start because of 'libvirt' has no attribute 'VIR_CONNECT_LIST_NODE_DEVICES_CAP_VDPA'
Moving to valid as we are now seeing this in our own upstream CI: https://zuul.opendev.org/t/openstack/build/68e59744ef7444a5ae108118983c9353/log /job-output.txt 2021-06-27 04:37:51.638267 | controller | Collecting libvirt-python===7.4.0 2021-06-27 04:37:51.647585 | controller | Downloading https://mirror.mtl01.inap.opendev.org/wheel/centos-8-x86_64/libvirt-python/libvirt_python-7.4.0-cp36-cp36m-linux_x86_64.whl (554 kB) 2021-06-27 04:37:53.675754 | controller | Installing collected packages: libvirt-python 2021-06-27 04:37:53.831073 | controller | Successfully installed libvirt-python-7.4.0 https://zuul.opendev.org/t/openstack/build/68e59744ef7444a5ae108118983c9353/log/controller/logs/screen-n-cpu.txt#1525 Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager [None req-d06862c3-c4b9-4f25-b7e7-e8a4bc48a71e None None] Error updating resources for node centos-8-stream-inap-mtl01-0025287196.: AttributeError: module 'libvirt' has no attribute 'VIR_CONNECT_LIST_NODE_DEVICES_CAP_VDPA' Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager Traceback (most recent call last): Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager File "/opt/stack/nova/nova/compute/manager.py", line 9939, in _update_available_resource_for_node Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager startup=startup) Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 879, in update_available_resource Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager resources = self.driver.get_available_resource(nodename) Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 8922, in get_available_resource Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager data['pci_passthrough_devices'] = self._get_pci_passthrough_devices() Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7641, in _get_pci_passthrough_devices Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager dev_flags |= libvirt.VIR_CONNECT_LIST_NODE_DEVICES_CAP_VDPA Jun 27 05:03:22.685506 centos-8-stream-inap-mtl01-0025287196 nova-compute[112332]: ERROR nova.compute.manager AttributeError: module 'libvirt' has no attribute 'VIR_CONNECT_LIST_NODE_DEVICES_CAP_VDPA' ** Changed in: nova Status: Invalid => 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/1933096 Title: nova fail to start because of 'libvirt' has no attribute 'VIR_CONNECT_LIST_NODE_DEVICES_CAP_VDPA' Status in OpenStack Compute (nova): Confirmed Bug description: Since june 11, CI on centos stream started to fail because of error: AttributeError: module 'libvirt' has no attribute 'VIR_CONNECT_LIST_NODE_DEVICES_CAP_VDPA' By comparing the environment with the last successful build of the CI, it seems the difference is the distro libvirt version. The CI started to fail since libvirt-7.0.0-14.1.el8.x86_64 was installed on the centos stream setup. Logs to the failed build can be found at [1] Logs to the last successful built can be found at [2] [1] http://13.74.249.42/550/OpenVswitch-HW-Offload-os-vif-Daily/ [2] http://13.74.249.42/549/OpenVswitch-HW-Offload-os-vif-Daily/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1933096/+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 1890432] Re: Create subnet is failing under high load with OVN
Given that the three point releases mentioned are now included in Ubuntu
/ the Cloud Archive, I'm marking this fix-released for all affected
targets.
Focal-updates: 2:16.3.2
Groovy-updates: 2:17.1.1
Hirsute: 2:18.0.0
** Changed in: neutron (Ubuntu Focal)
Status: Triaged => Fix Released
** Changed in: neutron (Ubuntu Groovy)
Status: Triaged => 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/1890432
Title:
Create subnet is failing under high load with OVN
Status in neutron:
Fix Committed
Status in neutron package in Ubuntu:
Fix Released
Status in neutron source package in Focal:
Fix Released
Status in neutron source package in Groovy:
Fix Released
Bug description:
Under a high concurrency level create subnet is starting to fail.
(12-14% failure rate) The bundle is OVN / Ussuri.
neutronclient.common.exceptions.Conflict: Unable to complete operation
on subnet This subnet is being modified by another concurrent
operation.
Stacktrace: https://pastebin.ubuntu.com/p/sQ5CqD6NyS/
Rally task:
{% set flavor_name = flavor_name or "m1.medium" %}
{% set image_name = image_name or "bionic-kvm" %}
---
NeutronNetworks.create_and_delete_subnets:
-
args:
network_create_args: {}
subnet_create_args: {}
subnet_cidr_start: "1.1.0.0/30"
subnets_per_network: 2
runner:
type: "constant"
times: 100
concurrency: 10
context:
network: {}
users:
tenants: 30
users_per_tenant: 1
quotas:
neutron:
network: -1
subnet: -1
Concurrency level set to 1 instead of 10 is not triggering the issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1890432/+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 1933802] [NEW] missing global_request_id in neutron_lib context from_dict method
Public bug reported:
code:
@classmethod
def from_dict(cls, values):
return cls(user_id=values.get('user_id', values.get('user')),
¦ ¦ ¦ tenant_id=values.get('tenant_id', values.get('project_id')),
¦ ¦ ¦ is_admin=values.get('is_admin'),
¦ ¦ ¦ roles=values.get('roles'),
¦ ¦ ¦ timestamp=values.get('timestamp'),
¦ ¦ ¦ request_id=values.get('request_id'),
¦ ¦ ¦ #global_request_id=values.get('global_request_id'),
¦ ¦ ¦ tenant_name=values.get('tenant_name'),
¦ ¦ ¦ user_name=values.get('user_name'),
¦ ¦ ¦ auth_token=values.get('auth_token'))
project: neutron_lib
path: neutron_lib/context.py
please note the comment line, which should have been passed.
** 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/1933802
Title:
missing global_request_id in neutron_lib context from_dict method
Status in neutron:
New
Bug description:
code:
@classmethod
def from_dict(cls, values):
return cls(user_id=values.get('user_id', values.get('user')),
¦ ¦ ¦ tenant_id=values.get('tenant_id', values.get('project_id')),
¦ ¦ ¦ is_admin=values.get('is_admin'),
¦ ¦ ¦ roles=values.get('roles'),
¦ ¦ ¦ timestamp=values.get('timestamp'),
¦ ¦ ¦ request_id=values.get('request_id'),
¦ ¦ ¦ #global_request_id=values.get('global_request_id'),
¦ ¦ ¦ tenant_name=values.get('tenant_name'),
¦ ¦ ¦ user_name=values.get('user_name'),
¦ ¦ ¦ auth_token=values.get('auth_token'))
project: neutron_lib
path: neutron_lib/context.py
please note the comment line, which should have been passed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1933802/+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
