July 2022 - openstack-discuss - lists.openstack.org

[release] Release countdown for week R-11, Jul 18 - 22
by Előd Illés 15 Jul '22

15 Jul '22

Development Focus ----------------- We are now past the Zed-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to the end of the release cycle, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (August 26th, 2022). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (September 1st, 2022) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, September 1st, 2022. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (September12th, 2022) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (September 29th, 2022) Upcoming Deadlines & Dates -------------------------- Non-client library freeze: August 26th, 2022 (R-6 week) Client library freeze: September 1st, 2022 (R-5 week) Zed-3 milestone: September 1st, 2022 (R-5 week) Előd Illés irc: elodilles

1 0

[neutron] change of API performance from Pike to Yoga
by Bence Romsics 15 Jul '22

15 Jul '22

Hi Neutrinos! Inspired by Julia Kreger's presentation on the summit [1] I wanted to gather some ideas about the change in Neutron API performance. For that I used Rally with Neutron's usual Rally task definition [2]. I measured against an all-in-one devstack - running always in a same sized VM, keeping its local.conf the same between versions as much as possible. Neutron was configured with ml2/ovs. Measuring other backends would also be interesting, but first I wanted to keep the config the same as I was going back to earlier versions as long as possible. Without much pain I managed to collect data starting from Yoga back to Pike. You can download all Rally reports in this tarball (6 MiB): https://drive.google.com/file/d/1TjFV7UWtX_sofjw3_njL6-6ezD7IPmsj/view?usp=… The tarball also contains data about how to reproduce these tests. It is currently available at my personal Google Drive. I will keep this around at least to the end of July. I would be happy to upload it to somewhere else better suited for long term storage. Let me also attach a single plot (I hope the mailing list configuration allows this) that shows the load_duration (actually the average of 3 runs each) for each Rally scenario by OpenStack release. Which I hope is the single picture summary of these test runs. However the Rally reports contain much more data, feel free to download and browse them. If the mailing list strips the attachment, the picture is included in the tarball too. Cheers, Bence (rubasov) [1] https://youtu.be/OqcnXxTbIxk [2] https://opendev.org/openstack/neutron/src/commit/a9912caf3fa1e258621965ea8c…

3 4

Propose to add Tobias Urdin as Tooz core reviewer
by Herve Beraud 15 Jul '22

15 Jul '22

Hello everybody, It is my pleasure to propose Tobias Urdin (tobias-urdin) as a new member of the Tooz project core team. During the last months Tobias has been a significant contributor to the Tooz project. Obviously we think he'd make a good addition to the core team. If there are no objections, I'll make that happen in a week. Thanks. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud

2 2

Propose to add Takashi Kajinami as Oslo core reviewer
by Herve Beraud 15 Jul '22

15 Jul '22

Hello everybody, It is my pleasure to propose Takashi Kajinami (tkajinam) as a new member of the oslo core team. During the last months Takashi has been a significant contributor to the oslo projects. Obviously we think he'd make a good addition to the core team. If there are no objections, I'll make that happen in a week. Thanks. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud

4 4

[kuryr] Proposal to clean up Kuryr core reviewers
by Maysa De Macedo Souza 15 Jul '22

15 Jul '22

Hello, We went through the list of current Kuryr core reviewers on the last PTG session and we noticed a couple of people that are not active Kuryr contributors anymore. I would to propose removing the following contributors from the Kuryr core team: - Irena Berezovsky - Gal Sagie - Liping Mao I take this opportunity to thank all of them for their contributions to the Kuryr project. I will wait one week for any feedback before proceeding with the removal. Thank you, Maysa Macedo

2 1

[adjutant][tc][all] Call for volunteers to be a PTL and maintainers
by Slawek Kaplonski 15 Jul '22

15 Jul '22

Hi, After last PTL elections [1] Adjutant project don't have any PTL. It also didn't had PTL in the Yoga cycle already. So this is call for maintainters for Adjutant. If You are using it or interested in it, and if You are willing to help maintaining this project, please contact TC members through this mailing list or directly on the #openstack-tc channel @OFTC. We can talk possibilities to make someone a PTL of the project or going with this project to the Distributed Project Leadership [2] model. [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411… [2] https://governance.openstack.org/tc/resolutions/20200803-distributed-projec… -- Slawek Kaplonski Principal Software Engineer Red Hat

4 8

[nova][ops] seeking input about local/ephemeral disk encryption feature naming
by melanie witt 14 Jul '22

14 Jul '22

Hi everyone, A potential issue regarding naming has come up during review of the ephemeral storage encryption feature [1][2] patch series [3] and we're looking for input before moving forward with any naming/terminology changes across the specs and the entire patch series. The concern that has been raised is around use of the term "ephemeral" for the name of this feature including traits, extra specs, and image properties [4]. For context, the objective of this feature is to provide users with the ability to specify that all local disks for the instance be encrypted. This includes the root disk and any other local disks. The initial concern is around use of the word "ephemeral" for the root disk. My general interpretation of the word "ephemeral" for storage in nova has been that it means attached storage that only persists for the lifetime of the instance and is destroyed if and when the instance is destroyed. This is in contrast to attached cinder volumes which can persist after instance deletion. But should "ephemeral" ever be used to describe a root disk? Is it incorrect and/or ambiguous to refer to it as such? This is part of what is being discussed in [4]. During discussion, I also realized there is a separate gap in the above interpretation of "ephemeral" in nova. When cinder volumes are attached to an instance, their persistence after the instance is deleted depends on whether the 'delete_on_termination' attribute is set to true in the request payload when the instance is created [5] or when attaching a volume to the instance [6] or updating a volume attached to the instance [7]. This means that in the currently proposed patches, if a user specifies hw:ephemeral_encryption in the extra_specs, for example, and they also have a volume with delete_on_termination=True attached, only the root disk will be encrypted via the extra spec -- the volume would not be encrypted. Encryption of the volume has to be requested in cinder. Could this mislead a user into thinking both the root disk and cinder volume are encrypted when only the root disk is? Because of the above issues, we are considering whether we should change the terminology used in this feature at this stage. Some ideas include "local encryption", "local disk encryption", "disk encryption". IMHO "disk_encryption" is ambiguous in its own way because an attached cinder volume also has a disk. Changing the naming will be a non-trivial amount of work, so we wanted to get additional input before going ahead with such a change. Another thing noted in a comment on another patch in the series [8] is that the os-traits for this feature have already been merged [9]. If we decide to change the naming, should we go ahead and use these traits as-is and have them not match the naming in nova or should we deprecate them and add new traits that match the new name and use those? I hope this makes sense and your input would be much appreciated. Cheers, -melwitt [1] https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/epheme… [2] https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/epheme… [3] https://review.opendev.org/q/topic:specs%252Fyoga%252Fapproved%252Fephemera… [4] https://review.opendev.org/c/openstack/nova/+/764486/10/nova/api/validation… [5] https://docs.openstack.org/api-ref/compute/?expanded=create-server-detail#c… [6] https://docs.openstack.org/api-ref/compute/?expanded=attach-a-volume-to-an-… [7] https://docs.openstack.org/api-ref/compute/?expanded=update-a-volume-attach… [8] https://review.opendev.org/c/openstack/nova/+/760456/10/nova/scheduler/requ… [9] https://github.com/openstack/os-traits/blob/f64d50e4dd2f21558fb73dd4b59cd1d…

2 1

[neutron] Drivers meeting - Friday 14.7.2022 - cancelled
by Lajos Katona 14 Jul '22

14 Jul '22

Hi Neutron Drivers! Due to the lack of agenda, let's cancel tomorrow's drivers meeting. See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

[cinder] Festival of XS reviews
by Rajat Dhasmana 14 Jul '22

14 Jul '22

Hello Argonauts, We will be having our monthly festival of XS reviews tomorrow i.e. 15th July (Friday) from 1400-1600 UTC. Following are some additional details: Date: 15th July, 2022 Time: 1400-1600 UTC Meeting link: https://meetpad.opendev.org/cinder-festival-of-reviews etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews Thanks and regards Rajat Dhasmana

1 0

Changing Ubuntu Cloud Repo On Instance
by Adam Pankow 14 Jul '22

14 Jul '22

Ubuntu instance images seem to utilize "nova.clouds.archive.ubuntu.com" as their default repository. It seems that either this server does not efficiently route to an alternate mirror, or it itself is a mirror. This results in quite abysmal download speeds that I have seen. Would there be any downside to picking any other Ubuntu mirror, that is definitively more geographically close to me, but not explicitly labeled a Nova/Cloud mirror? i.e. would there be issues encountered, or features lost, by not using Ubuntu's designated Nova/Cloud repo?

3 2