September 2023 - openstack-discuss

[openstack-ansible][manila deployment] error: No valid host was found
by Danish Khan 25 Sep '23

25 Sep '23

Dear Team, I have deployed Manila in openstack-ansible and I have created share type and share network. But I am still unable to create a share in it. Below is the journalctl error from manila container : Sep 24 16:45:13 aio1-manila-container-5cce4ee7 manila-scheduler[69]: 2023-09-24 16:45:13.689 69 ERROR manila.scheduler.manager [req-13a8ec7b-2b66-452b-964b-f531b75b699b c0806f7a8b534149a72931b84f7d60af 61c6349cbba74db88d14d3b7348de585 - - -] Failed to schedule create_share: No valid host was found. Failed to find a weighted host, the last executed filter was AvailabilityZoneFilter.: manila.exception.NoValidHost: No valid host was found. Failed to find a weighted host, the last executed filter was AvailabilityZoneFilter. And below is the error of manila-share.service from controller node: Sep 24 16:44:24 aio1 manila-share[250518]: 2023-09-24 16:44:24.016 250518 CRITICAL manila [req-3c0e428b-226b-4bff-ade1-3d4ac5befb99 - - - - -] Unhandled error: manila.exception.ManilaException: Config opt 'driver_handles_share_servers' has improper value - 'None'. Please define it as boolean. Note: manila-share service is continueously giving this error even if there is no resources of manila(even in the setup). I am not sure where I am supposed to define driver_handles_share_servers defautl value if there is no share type. Thanks in advance. Regards, Danish

2 1

[neutron] Bug deputy report (week starting on September 18)
by Bernard Cafarelli 25 Sep '23

25 Sep '23

Hey neutrinos, time for a new bug deputy rotation again! Here are the bugs reported between 2023-09-18 and 2023-09-24 Quite a few bugs have patches in progress. For the rest, some failures on neutron-tempest-plugin-openvswitch tempest jobs in the first 2 bugs listed below, possibly a design question for https://bugs.launchpad.net/neutron/+bug/2036705 <https://bugs.launchpad.net/neutron/+bug/2036705> (different behaviour in ML2/OVN), one RBAC bug on tags in https://bugs.launchpad.net/neutron/+bug/2037002 and 2 other unassigned bugs https://bugs.launchpad.net/neutron/+bug/2037107 and https://bugs.launchpad.net/neutron/+bug/2036877 Critical * neutron-tempest-plugin-openvswitch-* jobs randomly failing in gate - https://bugs.launchpad.net/neutron/+bug/2037239 Just reported by haleyb - tests failing with "x is not active on any of the L3 agents" High * [tempest] Test "test_multicast_between_vms_on_same_network" radonmly failing - https://bugs.launchpad.net/neutron/+bug/2036603 Unassigned. Random recent failure in that test * Neutron tempest plugin zuul job definitions uses deprecated regex syntax - https://bugs.launchpad.net/neutron/+bug/2037034 Fix by ykarel: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/896188 * neutron-ovn-metadata-agent dies on broken namespace - https://bugs.launchpad.net/neutron/+bug/2037102 Not a common case but it can keep the agent down until fixed Patch by felix.huettner: https://review.opendev.org/c/openstack/neutron/+/896251 New * Reader can update object tag - https://bugs.launchpad.net/neutron/+bug/2037002 *_reader roles were not cooperating when I tried to reproduce this in devstack - needs another set of eyes Medium * Neutron fails to respawn radvd due to corrupt pid file - https://bugs.launchpad.net/neutron/+bug/2033980 When radvd crashes (it can happen like in cases described by users in LP), neutron does not respawn it properly - it works fine when we are restarting/killing it Patch by haleyb: https://review.opendev.org/c/openstack/neutron/+/895832 * [OVN] The API worker fails during "post_fork_initialize" call - https://bugs.launchpad.net/neutron/+bug/2036607 Enhancement to better handle restarts (as tested by tobiko). Patches by ralonsoh: https://review.opendev.org/c/openstack/neutron-lib/+/895940 https://review.opendev.org/c/openstack/neutron/+/895946 https://review.opendev.org/c/openstack/neutron/+/896009 * [ovn-octavia-provider] Fix issue when LRP has more than one address - https://bugs.launchpad.net/neutron/+bug/2036620 Fix by froyo - https://review.opendev.org/c/openstack/ovn-octavia-provider/+/895826 * A port that is disabled and bound is still ACTIVE with ML2/OVN - https://bugs.launchpad.net/neutron/+bug/2036705 Unassigned. Different behaviour compared to ML2/OVS (where status is down) * [pep8] Pylint error W0105 (pointless-string-statement) in random CI executions - https://bugs.launchpad.net/neutron/+bug/2036763 Random failure, fix by ralonsoh: https://review.opendev.org/c/openstack/neutron/+/895975 * radvd seems to crash when ipv4 addresses are supplied as nameservers to ipv6 subnets - https://bugs.launchpad.net/neutron/+bug/2036877 Unassigned. Follow-up enhancement to https://bugs.launchpad.net/neutron/+bug/2033980 to prevent adding IPv4 servers to radvd config * slow port creation with a large amount of networkrbacs - https://bugs.launchpad.net/neutron/+bug/2037107 Unassigned. We pushed an enhancement for similar slowness in https://bugs.launchpad.net/neutron/+bug/1918145 but not fixing this case. sqlalchemy/SQL experts welcome there Incomplete * subnet's gateway ip can be unset while attached to router - https://bugs.launchpad.net/neutron/+bug/2036423 Regards, -- Bernard Cafarelli

1 0

[kolla-ansible][keystone][skyline] Keystone use SSO for authentication
by Nguyễn Hữu Khôi 24 Sep '23

24 Sep '23

Hello guys. I want to share a lab to help newbies understand how setup Keystone and Skyline to use Google SSO for authentication, https://github.com/ngyenhuukhoi/openstack-note/blob/main/skyline%20with%20s… I will try to contribute what I can for newbies and community. Nguyen Huu Khoi

3 2

[aodh][mistral][solum][release][requirements] Feature freeze exception for wsme, sphinxcontrib-pecanwsme
by Stephen Finucane 22 Sep '23

22 Sep '23

o/ I'd like to request a feature freeze exception for the aforementioned packages to include fixes we recently merged: * WSME 0.12.1 includes two fixes to the Sphinx extension to fix compatibility with recent Sphinx versions. There are also additional fixes to address compatibility with Python 3.11 (by switching from nose to pytest, by replacing use of pkg_utils with importlib.metadata, and by replacing use of inspect.getargspec with inspect.getfullargspec). * sphinxcontrib-pecanwsme 0.11.0 includes a fix for Python 3.11 compatibility (replacing use of inspect.getargspec with inspect.getfullargspec), drops support for Python < 3.8, and removes the use of six. I've included a summary of the git logs below. I would argue that both version bumps are low-risk and address issues we're seeing in the gates of multiple projects. I would also argue that bumping these versions is a lower risk strategy than the alternative proposal, namely the reintroduction of a cap on the Sphinx version used to a version released nearly 18 months ago [2] (!!). Finally, I would argue that this would be the preferred approach by our packagers (zigo, are you there?). The change is available [3] and waiting for reviews. Cheers, Stephen PS: Why WSME 0.12.1 rather than 0.12.0, you ask? You can blame a typo [4] for that 🙈 [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-September/0351… [2] https://pypi.org/project/Sphinx/4.5.0/ [3] https://review.opendev.org/c/openstack/requirements/+/896195 [4] https://review.opendev.org/c/x/wsme/+/896153

2 1

[release] Release countdown for week R-1 Sept 25-29
by Herve Beraud 22 Sep '23

22 Sep '23

Development Focus ----------------- We are on the final mile of the 2023.2 Bobcat development cycle! Remember that the 2023.2 Bobcat final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. September 28, 2023 is the deadline for final 2023.2 Bobcat release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on October 4, 2023. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2024.1 Caracal development cycle, including discussing Forum and PTG sessions content, in preparation of the 2024.1 Caracal Virtual PTG (October 23-27, 2023). Actions ------- Watch for any translation patches coming through on the stable/2023.2 branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/2023.2 branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final 2023.2 Bobcat release: October 4, 2023 2024.1 Caracal Virtual PTG: October 23-27, 2023 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[Nova][Neutron] Help troubleshooting metadata service error 404 (Ussuri)
by Jérôme BECOT 22 Sep '23

22 Sep '23

Hello, I am operating several OpenStack Ussuri clouds and we lately have random troubles with the metadata service. We run all our networks as provider networks. The metadata service works fine for months some hosts can't get their metadata with a 404 error I restarted nova-api, neutron-dhcp-agent and neutron-metadata-agent on all controllers but we still experience 404 on random nodes: ssh 10.60.51.130 $ ip r s ... 169.254.169.254 via 10.60.51.121 dev eth0 $ curl -s http://169.254.169.254 <html> <head> <title>404 Not Found</title> </head> <body> <h1>404 Not Found</h1> The resource could not be found.<br /><br /> </body> </html> ssh 10.60.51.131 $ ip r s ... 169.254.169.254 via 10.60.51.121 dev eth0 $ curl -s http://169.254.169.254 {"uuid": "ee6e8dea-796b-4a56-bb1e-1c38f4ac9030", "meta": {"Created By": "terraform"}...} $ grep "10.60.51.131" /var/log/neutron/neutron-metadata-agent.log 2023-09-22 12:41:10.687 21954 INFO eventlet.wsgi.server [-] 10.60.51.131,<local> "GET /openstack/latest/meta_data.json HTTP/1.1" status: 200 len: 2729 time: 0.3817778 $ grep "10.60.51.130" /var/log/neutron/neutron-metadata-agent.log $ grep "10.60.51.130" /var/log/nova/nova-api.log # on all controllers $ grep "10.60.51.131" /var/log/nova/nova-api.log # on all controllers 2023-09-22 12:41:10.682 57433 INFO nova.metadata.wsgi.server [req-1d222a75-ccb4-49bc-8b17-2e2e81dc5f9b - - - - -] 10.60.51.131,1.2.3.4 "GET /openstack/latest/meta_data.json HTTP/1.1" status: 200 len: 2710 time: 0.2587621 Can you help me to troubleshoot this behaviour for some hosts ? Regards -- *Jérôme B*<https://www.deveryware.com>

2 5

Problem with Barbican
by Derek O keeffe 22 Sep '23

22 Sep '23

Hi all, Hopefully someone may be able to give me some info/advice on this one. I've been asking in the IRC chat but unfortunately we couldn't get to the bottom of it, I'm hoping someone here may not be in the chat but able to help :) So I have an Openstack AIO that I'm trying to test Barbican on with a Thales Luna HSM. I get through the instructions to the point where I successfully create the HMAK and MKEK keys. After this I try the following commands: openstack secret store --name mysecret1 --payload testPayload openstack volume create --size 1 --type LUKS 'encrypted volume' Both of those fail and the logs from the Barbican container are here: Paste #bU1E0joDdf4eWiV8wjlj | LodgeIt! | | | | Paste #bU1E0joDdf4eWiV8wjlj | LodgeIt! | | | I have made sure that "library_path: /opt/barbican/libs/libCryptoki2.so in Barbican.conf actually exists so I have no idea really where to look after this, I can't see any info as to where Barbican is trying to find the crypto plugin or maybe do I need to install something else manually?? Anyway I hope someone might have some useful info or advice to help and thanks all for reading. Regards,Derek

2 1

[neutron] Thanks for the Bobcat release (and now let's continue working in Caracal)
by Rodolfo Alonso Hernandez 22 Sep '23

22 Sep '23

Hello Neutrinos: Before stepping down as Neutron PTL, I would like to thank you for your commitment and work done during the last two releases. Let's keep Neutron, the stadium projects and OpenStack in general healthy and growing every day. We are now in the RC phase and we should be focused on delivering the best possible code for Bobcat cycle. So far I think we are going to deliver a good quality release. And in advance for the next cycle, let me bring here the hot topics we have right now in gerrit. I would ask you, as I've done during the last year, to spend some time reviewing them in order to continue the development of these features. The sooner we merge them in the Caracal cycle, the better we'll test it during the release development period. Please remember this list is just a brief summary of the most relevant features under review. ** Specs ** https://review.opendev.org/c/openstack/neutron-specs/+/891204: Add spec for partial support for OVN Interconnect RFE ** RFEs and important bugs ** https://review.opendev.org/q/topic:neutron_ovn_l3_scheduler: a series of patches related to LP#2023993, that will improve the OVN L3 scheduler. https://review.opendev.org/c/openstack/neutron/+/894026: support for IPv6 in the OVN metadata, closing a present gap between ML2/OVS and ML2/OVN. https://review.opendev.org/c/openstack/neutron/+/882832: provide a new parameter to define the port HW offload capability, instead of writing directly on the port binding profile. https://review.opendev.org/q/topic:distributed_metadata_data_path: a series of patches for ML2/OVS, to provide distributed metadata capabilities. https://review.opendev.org/q/topic:2023-aa-l3-gw-multihoming: a series of patches to provide to ML2/OVN multihoming (active-active) L3 GW capabilities. Regards.

1 0

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 22 Sep '23

22 Sep '23

Hello Neutrinos: Due to the lack of agenda [1], today's meeting is cancelled. Have a nice weekend. [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

Requirements FFE to return Sphinx to known working version
by Erno Kuvaja 21 Sep '23

21 Sep '23

Hi all, I'm writing to request FFE for https://review.opendev.org/c/openstack/requirements/+/896018 Revert "Bump Sphinx to the latest version" as it broke the gate of at least following projects: Aodh https://zuul.opendev.org/t/openstack/build/5df111c602944396bf6e334e1bec4e42 Solum https://zuul.opendev.org/t/openstack/build/e4b170cc25f2428caadce8870d27c62e Mistral https://zuul.opendev.org/t/openstack/build/a3e00a6312cf46059fa81c56fe9b5e11 Stephen kindly provided monkeypathing for Aodh as alternative https://review.opendev.org/c/openstack/aodh/+/896125 With kind regards that we shouldn't revert this breaking patch due to it being breaking via wsme dependency that is apparently not really maintained anymore. I'd be easily agreeing with that if Aodh was the only project suffering the breakage or using it at all, but the lib is in use for about dozen openstack projects and this dependency bump broke the gates for three of them. Other alternative for this is that wsme would get released (the fix is merged already) and we would bump that in the upper constraints. I would personally prefer any other option than needing to monkeypatch/vendor the wsme code in the projects long enough that we can find a solution to remove it as dependency across. Thanks for looking into this, Erno "jokke" Kuvaja

2 1