- openstack-discuss - lists.openstack.org

[keystone] Feature freeze exceptions
by Hiromu Asahina 18 Feb '23

18 Feb '23

Hi All, As discussed in the reviewathon today, due to the shortage of review bandwidth, we are planning to extend the feature freeze for the changes related to mTLS OAuth2.0. Current feature freeze date (for keystone): 17 February 2023 New feature freeze date (for keystone): 24 February 2023 Kindly let me know if there are any objections to the above proposal else the changes related to topic:bp/support-oauth2-mtls [1] are eligible for the feature freeze exception of 1 week. [1] https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls Thanks, Hiromu Asahina

1 0

[release] Release countdown for week R-4, Feb 20-24
by Elõd Illés 18 Feb '23

18 Feb '23

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the 2023.1 Antelope deliverables can be proposed, well ahead of the final 2023.1 Antelope release date. General Information ------------------- We are still finishing up processing a few release requests, but the 2023.1 Antelope release requirements are now frozen. If new library releases are needed to fix release-critical bugs in 2023.1 Antelope, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in 2023.1 Antelope that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By March 2nd, 2023 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/2023.1 branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for 2023.1 Antelope changes should be added there to make sure the consumers of your release notes see them. Finally, if you haven't proposed 2023.1 Antelope cycle-highlights yet, then you are encouraged to do so as deadline is February 23rd, 2023. A separate email will be sent early next week. Upcoming Deadlines & Dates -------------------------- Cycle Highlights Due: February 23rd, 2023 (R-4 week) RC1 deadline: March 2nd, 2023 (R-3 week) Final RC deadline: March 16th, 2023 (R-1 week) Final 2023.1 Antelope release: March 22nd, 2023 2023.2 Bobcat Virtual PTG: March 27-31, 2023 Előd Illés irc: elodilles @ #openstack-release

1 0

[elections][Cinder] PTL Candidacy for 2023.2 (Bobcat)
by Rajat Dhasmana 18 Feb '23

18 Feb '23

Hi All, I would like to nominate myself to be Cinder PTL during the 2023.2 (Bobcat) cycle. I have been serving as the PTL for the last two cycles i.e. Zed and 2023.1 (Antelope) and there were a lot of key areas which we were able to improve as follows: ** Review bandwidth and quality:* Cinder's policy of "Do reviews to get reviews" has helped improve the review bandwidth and we have seen more participation and activity in code reviews. We have also added efficient review guidelines[1] to help new contributors onboard to the review process quickly and help them do quality reviews. ** cinderclient to openstackclient migration:* We are working towards reducing the parity between cinderclient and openstackclient and the effort can be tracked with this topic[2]. Currently we have proposed all the commands that were missing in openstackclient. ** Third party CI to report on os-brick changes: *The third party vendor CI's used to report only on cinder gate and not on os-brick gate which means their driver wasn't tested with the connector and they could only see issues when the os-brick release happens. Unfortunately, the driver merge deadline is milestone-2 and os-brick (non-client library) release is 1 week before feature freeze so it doesn't give enough time for driver maintainers to fix the issues. Reporting the CI on os-brick gate helps identify issues earlier and fix them timely. ** Security Vulnerabilities:* We went through the open security issues in Zed and triaged their priority and importance. A new security issue was reported in 2023.1 regarding VMDK file format for which a CVE has been filed, CVE-2022-47951 [3]. We have addressed the issue and releases were done for the actively maintained stable branches i.e. Zed[1], Yoga[2] and Xena[3]. Apart from that, we were able to handle deadlines better by managing and prioritizing work based on the milestones. Following are the plans for the 2023.2 cycle: * our first target will be to move away from adding additional commands to cinderclient and only rely on openstackclient for the CLI interface. Also we will explore openstacksdk to add support for cinder commands so we can break the dependency on the python bindings that exist in cinderclient. * Another thing to address is adding the service role after the keystone implements it[7]. * Third party drivers are the core of cinder that allows cinder to what the end users desire i.e. to interface between users and storage backends. We will focus to improve the experience of driver vendors to implement new drivers by improving our driver documentation and test stability by doing a 3rd party CI compliance check. We have been making progress in this area but more efforts are required that we will target for the next cycle. Finally will try to continue all the good things we have started that keeps the project healthy and active and also address new gaps discovered along the way. [1] https://docs.openstack.org/cinder/latest/contributor/gerrit.html#efficient-… [2] https://review.opendev.org/q/topic:add-missing-cinderclient-commands [3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47951 [4] https://pypi.org/project/cinder/21.1.0 [5] https://pypi.org/project/cinder/20.1.0 [6] https://pypi.org/project/cinder/19.2.0 [7] https://review.opendev.org/c/openstack/keystone/+/863420 - Rajat Dhasmana

2 1

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 17 Feb '23

17 Feb '23

Hello Neutrinos: Due to the lack of agenda [1], today's drivers meeting is cancelled. Have a nice weekend! [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

Answer questions about 'OpenInfra Live - VGPU Management by OpenStack Nova and Cyborg'
by Alex Song (宋文平) 17 Feb '23

17 Feb '23

Hi everyone, The Episode of VGPU Management by OpenStack Nova and Cyborg has completed. Below is the answer of questions: Q:Does Cyborg do the MIG configuration or is that done manually outside OpenStack? A: We can configure MIG by cyborg-api, we list the MIG split combinations on the page for user to set. Cyborg-agent only need configure the driver of nvidia_mig_driver. In the driver, we automatic discover the vgpu_types and PCI addresses and set default vgpu_types. Q:Do l get it right that we need at least Ussuri on the hosts for Nova ? A: Yeah, from Ussuri we complete the interaction with Nova and Cyborg. If you use old Nova version, you can cherry pick the Cyborg part code. Q:does cyborg also help with SRIOV netork with MIG and passthrough hosts? A: Firstly, Cyborg has supported manage SmartNIC SRIOV network. Secondly, MIG and vGPU only support passthrough hosts in OpenStack nowadays, GPUDirect need RDMA communication. Thanks, Alex

1 0

[election][keystone] PTL candidacy for 2023.2 (Bobcat)
by Dave Wilde 17 Feb '23

17 Feb '23

Hello, I would like to nominate myself to be Keystone PTL for the 2023.2 (Bobcat) cycle. This will be my second cycle serving as PTL and I am looking forward to continuing the progress that we're making in Keystone. Some of the highlights of the last cycle that I would like to continue and build upon are: *Reviewathons*: We have been holding weekly reviewathons that I feel have been quite successful. We meet on Fridays (ping me if you'd like an invite) in an informal hour long GMeet room and either go down the list of pending reviews or if there is a specific topic/feature we might focus on that. The reviewathons have helped in significantly reducing our backlog of easily merged, maintenance type patches and have given us a very good opportunity to discuss in detail a very complicated feature. I would like to continue the reviewathons and extend an invitation to anyone who would like to join. *Weekly Meetings*: The weekly meetings are happening regularly and are fostering good discussion and information sharing. The weekly meetings are currently scheduled for Tuesdays at 15:00 UTC but I am always open to changing the day and time if it will garner more participation. *Bug Cleanup*: Keystone proper has over two hundred bugs and the other Identity projects probably contribute another one hundred, this is too many. I have been slowly going through and trying to close out old and irrelevant bugs as well as triage those that need fixing (my apologies for the emails about bugs that are years old :). I would like to continue this work and get our bug backlog into a manageable state. I've enjoyed my first cycle as PTL and with your continued support am looking forward to another cycle. Thanks for your consideration. /Dave

2 1

[cinder] festival of feature reviews 17th February 2023
by Rajat Dhasmana 17 Feb '23

17 Feb '23

Hello Argonauts, We will be having our monthly festival of reviews tomorrow i.e. 17th February (Friday) from 1400-1600 UTC. This time we are planning to review features instead of XS patches since we have feature freeze this week. Following are some additional details: Date: 17th February, 2023 Time: 1400-1600 UTC Meeting link: https://bluejeans.com/556681290 etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews See you there! Thanks Rajat Dhasmana

1 0

[horizon][kolla] xstatic libraries and setuptools 67.3.1
by Michał Nasiadka 16 Feb '23

16 Feb '23

Hello, Recently setuptools 67.3.1 has been released, and it broke Kolla Horizon container builds. It seems that xstatic libraries rely on setuptools importing pkg_resources during build, which does not work in latest setuptools [1]. I raised a horizon bug #2007574 (https://bugs.launchpad.net/horizon/+bug/2007574) Raising awareness on the ML, because maybe that affects more projects than only Horizon. We’ve pinned to 67.2.0 in Kolla for now (in master and stable/zed, because earlier branches have a pin from u-c) [1]: https://github.com/pypa/setuptools/issues/3824 Michal Nasiadka

1 0

overcloud node import shows node already registered for a new baremetal box | ironic | wallaby
by Swogat Pradhan 16 Feb '23

16 Feb '23

Hi, I have 2 separate baremetal boxes, 1 is dell and the other is of lenovo make. I have created 2 separate instanenv.json files for both of them, and tried importing. the dell box was imported earlier and is now part of the cloud and now when i am trying to import the lenovo box it gives me the <uuid of dell> is alredy registered. I am not sure why this is coming when they both have separate ip addresses and even mac. json files: (undercloud) [stack@hkg2director ~]$ cat dcn01/hci3.json { "nodes": [ { "name": "HCI3", "pm_type": "ipmi", "ports": [ { "address": "90:B1:1C:4F:CA:3B", "physical_network": "ctlplane" } ], "cpu": "24", "memory": "114688", "disk": "2602", "arch": "x86_64", "pm_user": "root", "pm_password": "password", "pm_addr": "172.25.180.57", "_comment": "HCI 3" } ] } (undercloud) [stack@hkg2director ~]$ cat dcn02/ceph3.json { "nodes": [ { "name": "ceph3", "pm_type": "ipmi", "ports": [ { "address": "38:68:DD:8D:9E:4A", "physical_network": "ctlplane" } ], "cpu": "48", "memory": "65536", "disk": "558", "arch": "x86_64", "pm_user": "root", "pm_password": "password", "pm_addr": "10.11.11.12", "_comment": "ceph 3" } ] } With regards, Swogat Pradhan

1 0

[Magnum]enable cluster user trust
by Nguyễn Hữu Khôi 16 Feb '23

16 Feb '23

Hello guys. I am going to use Magnum for production but I see that https://nvd.nist.gov/vuln/detail/CVE-2016-7404 if I want to use cinder for k8s cluster. Is there any way to fix or minimize this problem? Thanks. Nguyen Huu Khoi

2 3