[Yahoo-eng-team] [Bug 2054797] [NEW] Unshelve can cause quota over-consumption
Public bug reported: Description === Unshelving a VM can cause an over consumption of a project's quota. I'm not sure if this is a bug or if it's actually intended behaviour, but in my opinion this should not be possible since this will allow users to potentially use a lot more resources than their intended quota. Steps to reproduce == * Create a project with a quota of i.e. 4 CPUs and 4GB of RAM * Create server1 with 2 CPUs and 2GB RAM, and shelve it after it successfully spawns * When server1 in shelved, create server2 with 4 CPUs and 4GB of RAM (effectively using up the entire CPU and RAM quota of the project) * Unshelve server1 Expected result === I would then expect that unshelving server1 would fail, since the quota was used up by server2 Actual result = Unshelving server1 is completed, and I have now used 6 of 4 CPUs and 6 of 4GB RAM on my project's quota. FWIW this also works if at the time of unshelving the quota is already used up. Environment === Openstack Yoga nova-api 3:25.1.1-0ubuntu1~cloud0 nova-scheduler 3:25.1.1-0ubuntu1~cloud0 Running KVM/libvirt on Ubuntu 20.04 and Ceph 17.x ** 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/2054797 Title: Unshelve can cause quota over-consumption Status in OpenStack Compute (nova): New Bug description: Description === Unshelving a VM can cause an over consumption of a project's quota. I'm not sure if this is a bug or if it's actually intended behaviour, but in my opinion this should not be possible since this will allow users to potentially use a lot more resources than their intended quota. Steps to reproduce == * Create a project with a quota of i.e. 4 CPUs and 4GB of RAM * Create server1 with 2 CPUs and 2GB RAM, and shelve it after it successfully spawns * When server1 in shelved, create server2 with 4 CPUs and 4GB of RAM (effectively using up the entire CPU and RAM quota of the project) * Unshelve server1 Expected result === I would then expect that unshelving server1 would fail, since the quota was used up by server2 Actual result = Unshelving server1 is completed, and I have now used 6 of 4 CPUs and 6 of 4GB RAM on my project's quota. FWIW this also works if at the time of unshelving the quota is already used up. Environment === Openstack Yoga nova-api 3:25.1.1-0ubuntu1~cloud0 nova-scheduler 3:25.1.1-0ubuntu1~cloud0 Running KVM/libvirt on Ubuntu 20.04 and Ceph 17.x To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2054797/+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 1927691] [NEW] Port forwading does only work between VMs in the same neutron network
Public bug reported: First of all, I'm not really sure if this is a bug, or some sort of configuration error on our side.. But I'm having issues with the port forwarding in neutron. Openstack ussuri, running on Bionic neutron-l3-agent2:16.2.0-0ubuntu1~cloud0 openvswitch-switch 2.13.1-0ubuntu0.20.04.1~cloud0 My scenario: - Create two networks (net1 and net2), and attach a router to each of them - Create two VMs in net1, one in net2 - Attach a "plain" FIP to VM-1 and VM-3 - Create a FIP for the port forwarding, and create a port forwarding rule pointing to VM-2 (i.e map FIP:80 to VM-2:8000) - Login to VM-2 and start listening to tcp 8000 with "python3 -m http.server 8000" What I expect: curl http://FIP:80 should give a response from VM-2:8000 from both VM-1, VM-3 and externally What happens: The port forwarding only works for VM-1. In other words, only between VMs in the same neutron network. -- I've done some debugging with tcpdump on my network nodes within the netns of the qrouter. When I try to connect from either VM-3 or externally, I observe the packets arriving on the qrouter's external interface and they get dropped "somewhere". I've failed to understand/discover where and/or by what. In the dumps, we have the following IP addresses. All FIPs are in 10.212.136.0/21: VM-1 (net1): 192.168.0.92(FIP: 10.212.143.126) VM-2 (net1): 192.168.0.35(No FIP, but port forwarding rule on 10.212.141.76 80->8000) VM-3 (net2): 192.168.111.213 (FIP: 10.212.138.184) Router of net1: 192.168.0.1 / 10.212.140.143 Iptables for the qrouter that hosts the FIP with port forwarding: http://paste.openstack.org/show/805020/ tcpdump on the qrouter interal interface when doing "curl http://FIP; from VM-1 (this works, but is of course rather useless): http://paste.openstack.org/show/805021/ tcpdump on the qrouter external interface when doing "curl http://FIP; from VM-3 (this is identical for connections from machines outside of our openstack environment - and no packets appear on the internal interface): http://paste.openstack.org/show/805022/ ** 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/1927691 Title: Port forwading does only work between VMs in the same neutron network Status in neutron: New Bug description: First of all, I'm not really sure if this is a bug, or some sort of configuration error on our side.. But I'm having issues with the port forwarding in neutron. Openstack ussuri, running on Bionic neutron-l3-agent 2:16.2.0-0ubuntu1~cloud0 openvswitch-switch 2.13.1-0ubuntu0.20.04.1~cloud0 My scenario: - Create two networks (net1 and net2), and attach a router to each of them - Create two VMs in net1, one in net2 - Attach a "plain" FIP to VM-1 and VM-3 - Create a FIP for the port forwarding, and create a port forwarding rule pointing to VM-2 (i.e map FIP:80 to VM-2:8000) - Login to VM-2 and start listening to tcp 8000 with "python3 -m http.server 8000" What I expect: curl http://FIP:80 should give a response from VM-2:8000 from both VM-1, VM-3 and externally What happens: The port forwarding only works for VM-1. In other words, only between VMs in the same neutron network. -- I've done some debugging with tcpdump on my network nodes within the netns of the qrouter. When I try to connect from either VM-3 or externally, I observe the packets arriving on the qrouter's external interface and they get dropped "somewhere". I've failed to understand/discover where and/or by what. In the dumps, we have the following IP addresses. All FIPs are in 10.212.136.0/21: VM-1 (net1): 192.168.0.92(FIP: 10.212.143.126) VM-2 (net1): 192.168.0.35(No FIP, but port forwarding rule on 10.212.141.76 80->8000) VM-3 (net2): 192.168.111.213 (FIP: 10.212.138.184) Router of net1: 192.168.0.1 / 10.212.140.143 Iptables for the qrouter that hosts the FIP with port forwarding: http://paste.openstack.org/show/805020/ tcpdump on the qrouter interal interface when doing "curl http://FIP; from VM-1 (this works, but is of course rather useless): http://paste.openstack.org/show/805021/ tcpdump on the qrouter external interface when doing "curl http://FIP; from VM-3 (this is identical for connections from machines outside of our openstack environment - and no packets appear on the internal interface): http://paste.openstack.org/show/805022/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1927691/+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 1914045] [NEW] Impossible to launch instance from community image
Public bug reported: Hi, This seems to be a "duplicate" of #1779250 but not quite. I have trouble launching a community image from horizon: How to reproduce: - Create two projects, A and B. - In project A, create a snapshot of a VM - Set the snapshot to community - Switch to project B - Try to launch a new instance, and select "visibility: community" in the launch instance panel - Observe that no images are listed. The community image is visible in the images panel, but the same issue occurs if I try to launch a new instance of the community image from the images panel. Running CentOS 8.3 and openstack-dashboard.noarch 1:18.3.2-1.el8 This happens with both legacy and angular images_panel in the Horizon config. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1914045 Title: Impossible to launch instance from community image Status in OpenStack Dashboard (Horizon): New Bug description: Hi, This seems to be a "duplicate" of #1779250 but not quite. I have trouble launching a community image from horizon: How to reproduce: - Create two projects, A and B. - In project A, create a snapshot of a VM - Set the snapshot to community - Switch to project B - Try to launch a new instance, and select "visibility: community" in the launch instance panel - Observe that no images are listed. The community image is visible in the images panel, but the same issue occurs if I try to launch a new instance of the community image from the images panel. Running CentOS 8.3 and openstack-dashboard.noarch 1:18.3.2-1.el8 This happens with both legacy and angular images_panel in the Horizon config. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1914045/+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 1906494] [NEW] Placement error when using GPUs that is utilizing SR-IOV for VGPU
Public bug reported: I'm experiencing some weird bugs/brokenness when trying to use the Nvidia A100 for vGPU in nova. It's a little bit involved, but I tihnk I have an idea of what's going on. My setup: Dell R7525 with 2xNvidia A100 CentOS 8.2 Openstack Ussuri (openstack-nova-compute.noarch 1:21.1.1-1.el8) Nvidia GRID 11.2 A little preface The Nvidia A100 is utilizing SR-IOV to create mdev files for vGPUs. The nvidia-driver ships a tool to enable SR-IOV on the physical cards, and this creates 16 VFs per card, which all appears in /sys/class/mdev_bus. Each VF can create only one mdev (no matter which GRID profile you are using). When nova-compute starts, it will automatically populate placement with (in my case) all the 32 VFs with the inventory of 1 VGPU each. In my case, I create VMs with the GRID A100-20C profile (so, two VGPUs per GPU). I've configured nova.conf with the correct "devices/enabled_vgpu_types" (nvidia-472), and four of the 32 VFs as valid in "vgpu_nvidia-472/device_addresses". In addition, I've set a custom trait on the resource providers that corresponds to the devices listed in nova.conf, and of course listed this trait in my flavor spec. The problem === When a physical card is full of vGPUs, nova-compute is seemingly trying to tell placement that all of the remaining VFs from that card now has 0 VGPUs in their inventory. This fails a JSON validation since all of the resource providers was created with 1 as minimum. Here's the python stacktrace from nova-compute.log: https://paste.ubuntu.com/p/TwfTkyMvqR/ The UUID from the stacktrace is _not_ one of the resource providers which was successfully used to create a VGPU for the two VMs already created. It's the UUID for the last VF on the same physical card when listed from 'openstack resource provider list' This error also stops me from: * Creating more VMs with a VGPU (even though it's still physical cards that has free space) * Deleting the existing VMs (They end up in an error state, but can then be deleted if I reboot the host) The stacktrace is persistent through nova-compute restarts, but it disappears on host reboot when the existing VMs is in the error state after the deletion attempt... Expected result === Well, I expect nova to handle this properly.. I have no idea how, or why this happens, but I'm confident that you clever people will find a fix! ** Affects: nova Importance: Undecided Status: New ** Tags: vgpu -- 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/1906494 Title: Placement error when using GPUs that is utilizing SR-IOV for VGPU Status in OpenStack Compute (nova): New Bug description: I'm experiencing some weird bugs/brokenness when trying to use the Nvidia A100 for vGPU in nova. It's a little bit involved, but I tihnk I have an idea of what's going on. My setup: Dell R7525 with 2xNvidia A100 CentOS 8.2 Openstack Ussuri (openstack-nova-compute.noarch 1:21.1.1-1.el8) Nvidia GRID 11.2 A little preface The Nvidia A100 is utilizing SR-IOV to create mdev files for vGPUs. The nvidia-driver ships a tool to enable SR-IOV on the physical cards, and this creates 16 VFs per card, which all appears in /sys/class/mdev_bus. Each VF can create only one mdev (no matter which GRID profile you are using). When nova-compute starts, it will automatically populate placement with (in my case) all the 32 VFs with the inventory of 1 VGPU each. In my case, I create VMs with the GRID A100-20C profile (so, two VGPUs per GPU). I've configured nova.conf with the correct "devices/enabled_vgpu_types" (nvidia-472), and four of the 32 VFs as valid in "vgpu_nvidia-472/device_addresses". In addition, I've set a custom trait on the resource providers that corresponds to the devices listed in nova.conf, and of course listed this trait in my flavor spec. The problem === When a physical card is full of vGPUs, nova-compute is seemingly trying to tell placement that all of the remaining VFs from that card now has 0 VGPUs in their inventory. This fails a JSON validation since all of the resource providers was created with 1 as minimum. Here's the python stacktrace from nova-compute.log: https://paste.ubuntu.com/p/TwfTkyMvqR/ The UUID from the stacktrace is _not_ one of the resource providers which was successfully used to create a VGPU for the two VMs already created. It's the UUID for the last VF on the same physical card when listed from 'openstack resource provider list' This error also stops me from: * Creating more VMs with a VGPU (even though it's still physical cards that has free space) * Deleting the existing VMs (They end up in an error state, but can then be deleted if I reboot the host) The stacktrace is persistent through nova-compute restarts,
[Yahoo-eng-team] [Bug 1900800] [NEW] VGPUs is not recreated on host reboot
Public bug reported: Description === In Ussuri, when a compute node providing vGPUs (Nvidia GRID in my case) is rebooted, the mdevs for VGPUs is not recreated, and a traceback from libvirt.libvirtError is thrown. https://paste.ubuntu.com/p/4t4NvTHGd8/ As far as I understand, this should have been fixed in https://review.opendev.org/#/c/715489/ but it seems like it fails even before it tries to recreate the mdev. Expected result === Upon host reboot, the mdevs should be recreated and the VMs should be restarted. Actual result = nova-compute throws the aforementioned error, the mdevs are not re-created and the VMs is left in an unrecoverable state. Environment === # dnf list installed | grep nova openstack-nova-common.noarch 1:21.1.0-2.el8 @centos-openstack-ussuri openstack-nova-compute.noarch 1:21.1.0-2.el8 @centos-openstack-ussuri python3-nova.noarch 1:21.1.0-2.el8 @centos-openstack-ussuri python3-novaclient.noarch 1:17.0.0-1.el8 @centos-openstack-ussuri # dnf list installed | grep libvirt libvirt-bash-completion.x86_646.0.0-25.2.el8 @advanced-virtualization libvirt-client.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-config-nwfilter.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-interface.x86_646.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-network.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-nodedev.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-nwfilter.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-qemu.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-secret.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-core.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-disk.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-gluster.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-iscsi.x86_646.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-iscsi-direct.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-logical.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-mpath.x86_646.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-rbd.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-driver-storage-scsi.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-daemon-kvm.x86_64 6.0.0-25.2.el8 @advanced-virtualization libvirt-libs.x86_64 6.0.0-25.2.el8 @advanced-virtualization python3-libvirt.x86_646.0.0-1.el8 @advanced-virtualization ** 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/1900800 Title: VGPUs is not recreated on host reboot Status in OpenStack Compute (nova): New Bug description: Description === In Ussuri, when a compute node providing vGPUs (Nvidia GRID in my case) is rebooted, the mdevs for VGPUs is not recreated, and a traceback from libvirt.libvirtError is thrown. https://paste.ubuntu.com/p/4t4NvTHGd8/ As far as I understand, this should have been fixed in https://review.opendev.org/#/c/715489/ but it seems like it fails even
[Yahoo-eng-team] [Bug 1893904] [NEW] Placement is not updated if a VGPU is re-created on new mdev upon host reboot
Public bug reported: First of all, I'm not really sure which project to "blame" for this bug, but here's the problem: When you reboot a compute-node with Nvidia GRID and guests running with a VGPU attached, the guests will often have their VGPU re-created on a different mdev than before the reboot. This is not updated in placement, causing the placement API to provide false information about which resource provider that is actually a valid allocation candidate for a new VGPU. Steps to reproduce: 1. Create a new instance with a VGPU attached, take note of wich mdev the VGPU is created on (with nvidia-smi vgpu) 2. Reboot the compute-node 3. Start the instance, and observe that its VGPU now lives on a different mdev 4. Check "openstack allocation candidate list --resource VGPU=1" and correlate the resource provider id with "openstack resource provider list" to see that placement now will list the allocated mdev ass free, and the inital mdev (from before the reboot) is still marked as used. Examples: https://paste.ubuntu.com/p/PZ6qgKtnRb/ This will eventually cause scheduling of new VGPU instances to fail, because they will try to use a device that in reality is already used (but marked as available in placement) Expected results: Either that the GRID-driver and libvirt should ensure that an instance keeps the same mdev for its VGPU through reboots (effectively making this.. not a nova bug) OR nova-compute should notify placement of the change and update the allocations Versions: This was first observed in stein, but the issue is also present in train. # rpm -qa | grep nova python2-nova-20.3.0-1.el7.noarch python2-novaclient-15.1.1-1.el7.noarch openstack-nova-compute-20.3.0-1.el7.noarch openstack-nova-common-20.3.0-1.el7.noarch ** 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/1893904 Title: Placement is not updated if a VGPU is re-created on new mdev upon host reboot Status in OpenStack Compute (nova): New Bug description: First of all, I'm not really sure which project to "blame" for this bug, but here's the problem: When you reboot a compute-node with Nvidia GRID and guests running with a VGPU attached, the guests will often have their VGPU re-created on a different mdev than before the reboot. This is not updated in placement, causing the placement API to provide false information about which resource provider that is actually a valid allocation candidate for a new VGPU. Steps to reproduce: 1. Create a new instance with a VGPU attached, take note of wich mdev the VGPU is created on (with nvidia-smi vgpu) 2. Reboot the compute-node 3. Start the instance, and observe that its VGPU now lives on a different mdev 4. Check "openstack allocation candidate list --resource VGPU=1" and correlate the resource provider id with "openstack resource provider list" to see that placement now will list the allocated mdev ass free, and the inital mdev (from before the reboot) is still marked as used. Examples: https://paste.ubuntu.com/p/PZ6qgKtnRb/ This will eventually cause scheduling of new VGPU instances to fail, because they will try to use a device that in reality is already used (but marked as available in placement) Expected results: Either that the GRID-driver and libvirt should ensure that an instance keeps the same mdev for its VGPU through reboots (effectively making this.. not a nova bug) OR nova-compute should notify placement of the change and update the allocations Versions: This was first observed in stein, but the issue is also present in train. # rpm -qa | grep nova python2-nova-20.3.0-1.el7.noarch python2-novaclient-15.1.1-1.el7.noarch openstack-nova-compute-20.3.0-1.el7.noarch openstack-nova-common-20.3.0-1.el7.noarch To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1893904/+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 1847203] [NEW] l3-agent stops processing router updates
Public bug reported: In our work on upgrading from Queens to Rocky, we have stumbled upon some weird behaviour in neutron-l3-agent. After "a while" (usually ~days), the l3-agent will simply stop processing router updates. In the debug log, we see: Got routers updated notification :[u'1dea9d84-e5ec-44be-b37f- 7f9070dd159e'] routers_updated /usr/lib/python2.7/dist- packages/neutron/agent/l3/agent.py:446 But then nothing happens after that. We're testing this with adding and removing a floating IP. The problem is that we really have noe clue what happens, other than the observed symptoms, so we can't really provide a way to reproduce this.. neutron-l3-agent 2:13.0.4-0ubuntu1~cloud0 openvswitch-switch 2.10.0-0ubuntu2~cloud0 Ubuntu 18.04 LTS, running the 4.15.0-51-generic kernel ** 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/1847203 Title: l3-agent stops processing router updates Status in neutron: New Bug description: In our work on upgrading from Queens to Rocky, we have stumbled upon some weird behaviour in neutron-l3-agent. After "a while" (usually ~days), the l3-agent will simply stop processing router updates. In the debug log, we see: Got routers updated notification :[u'1dea9d84-e5ec-44be-b37f- 7f9070dd159e'] routers_updated /usr/lib/python2.7/dist- packages/neutron/agent/l3/agent.py:446 But then nothing happens after that. We're testing this with adding and removing a floating IP. The problem is that we really have noe clue what happens, other than the observed symptoms, so we can't really provide a way to reproduce this.. neutron-l3-agent 2:13.0.4-0ubuntu1~cloud0 openvswitch-switch 2.10.0-0ubuntu2~cloud0 Ubuntu 18.04 LTS, running the 4.15.0-51-generic kernel To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1847203/+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 1843025] [NEW] FWaaS v2 fails to add ICMPv6 rules via horizon
Public bug reported: In rocky, FWaaS v2 fails to add the correct ip6tables rules for ICMPv6. Steps to reproduce: * Create rule with Protocol ICMP, IP version 6 in horizon * Add the rule to a policy, and make sure the firewall group with that policy is attached to a port * Login to the neutron network node that has the netns for your router and run ip6tables-save Observe that your rule is added like: -A neutron-l3-agent-iv63872a6fc -s 2001:db8:1d00:13::/64 -p icmp -j neutron-l3-agent-accepted It should've added: -A neutron-l3-agent-iv63872a6fc -s 2001:db8:1d00:13::/64 -p ipv6-icmp -j neutron-l3-agent-accepted Ubuntu 18.04 neutron-l3-agent 2:13.0.4-0ubuntu1~cloud0 python-neutron-fwaas 1:13.0.2-0ubuntu1~cloud0 ** 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/1843025 Title: FWaaS v2 fails to add ICMPv6 rules via horizon Status in neutron: New Bug description: In rocky, FWaaS v2 fails to add the correct ip6tables rules for ICMPv6. Steps to reproduce: * Create rule with Protocol ICMP, IP version 6 in horizon * Add the rule to a policy, and make sure the firewall group with that policy is attached to a port * Login to the neutron network node that has the netns for your router and run ip6tables-save Observe that your rule is added like: -A neutron-l3-agent-iv63872a6fc -s 2001:db8:1d00:13::/64 -p icmp -j neutron-l3-agent-accepted It should've added: -A neutron-l3-agent-iv63872a6fc -s 2001:db8:1d00:13::/64 -p ipv6-icmp -j neutron-l3-agent-accepted Ubuntu 18.04 neutron-l3-agent 2:13.0.4-0ubuntu1~cloud0 python-neutron-fwaas 1:13.0.2-0ubuntu1~cloud0 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1843025/+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 1788159] Re: AngularJS keypair panel is broken
** Changed in: horizon
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1788159
Title:
AngularJS keypair panel is broken
Status in OpenStack Dashboard (Horizon):
Invalid
Bug description:
In queens, the AngularJS panel for key pairs is enabled by default. I
would consider it broken, because both "Create keypair" and "Import
keypair" don't work. They throw the following JS error to the console:
http://paste.openstack.org/show/728509/
If I set
ANGULAR_FEATURES = {
'images_panel': True,
'key_pairs_panel': False,
'flavors_panel': False,
'domains_panel': False,
'users_panel': False,
'groups_panel': False,
'roles_panel': True
}
in local_settings.py - effectively disabling the Angular panel for key
pairs, it (obviously) works.
Somewhat related to https://bugs.launchpad.net/ubuntu/+source
/designate-dashboard/+bug/1659620?comments=all where they claim it's a
problem with the openstack-dashboard, and that it's still broken in
queens.
Using openstack-dashboard 3:13.0.1-0ubuntu1~cloud0
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1788159/+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 1794421] [NEW] Add allowed address pair button is only visible to admin
Public bug reported: In Queens (openstack-dashboard 3:13.0.1-0ubuntu1~cloud0), when logging into Horizon in context of a _member_ in any project, the "Add allowed address pair" button in "Network" -> "Networks" -> -> "Ports" -> -> "Allowed address pairs" is not visible. When accessing the same panel in context of a project where the user has the admin role, the "add"-button is visible and functional. I consider this to be a horizon/dashboard bug, beacause I am able to add an allowed address pair to a port with the "neutron port-update" command in context of a non-admin user. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1794421 Title: Add allowed address pair button is only visible to admin Status in OpenStack Dashboard (Horizon): New Bug description: In Queens (openstack-dashboard 3:13.0.1-0ubuntu1~cloud0), when logging into Horizon in context of a _member_ in any project, the "Add allowed address pair" button in "Network" -> "Networks" -> -> "Ports" -> -> "Allowed address pairs" is not visible. When accessing the same panel in context of a project where the user has the admin role, the "add"-button is visible and functional. I consider this to be a horizon/dashboard bug, beacause I am able to add an allowed address pair to a port with the "neutron port-update" command in context of a non-admin user. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1794421/+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 1788159] [NEW] AngularJS keypair panel is broken
Public bug reported:
In queens, the AngularJS panel for key pairs is enabled by default. I
would consider it broken, because both "Create keypair" and "Import
keypair" don't work. They throw the following JS error to the console:
http://paste.openstack.org/show/728509/
If I set
ANGULAR_FEATURES = {
'images_panel': True,
'key_pairs_panel': False,
'flavors_panel': False,
'domains_panel': False,
'users_panel': False,
'groups_panel': False,
'roles_panel': True
}
in local_settings.py - effectively disabling the Angular panel for key
pairs, it (obviously) works.
Somewhat related to https://bugs.launchpad.net/ubuntu/+source/designate-
dashboard/+bug/1659620?comments=all where they claim it's a problem with
the openstack-dashboard, and that it's still broken in queens.
Using openstack-dashboard 3:13.0.1-0ubuntu1~cloud0
** Affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1788159
Title:
AngularJS keypair panel is broken
Status in OpenStack Dashboard (Horizon):
New
Bug description:
In queens, the AngularJS panel for key pairs is enabled by default. I
would consider it broken, because both "Create keypair" and "Import
keypair" don't work. They throw the following JS error to the console:
http://paste.openstack.org/show/728509/
If I set
ANGULAR_FEATURES = {
'images_panel': True,
'key_pairs_panel': False,
'flavors_panel': False,
'domains_panel': False,
'users_panel': False,
'groups_panel': False,
'roles_panel': True
}
in local_settings.py - effectively disabling the Angular panel for key
pairs, it (obviously) works.
Somewhat related to https://bugs.launchpad.net/ubuntu/+source
/designate-dashboard/+bug/1659620?comments=all where they claim it's a
problem with the openstack-dashboard, and that it's still broken in
queens.
Using openstack-dashboard 3:13.0.1-0ubuntu1~cloud0
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1788159/+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 1690782] [NEW] Role assignment list with name resolution fails if a project contains a disabled AD user
Public bug reported: If you have configured keystone with an LDAP backend, and you have project with a disabled AD user as a member, the "openstack role assignment list --project --names" command will fail with a HTTP 404 response, beacause it can't resolve the name of the disabled user. Example: larserik@manager:~$ openstack role assignment list --project 9a71b116d24747e19671ed4f28bfd512 -f value 9fe2ff9ee4384b1894a90878d3e92bab 3e2e82db86d8423db18595a2a5dd926a 9a71b116d24747e19671ed4f28bfd512 False 9fe2ff9ee4384b1894a90878d3e92bab 83b6168d45c9362ce1ec257c224887428ba76d9f70d6f634c7ebb08b9cbd2cf3 9a71b116d24747e19671ed4f28bfd512 False With --names: larserik@manager:~$ openstack role assignment list --project 9a71b116d24747e19671ed4f28bfd512 --names -f value Could not find user: (HTTP 404) (Request-ID: req-b7389d49-d60d-49b1-a0af-dd9ced9ba3da) What's kind of strange, is that the 404 response actually contains the username it can't find. python-keystone 2:9.0.0-0ubuntu1~cloud0 python-keystoneclient 1:2.3.1-2~cloud0 python-openstackclient 2.3.0-2~cloud0 ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1690782 Title: Role assignment list with name resolution fails if a project contains a disabled AD user Status in OpenStack Identity (keystone): New Bug description: If you have configured keystone with an LDAP backend, and you have project with a disabled AD user as a member, the "openstack role assignment list --project --names" command will fail with a HTTP 404 response, beacause it can't resolve the name of the disabled user. Example: larserik@manager:~$ openstack role assignment list --project 9a71b116d24747e19671ed4f28bfd512 -f value 9fe2ff9ee4384b1894a90878d3e92bab 3e2e82db86d8423db18595a2a5dd926a 9a71b116d24747e19671ed4f28bfd512 False 9fe2ff9ee4384b1894a90878d3e92bab 83b6168d45c9362ce1ec257c224887428ba76d9f70d6f634c7ebb08b9cbd2cf3 9a71b116d24747e19671ed4f28bfd512 False With --names: larserik@manager:~$ openstack role assignment list --project 9a71b116d24747e19671ed4f28bfd512 --names -f value Could not find user: (HTTP 404) (Request-ID: req-b7389d49-d60d-49b1-a0af-dd9ced9ba3da) What's kind of strange, is that the 404 response actually contains the username it can't find. python-keystone 2:9.0.0-0ubuntu1~cloud0 python-keystoneclient 1:2.3.1-2~cloud0 python-openstackclient 2.3.0-2~cloud0 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1690782/+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
