Hello, zorillas and interested stackers! Thank you for attending the PTG over the last week. We had a good audience and a lot of good discussions over the proposed topics. On the official etherpad [9] you will find the notes we took during the discussions, as well as links to additional etherpads or other references. The YouTube playlist [14] holds all the recordings we had over the week. Every video corresponds to one PTG day, and their description contains the exact time frame of the discussions. *== Xena cycle retrospective ==* * We agreed and were happy with the events we have been doing in the community (collaborative review sessions, bugsquashes and some other). They help us to understand the changes that are coming in every cycle, and also get to share knowledge with the contributors. For this cycle we will define different themes for our bugsquashes. Some dates are already defined. * We agreed on the importance of the reviews from different affiliations and we decided on a few practices to involve more community members in the review process. * We brought up the enhancements we need to do in the Manila UI, and mentioned some features that we are lacking for feature parity compared to the Manila core code. * We decided to host a hackathon in the beginning of the cycle, as we had a very positive output from the last one we had. This one can focus on the functional testing of the OSC for Manila, which we are lacking. * During the Z cycle we will host the first code walkthrough for Manila. (kudos for gouthamr for the idea). The intention of this event is to help the new contributors to better understand the code and allow them to ask questions, as well as explain the structure of our repositories and go over some key parts of Manila. * We discussed the difficulties we are facing with ethercalc and we got to a point where we saw there was no alternative way to replace it. More details about the retrospective available in [1]. *== Thin Provisioning and Oversubscription improvements ==* * haixin and gouthamr brought up this topic after a few discussions on how the oversubscription issue should be solved in Manila. * Storage pools that support thin provisioning are open to an "oversubscription". * We have a ratio for allowing oversubscriptions and it also influences the way the manila scheduler filters acts. We currently have issues with that calculation. * If the backends do not report their allocated_capacity_gb, it will be inaccurate. * We can have the share manager to have a more precise calculation. * Action Items: ** haixin will write a spec with more details on how this issue is going to be addressed. *== NetApp ONTAP - migration from ZAPI to REST API ==** nahimsouza and fabioaurelio talked about the NetApp ONTAP drivers that are currently using ZAPI for communication with NetApp hardware. * NetApp is now planning to deprecate ZAPI in favor of REST. This means that if they find issues within the ZAPI calls, NetApp won't fix them anymore. * The side effect of this is that NetApp wants to migrate their driver calls from ZAPI to rest, but it will impact pretty much all operations the driver performs. * These are going to be huge changes and they intend to backport it to the oldest maintained release. * They have lots of customers using the latest versions of ONTAP but those customers do not often upgrade their OpenStack deployments. * They are looking for approaches on how to backport these changes even further. *== Add support for automatic snapshot creation and removal ==** Kiran brought up the solution proposed with a spec [2], which intends to add an automatic snapshot creation policy and automatic snapshot deletion policy for a share, considering an interval defined by an administrator. * We've asked for possible alternatives such as automating the snapshots creation via manilaclient/REST API, and also raised a few questions that would help us to enforce the need of enhancing the API. * Action Items: ** Kiran will come back with updates on the discussion points. *== Manila UI updates ==** vkmc discussed the updates for Manila UI alongside the NDSU students. * They talked about the plans we have for the UI in this cycle, as well as bringing up the feature-parity issue we currently have. * We started by filing blueprints and identifying the scope of necessary changes to get feature parity. * A taiga board [3] was created to track the progress. * We also have a few blueprints [4] for that. *== Consistent and Secure RBAC changes ==** gouthamr, gmann and vhari brought up the plans for the Z cycle, which would be continuing the plans highlighted on [5] So for Z, the idea is to: * Harden Phase 1 by re-evaluating the use of "admin" at system scope, disallowing system scope users from creating/manipulating project resources * Continue working on tempest protection tests. Liron has a patch pending reviews that starts this work [6] * Test existing tempest API/scenario tests with the new RBAC defaults and adjust any credential use or API expectations by the end of the cycle * Start working on the phase 2 per the community goal in [5] Beyond Z: * A release - Phase 3: System Reader and System Member in the default RBAC * B release: Remove deprecated policies * == OpenStack Client updates for Manila ==** maaritamm presented the progress we had so far for the OSC integration. * We are quite close to feature parity. The idea is to reach feature parity in the Z cycle and add a deprecation warning to the native client shell in python-manilaclient. * We are lacking functional tests and we came up with a plan of organizing a hackathon to be hosted close to the z-3 milestone. * This hackathon will be focused on addressing the functional tests for the client and wrapping it up. * As enforced in the past cycle, maintainers implementing new functionalities to python-manilaclient must _only_ implement them for OSC. * New features in the python-manilaclient shell will actively be discouraged. * A more detailed version is available in [7]. *== Support for highly available NFS Ganesha in the CephFS driver ==** vkmc, fmount and gouthamr presented the the Ceph orchestrator tooling that now natively supports deploying nfs-ganesha gateway servers as "ceph-nfs" cluster daemons in active/active configurations. * The Ceph community has also added support for nfs APIs to create and manipulate exports on such ceph-nfs daemons. * We discussed the changes needed to support these in Manila and how users can migrate their workloads. To provide adequate control to deployers and end users, we agreed to introduce a new protocol helper layer that will live alongside the current DBUS API helper. * When the deployment supports new NFS clusters, deployers would be able to configure "alternate" server IPs in manila which can aid a slow transition for end users to migrate to newer "preferred" servers. * We're planning to automate this transition in Triple-O while also documenting this for developers of other deployment tools. *== Devstack-plugin-ceph changes ==* * vkmc and fmount presented the changes they are implementing in order to install/deploy the ceph cluster using cephadm. There is an open change for review [8]. We are also testing the Manila CephFS job in [9]. * Native CephFS scenario tests concerning ceph-fuse are failing sporadically with timeouts while mounting. * There are few issues with testing and there is more information about them in [9]. As next steps we have: * Testing with CentOS as the devstack host and Manila's client, so we have different approaches of testing and can ensure that ubuntu testing isn't compromising the VMs and causing the possible lack of resources we are experiencing. * Splitting CI changes into different test sets focusing on different services * Turning on cephadm based deployment in the multi-node job *== Topic #Bug updates ==** vhari has shown some bug analytics and the progress we have been making over the past cycles. * We have a bunch of bugs that are old and no one has been touching them in a while (at least 2 years). * Maintainers should check launchpad and evaluate those bugs we created and/or are assigned to us and see if they are still relevant. If they are, we should keep active on them, otherwise we can just let it fall into the auto-expiry policy. * Bugsquashes have been efficient for us, we should keep doing them. ** fabioaurelio suggested a bugsquash theme that would double up as a review jam. We'd be focusing on looking at the lingering changes that are closing bugs and getting closure for them. * When we don't have the time to do the bug triaging during the Manila meeting, we will do the triaging in #openstack-manila after. * We will be hosting our bugsquashes in Z-1 and the other one between Z-2 and 3. * Action items: ** carloss will update the change with manila specific milestones to reflect our scheduled events *== Metadata API status update ==** This is an effort that started some cycles ago. We intend to allow metadata on more user facing resources in Manila [10], and do that in a generic way. * Over the Yoga cycle that was accomplished for shares, and there is a change to also permit that for share snapshots. What's next: * Getting the share snapshots changes merged over the Z cycle (M-1) * Getting the new metadata mechanism also implemented for * Share Export Locations - Target: M3 (at least API + CLI) * Share Access Rules - Target: M3 (at least API + CLI) * Share Groups - Target: M3 (at least API + CLI) *== NetApp CI Zuul v3 Migration - Challenges and lessons learned ==** Building and maintaining a stable CI system has been a huge pain point to Manila's "third party" vendor storage developers for the past few releases. * NetApp contributors have talked about their Zuul v3 setup using Software Factory. They brought up some information on their Zuul v3 CI setup and talked about some difficulties they faced during the setup. * The recording is on Manila's YouTube channel [11]. There were questions asked and raised and the discussion documented in [9]. * Action items: * Through the release cycle, we hope to offer more venues for more knowledge sharing regarding third party CI maintenance. *== FIPS compliance ==** carloss ashrod98 and ade_lee talked the attendance through the challenges and testing for FIPS * We've been through the next steps and what has been done so far in Manila ** Few changes were proposed and merged ** Our CI job is working fine with CentOS 8 but we decided we should already have it on CentOS 9 * We needed to monkey patch paramiko for some drivers ** gouthamr is concerned that if this patching paramiko change is merged, this could break older branches in the future ** A discussion in openstack-discuss will be started to ensure if this is the best approach for this issue. * At the moment, we should stick with testing using CentOS but testing with Ubuntu is under way. * Compliance steps will start on Z release * ade_lee started an audit in OpenStack services to identify non FIPS compliant libraries * Goal should be completed on AA cycle * Action Items: ** Start a discussion on patching paramiko or switching to other lib ** Submit the jobs for python-manilaclient, manila-ui and manila-tempest-plugin *== Tech Debt ==*These are a few items we would like to get moving for Manila in the next cycles. They usually involve a community goal, a request for enhancement or recommendations from the community: * Migrating from privsep to rootwrap: In progress, few changes were merged over Y cycle and we intend to have even more progress over Z. * Dropping python-keystoneclient from python-manilaclient: this is also in progress and we got a few related changes merged. We will bring this up again in the upcoming manila meetings. * Cinder/Nova online extensions support with the generic driver: this hasn't started yet and we are looking for an owner. This is more of a request for enhancement that would benefit those using the generic driver. * 26 volumes limit in the generic driver: this is something that was called out in the generic driver documentation. We agreed to try an approach where we would update the manila image and check the output for it. * Publish the container driver image on tarballs.openstack.org (or quay.io): we had few changes to the container driver in the past cycles. One functionality was implemented on it (add/update security services in share networks that are used), and for that change to be tested, the container must have OpenLDAP installed. We have a way to publish new artifacts and we could benefit from reusing that. Action items: ** carloss will work on having the new image proposed ** Bring the keystoneclient change in the upcoming manila meetings. ** Update the manila image setting hw_scsi_model=virtio-scsi and investigate if the 26 volumes limit will be solved ** Work on finding people interested to contribute in the Cinder/Nova online extensions support with the generic driver *== Manila CSI updates ==** gman0, gouthamr and vkmc talked us through some of the updates in the Manila CSI since the last PTG [12]. * We don't currently test using RWO volumes with manila-csi in cloud-provider-openstack, so we could add an "external-attacher" sidecar to ensure RWO-ness * Doing backups with manila-csi and velero/restic * Action items: ** open an issue against the CPO repo and work on testing with RWO ** open a redmine tracker to call the limitation of giving huge names to snapshots in the docs *== Community Hour ==** gouthamr brought up some details about the release cadency adjustment [13] * Also, mentioned a few implications of this and how deprecations, testing and upgrades will work * Few details in the deprecation windows and how we should be working and targeting changes in the next few cycles. * A job was recently merged in Manila to test the upgrade from tick to tick releases * Action items: ** Update the tick release job to the Xena branch [1] https://etherpad.opendev.org/p/manila-yoga-retrospective [2] https://review.opendev.org/c/openstack/manila-specs/+/823165 [3] https://review.opendev.org/c/openstack/manila-specs/+/823165 [4] https://blueprints.launchpad.net/manila-ui/+spec/api-version-features [5] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... [6] https://review.opendev.org/c/openstack/manila-tempest-plugin/+/805938 [7] https://etherpad.opendev.org/p/zorilla-ptg-manila-osc [8] https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/826484 [9] https://etherpad.opendev.org/p/zorilla-ptg-manila [10] https://specs.openstack.org/openstack/manila-specs/specs/yoga/metadata-for-s... [11] https://www.youtube.com/watch?v=Pn1ZEnlHE7A [12] https://etherpad.opendev.org/p/zorilla-ptg-manila#L413 [13] https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adj... [14] https://www.youtube.com/watch?v=AIqrLdprkaE&list=PLnpzT0InFrqCjifjP1OzFgnfiB1j0j6F2