September 2024 - openstack-discuss

[sdk] possible bug in the openstacksdk/cloud?
by astepanov2007＠gmail.com 16 Sep '24

16 Sep '24

Hello, Recently, I was debugging an issue related to the ansible openstack.cloud.server module while creating an instance with floating ip attached. A part of stack trace goes below: ... File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_compute.py", line 1013, in create_server server = self.wait_for_server( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_compute.py", line 1153, in wait_for_server server = self.get_active_server( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_compute.py", line 1200, in get_active_server return self.add_ips_to_server( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_network_common.py", line 1412, in add_ips_to_server server = self._add_ip_from_pool( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_network_common.py", line 1247, in _add_ip_from_pool f_ip = self.create_floating_ip( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_network_common.py", line 765, in create_floating_ip return self._neutron_create_floating_ip( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_network_common.py", line 824, in _neutron_create_floating_ip network_id = network['id'] ~~~~~~~^^^^^^ TypeError: 'NoneType' object is not subscriptable Tracing this down to openstacksdk python module I have found a suspicious place in the openstacksdk code: if network_name_or_id: try: network = self.network.find_network(network_name_or_id) except exceptions.NotFoundException: raise exceptions.NotFoundException( "unable to find network for floating ips with ID " "{}".format(network_name_or_id) ) network_id = network['id'] https://github.com/openstack/openstacksdk/blob/de07fd02639eb565f10956b612ed… I suppose that this call to self.network.find_network lacks "ignore_missing=True" param. E.g.: network = self.network.find_network(network_name_or_id, ignore_missing=True) This fixed my issue with floating ips, but I'm not sure such patch is suitable for the mainline code of the openstacksdk. Am I correct? Regards, Alexander.

2 2

[neutron] Bug Deputy Report September 9 - 15
by Lucas Alvares Gomes 16 Sep '24

16 Sep '24

Hi, This is the Neutron bug report from September 9th to 15th. *High:* * https://bugs.launchpad.net/neutron/+bug/2080072 - "Failed to delete vpnaas ipsec-site-connections with 502 error, ORM session: SQL execution without transaction in progress" Unassigned * https://bugs.launchpad.net/neutron/+bug/2080199 - "Functional jobs failing with "Too many open files"" Assigned to: Lajos Katona * https://bugs.launchpad.net/neutron/+bug/2080447 - "Update firewall policy interface timeout when it's associated with a large number of rules " Assigned to: dongdong *Medium:* * https://bugs.launchpad.net/neutron/+bug/2080314 - "ML2 plugin: No consumers for q-agent-notifier-port-delete_fanout exchange result in unroutable RabbitMQ messages" Unassigned *Low:* * https://bugs.launchpad.net/neutron/+bug/2079996 - "[OVN] OVN metadata agent check to restart the HAProxy container" Assigned to: Rodolfo Alonso *Needs further triage:* * https://bugs.launchpad.net/neutron/+bug/2080492 - "[OVN] VIP port does not come up when its virtual-parents are trunk sub-ports" Cheers, Lucas

1 0

[cinder] Retype encrypted cinder volume to non-encrypted volume
by Jan Wasilewski 14 Sep '24

14 Sep '24

Hi, I would like to ask about the procedure to retype a Cinder volume that is in-use (bootable volume, connected to a VM) from an encrypted (LUKS) type to a non-encrypted type (1000 IOPS). I tried to do this via the CLI[1], and while it seemed to work (at least according to the CLI output), the process didn’t complete successfully. Cinder logs[2] indicate that everything looks more or less fine: the volume is created, the volume migration is OK, and the retype is marked as completed. However, in the end, it doesn’t work (final output of [1]). I reviewed the blueprint at https://blueprints.launchpad.net/cinder/+spec/retype-encrypted-volume, which appears to be implemented. Am I doing something wrong, or does this functionality not work as expected? Thanks in advance for your help and guidance. /JW *[1] Retype from CLI: https://paste.openstack.org/show/bVpFT82oURnanXkixreT/ <https://paste.openstack.org/show/bVpFT82oURnanXkixreT/>[2] cinder-logs: https://paste.openstack.org/show/b5rZpWNMqdi6qdpjaDfg/ <https://paste.openstack.org/show/b5rZpWNMqdi6qdpjaDfg/>*

2 1

Re: Migratekit: near-live migrations from VMware to OpenStack
by Oliver Weinmann 14 Sep '24

14 Sep '24

Hi Mohammed, We struggled using virt-v2v directly with OpenStack. Our approach was using ovftool to export the VM as OVA and then create a qcow2 image that we can import in OpenStack. So many manual steps involved. So I tested your tool aganst vsphere 7.x vcenter. But I just can't manage to get it working. It keeps complaining about the path of the source VM. I can use the following just fine with virt-v2v: virt-v2v -v -x --password-file pass.txt -ic vpx:// user123(a)vcenter.somedomain.local /GE%Office%20One/Projects/esx01.somedomain.local?no_verify=1 test-vm-01 Using the same in your tool: docker run -it --rm --privileged \ -v /dev:/dev \ -v /usr/lib64/vmware-vix-disklib/:/usr/lib64/vmware-vix-disklib:ro \ --env-file <(env | grep OS_) registry.atmosphere.dev/library/migratekit:latest migrate \ --vmware-endpoint vcenter.somedomain.local \ --vmware-username user123 \ --vmware-password XXXXXX \ --vmware-path /GE%Office%20One/Projects/esx01.somedomain.local/test-vm-01 Results in: Error: vm '/GE%Office%20One/Projects/ esx01.somedomain.local/test-vm-01 ' not found I tried many different variants of the path none has worked. Is there a way to lookup the path of a VM? I can also use: virsh -c 'vpx:// user123(a)vcenter.somedomain.local /GE%Office%20One/Projects/esx01.somedomain.local?no_verify=1 list --all which shows me all VMs running on that particular ESXi host. Best Regards, Oliver

2 9

neutron
by Saeed 14 Sep '24

14 Sep '24

I run some scenarios with ML2/OVN and ML2/OVS (in all tests security-group has no rule) With the OVN backend, when port security is enabled I can NOT watch the unicast traffic of other instances by tcpdump, but when port security is disabled I can watch other unicast traffic for other instances. I also run the same scenarios when the backend is Openvswitch only (not OVN) I can watch unicast traffic of other instances (enabling or disabling port security has no impact). Is there any link or reference that explicitly explains this issue and the impact of OVN in OpenStack for dropping other traffic? I dump flow rules from openvswitch and compare them, and I'm pretty sure that the OVN adds some rules to drop other unicast traffic. Can I drop the unicast traffic of other instances in Openvswitch when I do not use OVN as the backend? (automatically or by configuration)

1 0

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

13 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

(외부메일) [heat][heat-cinder] How can I use the Cinder volume extend in Heat?
by 박광우 13 Sep '24

13 Sep '24

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