August 2024 - openstack-discuss - lists.openstack.org

[all] Please remove sphinxcontrib-*diag from your (docs) dependencies
by Stephen Finucane 26 Aug '24

26 Aug '24

o/ A large number of projects are using the sphinxcontrib-blockdiag, sphinxcontrib- nwdiag and sphinxcontrib-seqdiag projects in their documentation. These packages are no longer maintained and have not seen releases in over 3 years. They are also not compatible with Pillow 10.x and are thus preventing us from bumping Pillow to a version that has pre-built Python 3.12 wheels [1][2]. Please remove these dependencies. In Nova, we decided to just take the build assets (SVG or PNG) and use these directly in our documentation [3]. Absent a better idea, this approach will work for you also. As someone with Python 3.12 (and soon, 3.13) as their default Python version, I would reallyu like to get Pillow bumped early in E, so by doing this work now we avoid broken docs CI jobs when that bump happens. Cheers, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/927102 [2] https://bugs.launchpad.net/ironic/+bug/2026345 [3] https://review.opendev.org/c/openstack/nova/+/906309

1 0

[telemetry] [kolla] help measuring neutron router bandwidth
by garcetto 26 Aug '24

26 Aug '24

good afternoon, i would like to get bandwidth usage of neutron router interfaces, using kolla-ansible, enabled ceilometer and gnocchi, but if i try to enumerate with: openstack metric resource list --max-width 1000 under type i dont see BANDWIDTH as indicated in docs ( https://docs.openstack.org/ceilometer/zed/admin/telemetry-measurements.html… ) [image: image.png] what am i missing? thank you.

1 0

[neutron][eventlet] RPC handler thread model incompatible with eventlet
by Rodolfo Alonso Hernandez 26 Aug '24

26 Aug '24

Hello Neutrinos: I think you are aware about the effort to move all CI jobs to use WSGI. Other OpenStack projects have already migrated to this implementation to the detriment of the eventlet server. That will help us in the evenlet deprecation task. However some modules are still using eventlet, thus even when using WSGI in the Neutron API, it is still needed to monkey patch the system libraries. The most recent case is LP#2075147 [1]. To that purpose [2] was proposed. Again, we had another adverse effect of [2] in the RPC event handler, that is used to inform the agents, via RPC, about resource events (creation, update, deletion); this is why only the ML2/OVS jobs were affected in the CI, as opposed to ML2/OVN that is not using RPC. With [2] in place, the RPC handler thread model was not working correctly (check LP#2077790 [3]). The thread in charge of sending the RPC messages got stuck during the DB retrieval process or the RPC cast itself. That was leading to a delay in the event processing in the agents. In the CI, the most affected tests were those related to the SG rule creation/deletion. The OVS agent didn't receive on time the SG rule creation/deletion and didn't create the needed OF rules in the local OVS. In order to fix this issue, [4] has been proposed. This patch proposes to handle the RPC messages in the same thread of the API call. Because the RPC call is a ``cast`` call (no reply is expected), that won't block the API call and will just increase the time a bit. Once eventlet is deprecated and removed, it would be possible to go back to the previous model using a thread (preemptive in this case) to make the RPC calls. Regards. [1]https://bugs.launchpad.net/neutron/+bug/2075147 [2]https://review.opendev.org/c/openstack/neutron/+/925376 [3]https://bugs.launchpad.net/neutron/+bug/2077790 [4]https://review.opendev.org/c/openstack/neutron/+/926922

1 1

[neutron] bug deputy report for week of 2024-08-19
by Bence Romsics 26 Aug '24

26 Aug '24

Hi All, We had the following new bugs last week: OVN-Octavia (not yet triaged): * https://bugs.launchpad.net/neutron/+bug/2077399 OVN-Octavia maintainers please have a look! High: * https://bugs.launchpad.net/neutron/+bug/2077790 [eventlet] RPC handler thread model is incompatible with eventlet fix proposed: https://review.opendev.org/c/openstack/neutron/+/926922 Medium: * https://bugs.launchpad.net/neutron/+bug/2077532 Two floatingip_agent_gateways are created which are bound to the same agent. assigned to Anton Low: * https://bugs.launchpad.net/neutron/+bug/2077351 "Error formatting log line" sometimes seen in l3-agent log fix proposed: https://review.opendev.org/c/openstack/neutron/+/926566 Incomplete: * https://bugs.launchpad.net/neutron/+bug/2077533 An error in processing one DVR router can lead to connectivity issues for other routers discussing with Anton whether a standalone bug or a repercussion of #2077532, will follow up RFE: * https://bugs.launchpad.net/neutron/+bug/2077596 [rfe][fwaas] Add normalized_cidr column to firewall rules Cheers, Bence

1 0

[release] [ironic] [swift] Missing releases
by Thierry Carrez 26 Aug '24

26 Aug '24

Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Dalmatian cycle: bifrost ironic-prometheus-exporter ironic-python-agent-builder ironic-ui networking-baremetal networking-generic-switch swift Those should be released ASAP, and in all cases before September 13th, 2024, so that we have a release to include in the final 2024.2 release. -- Thierry Carrez (ttx)

2 1

[release] Release countdown for week R-5
by Thierry Carrez 23 Aug '24

23 Aug '24

Development Focus ----------------- We are getting close to the end of the 2024.2 "Dalmatian" cycle! Next week on August 29th, 2024 is the dalmatian-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the 2025.1 "Epoxy" cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on August 29th, 2024. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2024.2 branching request with the review. As an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… Dalmatian-3 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also a good time for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Dalmatian-3 milestone (feature freeze): August 29th, 2024 (R-5 week) Cycle Highlights Due: September 5th, 2024 (R-4 week) RC1 deadline: September 13th, 2024 (R-3 week) Final RC deadline: September 26th, 2024 (R-1 week) Final 2024.2 Dalmatian release: October 2nd, 2024 OpenInfra Summit Asia: September 3-4, 2024 -- Thierry Carrez (ttx)

1 0

Openstack Instance Snapshot and Rescue Problem
by meteccinar＠gmail.com 23 Aug '24

23 Aug '24

Hi everyone, We use Ceph in Cinder as Block Storage. Firsly, we create a VM with volume (volume create automatically) and we write a data in the VM and take an snapshot after wrote data. Then we write data in main VM again and take second snapshot. But, when we try to rescue instance related main VM with first snapshot, there was an error occured. Nova Log: 2024-08-22 08:23:25.594 19 WARNING nova.compute.api [None req-eb3b4856-c8be-4926-be51-99aaec4de0e0 41040b4a21e34904b6906c12b228d8e9 67ddd9f771be452a808ba3458af544f8 - - default default] Unable to rescue an instance using a volume snapshot image with img_block_device_mapping image properties set Horizon Output: Requested rescue image 'ddc2df28-c4f5-434b-9f9a-030e56425fc5' is not supported (HTTP 400) (Request-ID: req-bd8037a1-3cd4-43fe-a945-e809b1f8ce16) Ceph Block: https://imgtr.ee/images/2024/08/22/2108d8aacee12eaf800377593a229659.png Instance Snapshot Image: https://imgtr.ee/images/2024/08/22/ca1fa81683acc0518ac161e7f97fda0e.jpeg Could it be any configuration wrong ? We will wait for your answers. Thanks.

5 8

[nova][OpenStackSDK][vitrage][zaqar] broken gates in libraries
by Elõd Illés 22 Aug '24

22 Aug '24

Hi teams in $subject, Since we are close to Feature Freeze period and Dalmatian-3 milestone, the relmgt team checked the status of the gates of libraries [1] and the following repositories seem to have broken gates on their master branches: python-novaclient osc-lib python-vitrageclient python-zaqarclient Could the teams check the broken jobs please and fix them as soon as possible? [1] https://review.opendev.org/q/topic:release-health-check-cwi-dalmatian+is:op… Thanks in advance, Előd Illés irc: elodilles @ #openstack-release

1 0

[neutron] dsvm-fullstack test suite: issues with ovs datapaths when running locally?
by Ihar Hrachyshka 22 Aug '24

22 Aug '24

Hi all, This must be simple to do, but when I try to follow the guide in a vagrant box to run the fullstack suite locally, I am hitting a wall. I suspect I miss something obvious but I can't figure it out. I'm following this doc: https://docs.openstack.org/neutron/latest/contributor/testing/fullstack.htm… I start with an empty ubuntu 22.04 vagrant box with enough memory, disk, cpu. Then I check out the neutron repo and devstack into my home dir. I also `mkdir -p /opt/stack/ && chmod a+rwx /opt/stack` and clone `requirements` repo in /opt/stack/requirements. (Otherwise configure_for_func_testing script fails.) Then I execute: export VENV=dsvm-fullstack tools/configure_for_func_testing.sh ~/devstack -i (I am not sure setting VENV envvar is needed, but that's what is in the doc) It successfully completes (I see "Phew, we're done!" message from the script.) I then: $ tox -e dsvm-fullstack neutron.tests.fullstack.test_logging (or any other test case that triggers Open vSwitch) and the test just fails with timeout. And when I look into logs, I see interface additions failing and in vswitchd log: Aug 21 20:24:26 ubuntu ovs-vswitchd[42747]: ovs|00032|bridge|ERR|failed to create bridge br-eth68909740e: No such file or directory Aug 21 20:24:26 ubuntu ovs-vswitchd[42747]: ovs|00031|ofproto|ERR|failed to open datapath br-eth68909740e: No such file or directory Aug 21 20:24:26 ubuntu ovs-vswitchd[42747]: ovs|00030|ofproto_dpif|ERR|failed to open datapath of type system: No such file or directory (there are more errors of the same...) I disabled apparmor as the doc suggests. I also confirmed that the `openvswitch` kernel module is loaded (it is not loaded after ovs and ovn are built from source as part of configure_for_func_testing.sh execution). I also tried to run the suite as root. (I don't think this is needed, but I figured I'll check.) Anyone else running into this? How do you guys execute the suite locally? Ihar

2 2

[all][elections][ptl][tc] Combined PTL/TC 2025.1 cycle Election Nominations Kickoff
by Slawomir Kaplonski 22 Aug '24

22 Aug '24

Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (4 positions) are now open and will remain open until Aug 28, 2024 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained at https://governance.openstack.org/election/#how-to-submit-a-candidacy Please make sure to follow the candidacy file naming convention: candidates/2025.1/<Project_Name or "TC">/<email_address> (for example, "candidates/2025.1/TC/stacker(a)example.org"). The name of the file should match an email address for your current OpenStack Foundation Individual Membership. Take this opportunity to ensure that your OSF member profile contains current information: https://www.openstack.org/profile/ Any OpenStack Foundation Individual Member can propose their candidacy for an available, directly-elected seat on the Technical Committee. In order to be an eligible candidate for PTL you must be an OpenStack Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the 2024.1 to 2024.2 timeframe, Sep 15, 2023 00:00 UTC - Aug 28, 2024 00:00 UTC. Your Gerrit account must also have a verified email address matching the one used in your candidacy filename. Both PTL and TC elections will be held from Sep 04, 2024 23:45 UTC through to Sep 18, 2024 23:45 UTC. The electorate for the TC election are the OpenStack Foundation Individual Members who have a code contribution to one of the official teams over the 2024.1 to 2024.2 timeframe, Sep 15, 2023 00:00 UTC - Aug 28, 2024 00:00 UTC, as well as any Extra ACs who are acknowledged by the TC. The electorate for a PTL election are the OpenStack Foundation Individual Members who have a code contribution over the 2024.1 to 2024.2 timeframe, Sep 15, 2023 00:00 UTC - Aug 28, 2024 00:00 UTC, in a deliverable repository maintained by the team which the PTL would lead, as well as the Extra ACs who are acknowledged by the TC for that specific team. The list of project teams can be found at https://governance.openstack.org/tc/reference/projects/ and their individual team pages include lists of corresponding Extra ACs. Please find below the timeline: PTL + TC nomination starts @ Aug 14, 2024 23:45 UTC PTL + TC nomination ends @ Aug 28, 2024 23:45 UTC TC campaigning starts @ Aug 28, 2024 23:45 UTC TC campaigning ends @ Sep 04, 2024 23:45 UTC PTL + TC elections start @ Sep 04, 2024 23:45 UTC PTL + TC elections end @ Sep 18, 2024 23:45 UTC Shortly after election officials approve candidates, they will be listed on the https://governance.openstack.org/election/ page. The electorate is requested to confirm their email addresses in Gerrit prior to 2024-08-28 00:00:00+00:00, so that the emailed ballots are sent to the correct email address. This email address should match one which was provided in your foundation member profile as well. Gerrit account information and OSF member profiles can be updated at https://review.openstack.org/#/settings/contact and https://www.openstack.org/profile/ accordingly. If you have any questions please be sure to either ask them on the mailing list or to the elections officials: https://governance.openstack.org/election/#election-officials -- Best regards Slawek Kaplonski skaplons(a)redhat.com

5 5