October 2022 - openstack-discuss - lists.openstack.org

single Network interface
by Parsa Aminian 23 Oct '22

23 Oct '22

Hello I use kolla ansible wallaby version . my compute node has only one port . is it possible to use this server ? as I know openstack compute need 2 port one for management and other for external user network . Im using provider_networks and it seems neutron_external_interface could not be the same as network_interface because openvswitch need to create br-ex bridge on separate port is there any solution that i can config my compute with 1 port ?

7 9

[tc][all][policy][rbac] RBAC 2023.1 Antelope cycle Virtual PTG discussions summary
by Ghanshyam Mann 22 Oct '22

22 Oct '22

Hello Everyone, Last week, I tried to attend all the RBAC-related sessions on various projects. We mainly discussed the next steps on RBAC and implementing the project personas if not yet done. I captured the summary and outcome of the discussions of those projects in the below etherpad: Look for the section: "RBAC/Policy 2023.1 Antelope PTG summary". If I have missed any project discussion, please add it to the etherpad. - https://etherpad.opendev.org/p/rbac-goal-tracking One of the big outcomes, we agreed on all the projects (implemented phase-1) to enable the scope checks and new defaults by default. But before doing that, we need to test the new defaults and scope in Tempest (tempest plugin) integrated gate. I have started working on the job enabling the scope and new defaults[1]. [1] https://review.opendev.org/c/openstack/tempest/+/614484 -gmann

1 0

[tc][all][ Technical Committee 2023.1 Antelope cycle Virtual PTG discussions summary
by Ghanshyam Mann 22 Oct '22

22 Oct '22

Hello Everyone, I am summarizing the Technical Committee discussion that happened in the 2023.1 Antelope cycle PTG last week. Also, in case anyone wanted to search for all the projects etherpad later after ptgbot cleans them, I have added those to this wiki[1] Attendance: ========= * ~30 on Monday, ~25 on Thursday, ~20 on Friday Improvement in project governance: =========================== We continued the discussion from Monday and discussed a few high-level criteria which can be the potential criteria to monitor inactive projects. Along with contributors, event, and meeting occurrence is one of them but not all. JayF will be working on this to list the exact criteria/things TC can monitor to find and work on help inactive projects. User Survey: ========== * 2021 user Survey result analysis: We started with the pending review of the 2021 survey analysis[2]. There wasn't 2020 analysis so, the comparison was done using 2019. Overall, the trends in the survey were positive. We discussed adding the question about UI participants especially if users need new features to be implemented in UI then what prevents them to help and contribute? * 2022 User Survey result: knikolla and I will be working on the analysis of this survey result. jungleboyj will help on documenting the process and tips to analyze the survey xls which is not an easy task. Thanks to jungleboyj for doing the survey analysis and helping with the 2022 survey too. * 2023 User Survey question review: While doing the 2021 survey analysis, we discussed the below changes in 2023 survey. ** Remove "Other ways users participate:" ** Add: 1. how users are consuming OS. From pypi packages? From RHOSP? etc. 2. How are users interacting with OpenStack? Through Horizon? CLI? Skyline? An internally developed tool? etc. 3. Adding a sub-question about UI development help in "To which projects does your organization contribute maintenance resources such as patches for bugs and reviews on master or stable branches?" 4. Asking about what all OSS/software/services are used in your OpenStack provisioned cloud/resource. * Action: As the next step, we will work on the exact wording for the above questions and send it to Allison before the end of Oct month. Next step for OSC work ================== We started the discussion on sdk/osc should continue supporting the old interfaces even if we are not able to test them properly. Anyone running a very old cloud should be able to use the sdk/osc latest. We agree and Artem mentioned being more careful about removing the things. Next, we discussed where we stand on OSC work and direction from the project side and good progress from nova, neutron, and manila (might be a few more) but at the same time, many other projects need work on fixing the feature gaps. Glance is also in agreement to work towards OSC. There was a question on when and how we should work towards deprecating/removing the project's python client. The best way is to start implementing the new features in OSC and try their best to fill the old feature gap. Based on the current state, we agree to start this work as one of the community-wide and Artem volunteers to help here. * Action: ** Propose this as a community-wide goal "focus on fixing the feature gaps in osc not to remove the pythonclient which can be another goal" ** Look at devstack's use of OSC to see if we can enable token caching and perhaps use a smaller venv for performance Consistent and Secure Default RBAC ============================ As a good amount of the services are ready with the project personas, We will be testing them in the integrated gate (tempest and tempest plugins jobs), and based on the results we will enable the scope to enforce and new defaults enforce by default in this cycle. Also, services can start implementing phase 2 of the goal which is the service-to-service role. On Horizon question of moving to new defaults. because of the explicit policy files (with defaults) on the horizon side, the operator will not be able to just switch the flag until they change the policy file. For a better migration path and getting one more cycle to test the new defaults by default on the service side, it is better for Horizon to move to new defaults in the next cycle. FIPs goal ======= Ade lee provided the current status[3] of the goal which is good progress. There is work going on having the ubuntu based FIPs enabled job[4] and that will be to achieve the goal of having of voting job in the check/gate pipeline. Migrate CI/CD jobs to Ubuntu 22.04 (Jammy Jellyfish) ========================================= Projects are testing the jobs on Jammy but not all[5], we encourage the projects to start testing your project jobs before the deadline which is m-1 (Nov 18), and fix the issues if there are any. One known issue is Ceph job failing on Jammy as there aren't jammy upstream packages. There are packages in UCA and Ubuntu proper that could be used instead. The community-wide goal process in a world with few contributors =================================================== This topic is on how we can improve the community-wide goal progress and productivity but at the same time reduce the overhead on projects. Also, to highlight that the Champion of a goal is not required to do all the work and it is up to the champion. knikolla will work on the goal documentation to try goal overhead minimum. We will be more careful with goal selection to make sure if any work can be done without a community-wide goal then we should proceed that way. * Action: knikolla: see opportunities for rewording the community goal document. mention: striving to keep goals to a minimum to reduce overhead on teams and try to build consensus first. Pop-Up Team checks ================ We have two active popup teams, 1. Image Encryption 2. Policy(RBAC). Both have pending work to finish so will continue in this cycle also. Support policy for 32-bit platforms support ================================= Zigo is testing the OpenStack on 32-bit and filed bugs[6]. As we do not test it in the upstream CI/CD, we will not be committing to its support. But it is completely ok to fix the bug or add a skip in tests. Thanks to zigo for testing and reporting the bugs. Fixing docs build issues with recent Sphinx ================================ Sphinx is capped at 4.5.0 in upper constraints for a long time and whether we should move our doc to 6.0 or not is the question. Moving to 6.0 needs more work in openstackdocstheme. Until we have someone fixing things, it is ok to continue on Sphinx 4.5.0. Election retrospective: ================= We had a good amount of discussion on elections and many ideas to improve them in the future. Also by discussing the k8s election process with k8s steering committee members. We also discussed TC Chair election process to record the nomination in a better way. This is still not concluded and we continue the discussion in TC. Overall it was a productive discussion and we came up with below action items: *Action: 1. Extend the nomination and voting period to two weeks and also communicate the election well in advance. 2. Along with existing projects/SIG repos, add a few more related repos (governance, etc) in election tooling to count the electorate. 3. Add in the election process: call for AC on openstack-discuss or any other ML before the deadline. 4. Appoint a TC liaison as a point of contact to track the election dates more carefully and ICAL for election tasks will be a good idea to send/add. 5. Update the TC charter to mention the election period, and deadline explicitly. Cross-community sessions with k8s steering committee team: =============================================== We invited Kubernetes Steering Committee members to TC sessions. Tim and Christoph joined the sessions. This is a great way to collaborate between two communities. Following the introduction from both sides, we discussed various topics and share the process, challenges, and feedback from both sides. The election process, contributor recruiting, and how to engage them as long-term contributors. Also having part-time or non-corporate contributors is still a challenge for both communities. We also discussed the operator engagement challenges OpenStack is facing. Kubernetes operator thing is a bit complicated and they have app dev, cluster, app, and infra operator. Similar to OpenInfra foundation to the OpenStack community, CNCF foundation plays an important role for them to connect the operator with the community as much as possible. Discuss and clarify the supported upgrade-path testing in PTI: =============================================== To provide a better upgrade path, we decided to test the old distro version also whenever we will bump the distro version in our CI/CD. Below are details of the upgrade testing we will be following: Agree: * Supporting two distro versions when we bump the new distro version in any release: (this is only for the release bump of the distro and after that, we can go back to a single distro version testing) ** Run single tempest job in project gate on old distro version, not all jobs ** Add the previous python version unit test job in the new release testing template. * For non-SLURP releases, we will try not to change the testing runtime unless it is very much required due to the EOL of versions, we are using in testing. * In case the project has to add some feature that needs a new version of deps which is not supported in the old distro version then they need to be explicit about it and communicate in a better way. * Action: I will document the above in PTI. Guidelines for using the OpenStack release version/name and project version in 1. releasenotes 2. Documentation ===================================================================================== In Zed cycle, TC passed a resolution[7] and also prepared the guidelines[8] on using the release number as a primary identifier. During nova PTG, there was a question on what is the recommendation for using OpenStack version and package version (say Nova 27.0.0) in project documentation, releasenotes etc. After discussing the multiple options listed in etherpad we agree to go for the below: * OpenStack <release version> (<project> <project vesion>) Example: OpenStack 2023.1 (Nova 27.0.0) I will add this to the release identifier page[8] so that all projects can use it consistently. Discussion on projects (like neutron, ceilometer ) in Upper Constraints: ===================================================== Having projects in u-c makes it difficult for users to have a consistent deployment of those services. But we do not recommend using the u-c in production and it can be explicitly mentioned in the requirement and project-team-guide document. * Action: tonyb to document the upper constraints usage expectation (especially for production usage) in the requirement document as well as in project-team-guide[9]. Zed Retrospective: ============== In the end, we discussed the Zed cycle retrospective. * What went well? ** Good amount of work in the zed cycle[10] ** New TC members ** Good participation in meetings especially video call ** TC & Community Engagement (leaders interaction) improving *** i18 SIG team having there helped to proceed with i18 SIG work One thing to improve next time is to explicitly call out the team/members with a courtesy ping for future PTG if any related discussion. We do send the agenda on ML in advance but no harm in ping also. Meeting time check: =============== TC weekly Video calls are more productive compared to text meetings and we will do two video calls in a month. We will also start a poll to select the meeting time. 2023.1 cycle TC Tracker ================== I prepared the TC tracker for 2023.1 and listed all the actionable working items that came up during the PTG discussion. This is helpful for tracking the working items. - https://etherpad.opendev.org/p/tc-2023.1-tracker Thank you for reading the summary or I will say detailed summary :), have a nice weekend everyone. [1] https://wiki.openstack.org/wiki/PTG/2023.1/Etherpads [2] https://review.opendev.org/c/openstack/governance/+/836888 [3] https://etherpad.opendev.org/p/fips_goal_status [4] https://review.opendev.org/c/openstack/project-config/+/861457/ [5] https://etherpad.opendev.org/p/migrate-to-jammy [6] https://bugs.launchpad.net/glance-store/+bug/1991406 [7] https://governance.openstack.org/tc/resolutions/20220524-release-identifica… [8] https://governance.openstack.org/tc/reference/release-naming.html [9] https://docs.openstack.org/project-team-guide/dependency-management.html [10] https://etherpad.opendev.org/p/tc-zed-tracker -gmann

1 0

[tc][all][ptg] "Technical Committee + Leaders interaction" 2023.1 cycle vPTG sessions summary
by Ghanshyam Mann 22 Oct '22

22 Oct '22

Hello Everyone, I am writing the Technical Committee + Leader interaction session discussion summary that happened in the 2023.1 Antelope cycle PTG this week. We continue the interaction session in this PTG also. The main idea here is to interact with community leaders and ask for their feedback on TC. I am happy to see ~30 attendance and had a good amount of discussions. Below are the topics we discussed in this feedback session. Updates from TC: ============= * Conveying current selected Community-wide goals. * Avoid Bare recheck * TC PTG slots: 15-19 UTC on Thursday and Friday * Status on previous PTG interaction sessions' Action items/feedback: ** PTLs/Leaders to start spreading the word and monitor ignorant recheck in their weekly meeting Status: Good progress in this, many projects started monitoring it and slaweq continues contacting the PTL for this. But we still encourage PTLs/Leaders to publish the blog/video of their stories/project updates etc at least once in a cycle. You can check the places where to publish such blogs/videos [1]. ** Recognize the contribution: Status: Not done, we are continuing this AI and will work on it this cycle. ** Bare Recheck: Status: Done. TC is monitoring the bare recheck in the weekly meetings and slaweq reaching out to projects to do the same in their weekly meeting. Feedback on TC activities or anything Community Leaders would like TC to spend more time on: ========================================================================= * Continue the TC weekly summary email which is helpful * TC to build a review process that would happen periodically to check the project status. Basically to ensure the project status as per "Emerging Technology and Inactive projects"[2]. JayF volunteered to work on this to write some documentation or resolution. ** Action Item: 1. JayF to write a resolution on criteria/flag to identify/action on the inactive projects. Renovate translation SIG i18: ====================== Ian and Seongsoo joined the discussion to provide the current state and help needed in i18 SIG. We collected some information on translation usage, language, and content(GUI, doc, log etc). Motoki updated information from the Japan group but still, needs more information from other groups/translation users and agrees to add some queries in the 2023 user survey. Also, Brian will investigate the possibility of migration to weblate tool. * Action Item: 1. rosmaita: draft questions for the survey, get feedback from ian and seongsoo 2. rosmaita: follow up with weblate service to determine whether OpenStack qualifies for gratis service 3. Ian to reach out to contributors/users to know the translation requirements for applicable language. Possibilities to avoid RC time issues with Oslo release: ======================================== After discussing the issue that occurred for Sqlalchemy 2.0 related merge in the zed cycle, we discuss one option to propose the non-client feature freezes to m-2 and get more feedback from Oslo or other non-client lib maintainers. Also, we encourage adding the lib forward testing which tests the integration gate with the master version of lib which can help to find the issues while the code merges itself. As discussed Elod proposed the review to get more feedback[3] and also email it to ML[4]. After getting feedback from Oslo maintainer it seems it is not a good idea to preponed the lib feature freeze. Discussion is going on in ML[4]. Clean up Zuul config errors: ===================== At the end of the session, we discussed the current zuul config error in OpenStack projects. TC is actively working on this and knikolla and other members trying to fix them as much as possible. Please check your projects and fix them, priority is to fix the master and supported branches, not the EM state branches. [1] https://docs.openstack.org/project-team-guide/spread-the-word.html [2] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [3] https://review.opendev.org/c/openstack/releases/+/861900 [4] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030914… -gmann

1 0

Follow up on https://storyboard.openstack.org/#!/story/2010377
by rajiv mucheli 22 Oct '22

22 Oct '22

Hi, Unlike Openstack Yoga, where the setuptools version was set in upper-contstraints.txt. This is not set in Openstack Zed, which uses jammy with python 3.10. I get the below while performing few tests : - [[ -f /failure ]] - echo Wheel failed to build - cat /failure Wheel failed to build thrift===0.16.0 python-nss===1.0.1 We will need to stay with setuptools <58 to fix the 2to3 compiler issue, else anyjson packages adds up to the above list, but thrift is removed when setuptools >63. Regards, Rajiv

2 5

[PTL][TC] library *feature* freeze at Milestone-2
by Elõd Illés 21 Oct '22

21 Oct '22

Hi, During 'TC + Community leaders interaction' [1] a case was discussed, where a late library release caused last minute fire fighting in Zed cycle, and people discussed the possibility to introduce a (non-client) library *feature* freeze at Milestone-2 to avoid similar issues in the future. I've started to propose the possible schedule change [2] (note: it's not ready yet as it does not emphasize that at Milestone-2 we mean *feature* freeze for libraries, not "final library release"). The patch already got some reviews from library maintainers so I'm calling the attention to this change here on the ML. Thanks everyone for the responses in advance, Előd [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030718… [2] https://review.opendev.org/c/openstack/releases/+/861900

4 5

[neutron]: DVR with OVN
by Farhad Sunavala 21 Oct '22

21 Oct '22

Hi, Just want to get a feel with how users are using DVR with OVN especially for a medium sized installation (500 nodes, 3000-4000 VMs)Are you just using it in the default configuration with all the complexities and just take the hit when troubleshooting why a particular path doesn't work as expected? Are you taking precautions such as providing VMs with a separate direct path to the public network in case the main interface connected to DVR fails?See OpenInfra 17th minute of Live Ep. 26 Large Scale Neutron Best Practices @ (340) OpenInfra Live Ep. 26: Large Scale OpenStack: Neutron Scaling Best Practices - YouTube | | | | | | | | | | | OpenInfra Live Ep. 26: Large Scale OpenStack: Neutron Scaling Best Pract... | | | Is DVR with OVN reasonably solid for production environments that makes you comfortable enough to use it in installations with around 5000 VMs? thanks,Fred.

1 0

[tripleo] gate blocker centos 9 content provider - trending fixed
by Marios Andreou 21 Oct '22

21 Oct '22

Hello FYI (few folks asking in irc apologies should have sent sooner) gate blocker on the content provider https://bugs.launchpad.net/tripleo/+bug/1984237/comments/5 thanks chkumar we are trying to get a fix through gate at https://review.opendev.org/c/openstack/tripleo-quickstart/+/856582 please hold your recheck until that merges or use depends-on thank you!

2 1

Track Chair Nominations Close in One Week!
by Helena Spease 21 Oct '22

21 Oct '22

Hey everyone! Track Chair nominations <https://openinfrafoundation.formstack.com/forms/trackchairnominations2023> for the 2023 OpenInfra Summit in Vancouver (June 13-15, 2023) are closing soon! Please submit your nominations before they close on October 28, 2022 Track Chairs for each Track will help build the Summit schedule, and are made up of individuals working in open infrastructure. Responsibilities include: - Help the Summit team put together the best possible content based on your subject matter expertise - Promote the individual Tracks within your networks - Review the submissions and Community voting results in your particular Track - Determine if there are any major content gaps in your Track, and if so, potentially solicit additional speakers directly to submit - Ensure diversity of speakers and companies represented in your Track - Avoid vendor sales pitches, focusing more on real-world user stories and technical, in-the-trenches experiences 2023 Summit Tracks: - 5G/NFV & Edge - AI/Machine Learning/HPC - CI/CD - Container Infrastructure - Getting Started - Hardware Enablement - Open Development - Private & Hybrid Cloud - Public Cloud - Security - Hands On Workshops Full track descriptions are available here <https://openinfra.dev/summit/vancouver-2023/summit-tracks/>. If you’re interested in nominating yourself or someone else to be a member of the Summit Track Chairs for a specific Track, please fill out the nomination form <https://openinfrafoundation.formstack.com/forms/trackchairnominations2023>. Nominations will close on October 28th, 2022. Track Chairs selections will occur before we close the Call for Presentations (CFP) so that the Chairs can host office hours to consult on submissions, and help promote the event. CFP will be opening in November, registration <https://openinfrasummit2023.eventbrite.com/> and sponsorship <http://openinfra.dev/summit/vancouver-2023/summit-sponsor/> information are already available. Please email speakersupport(a)openinfra.dev with any questions or feedback. Cheers, Helena Spease

1 0

[ptl][release][stable][EM] Extended Maintenance - Wallaby
by Elõd Illés 21 Oct '22

21 Oct '22

Hi, In less than a two weeks Wallaby is planned to transition to Extended Maintenance phase [1] (planned date: November 2nd, 2022). The release patches for the transition have been generated [2], these patches mark the latest release in stable/wallaby with wallaby-em. PTLs and release liaisons are encouraged to approve them as soon as possible, by latest before the transition date. After the transition stable/wallaby will be still open for bug fixes, but there won't be any official releases. Note: if a team wants to do a final release before the transition, then it can be done, but be careful to not release fixes that could break things to avoid broken releases as *final* stable Wallaby release. Thanks, Előd irc: elodilles @ #openstack-releases [1] https://releases.openstack.org/ [2] https://review.opendev.org/q/topic:wallaby-em

1 0