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

[neutron] Neutron team meeting cancelled Nov 1st
by Rodolfo Alonso Hernandez 26 Oct '22

26 Oct '22

Hello Neutrinos: The next Neutron team meeting on November 1st is cancelled (All Saints' Day [1]). The next one will take place at the same time on November 8th. Regards. [1]https://en.wikipedia.org/wiki/All_Saints%27_Day

1 0

[manila] Antelope PTG Summary
by Carlos Silva 25 Oct '22

25 Oct '22

Hello, Zorillas and interested stackers. Thank you for the productive PTG we had last week. Here goes the summary for the past week's discussions. In case you would like to see the expanded versions, please refer to [0] or check out the recordings in the Manila YouTube Channel [11]. Different approaches for the images we use in our jobs - Recent changes in the Manila CI (related to the service image) made the jobs take longer to run and become more resource intensive, causing jobs to fail more often due to lack of resources in dsvm - We have been looking for approaches to tackle this issue - In the short term, if a job keeps failing due to such issues, we will split it into two jobs - One to run scenario tests (these tests spawn VMs) - One to run API tests - We agreed that this can get worse in the future with dsvm images that could be even more resource demanding, and that we will look for containerized approaches to try and solve this issue Share backup - (kpdev) The proposed approach for share backup has changed - An existing specification [1] was restored - The idea is to have new APIs for share backup and a new generic Backup driver in a similar way to what Cinder does. - This would allow backends to have their specific implementations for share backups - Reviews for this specification are ongoing Secure RBAC changes - Goutham has shared with the community all the good progress we had in Manila, and also mentioned what we did in Zed, after all the operator's feedback. - Now, we are entering a phase where we want to test a lot! - We have a CI jobs and some test cases covered, but we still want to have more coverage - During Antelope, we will promote a hackathon in order to accelerate the functional tests coverage Outreachy Internships - On this topic, ashrodri, fmount, gouthamr and carloss shared the two proposed Outreachy project that are Manila related - ashrodri and fmount are proposing a project to have an intern creating a multi-node test environment with Devstack and Ceph [2], as these tests are becoming more resource demanding - carloss and gouthamr are proposing a project for an intern to work in Manila UI [3]. The idea is to close down the gap of features between Manila UI and the Manila API. OpenStackSDK Manila Status - This has been an effort for some time, and during the Zed cycle some code was merged for integrating share groups and share group snapshots. - This is a good candidate project for an internship, and the idea is that we will be able to get some interns working on this project (potentially a project for a college capstone project) OSC Updates - Zed was the release we targeted to reach feature parity with the native client, and we made it! - We had an idea to add a deprecation warning to the native manila client, but that will need to wait - There is still a missing bit for adding the deprecation warning: having version autonegotiation working, which is something we are targeting for Antelope - OSC is now the primary focus of the project when doing implementations for CLIs. Bandit Testing / VMT - The Manila team was introduced to the VMT (vulnerability management team) and Bandit, and we had contributors sharing their ideas around having manila under the VMT and running bandit tests. - VMT - The audience agreed with the conditions to be under the overseen repos. - Goutham has volunteered to be the security liaison for Manila - Bandit - There were some errors pointed out in a preliminar test run [4]. - We will add a bandit non-voting job and file bugs against third party drivers that have issues pointed out by the new job - New bugs will be filed and will be distributed across community members All Things CephFS - Ingress aware NFS Ganesha - Ceph Orchestrator is now capable of creating an ingress service to front-end a cluster of active-active NFS Ganesha instances via a single load-balanced IP address - Previously, we would only use one single instance of NFS Ganesha. This introduces a SPOF and is not suitable for production environments without HA being handled externally (like TripleO deployments do). With this change, Manila CephFS NFS users would be able to deploy multiple NFS Ganesha servers and leverage inbuilt HA capabilities - Currently though manila client restrictions (access rules) will not work since NFS-Ganesha sees the ingress service's IP instead of the client's IP address. - ffilz proposed his design to support the PROXY protocol with NFS-Ganesha. Ceph Ingress can pass the Client's IP address to NFS-Ganesha [5] - An alternative would be to have cephadm assign stable IP addresses to ganesha instances - No driver changes are anticipated in either approach - AI: Investigating deploying ceph-ingress with devstack - Migration tool for Manila with CephFS NFS - After the new helper was introduced to the driver, we are able to interact with cephadm-deployed CephNFS service (which comes with a lot of benefits) - Now, we need to figure out how to upgrade deployments with CephFS NFS using the current helper (which interacts with NFS Ganesha through DBUS) - There are two main issues: - Representing a change in exports when migrating across NFS Servers (current use case) or when decommissioning NFS Servers - Representing exports from multiple servers - a special case enabling migration where an old server will eventually be decommissioned: - These issues were talked through and possible solutions were proposed and will be worked on in the following cycles. More details on [6] - DHSS=True for CephFS driver - Currently, CephFS driver, whether you'd like to use it for Native CephFS, NFS via DBUS, NFS via ceph-mgr only supports DHSS=False. The request of this feature was raised during the OpenInfra Summit in Berlin from several Manila users. - We discussed some alternatives for making it happen: - 1) Operator determines Ceph cluster limits, and creates isolated file systems and declares multiple manila backends with each filesystem - 2) Subvolume groups - pinning a subvolume group to mds can isolate/dedicate mds load - CephFS CI issues - The lack of resources in the dsvms is affecting the CephFS Native and NFS jobs, causing them to be unstable. The jobs often run into timeouts - The situation could get worse as Jammy Jellyfish packages are not available yet - We will ask the ceph-users if jammy release bits can be made available Oversubscription enhancements - Storage pools supporting thin provisioning are open to oversubscription. This caused some problems mentioned in [7]. - We have an open specification which we intend to merge in the Antelope cycle, as well as the changes to address such issue FIPS - We have shared our testing status with regards to FIPS. We have jobs merged on stable branches up to wallaby for both manila and python-manilaclient repositories. - The next steps would be a more in-depth code audit to identify non-compliant libraries and making our jobs voting - We agreed to make our jobs voting when the Ubuntu images supporting FIPS are out - For drivers using non FIPS compliant libraries, we will notify the maintainers Metadata API update - Metadata APIs for share snapshots were added during the Zed cycle - The goal for this cycle is to have functional testing and the CLI merged. Both patches are under review and expected to be merged not late in the release. Manila CSI - The CSI plugin's been pretty stable in the last six months [8] - There was a good talk presented at KubeCon by Robert Vasek [9] - The next steps include getting a fix for an issue involving long snapshot names in the CephFS backend and supporting volume expansion in the OpenShift Manila CSI driver operator Manila Configuration of VLAN Network information - A issue was found where Contrail Neutron Plugin did not return the VLAN ID during port allocation [10] - To tackle this issue, we have agreed to add metadata to the share network APIs so the administrators would be able to add VLAN as metadata and drivers would be able to consume it. *Better use of bug statuses* - Our bugs were stuck in "New" instead of "Confirmed" or "Triaged" and this could be misleading. - We agreed to tag the bugs as confirmed or triaged depending on the outcome of our triaging and not leave bugs as "new" - We will ask the bug assignees to update their open bugs in case one of them has the new status, so we can have a better visibility [0] https://etherpad.opendev.org/p/antelope-ptg-manila [1] https://review.opendev.org/c/openstack/manila-specs/+/330306 [2] https://www.outreachy.org/outreachy-december-2022-internship-round/communit… [3] https://www.outreachy.org/outreachy-december-2022-internship-round/communit… [4] https://gist.github.com/gouthampacha/c0d96966670956761b2b620be730efe2 [5] https://docs.google.com/document/d/1orjNjtEeeyRrgvbQuFU5BdsCnZG9gF3MymDCZl-… [6] https://etherpad.opendev.org/p/antelope-ptg-manila-cephfs [7] https://etherpad.opendev.org/p/manila_oversubscription_enhancements [8] https://github.com/kubernetes/cloud-provider-openstack/commits/master/pkg/c… [9] https://www.youtube.com/watch?v=XfpP9pBTXfY&t=1145s [10] https://bugs.launchpad.net/charm-manila/+bug/1987315 [11] https://www.youtube.com/playlist?list=PLnpzT0InFrqBzbSP6lcYDStKpbEl3GNHK Thanks, carloss

1 0

[Glance] Antelope PTG Summary
by Pranali Deore 25 Oct '22

25 Oct '22

Hello Everyone, We had our sixth virtual PTG between 18th OCt to 21st OCT 2022. Thanks to everyone who joined the virtual PTG sessions. Using bluejeans app we had all the discussion around different topics for glance, glance + cinder, glance + ceph, fips and secure RBAC. I have created etherpad[1] with notes from the session and also included the recordings of each session. Here is the short summary of the discussions. Tuesday, OCT 18th 2022 # Zed Retrospective On the positive note, we have merged a number of useful features this cycle. We managed to implement glance-download internal plugin to download the image from remote glance, Implemented support for immediate caching of an image, Extended the functionality of stores-detail API to expose store details of other stores and we have removed the scope scheck from scope_types for all project resources and done with phase 1 as per the revised community goal. In addition to that we have successfully organized the review party before each milestone to perform group review to cover the review load till the final milestone. On the other side we decided to organize a midcycle general cross project meetup/drivers meetup towards the end of the 2nd milestone to increase our presence in cross-projects. Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 1 # Distributed responsibilities among cores/team This cycle also we have decided to follow the distributed leadership internally, we are going to distribute below responsibilities among the team, Release management:pranali Bug management: cyril Meetings: pranali Stable branch management: cyril and Erno Cross project communication: abhishekk Mailing lists: share responsibility, pranali PTG/summit preparation:pranali Vulnerability management: glance-coresec group Infra management: periodic-jobs - abhishekk migration of test jobs -abhishekk Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 2 # Default Glance to configure multiple stores Glance has deprecated single store configuration since Stein Cycle and this cycle we are going to start putting our efforts to deploy glance using multistore by default and then remove the single store support from glance. Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 3 # Add missing CLI support for some Glance API in Openstack Client The CLI support for all glance APIS is already there in GlanceClient and the similar CLI support we need to have in OpenstackClient, in this Cycle we are going to put efforts to have OSC support for all the missing glance APIs. Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 4 # Glance Cache improvements, restrict duplicate downloads This is abou how we can avoid multiple downloading of the same image in cache on first download Spec : https://review.opendev.org/c/openstack/glance-specs/+/734683 We had this spec in the last cycle & decided to break the image into chunks and when the first request gets to the backend store it will start caching that image and if any other request comes in between and if caching is still in process it will read from the chunks created by the first request. But currently we have made one caching state to check if the image is still in caching but that was relying on md checksum to check if the image iterator has read the image completely or not but in new images we might not have checksum, multihash or size of the image, bcz if that is not present with the image we won't be able to change the state of image and thus we will never be able to resolve the issue of checking the image is in caching or not. Decided to dig more on the size verification & need to revisit this topic during mid-cycle meeting and update the spec with the solution for handling the multiple request and multiple chunks Recording: https://bluejeans.com/s/II_@CAqrZdd - Chapter 5 Wednesday OCT 19th , 2022 # Image uploads to the filesystem driver are not fully atomic No efficient way to reproduce this issue, so it's decided to mark it as 'Won't fix' Recording: https://bluejeans.com/s/j_UgZFw_jEV - Chapter 1 # DB migration constant change handling Till now we have all the migration scripts by the name of the cycle and since currently release has been change to 2023.1 which is going to break the migration test because when our DB sync tool runs it will check the initial version liberty and it finds the migration script from the liberty and traverse through all the directories till the current release and executes all the scripts available in that path. Decided to fix this by updating the data migration current release to '2023.1' and check with actual migration script to check whether there is any regression or not and check if it executes the scripts in serial manner. Recording: https://bluejeans.com/s/j_UgZFw_jEV - Chapter 2 # Configurable Soft Delete Stephen initiated this topic for nova and oslo.db but also sent out a mail for glance, cinder and for other projects, if we would be interested in the idea https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030729… But Glance replies a lot on soft delete and doesn't allow hard delete as glance allows the user to specify the UUID of the image , so it's part of a security promise of an immutable images that you are not able to delete an image and then recreate image with same UUID right after, hence soft delete model can't be removed from Glance. Recording: https://bluejeans.com/s/j_UgZFw_jEV - Chapter 3 # Secure RBAC As per the revised community goal, till zed cycle we must have the project prosona implementation & drop the system scope which we have already done in glance. We have implemented project scope for image apis in wallaby & in Xena we have managed to move all policy checks to API layer and implemented project scope of metadef APIs. During zed cycle, we had discussed that like which apis should be exposed to system scope but after the operators feedback & as per the revised community goal it was decided to drop the system scope, we just had to remove the scope scheck from scope_types for all project resources, so we are done with Phase 1. In Antelope Cycle glance is going to switch the new defaults flag ON, once it is verified by tempest for all the services. Recording: https://bluejeans.com/s/j_UgZFw_jEV - Chapter 4 # Image Export with Metadata This is about exporting images with associated metadata for importing into another Glance deployment. This cycle we need some volunteers to work on this, the glance team will help in terms of reviews/finalizing the design etc otherwise we will revisit this in the next cycle. This session was not recorded as it was a small discussion # Fips Overview Path forward: - Investigate on the time outing of the existing glance fips job - Try to do the centos9 jobs stable till wallaby, so could possibly move to voting - Have ubuntu jobs working & running and make them stable Recording: https://bluejeans.com/s/j_UgZFw_jEV - Chapter 5 Thursday, OCT 20th, 2022 # Option needed to create image in erasure coded ceph pool To use the erasure coded ceph pool feature where the data will be held needs to be specified during image creation, a config option is needed. Decided to write a spec first describing this in detail and modify the existing devstack job for ceph. Recording: https://bluejeans.com/s/cNEJ@Yq_hv5 - Chapter 1 # Parallelization of RADOS image writes when creating an image This is for parallelization of image writes into ceph, by increasing the amount of data written at once. Decided to not have this without testing to measure if there's an actual gain. Recording: https://bluejeans.com/s/cNEJ@Yq_hv5 - Chapter 2 # Add chunk download support for rbd backend Rbd supports random reading, and the rbd driver is designed to support partial download. But the current version disables this feature, and doesn't implement the chunk support. There is potential future use for it, but there's nothing that users would gain from this. If not usable through the API then we will drop this. Recording: https://bluejeans.com/s/cNEJ@Yq_hv5 - chapter 3 # Operators hour No operator joined the session # Speedup upload images for Swift backend Upload images using Swift backend is slow due to the synchronous way of uploading fragments and which causes loading that can take several hours, especially in cases with very large images. Decided to update the spec with two implementations one as traditional & one for multithreaded one, by having a new configuration option ``swift_store_thread_pool_size`` to the Swift store backend. Recording: https://bluejeans.com/s/cNEJ@Yq_hv5 - Chapter 4 Friday, OCT 21st, 2022 # Cross project meet with Cinder # Glance Image Direct URL access Issue Glance has OSSN-0090[2] describing the security risk when you are operating glance with 'show_multiple_locations' or if the end user facing glance-api has 'show_image_direct_url' options set to true. When glance shares a common storage backend with nova & cinder, it is possible to open some known attack vendors by which malicious data modification can occur. Decided to fix this by going with the solution proposed by Rajat during last cycle, to remove the show_multiple_locations config option and to have below 2 new location APIs[3] which will replace the image-update mechanism for consumers like cinder and nova in glance, 1. Location ADD API: Design this api in way that the location will be added only once during image create when the image is in QUEUED state and no-one should be allowed to add location after the image is active This wouldn't require the 'service role' and a basic check on the glance side to check image status should suffice. 2. Location GET API: This will show all the locations associated with an existing image. Returns an empty list if an image contains no locations. This would still require the 'service role' since we don't want to expose locations to end users. Glance has dependency on keystone for 'service role' which is going to be implemented in this cycle as per phase 2 target mentioned in SRBAC community goals[4]. Recording : https://bluejeans.com/s/B4Rlifuwx_l - Chapter 1 You will find the detailed information about the same in the PTG etherpad[1] along with the recordings of the sessions and milestone wise priorities at the bottom of the etherpad. Kindly let me know if you have any questions about the same. [1]: https://etherpad.opendev.org/p/antelope-glance-ptg [2]: https://wiki.openstack.org/wiki/OSSN/OSSN-0090 [3]: https://specs.openstack.org/openstack/glance-specs/specs/zed/approved/glanc… [4]: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… Thanks, Pranali

1 0

[cinder] Cancelling this weeks meeting 26 Oct
by Rajat Dhasmana 25 Oct '22

25 Oct '22

Hello Argonauts, Since we just had PTG last week, it seems reasonable to skip this week's meeting. Also I will be on leave tomorrow so cancelling this week's cinder meeting (26 October, 2022). - Rajat Dhasmana

1 0

[kolla] [train] Endpoints fail when one controller is down
by Albert Braden 25 Oct '22

25 Oct '22

Some of our clusters are heavily used, and in those clusters we get complaints when we reboot a controller (or sometimes when we deploy and containers restart). Is that normal, or does it mean that we have something configured wrong? The symptoms are intermittent 504 from endpoints, and VM creation/deletion failing or partially completing, for example the VM is created but without DNS records. We are not following the "Removing existing controllers" procedure [1] before rebooting the controller; is that necessary to avoid these issues? 1. https://docs.openstack.org/kolla-ansible/latest/user/adding-and-removing-ho…

1 0

[kolla-ansible][xena][Masakari] masakarimonitors-instancemonitor won't start
by wodel youchi 25 Oct '22

25 Oct '22

Hi, I have this in my computes nodes; masakarimonitors-instancemonitor won't start 2022-10-25 14:37:27.354 7 INFO masakarimonitors.service [-] Starting masakarimonitors-instancemonitor 2022-10-25 14:37:27.357 7 WARNING masakarimonitors.instancemonitor.instance [-] Error from libvirt : authentication failed: Failed to start SASL negotiation: -4 (SASL(-4): no mechanism available: No worthy mechs found) *2022-10-25 14:37:27.357 7 ERROR oslo_service.service [-] Error starting thread.: libvirt.libvirtError: authentication failed: Failed to start SASL negotiation: -4 (SASL(-4): no mechanism available: No worthy mechs found) 2022-10-25 14:37:27.357 7 ERROR oslo_service.service Traceback (most recent call last): 2022-10-25 14:37:27.357 7 ERROR oslo_service.service File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_service/service.py"* , line 806, in run_service 2022-10-25 14:37:27.357 7 ERROR oslo_service.service service.start() 2022-10-25 14:37:27.357 7 ERROR oslo_service.service File "/var/lib/kolla/venv/lib/python3.6/site-packages/masakarimonitors/service .py", line 62, in start 2022-10-25 14:37:27.357 7 ERROR oslo_service.service self.manager.main() 2022-10-25 14:37:27.357 7 ERROR oslo_service.service File "/var/lib/kolla/venv/lib/python3.6/site-packages/masakarimonitors/instanc emonitor/instance.py", line 166, in main 2022-10-25 14:37:27.357 7 ERROR oslo_service.service self._virt_event(uri) 2022-10-25 14:37:27.357 7 ERROR oslo_service.service File "/var/lib/kolla/venv/lib/python3.6/site-packages/masakarimonitors/instanc emonitor/instance.py", line 128, in _virt_event 2022-10-25 14:37:27.357 7 ERROR oslo_service.service vc = libvirt.openReadOnly(uri) 2022-10-25 14:37:27.357 7 ERROR oslo_service.service File "/usr/lib64/python3.6/site-packages/libvirt.py", line 350, in openReadOnl y 2022-10-25 14:37:27.357 7 ERROR oslo_service.service raise libvirtError('virConnectOpenReadOnly() failed') 2022-10-25 14:37:27.357 7 ERROR oslo_service.service libvirt.libvirtError: authentication failed: Failed to start SASL negotiation: - 4 (SASL(-4): no mechanism available: No worthy mechs found) 2022-10-25 14:37:27.357 7 ERROR oslo_service.service 2022-10-25 14:37:27.359 7 INFO masakarimonitors.service [-] Stopping masakarimonitors-instancemonitor I have verified the auth.conf file on both containers the password is the same. In the other hand, in /var/log/kolla/libvirt/libvirtd.log I have this : 2022-10-25 13:29:16.911+0000: 1391031: error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error 2022-10-25 13:30:18.226+0000: 1391031: error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error 2022-10-25 13:31:19.516+0000: 1391031: error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error 2022-10-25 13:32:20.817+0000: 1391031: error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error 2022-10-25 13:33:22.066+0000: 1391031: error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error 2022-10-25 13:34:23.359+0000: 1391031: error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error 2022-10-25 13:35:24.740+0000: 1391031: error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error Any ideas? Regards.

1 0

[kolla-ansible][Yoga] How to configure rabbitmq heartbeat values
by wodel youchi 25 Oct '22

25 Oct '22

Hi, I need to tweak these variables in my Rabbitmq : heartbeat_timeout_threshold heartbeat_rate heartbeat_interval When I tried to add heartbeat_timeout_threshold = 600 to rabbitmq.conf and reconfigure, the service failed to start with : 13:39:41.756 [error] You've tried to set heartbeat_timeout_threshold, but there is no setting with that name. 13:39:41.758 [error] Did you mean one of these? 13:39:41.838 [error] socket_writer.gc_threshold 13:39:41.838 [error] handshake_timeout 13:39:41.838 [error] auth_http.http_method 13:39:41.838 [error] You've tried to set heartbeat_rate, but there is no setting with that name. 13:39:41.838 [error] Did you mean one of these? 13:39:41.888 [error] heartbeat 13:39:41.889 [error] cluster_name 13:39:41.889 [error] channel_max 13:39:41.889 [error] Error preparing configuration in phase transform_datatypes: 13:39:41.889 [error] - Conf file attempted to set unknown variable: heartbeat_rate 13:39:41.889 [error] - Conf file attempted to set unknown variable: heartbeat_timeout_threshold How can I modify those variables? Regards.

2 2

[TripleO] 2023.1 Antelope PTG summary
by Rabi Mishra 25 Oct '22

25 Oct '22

Hi All, Hope y'all had a great PTG last week and a great weekend. I would like to thank everyone who participated/contributed to Tripleo PTG sessions and helped all of us "share and learn". Though personally I don't like long emails, this summary is going to be a bit longer, please bear with me. We had a total of ten sessions spread over two days with very good participation (most sessions with 35+ [max 44] in attendance) and we shared/ discussed a multitude of topics. # Welcome and Zed Retrospective The highlights of the Zed cycle was collaboration across teams to add some new features and fine-tune features implemented in previous cycles that includes; Standalone roles, nftables switch, OVN RAFT support, ephemeral heat for upgrade use cases, CI jobs for Deployed Ceph and Ceph Container Promotion in CI etc. There was a discussion on the suggestion to stop backporting feature removals from stable branches as we did for wallaby in the last few cycles. Though TripleO does not follow stable policy, backporting feature removals with dependent patches across repos more often than not leads to broken CI and user support cases. We would be well placed if we can identify and do those before zed release and avoid the firefighting later. [Action Items] - Update zed review priorities etherpad[1] with deprecation/removal patches [All] # Standalone Ansible Roles Status Update James provided an update on the current status of "Standalone Ansible Roles' POC and we discussed the possible future scope of it beyond the current "scale-out compute" use case. He also demoed molecule based automation of deploying/testing a compute node with the new meta-role. Chandan shared the current work on CI jobs/scenarios to deploy computes with standalone roles. [Action Items] - Prioritize review/merge of proposed patches[2] on this topic [tripleo-core] - Finish the CI jobs for testing standalone roles and make them voting [Chandan/tripleo-ci-core] # Standalone Ansible Roles and External Ceph John presented his work to integrate computes deployed with standalone roles with external ceph. We don't plan to extend this effort to include tripleo deploying ceph using standalone roles, unless there is a requirement for that in the future. [Action Items] - Prioritize review of ceph related standalone role patches.[tripleo-core] # Multi-rhel support for Compute Brendan gave an update on the ongoing effort for multi-rhel support, different options evaluated and current POC status with composable roles approach. There is still some work left on automating role split during upgrade, which is expected to be completed this cycle. [Action Items] - Finish composable roles POC and test upgrade procedure manually [upgrades team] - Add CI jobs to test the proposed procedure upstream as feasible [upgrades team] - Implement role-split automation during upgrade [Takashi/Rabi] # OpenStack SDK, Ansible Collections OpenStack and TripleO We discussed the issues around openstacksdk backward incompatibility and the current pinning for it in RDO/TripleO. We agreed on an action plan to pre-release ansible-openstack-collection (AOC) for RDO/TripleO (though it is still not fully compatible with latest openstacksdk) and remove the pin so that Zed RDO can be released with openstacksdk 0.101.0. [Action Items] - Bump openstacksdk to 0.101.0 for RDO master and zed [Jakob/Alfredo] - Update RDO ansible-collections-openstack to the 2.0.0 pre-release [Jakob/Alfredo] # TripleO and Distributed Project Leadership (DPL) In this session, we discussed the possibility of opting for DPL in TripleO and sharing the responsibilities across multiple leaders in the team. There were a number of volunteers for different liaison roles and we in general agreed that it would be a good thing to do. We would propose the required change to governance sometime this cycle, unless there is any concern. [Action Items] - Finalize all required liaison roles and propose patch to openstack governance repo [Rabi] # Migration from puppetlabs/apache As part of the broader effort to reduce the puppet footprint, Cedric presented the ongoing effort to replace puppetlabs/apache with the new ansible role "tripleo_httpd_vhost"[3]. A few services have already been migrated and remaining ones are expected to be done this cycle with broader participation from sub teams. [Action Items] - Review/merge the already proposed patches for migration [tripleo-core] - Plan and work on migrating remaining services [Cedric] # State of CI CI team presented on a vast range of topics that included, - Added coverage of upgrade jobs across upstream check/gate, periodic component pipeline and periodic integration pipeline in zed (Marios) - Upstream jobs for multi-rhel testing (Marios) - Current state of OVB Jobs (Chandan) - TripleO CI Jobs on IBM Cloud and the new feature to hold nodes for troubleshooting (Chandan) - Tempest Allow List (Arx/Pooja/Soniya) - Tempest Dashboard (Arx/Lukas) # Container Capabilities We revisited the topic of privileged containers for services and how we can possibly avoid those by allowing the required limited container capabilities. As all these services are mostly for the compute role, we agreed that it would probably be better to align this effort with "Standalone Roles" for better testing. # OS Migrate Status Update Jirka provided an update on the tenant migration tool 'os-migrate', an ansible collection that is not a TripleO umbrella project, but used by the upgrades team. It's possible that I missed some important points from these discussions. Please feel free to add them by replying to this thread. All session etherpad links are in the main schedule etherpad[4] for reference. I'll share the session recordings once they're made available to us. Thanks Again. [1] https://etherpad.opendev.org/p/tripleo-zed-review-priorities [2] https://review.opendev.org/q/topic:standalone-roles [3] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [4] https://etherpad.opendev.org/p/oct2022-ptg-tripleo -- Regards, Rabi Mishra

1 0

[cloudkitty] Antelope PTG summary
by Rafael Weingärtner 25 Oct '22

25 Oct '22

Dear all, The CloudKitty project had a great PTG meeting. Thanks to the OpenInfra Foundation for holding it. Also, thanks to all who have dedicated precious time to attend. We started the meeting by revisiting the latest release and discussing the review format we have adopted in the past two years. Looking at the result of our process, we decided to maintain it, as it seems to bring results and concentrate our efforts on getting CloudKitty better and evolving throughout time. While reviewing the past release, we discussed the situation with patch [1] (Allow rating rules that have 12 digits in the integer part of the number). This patch is a bug fix, and we discussed the idea of backporting it. However, as it is a patch that affects the database schema, it can be troublesome to backport it. Therefore, before doing any work, we will consult the mailing list to gather others opinions on this matter. Users could upgrade CloudKitty to address this issue, if they need to, instead of applying a patch. Pierre volunteered to execute this "inquiry" with the CloudKitty user base in the mailing list. While discussing the ElasticSearch (ES) improvements in CloudKitty to support ES 7, we raised the concern that Kolla-ansible is moving from ElasticSearch to OpenSearch. Therefore, we need to evaluate if this can have an impact in CloudKitty. Most certainly it will impact people using ES as the backend. The goal is to revisit this discussion in our next bi-weekly meeting, and then communicate for users and community (Topics for meeting of 31/10/2022 [2]). Furthermore, as the current CloudKitty team is a bit small, we have decided to focus on the following topics for the Antelope cycle. - Multiple rating types for the same metric -- One metric being used to generate different rates - Different time frame group by options -- provide group by options to group by day of the year, week of the year, month, and year. - Improve some timeouts handling when using Gnocchi backends. This one needs some checking with Zigo, who was the one that reported this situation. Zigo, I added you to this e-mail, can you reply back with more details regarding this situation? - A regression API that takes the resource ID Or project ID or scope ID, and executes a regression (prediction) based on the collected data so far for the given resources/elements/scope. - Add CloudKitty API reference docs ( https://docs.openstack.org/cloudkitty/latest/api-reference/index.html) to https://docs.openstack.org/api-ref/ We also briefly discussed the situation with Monasca, which has already been deprecated from Kolla-ansible, and might be losing some traction and support. Therefore, we (as a community), might need to start thinking about deprecating it, and removing some non-tested code from our code base. We do understand that deprecating and removing support is complicated for users, but nobody is maintaining and testing that integration. Therefore, it tends to get broken and unstable over time. However, if somebody wants to volunteer to maintain and improve it, you are welcome :) In summary that is the outcome of our small, but efficient PTG meeting. Let's keep improving and making CloudKitty better. If I missed something, please do not hesitate to reply back. Also, if somebody needs any help, you can always ping me :) See you guys. Have a nice week! [1] https://review.opendev.org/c/openstack/cloudkitty/+/837200 [2] https://etherpad.opendev.org/p/cloudkitty-meeting-topics -- Rafael Weingärtner

1 0

[neutron] Antelope PTG summary
by Rodolfo Alonso Hernandez 25 Oct '22

25 Oct '22

Hello Neutrinos: This is a quick summary of what we have discussed during the PTG week. Zed summary and retrospective: - Here is the output of this session: https://etherpad.opendev.org/p/neutron-antelope-ptg#L83 Spec handling: - To have a core reviewer assigned per spec. This reviewer will engage the community to review the spec and will be a kind of "godfather". - To have a weekly status report of the active specs in the community, to visibilize them, boost their impact and "coerce" the community to review them. Neutron CLI deprecation: - To remove the CLI code. - Python bindings: - Investigate and report the effort needed to make this migration in neutron client consumers (Nova, Horizon, Heat, etc). - Request other projects using the python bindings to move to OpenStack SDK. - Stop merging new features. Quota classes: - Information: https://docs.openstack.org/project-team-guide/technical-guides/unified-limi… - Neutron RFE: https://bugs.launchpad.net/neutron/+bug/1993288 - Still under development in the community, this is still not an accepted community goal, thus we won't start the development until some cons are discussed with the TC members (see the Neutron RFE description). Pyroute2 session: - IPmock, a new class to mock some pyroute2 objects: https://lab.pyroute2.org/ - Pluggable netlink engines. Still not compatible with NetNS (namespaces) - Transactional engine: - A daemon is always reading the netlink and inotify, and builds a DB with the system information. Data is read faster. This could be not compatible with the current sync calls using privsep. - Using NDB class. - Customize message parser, to reduce the amount of data retrieved from the kernel. - Dump/list operators will be generators (to check the compatibility with privsep). Remove the failed devstack migration and get back to what is called "neutron-legacy" (that was discussed before in a PTG but we didn't start the reversion). DNS subdomain support in ML2/OVN: - https://review.opendev.org/c/openstack/neutron-specs/+/832658 - On hold until there is a use case. DNS resolver in ML2/OVN: - https://bugzilla.redhat.com/show_bug.cgi?id=2104568 - The main devoplment part falls in the OVN core team. Once finished, the Neutron part should be almost trivial. ML2/OVN flow metering. - Same as we currently have with ML2/OVS + iptables firewall (currently not supported with native firewall because we can't count OF flows). - Same as the previous feature, the main development is in the OVN core team. Neutron QA: - Implement a grenade job based on the SLURP cadence, testing from Y to A (done). - Have the "tempest-integrated-networking" job in our gate/check queues (patch under review). PCI Device Tracking In Placement (Nova-Neutron session): - The different approaches are still under development. - Spec to be proposed during this release (see etherpad to check the possible implementation options). Port binding switchdev capabilities (Nova-Neutron session): - We agreed that the current implementation is incorrect: Neutron should not modify the port binding dictionary. Nova is not reading it but overwriting it. - We won't change the current code but no new features will rely on it. Nova mutable MTU support (Nova-Neutron session): - For now, Neutron will document that a network MTU change requires a VM reboot (ot port detach/attach operations) to be applied on this port. S-RBAC: - Neutron has three implemented personas: system wide admin, project user and project reader. - Tempest will integrate all RBAC testing projects during this release. Once done, the new RBAC flag will be enabled by default. - Neutron will create the corresponding RBAC job/jobs. - Neutron needs to identify what is called "service role" calls (done from other projects). This is a new concept that will be included in next releases. nftables migration: - The current iptables legacy interface could be deprecated. During this release, Neutron will start an epic to move the current iptables API to the new nftables API; if possible, incrementally, mixing both APIs in the same agent. Please, if there is any missing topic, let me know. Regards and thank you for attending and participating.

1 0