- openstack-discuss - lists.openstack.org

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-2)
by Goutham Pacha Ravi 17 Sep '24

17 Sep '24

Hello Stackers, This week, the community has been actively testing the release candidates from the 2024.2 release cycle [1]; you might notice projects re-spin their RCs if blocking bugs are reported. Our 2025.1 election season will conclude tomorrow, 2024-09-18. If you haven't already voted, please check your emails for a ballot [2]. There haven't been any governance changes made by the OpenStack Technical Committee this week. However, there are several proposals available for the community's review. === Weekly Meeting === Last week's meeting of the OpenStack Technical Committee was held on OFTC's #openstack-tc channel on 2024-09-10. The meeting logs are available on eavesdrop [3]. At this meeting, we started compiling a set of topics for the 2025.2 Project Teams' Gathering in October [4]. Please feel free to suggest any topics that may be of interest to you. Dr. Jens Harbott (frickler) shared a tracker organized by the release management team [5]. The tracker highlighted several projects where PTLs or release management liaisons had not reviewed releases for their projects. The release management team has the authority to tag releases of OpenStack software at any time, but it relies on the release liaisons (and Project Team Leads) to vet any release proposals that they make. If you are a Project Team Lead or a release liaison of an OpenStack deliverable that has releases, please take a look at the tracker and the guide on Liaison Responsibilities [6]. Your timely action will help ensure a smooth delivery process for the software you work on. The next meeting of the OpenStack TC is today, 2024-09-17, at 1800 UTC on OFTC's #openstack-tc channel. Please find the agenda for the meeting on the meeting wiki [7]. === Governance Proposals === ==== Open for review ==== - Add goal to migrate CI/CD jobs to Ubuntu Noble | https://review.opendev.org/c/openstack/governance/+/928078 - charms: retire unmaintained charms | https://review.opendev.org/c/openstack/governance/+/926793 - Appoint Tim Burke as PTL for Swift | https://review.opendev.org/c/openstack/governance/+/928881 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 === Upcoming Events === - 2024-09-18: OpenStack 2025.1 Election Polling Ends - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 2024-10-21: OpenInfra Project Teams Gathering https://openinfra.dev/ptg/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] Combined PTL/TC 2025.1 cycle Election Voting Last Days email: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] TC Meeting IRC Log, 2024-09-10: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-10-18.00.log.html [4] 2025.1 OpenStack TC/PTG planning Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [5] Relmgmt Score Card for Project Teams: https://etherpad.opendev.org/p/r.68bf834e08ac22df93204808812cb166#L479 [6] Relmgmt Liaison Responsibilities: https://docs.openstack.org/project-team-guide/release-management.html#liais… [7] TC Meeting Agenda, 2024-09-17: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

1 0

[tacker] Cancelling IRC meeting
by Yasufumi Ogawa 17 Sep '24

17 Sep '24

Hi tacker team, I'd like to skip IRC meeting this week since I'm out of office today. Thanks, Yasufumi

1 0

[dev][ptl][release] Cycle highlights reminder (2024.2/Dalmatian)
by Jeremy Stanley 17 Sep '24

17 Sep '24

Just a reminder in case anyone missed it: we're technically a week past the deadline for merging 2024.2/Dalmatian release highlights, but if anyone has something they want to mention then now is the time to write, push and approve it! The OpenInfra marketing machine is getting ready to digest what they find at https://releases.openstack.org/dalmatian/highlights.html and put together a press release and package for news outlets. They're interested in whatever you're excited to include, but especially anything related to AI, digital sovereignty, security, or VMware feature parity. Please get your remaining highlights in ASAP!!! -- Jeremy Stanley

1 0

[cloudkitty] Proposing Matt Crees as core reviewer
by Pierre Riteau 17 Sep '24

17 Sep '24

Hello, I would like to nominate Matt Crees as core reviewer for the CloudKitty project. He has been involved for around a year now and has provided valuable contributions, both as reviews and commits. He is also actively participating in our bi-weekly meetings. Cheers, Pierre Riteau (priteau)

2 1

[all][elections][ptl][tc] Combined PTL/TC 2025.1 cycle Election Voting Last Days
by Slawek Kaplonski 17 Sep '24

17 Sep '24

Hi, We are coming down to the last hours for voting in the TC elections. Voting ends Sep 18, 2024 23:45 UTC. Search your Gerrit preferred email address[0] for the messages with subjects like... Poll: OpenStack 2025.1 Cycle Technical Committee Election Poll That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/ What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * find the ID of at least one commit merged to an official deliverable repo[1] over the current and previous cycles, confirm you are an OpenStack Foundation Individual Member[2], and then email the election officials[3] or get in touch in the #openstack-elections channel on the OFTC IRC network. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org and go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/src/tag/to-be-released/reference/p… [2] https://www.openstack.org/profile/ [3] https://governance.openstack.org/election/#election-officials -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[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

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 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 11 Sep '24

11 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

Can only live migrate between hypervisors with same kernel
by sinan86polat＠gmail.com 10 Sep '24

10 Sep '24

Is it normal behavior that instances can only be live migrated between hypervisors running the same kernel? Like this I am not able to patch my hypervisors without downtime on the instances. When I live migrate all instances from hypervisor A to hypervisor B, patch hypervisor A, I cannot migrate the instances back to hypervisor A since it is running a newer kernel. The error is: guest CPU doesn't match specification: missing features: xsaves My source and target hypervisors have both the same CPU. Running OpenStack Rocky.

4 3

Clarification on Custom Role and Sub-User Management in OpenStack
by Thamanna Farhath 10 Sep '24

10 Sep '24

Dear OpenStack Community, I hope this message finds you well. I am reaching out to seek clarification and guidance on a scenario involving custom roles and sub-user management within OpenStack. In our deployment, we have the standard admin role as well as a custom role called super_user, which grants privileges for CRUD operations on projects, role assignments, and user management. We currently have two users with the super_user role, named Alice and John. Each of these super_user accounts manages their own sub-users: Alice manages the ABC sub-users, and John manages the XYZ sub-users. I would like to implement a restriction where Alice, as a super_user, can only manage the A,B,C sub-users and should not be able to delete or manage John's X,Y,Z sub-users. Similarly, John should not be able to manage or delete Alice's A,B,C sub-users. My questions are as follows: How can I identify and ensure that ABC sub-users belong to Alice and X,Y,Z sub-users belong to John? What is the best approach to implement this restriction within OpenStack, preventing cross-management of sub-users between Alice and John? Will using the multi-domain concept help me achieve this? Any insights, best practices, or suggestions on how to configure this within OpenStack would be greatly appreciated. Thank you for your assistance and support. Thanks & Regards, Thamanna Farhath | Associate Engineer-R&D Ph No: (+91) 9344093591 email: mailto:thamanna.f@zybisys.com Zybisys Consulting LLP | NO.1B 2nd floor, NSA Tower, Akila Nagar, Main Rd, Ganapathy Nagar, Thiruvanaikoil, Tiruchirappalli, Tamil Nadu 620005 zybisys.com Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

[swift] Ideas: Object Locking
by David Zanetti 10 Sep '24

10 Sep '24

Hello everyone! We've added an entry to the Swift ideas page about implementing Object Locks. The full description of what this would be and how we expect it to work is in the ideas page here: https://wiki.openstack.org/wiki/Swift/ideas/object-lock I have two questions of the community. The first is whether work on this would be accepted by the Swift project, as we wouldn't want to expend efforts on something we'd have to carry as our own patches to upstream. The second is if there is any interest from other people to collaborate on design/implementation of the locking feature. Happy to take replies off-list if people prefer, and thanks for reading this far! (Ob-reply: Yes, we know Ceph RGW does this already. We use Swift for Object for $REASONS, which we'd like to keep doing.) -- David Zanetti Chief Technology Officer [1]Aotearoa New Zealand's cloud provider e david.zanetti(a)catalystcloud.nz w catalystcloud.nz Follow us on LinkedIn [2] Level 9, 33 Federal Street, Auckland 1010 [1] https://catalystcloud.nz/ [2] Follow us on LinkedIn https://www.linkedin.com/company/catalyst-cloud-limited/

2 1

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-3)
by Goutham Pacha Ravi 10 Sep '24

10 Sep '24

Hello Stackers, Projects following a cycle-with-rc release model are hard at work alongside the release team to tag the first version of the 2024.2 release candidates (RC) this week [1]. The community would appreciate testing of these RC builds so we can weed out any critical issues prior to the coordinated release of this software in three weeks (2024-10-04). The OpenStack Technical Committee Election is ongoing. If you are a Foundation Individual Member who has been an Active Contributor during the past year, you should have received an email ballot with the details. If you haven't, please pop into #openstack-election and let us know. I hope you'll be able to make your vote count. === Weekly Meeting === The OpenStack Technical Committee met simultaneously over video [2] and IRC [3] last week. We took note of the smooth kick-off to the community elections and appreciated the effort the election officials have put in thus far. With the retirement of several inactive project teams and some focused outreach, we had far fewer projects without PTL candidates this time [4]. I will keep you posted on the TC's course of action in this matter over the next few weeks. At the meeting, we brainstormed reasons why these project teams had no PTL candidates, and whether Distributed Project Leadership is an appropriate choice for relatively stable project teams. We reflected on the community's experience with leadership appointments in the past where the appointed individuals couldn't sustain the project. These past experiences will help shape the TC's decisions. We noted that the maintenance phase transition for the stable/2023.1 ("Antelope") branch is coming up. The release team estimates transitioning the "stable/2023.1" branch across OpenStack repositories to "unmaintained/2023.1" [5] around 2024-10-30. After this transition, no further releases will be produced from these branches. If you are relying on this branch, please help project teams maintain testing and continuous integration for it. However, note that the release would be 19 months old at the time of this transition; consider upgrading the software to newer releases instead. The TC is considering a change to the OpenStack CI policy of re-enqueuing changes through Zuul when approved patches fail to get merged. Currently, if a change that fails "gate" jobs is re-enqueued, "check" jobs are re-run if new changes are detected in the repository. A suggestion was made to alter this policy so that only the "gate" jobs are repeated. We decided to defer this discussion to the upcoming PTG in October. We concluded the meeting by acknowledging the contributions Jay Faulkner (JayF) and Dan Smith (dansmith) made during their time on the TC. The elections will conclude on 2024-09-18. Again, please vote if you haven't already! :) The next meeting of the OpenStack Technical Committee is today: 2024-09-10. It will be hosted on OFTC's #openstack-tc channel at 1800 UTC. Please find the agenda on the meeting's wiki page [6]. I hope you'll be able to join. Please remember that you can propose discussion items to the agenda. === Governance Proposals === ==== Merged ==== - Fix typo in tested runtimes documents | https://review.opendev.org/c/openstack/governance/+/928603 ==== Open for review ==== - Add goal to migrate CI/CD jobs to Ubuntu Noble | https://review.opendev.org/c/openstack/governance/+/928078 - Adding Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Charms: retire unmaintained charms | https://review.opendev.org/c/openstack/governance/+/926793 - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 - Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 === Upcoming Events === - 2024-09-10: OpenInfra Board Meeting: https://board.openinfra.dev/ - 2024-09-18: OpenStack 2025.1 Election Polling Ends - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 2024-10-21: OpenInfra Project Teams Gathering https://openinfra.dev/ptg/ === How to Contact the TC === You can reach out to the TC in multiple ways: 1. **Email**: Send an email with the tag [tc] on this email list. 2. **IRC**: Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel. 3. **Weekly Meeting**: The Technical Committee meets every week on Tuesdays at 1800 UTC [6]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] TC Meeting Video Recording, 2024-09-03: https://youtu.be/22oyI9vuvhM [3] TC Meeting IRC Log, 2024-09-03: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-03-18.00.log.html [4] "Leaderless" projects for the 2025.1 release cycle: https://etherpad.opendev.org/p/2025.1-leaderless [5] "Unmaintained" branches: https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… [6] TC Meeting Agenda, 2024-08-27: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[neutron] bug deputy report for week of 2024-09-02+
by Ihar Hrachyshka 10 Sep '24

10 Sep '24

Hi, Processed everything up to end-of-Mon (Sep 9). --- Gate failures: - https://bugs.launchpad.net/neutron/+bug/2078846: gate failure that happened to me, some race (?) in provisioning blocks / ovn port UP status propagation. Couldn't figure out the cause completely. Would benefit from a second pair of eyes. No patch. - https://bugs.launchpad.net/neutron/+bug/2079047: gate issue with one test in openvswitch-iptables_hybrid-distributed-dhcp flavor (not regular one!) No patch. - https://bugs.launchpad.net/neutron/+bug/2079048: gate failure in functional, sporadic, metadata/l3 related. No patch. - https://bugs.launchpad.net/neutron/+bug/2079831: tempest issue. Patch posted (WIP): https://review.opendev.org/c/openstack/tempest/+/928471 Actionable, need an owner: - https://bugs.launchpad.net/neutron/+bug/2078849: designate / S-RBAC integration changes needed. - https://bugs.launchpad.net/neutron/+bug/1995078: OVN: order of external chassis / gateway chassis lists should be stable. There's a WIP from Rodolfo but AFAIU someone else should take it over. - https://bugs.launchpad.net/neutron/+bug/2066989: SR-IOV; reproducer info was now attached. - https://bugs.launchpad.net/neutron/+bug/2079996: idea to restart haproxy only when needed. No patch. Marked as Low but isn't it a regression / datapath impact? Waiting for info from reporters: - https://bugs.launchpad.net/neutron/+bug/2059405: old bug with DNS, confirmed by the user with a non-.local. domain, asked to attach logs etc and then move to New; - https://bugs.launchpad.net/neutron/+bug/2078856: ovn related, waiting for logs / db dump for ovn to triage VPNaaS: - https://bugs.launchpad.net/neutron/+bug/2078845: vpnaas, need someone from the project owners to take a look. - https://bugs.launchpad.net/bugs/2080072: vpnaas, sqlalchemy transaction issue. Affected gate. No patch yet. FWaaS: - https://bugs.launchpad.net/neutron/+bug/2078918: fwaas, TypeError, patch posted. - https://launchpad.net/bugs/2078930: fwaas, patch posted. I hope it's helpful, Ihar

1 0

[nova][ci] cyborg-tempest (non-voting) job is failing
by melanie witt 10 Sep '24

10 Sep '24

Hey everyone, I noticed that the cyborg-tempest (non-voting) CI job began failing on the master branch sometime on 2024-09-03: https://zuul.opendev.org/t/openstack/builds?job_name=cyborg-tempest&project… The errors I see in the test result report are policy related, for example: Details: {'error_message': '{"faultcode": "Server", "faultstring": "\\"cyborg:device_profile:create\\": \\"rule:system_admin_api\\" requires a scope of [\'system\'], request was made with project scope.", "debuginfo": null}'} I'm guessing this is related to the recent "oslo.policy 4.4.0 enable the RBAC new defaults by default" change [1]: https://review.opendev.org/c/openstack/requirements/+/925464 The job is non-voting so it's not blocking anything, but it would be great if someone knows the best way to fix it. -melwitt [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

2 1