[Yahoo-eng-team] [Bug 1896603] Re: ovn-octavia-provider: Cannot create listener due to alowed_cidrs validation
** Project changed: neutron => octavia -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1896603 Title: ovn-octavia-provider: Cannot create listener due to alowed_cidrs validation Status in Ubuntu Cloud Archive: Triaged Status in Ubuntu Cloud Archive victoria series: Triaged Status in octavia: Fix Released Status in ovn-octavia-provider package in Ubuntu: Fix Released Status in ovn-octavia-provider source package in Groovy: Fix Committed Status in ovn-octavia-provider source package in Hirsute: Fix Released Bug description: [Impact] * Users cannot add listeners to an Octavia loadbalancer if it was created using the ovn provider * This makes the ovn provider unusable in Victoria and will force people to use the more painful alternative of using the Amphora driver [Test Case] $ openstack loadbalancer create --provider ovn --vip-subnet-id f92fa6ca-0f29-4b61-aeb6-db052caceff5 --name test-lb $ openstack loadbalancer show test-lb -c provisioning_status (Repeat until it shows as ACTIVE) $ openstack loadbalancer listener create --name listener1 --protocol TCP --protocol-port 80 test-lb Provider 'ovn' does not support a requested option: OVN provider does not support allowed_cidrs option (HTTP 501) (Request-ID: req-52a10944-951d-4414-8441-fe743444ed7c) Alternatively run the focal-victoria-ha-ovn functional test in the octavia charm [Where problems could occur] * Problems would be isolated to the managment of octavia loadbalancers within an openstack cloud. Specifically the patch fixes the checking of the allowed_cidr option when a listener is created or updated. [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1896603/+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 1906759] Re: Port remains reserved even after deleting the instance managed via kubernetes
[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/1906759
Title:
Port remains reserved even after deleting the instance managed via
kubernetes
Status in OpenStack Compute (nova):
Expired
Bug description:
Delete instance with a Neutron port. Create an instance with the same port.
Port will remain in the wrong state ("in use" with deleted instance UUID).
The creation of the new instance will fail. Port should be released, not
stay.
Here, I'm managing the OpenStack instances directly using Kubernetes.
Also this a random problem and not happens every time.
Environment details:
k8s: kops (https://github.com/kubernetes/kops) to deploy kubernetes
CNI: Calico
Kubernetes version 1.19.3 specifically
A fix has been already done to kops:
https://github.com/kubernetes/kops/pull/10178
But there is still a bug with OpenStack API's which is causing race
condition and the port is getting left to reserved state even after
the instance is deleted.
Considering this as a production environment, there was a little
chance to reproduce and capture the logs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1906759/+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 1915216] [NEW] Can't find proper metadata source IP - Interoperability problem with CentOS8/Stream, NetworkManager and Apache CloudStack
Public bug reported: System environment: Apache CloudStack 4.11; KVM zone In CentOS 8 either Upstream, there is NetworkManager. cloud-init currently packaged there is 20.3-9.el8. We are talking about the code of the CloudStack datasource. What we observe, is that on our CentOS test systems, cloud-init jumps into the default_gateway() method to return VR IP address 192.102.146.1. This is however wrong, this IP does not return metadata. To compare, an Ubuntu 20.04 deployed on same network resolves to 192.102.146.5. This IP can be found under /run/NetworkManager: ./NetworkManager/resolv.conf:nameserver 192.102.146.5 ./NetworkManager/no-stub-resolv.conf:nameserver 192.102.146.5 ./NetworkManager/devices/2:next-server=192.102.146.5 While CloudStack datasource follows several approaches to find the IP, the code does not seem to implement the situation when there is NetworkManager. What happens instead: - first approach is to try data-server DNS entry first; this is up to our system, we will try out as well - then, it looks for DHCP lease file location "/run/systemd/netif/leases". For some reason, this value is a hardcoded variable in net/dhcp.py: NETWORKD_LEASES_DIR = '/run/systemd/netif/leases' - then, it finds lease file /var/lib/NetworkManager/internal-ea2b5464-7c5e-3243-aa40-7d77805f41ee-ens3.lease, but there is (as opposite to what we see in Ubuntu) just one line, "ADDRESS=192.102.146.34" - why this file does not contain the expected entry "SERVER_ADDRESS=192.102.146.5" as well, I am not sure. - well and finally it is going to the default gateway method. Would you say this is a bug, or maybe a missing feature to ensure interoperability with NetworkManager? (in terms that cloudinit does not look under /run/NetworkManager/) ** Affects: cloud-init Importance: Undecided Status: New -- 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/1915216 Title: Can't find proper metadata source IP - Interoperability problem with CentOS8/Stream, NetworkManager and Apache CloudStack Status in cloud-init: New Bug description: System environment: Apache CloudStack 4.11; KVM zone In CentOS 8 either Upstream, there is NetworkManager. cloud-init currently packaged there is 20.3-9.el8. We are talking about the code of the CloudStack datasource. What we observe, is that on our CentOS test systems, cloud-init jumps into the default_gateway() method to return VR IP address 192.102.146.1. This is however wrong, this IP does not return metadata. To compare, an Ubuntu 20.04 deployed on same network resolves to 192.102.146.5. This IP can be found under /run/NetworkManager: ./NetworkManager/resolv.conf:nameserver 192.102.146.5 ./NetworkManager/no-stub-resolv.conf:nameserver 192.102.146.5 ./NetworkManager/devices/2:next-server=192.102.146.5 While CloudStack datasource follows several approaches to find the IP, the code does not seem to implement the situation when there is NetworkManager. What happens instead: - first approach is to try data-server DNS entry first; this is up to our system, we will try out as well - then, it looks for DHCP lease file location "/run/systemd/netif/leases". For some reason, this value is a hardcoded variable in net/dhcp.py: NETWORKD_LEASES_DIR = '/run/systemd/netif/leases' - then, it finds lease file /var/lib/NetworkManager/internal-ea2b5464-7c5e-3243-aa40-7d77805f41ee-ens3.lease, but there is (as opposite to what we see in Ubuntu) just one line, "ADDRESS=192.102.146.34" - why this file does not contain the expected entry "SERVER_ADDRESS=192.102.146.5" as well, I am not sure. - well and finally it is going to the default gateway method. Would you say this is a bug, or maybe a missing feature to ensure interoperability with NetworkManager? (in terms that cloudinit does not look under /run/NetworkManager/) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1915216/+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 1844568] Re: [compute] "create_test_server" if networks is undefined and more than one network is present
https://review.opendev.org/c/openstack/tempest/+/770169 got merged.
** Changed in: tempest
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1844568
Title:
[compute] "create_test_server" if networks is undefined and more than
one network is present
Status in OpenStack Compute (nova):
Invalid
Status in tempest:
Fix Released
Bug description:
This problem was detected in "ServersNegativeTestJSON" [1]. When a
server is created ("cls.create_test_server"), if a network is not
defined but several networks are present in this project, Nova raises
the exception "NetworkAmbiguous", a seen in this log snippet:
Sep 13 23:44:15.520980 ubuntu-bionic-limestone-regionone-0011283625
devstack@n-api.service[27339]: DEBUG nova.network.neutronv2.api [None
req-c95ecec2-8d10-4984-8ba9-b608161dd645
tempest-ServersNegativeTestJSON-445859222
tempest-ServersNegativeTestJSON-445859222] validate_networks() for None
{{(pid=27340) validate_networks
/opt/stack/nova/nova/network/neutronv2/api.py:2251}}
Sep 13 23:44:15.754945 ubuntu-bionic-limestone-regionone-0011283625
devstack@n-api.service[27339]: INFO nova.api.openstack.wsgi [None
req-c95ecec2-8d10-4984-8ba9-b608161dd645
tempest-ServersNegativeTestJSON-445859222
tempest-ServersNegativeTestJSON-445859222] HTTP exception thrown: Multiple
possible networks found, use a Network ID to be more specific.
We can see that the network information provided to the server creation is
empty but Nova tries to assign a default single network for this server.
However Nova does not assign this default network because several networks are
present for this project ID. In this case, the server creation should be
specific passing the network information.
[1]https://58a87e825b9766115d07-cec36eea8e90c9127fc5a72b798cfeab.ssl.cf2.rackcdn.com/670177/9/check/networking-ovn-tempest-dsvm-ovs-release/b58638a/testr_results.html.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1844568/+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 1915193] [NEW] User with reader role has same permissions as with member role
Public bug reported: Default role reader doesn't meet its expectations from https://docs.openstack.org/keystone/ussuri/admin/service-api- protection.html , For example: "users with reader on a project could list instance, users with member on a project can list and create instances". Actual results: In my case, reader can create/delete instances or also routers, networks,... Expected results: Users with reader role should only list the mentioned resources and don't touch the virtual infrastructure. Environment: Centos 8.2.2004 OpenStack release: Ussuri, deployed using kolla-ansible Is there anything additional, that needs to be done for setup reader role? My policies of Keystone and Neutron are attached. ** Affects: keystone Importance: Undecided Status: New ** Attachment added: "keystone-policy.yaml" https://bugs.launchpad.net/bugs/1915193/+attachment/5461952/+files/keystone-policy.yaml -- 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/1915193 Title: User with reader role has same permissions as with member role Status in OpenStack Identity (keystone): New Bug description: Default role reader doesn't meet its expectations from https://docs.openstack.org/keystone/ussuri/admin/service-api- protection.html , For example: "users with reader on a project could list instance, users with member on a project can list and create instances". Actual results: In my case, reader can create/delete instances or also routers, networks,... Expected results: Users with reader role should only list the mentioned resources and don't touch the virtual infrastructure. Environment: Centos 8.2.2004 OpenStack release: Ussuri, deployed using kolla-ansible Is there anything additional, that needs to be done for setup reader role? My policies of Keystone and Neutron are attached. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1915193/+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 1915077] Re: genisoimage may be going away
** Also affects: cloud-utils (Ubuntu) Importance: Undecided Status: New -- 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/1915077 Title: genisoimage may be going away Status in cloud-init: New Status in cloud-utils package in Ubuntu: New Bug description: It seems that cdrkit, which is where genisoimage comes from, is dead upstream and is likely to be removed from debian: https://lists.debian.org/debian-cloud/2021/02/msg00011.html Plenty of cloud-init docs and tutorials refer to genisoimage to create seed ISOs, it may be time to find something else. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1915077/+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 1914592] Re: oslo.policy 3.6.1 breaks nova
** Changed in: oslo.policy Status: Confirmed => Fix Released ** Changed in: nova Status: Confirmed => 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/1914592 Title: oslo.policy 3.6.1 breaks nova Status in OpenStack Compute (nova): Fix Released Status in oslo.policy: Fix Released Bug description: As seen on the requirements change [1], a recently introduced version of oslo.policy appears to be breaking nova [2]. Initial investigations suggest both oslo.policy and nova are partially to blame. [1] https://review.opendev.org/c/openstack/requirements/+/773779 [2] https://d138d4f526b4feb9aa23-c0b1a48165a1318087e38ccc28dcb2b0.ssl.cf5.rackcdn.com/773779/1/check/cross-nova-functional/d9729b8/testr_results.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1914592/+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 1915151] [NEW] [RFE] There should be a way to set ethertype for the vlan_transparent networks
Public bug reported: Networks with enabled vlan_transparency can be any of any type available in Neutron (vxlan, vlan, flat in case of Linuxbridge, etc.). In most cases it is fine when packets in such case have ethertype 0x8100 (802.1q). The same ethertype is configured always for vlan network with vlan_transparent=True. But in such case as we have 2 vlans already (S-Tag and C-Tag) it is really QinQ. Neutron still configures ethertype to be 0x8100 in such case and it works for most of the cases. But in case of some hardware it needs to be 0x8a88 (802.1ad) which is real QinQ type. So I think that it would be good to add operators possibility to configure what ethertype will be used in such case. It could be simple config option and all vlan networks with enabled vlan transparency would use it. Default value of that option would be 0x8100 to be compatible with what we have now. ** Affects: neutron Importance: Wishlist Assignee: Slawek Kaplonski (slaweq) Status: New ** Tags: linuxbridge ml2 ovn rfe-triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1915151 Title: [RFE] There should be a way to set ethertype for the vlan_transparent networks Status in neutron: New Bug description: Networks with enabled vlan_transparency can be any of any type available in Neutron (vxlan, vlan, flat in case of Linuxbridge, etc.). In most cases it is fine when packets in such case have ethertype 0x8100 (802.1q). The same ethertype is configured always for vlan network with vlan_transparent=True. But in such case as we have 2 vlans already (S-Tag and C-Tag) it is really QinQ. Neutron still configures ethertype to be 0x8100 in such case and it works for most of the cases. But in case of some hardware it needs to be 0x8a88 (802.1ad) which is real QinQ type. So I think that it would be good to add operators possibility to configure what ethertype will be used in such case. It could be simple config option and all vlan networks with enabled vlan transparency would use it. Default value of that option would be 0x8100 to be compatible with what we have now. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1915151/+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 1915143] [NEW] Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500)
Public bug reported: Description = I am logged in as admin and created some instances and images as well , they were visible for one week but suddenly when I tried to check today I wasnt able to see any images or instances or volumes , however i was able to see the networks I created and the routers. The error I receved was: Error: Unable to retrieve usage information. Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-538dfec9-8464-4a92-9b03-2c610c3eff07) Environment Openstack Ussuri Release The log file = 2021-02-09 11:43:02.838 1506671 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 11:43:02.843 1506671 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 11:43:02.848 1506671 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 11:43:03.887 1506671 INFO oslo.messaging._drivers.impl_rabbit [-] [cad79092-0027-438d-9cce-8fbe181f4ff3] Reconnected to AMQP server on 172.25.8.252:5672 via [amqp] client with port 53754. 2021-02-09 11:43:04.573 1506671 INFO nova.api.openstack.requestlog [req-d2ca1be8-7bb3-45d1-91e2-0bf598112be7 5102000f220147a197c16910458eafb3 efc6ffe3908d447987ba5ed6d798ae08 - default default] 172.25.8.252 "GET /v2.1/efc6ffe3908d447987ba5ed6d798ae08/servers/detail?project_id=efc6ffe3908d447987ba5ed6d798ae08" status: 200 len: 17406 microversion: 2.42 time: 1.737148 2021-02-09 11:43:05.501 1506667 INFO nova.api.openstack.requestlog [req-02697d51-58f8-4528-afe2-2d24d8e802a5 5102000f220147a197c16910458eafb3 efc6ffe3908d447987ba5ed6d798ae08 - default default] 172.25.8.252 "GET /v2.1/efc6ffe3908d447987ba5ed6d798ae08" status: 404 len: 112 microversion: - time: 0.186829 2021-02-09 11:43:05.510 1506670 INFO nova.api.openstack.requestlog [req-2fd6b62e-cb1f-4919-88d2-d41af9b3a7b9 5102000f220147a197c16910458eafb3 efc6ffe3908d447987ba5ed6d798ae08 - default default] 172.25.8.252 "GET /v2.1/" status: 200 len: 386 microversion: 2.1 time: 0.006624 2021-02-09 11:43:06.220 150 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 11:43:06.231 150 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 11:43:06.235 150 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 11:43:06.737 150 INFO oslo.messaging._drivers.impl_rabbit [-] [67d970a3-15cd-4b87-8b2d-a47bd906b100] Reconnected to AMQP server on 172.25.8.252:5672 via [amqp] client with port 53794. 2021-02-09 11:43:08.143 150 INFO nova.api.openstack.requestlog [req-11e3f941-ecee-45e7-9964-d70b063a0290 5102000f220147a197c16910458eafb3 efc6ffe3908d447987ba5ed6d798ae08 - default default] 172.25.8.252 "GET /v2.1/efc6ffe3908d447987ba5ed6d798ae08/servers/detail?project_id=efc6ffe3908d447987ba5ed6d798ae08" status: 200 len: 17406 microversion: 2.42 time: 2.034052 2021-02-09 11:48:43.174 1506669 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 11:48:43.178 1506669 ERROR oslo.messaging._drivers.impl_rabbit [-] [7916d861-ee6d-484c-9cab-1cd4946ec11d] AMQP server on 172.25.8.252:5672 is unreachable: [Errno 104] Connection reset by peer. Trying again in 1 seconds.: ConnectionResetError: [Errno 104] Connection reset by peer 2021-02-09 11:48:43.388 1506669 INFO nova.api.openstack.requestlog [req-8b40bd1f-371b-40a2-aa78-6f073b80342a 12d3b5fee3be4e9c94bb60c8acc14997 781dc171cf7642dfa11c6649989fcd2d - default default] 172.25.8.252 "GET /v2.1/781dc171cf7642dfa11c6649989fcd2d/servers/detail?all_tenants=True&changes-since=2021-02-09T06%3A08%3A43.495476%2B00%3A00" status: 200 len: 15 microversion: 2.1 time: 0.216355 2021-02-09 14:34:31.067 1506667 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 14:34:31.119 1506667 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: Server unexpectedly closed connection 2021-02-09 14:34:31.124 1506667 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to
[Yahoo-eng-team] [Bug 1912596] Re: neutron-server report 500 error when update floating ip port forwarding
** Changed in: neutron Assignee: (unassigned) => yangjianfeng (yangjianfeng) ** 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/1912596 Title: neutron-server report 500 error when update floating ip port forwarding Status in neutron: Fix Released Bug description: I create two floating ip port forwarding, like below: # openstack floating ip port forwarding list 16c83a6f-8ab5-455f-a744-dccec61e408d -f value 6173dee8-8e7a-422f-bbb3-35e5726bf879 76a1f0d2-08ad-4975-a2ee-02d877960b35 192.168.5.4 7687 65530 udp None fea45432-321b-4362-b2d4-525680a4b6d9 76a1f0d2-08ad-4975-a2ee-02d877960b35 192.168.5.4 65535 6554 tcp None Then, I execute the below command to update one of them, like below: # openstack floating ip port forwarding set 16c83a6f-8ab5-455f-a744-dccec61e408d fea45432-321b-4362-b2d4-525680a4b6d9 --internal-protocol-port 7687 The neutron server report 500 error: HttpException: 500: Server Error for url: http://10.2.36.148:19696/v2.0/floatingips/16c83a6f-8ab5-455f-a744-dccec61e408d/port_forwardings/fea45432-321b-4362-b2d4-525680a4b6d9, Request Failed: internal server error while processing your request. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1912596/+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
