[Yahoo-eng-team] [Bug 2062965] Re: octavia/ovn: missed healthmon port cleanup
Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/916637 Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/f034bab144b68cf96c538339e389c4cc7c6d7d63 Submitter: "Zuul (22348)" Branch:master commit f034bab144b68cf96c538339e389c4cc7c6d7d63 Author: Fernando Royo Date: Mon Apr 22 15:47:46 2024 +0200 Remove leftover OVN LB HM port upon deletion of a member When a load balancer pool has a Health Monitor associated with it, an OVN LB Health Monitor port is created for each backend member subnet added. When removing backend members, the OVN LB Health Monitor port is cleaned up only if no more members are associated with the Health Monitor pool. However, this assumption is incorrect. This patch corrects this behavior by checking instead if there are more members from the same subnet associated with the pool. It ensures that the OVN LB Health Monitor port is deleted only when the last member from the subnet is deleted. If the port is being used by another different LB Health Monitor, `_clean_up_hm_port` will handle it. Closes-Bug: #2062965 Change-Id: I4c35cc5c6af14bb208f4313bb86e3519df0a30fa ** 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/2062965 Title: octavia/ovn: missed healthmon port cleanup Status in neutron: Fix Released Bug description: Creating an octavia load-balancer with the ovn provider, adding a health-monitor and then members, octavia creates a neutron hm port in each subnet where a member was added. Removing the members again, the hm ports do not get cleaned up. The hm removal then cleans up one of the hm ports, the one that is in the subnet where the vip happens to be. The others are still left and do not get cleaned up by octavia. This of course will cause issues when subnets can later not be deleted due to being still populated by the orphaned ports. The cleanup logic simply does not match the hm port creation logic. Mitigating factors: * openstack loadbalancer delete --cascade does clean up all hm ports. * Deleting the health mon before removing the members also avoids the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2062965/+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 1728031] Fix included in openstack/horizon 23.0.2
This issue was fixed in the openstack/horizon 23.0.2 release. ** Changed in: cloud-archive/zed Status: New => Fix Released -- 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/1728031 Title: [SRU] Unable to change user password when ENFORCE_PASSWORD_CHECK is True Status in Ubuntu Cloud Archive: New Status in Ubuntu Cloud Archive antelope series: New Status in Ubuntu Cloud Archive bobcat series: New Status in Ubuntu Cloud Archive yoga series: New Status in Ubuntu Cloud Archive zed series: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in horizon package in Ubuntu: New Status in horizon source package in Focal: New Status in horizon source package in Jammy: New Status in horizon source package in Mantic: New Bug description: After following the security hardening guidelines: https://docs.openstack.org/security-guide/dashboard/checklist.html#check-dashboard-09-is-enforce-password-check-set-to-true After this check is enabled Check-Dashboard-09: Is ENFORCE_PASSWORD_CHECK set to True The user password cannot be changed. The form submission fails by displaying that admin password is incorrect. The reason for this is in keystone.py in openstack_dashboard/api/keystone.py user_verify_admin_password method uses internal url to communicate with the keystone. line 500: endpoint = _get_endpoint_url(request, 'internalURL') This should be changed to adminURL === SRU Description === [Impact] Admins cannot change user's password as it gives an error saying that the admin's password is incorrect, despite being correct. There are 2 causes: 1) due to the lack of user_domain being specified when validating the admin's password, it will always fail if the admin is not registered in the "default" domain, because the user_domain defaults to "default" when not specified. 2) even if the admin user is registered in the "default" domain, it may fail due to the wrong endpoint being used in the request to validate the admin's password. The issues are fixed in 2 separate patches [1] and [2]. However, [2] is introducing a new config option, while [1] alone is also enough to fix the occurrence on some deployments. We are including only [1] in the SRU. [Test case] 1. Setting up the env 1a. Deploy openstack env with horizon/openstack-dashboard 1b. Set up admin user in a domain not named "default", such as "admin_domain". 1c. Set up any other user, such as demo. Preferably in the admin_domain as well for convenience. 2. Reproduce the bug 2a. Login as admin and navigate to Identity > Users 2b. On the far right-hand side of the demo user row, click the options button and select Change Password 2c. Type in any new password, repeat it below, and type in the admin password. Click Save and you should see a message "The admin password is incorrect" 3. Install package that contains the fixed code 4. Confirm fix 5a. Repeat steps 2a-2c 5b. The password should now be saved successfully [Regression Potential] The code is a 1-line change that was tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. No side effects or risks are foreseen. Usage of fix [1] has also been tested manually without fix [2] and still worked. [Other Info] None. [1] https://review.opendev.org/c/openstack/horizon/+/913250 [2] https://review.opendev.org/c/openstack/horizon/+/844574 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1728031/+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 2064369] [NEW] Install and configure controller node for Ubuntu in nova
Public bug reported: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: under the [service_user] section, it should be HTTP://controller:5000/identity instead of https://controller/identity, since the deployment guide did not have us make an https://controller/identity endpoint - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - The mailing list: https://lists.openstack.org - IRC: 'openstack' channel on OFTC --- Release: 28.0.2.dev25 on 2023-02-15 22:37:40 SHA: 1bbd44e16e51660eb4fea9d3c970a5aee99225a5 Source: https://opendev.org/openstack/nova/src/doc/source/install/controller-install-ubuntu.rst URL: https://docs.openstack.org/nova/2023.2/install/controller-install-ubuntu.html ** Affects: nova Importance: Undecided Status: New ** Tags: doc -- 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/2064369 Title: Install and configure controller node for Ubuntu in nova Status in OpenStack Compute (nova): New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: under the [service_user] section, it should be HTTP://controller:5000/identity instead of https://controller/identity, since the deployment guide did not have us make an https://controller/identity endpoint - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - The mailing list: https://lists.openstack.org - IRC: 'openstack' channel on OFTC --- Release: 28.0.2.dev25 on 2023-02-15 22:37:40 SHA: 1bbd44e16e51660eb4fea9d3c970a5aee99225a5 Source: https://opendev.org/openstack/nova/src/doc/source/install/controller-install-ubuntu.rst URL: https://docs.openstack.org/nova/2023.2/install/controller-install-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2064369/+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