- openstack-discuss - lists.openstack.org

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

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

10 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

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

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

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

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

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

09 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