January 2022 - openstack-discuss - lists.openstack.org

[all][tc] What's happening in Technical Committee: summary 28th Jan, 21: Reading: 5 min
by Ghanshyam Mann 29 Jan '22

29 Jan '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week meeting yesterday. Most of the meeting discussions are summarized below (Completed or in-progress activities section). Meeting full logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-01-27-15.00.log.html * Next week's meeting is on 3rd Feb Thursday 15:00 UTC, feel free add the topic on the agenda[1] by 2nd Feb. 2. What we completed this week: ========================= * "FIPS compatibility and compliance" community-wide goal proposal is merged[2] * Renamed Skyline repo to openstack/ namespace[3] 3. Activities In progress: ================== TC Tracker for Yoga cycle ------------------------------ * This etherpad includes the Yoga cycle targets/working items for TC[4]. 2 out of 9 items are completed. Open Reviews ----------------- * 3 open reviews for ongoing activities[5]. Renaming all `master` branches on all repos to `main` --------------------------------------------------------------- lourot brought this topic and we discussed if we want to do that. Key point here is how much effort it will take to do for all the existing repo in term of make it working in CI/integration testing tooling/other scripts or not. And we should do it for new repo only. All these are unknown as of now. As first step, lourot will try the project-config importing of dummy project with 'main' branch from GitHub. Based on that, we will discuss it further. Z release cycle name ------------------------- Name nomination is closed, election for proposed names are in-progress. Follow the ML thread for updates[6]. Z release cycle Technical Election --------------------------------------- Election schedule is under review [7], please review and add your feedback. Remove the tags framework --------------------------------- yoctozepto has proposed the WIP patch to remove the tag framework, feel free to review and provide early feedback[8]. OpenStack Pain points discussion ---------------------------------------- No updates in this week. Stay tuned on the ML thread[9] and Rico will inform you about the next meeting details. TC position on release cadence ------------------------------------- Dan started the skip level upgrade in grenade and made its working for stable/wallaby to master[10]. TC is planning to meet and discuss the release cadence on 3rd Feb 16 UTC. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[11]. Project updates ------------------- * Retire js-openstack-lib (waiting on Adjutant to have new PTL/maintainer) [12] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://governance.openstack.org/tc/goals/proposed/fips.html [3] https://review.opendev.org/c/openstack/governance/+/826243 [4] https://etherpad.opendev.org/p/tc-yoga-tracker [5] https://review.opendev.org/q/projects:openstack/governance+status:open [6] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026810.… [7] https://review.opendev.org/c/openstack/election/+/825017 [8] https://review.opendev.org/c/openstack/governance/+/822900 [9] http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026245… [10] https://review.opendev.org/c/openstack/grenade/+/826101 [11] https://etherpad.opendev.org/p/zuul-config-error-openstack [12] https://review.opendev.org/c/openstack/governance/+/798540 [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

Secure Boot VM issues (libvirt / SMM) | Secure boot requires SMM feature enabled
by Imran Hussain 29 Jan '22

29 Jan '22

Hi, Deployed Wallaby on Ubuntu 20.04 nodes. Having issues with libvirt XML being incorrect, I need the smm bit (<smm state='on'/>) and it isn't being added to the XML. Anyone seen this before? Or any ideas? More info below... Error message: : libvirt.libvirtError: unsupported configuration: Secure boot requires SMM feature enabled Versions: libvirt version: 6.0.0, package: 0ubuntu8.15 QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.18) Nova 23.1.1 (deployed via kolla, so kolla/ubuntu-source-nova-compute:wallaby is the image) ovmf 0~20191122.bd85bf54-2ubuntu3.3 Context: https://specs.openstack.org/openstack/nova-specs/specs/wallaby/implemented/… Image metadata: hw_firmware_type: uefi hw_machine_type: q35 os_secure_boot: required os_hidden: false hw_disk_bus: scsi hw_qemu_guest_agent: yes hw_scsi_model: virtio-scsi hw_video_model: virtio os_require_quiesce: yes os_secure_boot: required os_hidden: false XML snippets taken from nova-compute.log: <sysinfo type="smbios"> <system> <entry name="manufacturer">OpenStack Foundation</entry> <entry name="product">OpenStack Nova</entry> <entry name="version">23.1.1</entry> <entry name="serial">2798e3fe-ffae-4c26-955b-ef150b849561</entry> <entry name="uuid">2798e3fe-ffae-4c26-955b-ef150b849561</entry> <entry name="family">Virtual Machine</entry> </system> </sysinfo> <os> <type machine="q35">hvm</type> <loader type="pflash" readonly="yes" secure="yes">/usr/share/OVMF/OVMF_CODE.ms.fd</loader> <nvram template="/usr/share/OVMF/OVMF_VARS.ms.fd"/> <boot dev="cdrom"/> <smbios mode="sysinfo"/> </os> <features> <acpi/> <apic/> </features> Other info: # cat /usr/share/qemu/firmware/40-edk2-x86_64-secure-enrolled.json { "description": "UEFI firmware for x86_64, with Secure Boot and SMM, SB enabled, MS certs enrolled", "interface-types": [ "uefi" ], "mapping": { "device": "flash", "executable": { "filename": "/usr/share/OVMF/OVMF_CODE.ms.fd", "format": "raw" }, "nvram-template": { "filename": "/usr/share/OVMF/OVMF_VARS.ms.fd", "format": "raw" } }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "acpi-s3", "amd-sev", "enrolled-keys", "requires-smm", "secure-boot", "verbose-dynamic" ], "tags": [ ] }

2 3

[release] Release countdown for week R-8, Jan 31 - Feb 04
by Előd Illés 29 Jan '22

29 Jan '22

General Information ------------------- The following cycle-with-intermediary deliverables have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle. As a result, we have proposed[1] to change the release model for the following deliverables: ovn-octavia-provider ironic-prometheus-exporter ironic-python-agent-builder ironic-ui networking-baremetal networking-generic-switch patrole swift [1] https://review.opendev.org/q/topic:not-yet-released-yoga PTLs and release liaisons for each of those deliverables can either +1 the release model change, or propose an intermediary release for that deliverable. In absence of answer by the end of R-8week we'll consider that the switch to cycle-with-rc is preferable. We also published a proposed release schedule for the upcoming Zcycle. Please check out the separate thread: http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026696.… Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 17th, 2022(R-6 week) Client library freeze: February 24th, 2022(R-5 week) Yoga-3 milestone: February 24th, 2022(R-5 week) Yoga final release: March 30th, 2022 Next PTG: April 4 - 8, 2022 (virtual) Előd Illés irc: elodilles

1 0

[sdk][devstack] openstacksdk-functional-devstack job failing on stable branches
by Brian Rosmaita 29 Jan '22

29 Jan '22

openstacksdk-functional-devstack began failing in the stable branches (xena through ussuri) shortly after 2022-01-24 11:53:49 with the error openstack.exceptions.ResourceNotFound: ResourceNotFound: 404: Client Error for url: https://{ip_address}:9696/v2.0/qos/policies/69e472c0-37d2-46e0-9b9e-727c962c5511/minimum_packet_rate_rules, The resource could not be found. for these four tests: openstack.tests.functional.network.v2.test_qos_minimum_packet_rate_rule.TestQoSMinimumPacketRateRule.test_find openstack.tests.functional.network.v2.test_qos_minimum_packet_rate_rule.TestQoSMinimumPacketRateRule.test_get openstack.tests.functional.network.v2.test_qos_minimum_packet_rate_rule.TestQoSMinimumPacketRateRule.test_list openstack.tests.functional.network.v2.test_qos_minimum_packet_rate_rule.TestQoSMinimumPacketRateRule.test_update job build history: https://zuul.opendev.org/t/openstack/builds?job_name=openstacksdk-functiona… It's passing in master and stable/{train,stein,rocky}. Anyone know what's up?

6 6

[nova][powervm][zvm] Time to mark powervm and zvm drivers as deprecated for removal?
by Stephen Finucane 29 Jan '22

29 Jan '22

I've had a PR open against the pypowervm library for over a fortnight now [1] with no activity. This has prompted me to go looking into the state of the powervm driver and what I've found isn't great. It doesn't seem there has been any feature development on the driver for many years, and the last change I can see that wasn't simply of a case of "I need to do this to get tests to pass" was over three years ago [2]. The CI also doesn't appear to have been touched in years. The situation for zvm isn't any better. The last functional change to that driver was nearly 2 years ago and I wasn't able to spot any CI running (though it's possible I just missed this). This means the powervm and zvm drivers stand out from the other non-libvirt drivers in-tree, each of which are getting at least some activity (albeit out- of-tree for Hyper-V, from what I recall). It also begs the question: are these drivers something we want to keep around? If we do, how are we going to maintain them long term? If not, how aggressive should we be in removing that now dead code? I'll open patches to mark both powervm and zvm as deprecated shortly so that, assuming nothing changes in the interim, we can look to remove it early in the Z cycle. Please respond here or on the reviews if you have concerns. Stephen [1] https://github.com/powervm/pypowervm/pull/17 [2] Change ID I89ad36f19672368a1f795e1f29c5af6368ccfeec

1 1

[cyborg] cancel weekly meeting in on February 4, 2022
by Brin Zhang(张百林) 28 Jan '22

28 Jan '22

Hi all, February 1~ February 6, 2022 are the Spring Festival of China, so we will cancel next weekly meeting, if you have some questions you can ping us by email. best regard brinzhang

1 0

[neutron] Drivers meeting agenda - 28.01.2022
by Lajos Katona 28 Jan '22

28 Jan '22

Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. There is no RFE proposed this week, but I would like to discuss again how to handle neutron-fwaas. To simplify things TC asked to keep neutron-fwaas under openstack/ namespace, see the discussion on #openstack-tc: https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2022-0… [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda See you at the meeting tomorrow. Lajos Katona (lajoskatona)

1 0

[rbac][keystone][kolla][osa][tripleo][charms] RBAC in Yoga for deployment projects
by Mark Goddard 28 Jan '22

28 Jan '22

Hi, If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach. The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read. In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed. In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks. The next change we have staged is to add the service role to all service users [4], in preparation for [2]. Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope. We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis. In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal. How does that line up with other projects' approaches? What have we missed? Mark [1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/c… [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/c… [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1… [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible

6 23

[manila][cinder][glance][nova] Pop-up team for design and development of a Cephadm DevStack plugin
by Victoria Martínez de la Cruz 28 Jan '22

28 Jan '22

Hi all, I'm reaching out to you to let you know that we will start the design and development of a Cephadm DevStack plugin. Some of the reasons on why we want to take this approach: - devstack-plugin-ceph worked for us for a lot of years, but the development of it relies on several hacks to adapt to the different Ceph versions we use and the different distros we support. This led to a monolithic script that sometimes is hard to debug and break our development environments and our CI - cephadm is the deployment tool developed and maintained by the Ceph community, it allows their users to get specific Ceph versions very easily and enforces good practices for Ceph clusters. From their docs, "Cephadm manages the full lifecycle of a Ceph cluster. It starts by bootstrapping a tiny Ceph cluster on a single node (one monitor and one manager) and then uses the orchestration interface (“day 2” commands) to expand the cluster to include all hosts and to provision all Ceph daemons and services. [0]" - OpenStack deployment tools are starting to use cephadm as their way to deploy Ceph, so it would be nice to include cephadm in our development process to be closer with what is being done in the field I started the development of this in [1], but it might be better to change devstack-plugin-ceph to do this instead of having a new plugin. This is something I would love to discuss in a first meeting. Having said this, I propose using the channel #openstack-cephadm in the OFTC network to talk about this and set up a first meeting with people interested in contributing to this effort. Thanks, Victoria [0] https://docs.ceph.com/en/pacific/cephadm/ [1] https://github.com/vkmc/devstack-plugin-cephadm

5 6

[TripleO] gate blocker centos-9 please hold rechecks
by Marios Andreou 28 Jan '22

28 Jan '22

o/ Hi folks please hold rechecks especially if you see failing centos9 jobs (should be all of master tripleo repos now) we have a gate blocker there https://bugs.launchpad.net/tripleo/+bug/1959181 thank you, marios (on behalf of tripleo-ci team - #oooq and #tripleo channels)

1 1