September 2024 - openstack-discuss

[neutron] OpenStack compute nodes L3 agent reconfiguration `dvr` mode to `dvr_no_external`
by frantisek.reznicek.szn＠gmail.com 14 Sep '24

14 Sep '24

Dear upstream OpenStack colleagues, we recently identified a lot of allocated "network:floatingip_agent_gateway ports" as we were running in pure dvr / dvr_snat modes (compute/network nodes) as also discussed in thread [1]. As we want to reduce amount of "network:floatingip_agent_gateway ports", our approach is to migrate majority of compute nodes from L3 agent `dvr` to `dvr_no_external` mode. Although we have success with empty nodes where we can see the node working as expected so north/south traffic now goes via network nodes on the non-empty compute nodes we struggle. The reconfiguration steps we are taking: 1. our maintenance per each compute node (still in `dvr` mode) 1.1. we first identify all VMs with FIP addresses, keep track of the FIPs and connected ports 1.2. we disconnect each FIP from port 1.3. all VMs on the compute node does not have FIPs 1.4. compute node L3 agent configuration is switched `dvr` -> `dvr_no_external` 1.5 delete `hypervisor network:floatingip_agent_gateway` port 1.6. re-attach all tracked FIPs 1.7. test FIP traffic At the step 1.7. we can see FIPs are not accessible after L3 agent re-configuration. Revert of the L3 agent configuration into `dvr` mode helps to get back the FIP connectivity. Our questions are: 1. Principally, can we get rid of `hypervisor network:floatingip_agent_gateway` ports by switching L3 agent to dvr_no_external mode? Can you think of a better way? 2. Would you recommend other steps how to migrate drom `dvr` to `dvr_no_external`? [2] Is it necesary to restart whole neutron / OVS or reconfigured L3 agent is just enough? Hope for your reply. ;-) Kind Regards, František [1] https://lists.openstack.org/pipermail/openstack-dev/2016-June/096384.html [2] https://opendev.org/openstack/neutron/src/branch/master/releasenotes/notes/…

3 2

[release] Release countdown for week R-2
by Thierry Carrez 13 Sep '24

13 Sep '24

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the 2024.2 Dalmatian deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/2024.2 branch creation for all deliverables that have not branched yet, using the latest available 2024.2 Dalmatian release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/2024.2 branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/2024.2 branch before releasing out of the stable/2024.2 branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2025.1 Epoxy development, though the focus should still be on finishing up 2024.2 (Dalmatian) until the final release. Opening up the new development cycle is also a good opportunity to teams to revise their zuul jobs and used nodesets and clean up all unnecessary ones. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final 2024.2 Dalmatian release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targeted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the 2024.2 Dalmatian version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: September 26th, 2024 (R-1 week) Final 2024.2 Dalmatian release: October 2nd, 2024 2025.1 Epoxy Project Teams Gathering: October 21-25, 2024 -- Thierry Carrez (ttx)

1 0

PTG October 2024 Teams List
by Kendall Nelson 13 Sep '24

13 Sep '24

Hello Everyone! The October 2024 Project Teams List is official! The following teams will be attending our Project Team Gathering, taking place October 21-25, 2024! Projects + Teams - OpenInfra Foundation Teams - - Diversity WG - Kata Containers - StarlingX - OpenStack - - Services - - Blazar - Cinder - CloudKitty - Designate - Glance - Horizon - Ironic - Keystone - Kolla - Manila - Neutron - Nova - Octavia - OpenStack-Ansible - OpenStack-Helm - QA - SDK/CLI - Sunbeam - Tacker - Other OpenStack Teams - OpenStack Security SIG - OpenStack Technical Committee - Public Cloud SIG - Adjacent Open Source Communities - - OceanBase If your team was planning to meet and isn’t in this list, please contact ptg(a)openinfra.dev IMMEDIATELY. Soon I will be contacting moderators to sign up for time via the PTGBot[1] once I have it configured for the teams that are signed up to attend the event. Otherwise, please don't forget to register[2] — its FREE! As usual, feel free to let us know if you have any questions! Thanks! [1] PTGBot Docs: https://github.com/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: http://ptg.openinfra.dev/

1 0

On pre-commit, black, ruff, ruff-format and everything else $linter related
by Stephen Finucane 13 Sep '24

13 Sep '24

o/ Seeing as we've been doing quite a bit of experimentation on this topic in the SDK team recently, and it's come up in random discussions a few times over recent days, I thought it might be helpful to share a few tips and tricks on how our linting stored has evolved across SDK deliverables. Hopefully it's helpful to someone. Historically, teams have provided a `pep8` tox target to run their linters. Originally this would have run flake8 or the hacking wrapper, but over the years these targets have expanded to cover other linters like bandit, doc8 and mypy, as well as various flake8 plugins. In recent times, we have been slowly introducing use of the pre-commit tool [1]. Initially this was purely additive, as it's a nice help for users working in a terminal (like me!) and mostly duplicated what was defined in the `pep8` target. This duplication led to issues where pre-commit was doing slightly different things from the `pep8` target, so we have evolved this so that the `pep8` target now simply calls pre-commit. This is pretty easy to do now since most if not all of the linters in common use across OpenStack - flake8, hacking, doc8, bandit, etc. - provides pre-commit hooks. I recommend anyone using pre-commit does the same thing otherwise these thing can drift. For example, your pep8 target can become: [testenv:pep8] description = Run style checks. skip_install = true deps = pre-commit commands = pre-commit run --all-files --show-diff-on-failure We've since evolved this further to start changing the linters we've used in general. We first introduced black [2], the automatic code formatting tool. The rationale behind this was to remove the need to even think about code style and focus on the actual semantic change. We're already overburdened, and going back and forth on style issues is a waste of everyone's time. Contributors (particularly new ones) can simply install pre-commit or use the `pep8` tox target and their code will be automatically restyled in a generally non- offensive manner. Is it perfect? No, but it's close enough that we've decided we don't care. When we have introduced black, we have typically kept the changes introduced by black separate from the changes to e.g. the `.pre-commit- config.yaml` or `tox.ini` file. This allows us to introduce a `.git-blame- ignore-revs` file afterwards which some software forges (like GitHub, though sadly not Gittea (yet!)) can use to ignore these bulk update changes when using `git-blame`. You can also configure git locally to ignore this, and I've made an effort to place comments in the files whenever I've added them. In addition to black, we also added other linters like bandit [3] and pyupgrade [4], including these in pre-commit so that they would run automatically on commit and in CI. However, as anyone reading the orange site or surveying the broader Python landscape might be aware, the ruff [5] linter and formatter has been gaining steam and is pretty mature at this point. In recent weeks, we have been migrating pretty much all our linters and formatters - black, pyupgrade, bandit and (most of) flake8 - to ruff and ruff-format. We have kept hacking but only enable the H (hacking) ruleset plus any custom rules for now, but at some point we will explore getting these few hacking rules into ruff or writing them off. In any case, this migration has resulted in a significantly trimmer pre- commit-config.yaml file (and much faster runtime to boot). You can see the end result on a repo like e.g. osc-lib [6]. All in all, I think I can recommend this approach for anyone interested in pursuing it. Linters are far from the most important aspect of development, but I've found these tools to yield a nice improvement in developer experience. Top tips: * Have your 'pep8' target (and any other linter-related target run 'pre-commit' rather than the linters themselves), and don't forget to remove linters from test-requirements.txt once you do (with the exception of hacking if you have custom hacking rules) * Consider using ruff and ruff-format in place of all non-hacking linters/formatters: it's seriously fast and provides rules to cover most of these. * When applying ruff-format or the UP (pyupgrade) ruff rules, do it separately so you can add the commit ID to a .git-blame-ignore-revs file. You should be able to do this pre-merge since Gerrit/Zuul merge patches rather than rebasing them so the commit ID won't change. Other points: * When we first introduced pre-commit, some people noted that installing from Git rather than PyPI introduced a possible attack vector since tags can be changed. Given we only use a small, curated set of linters from trusted sources, I don't know how much of an issue this is but I'll raise it here. * Difficulty backporting code has been highlighted as an blocker for running a formatter like black or ruff-format. We don't do many backports in SDK, OSC etc. so this hasn't been a huge issue. If it were though, we would simply apply the formatter to the stable branch first before backporting. Hope this helps, Stephen [1] https://pre-commit.com/ [2] https://github.com/psf/black [3] https://github.com/PyCQA/bandit [4] https://github.com/asottile/pyupgrade [5] https://github.com/astral-sh/ruff [6] https://opendev.org/openstack/osc-lib/

3 3

[horizon] Weekly meeting cancelled Sept 18
by Tatiana Ovchinnikova 12 Sep '24

12 Sep '24

Hello team, I'm on PTO next week, so I'm cancelling the weekly meeting on September 18. See you on September 25! Regards, Tatiana

1 0

[kolla] Proposing Sven Kieske as Kolla and Kolla-Ansible core
by Michał Nasiadka 12 Sep '24

12 Sep '24

Hello Koalas, I would like to propose Sven Kieske as a core reviewer for Kolla and Kolla-Ansible Sven has been very active and providing insightful feedback to reviews as well as code contributions. If I won’t receive any negative votes until 11th of September - I’ll add Sven in Gerrit on the Kolla weekly meeting on that day. Thanks! Michał Nasiadka mnasiadka(a)gmail.com

7 7

[API] Gitea API return 404
by tzing0013＠gmail.com 11 Sep '24

11 Sep '24

Hi everyone， I'm testing Gitea API, I visit the web[1], and click "Try is out", no matter what I enter there, it returns 404, and I also test "/contents" [2], that's ok. [1] https://opendev.org/api/swagger#/repository/repoListPullRequests [2] https://opendev.org/api/swagger#/repository/repoGetContentsList

2 4

[openstack-ansible]: Move one control node to different chasis
by Ram Ram 11 Sep '24

11 Sep '24

Hi All We are currently running 3 control nodes with LXC containers deployed using openstack-ansible release ussuri and need to move 1 control node on HP blade from one chasis to another chasis. Is there any recommended way/procedure to do that? can we directly move the HP blade from one chasis to another? or we need to install new control node and decommission the older one? Regards Rambo

3 3

[kolla][vpn-as-a-service] docker container missing
by garcetto 10 Sep '24

10 Sep '24

good afternoon, installed all-in-one ubuntu 22.04 based kolla-ansible version 2024.1, so far so good. tried to enable vpnaas, folllowing the instructions here https://docs.openstack.org/kolla-ansible/2024.1/reference/networking/neutro… but still missing the container "neutron_vpnaas_agent". i checked the ansible playbook but see no evidence of deployment of this container, what am i doing wrong? thank you.

3 2

[charms] Proposing Rodrigo Barbieri for OpenStack Charms stable core
by Edward Hope-Morley 10 Sep '24

10 Sep '24

Hi everyone, I'd like to propose Rodrigo Barbieri for the OpenStack Charms stable maintenance team. Rodrigo has been a contributor to the charms for many years and has an impressive history of contributions to across all the OpenStack charms. He always demonstrates an attention to detail and provides insightful feedback in reviews and as such I believe he would make a valuable addition to our charms-stable maintenance core team. Thank you for your contributions to the project Rodrigo! Regards, Ed

2 1