Hello Zorillas and other awesome Stackers, Thank you for participating in the Yoga cycle Project Teams Gathering. A special thanks to the folks at the OpenInfra Foundation who provided the platform for this event! We brainstormed on numerous topics. You'll find the unabridged notes and links in the main etherpad [1]. Video recordings from the event are posted on our Youtube channel [2]. The following is my summary of the proceedings. Please feel free to follow up here, or on OFTC's #openstack-manila if you have any questions. == Xena cycle retrospective == Etherpad: https://etherpad.opendev.org/p/manila-xena-retrospective * We celebrated successful Outreachy internships (Kafilat Adeleke and Archana Kumari), completion of the senior design project of students from Boston University (Ashley Rodriguez, Nicole Chen and Mark Tony) and two Open Source Day mentoring events at the Grace Hopper Celebration. * We have long term contributors in kafilat and archanaserver, along the lines of ashrod98 (who is now a Red Hatter!), disap (at Microsoft!), kiwi_36 (continuing his unified limits work), maaritamm (at city network, is manila core!) and many others. Very proud of the effort the team puts in to attract and retain such talent in the community. * We also discussed the mentoring efforts coinciding with the Yoga release (Northeastern University Cloud Computing course project, Outreachy internships, others). * We anticipate more changes to the maintainers team in the Yoga cycle in our continued effort to build domain expertise around the team, and avoid reviewer burn out. * Thanks to the enthusiastic participation, and to a well groomed bug backlog (kudos, vhari) we had two successful bugsquash weeks and a hack-a-thon during the Xena cycle. We're pruning down the list of stale issues collaboratively. The team liked the frequency of these events. * We discussed the responses for the 2021 User Survey and key takeaways (need for active/active HA, unified limits, unified cli, virtiofs) * Action Items: ** Plan a hack-a-thon in Yoga (topics welcome) ** Update questions for the 2022 user survey ** Plan periodic collaborative code review events alongside the bug squash events to prevent languishing patches. == Share transfers == * haixin highlighted the need for APIs to safely transfer shares across project namespaces and discussed some caveats, and a rough workflow for the feature * To ensure secure multi-tenancy, many back end share drivers use the project_id metadata in their provisioning paths - so transferring resources must send appropriate notifications * For DHSS=True, transfering the share alone makes little sense without first transfering the share network onto which the share is exported - however, multiple shares can be associated with one share network, so this could need a multi-phase transfer needing an ability to rollback. * Action Items: * Propose a spec and discuss the multi-stage implementation of this feature == Project testing and Interoperability improvements == * vhari shared plans for the improvement of the interop guidelines associated with manila * We touched upon the work lkuchlan and vhari are doing to align optional feature testing with tempest's best practices * Third party CI maintainers were reminded that they must be running scenario tests * Action Items: * Team looks at the possible tests to add as advisory to the 2021.11 guideline: https://etherpad.opendev.org/p/refstack-test-analysis == CephFS driver and integration changes == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-cephfsnfs-cephadm * vkmc highlighted the changes intended in the Manila CephFS driver to adopt the ceph mgr nfs APIs instead of the DBUS interactions that the Ganesha interace is coded to perform. The ceph mgr NFS APIs would only work on cephadm-deployed ceph nfs (nfs-ganesha) clusters. * Ceph nfs can be deployed like any other ceph daemon in an active/active HA cluster. One concern was the backwards incompatible changes to default nfs-ganesha configuration - this is being worked out. * TripleO developers joined us to discuss deployment changes, and the upgrade concerns including the eventual change in the NFS VIP. * Action Items: * Share notes about the deployment and upgrade changes necessary to get manila's CephFS driver to work with an active/active NFS HA cluster for the benefit of operators as well as deployment tools like tripleo, kolla-ansible, juju charms, etc. == Manila deployment at the Edge == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-at-the-edge * I quizzed fultonj about the use cases and architecture of the Distributed Compute Node edge deployments that tripleo is capable of orchestrating. * DCN now supports persistent block storage, and enables setting up the service in a multi-backend configuration with local-to-compute backends associated with availability zones that represent the edge sites. * We captured work items to similarly support manila-share at edge sites in this architecture to enable RWX storage at edge sites, and brainstormed future possibilities around the feature (cross site share replication) * Action Items: - A spec to support manila-share in an active/active HA configuration - Testing template for A/A with vendor share drivers == Metadata APIs for all user facing resources == Etherpad: https://etherpad.opendev.org/p/yoga-manila-metadata * ashrod98 discussed the ongoing work to generalize user defined metadata to all end-user facing resources. Currently users can attach metadata to shares and access rules, and the service provides metadata to export locations. * There are changes to the initial design that were brainstormed wrt RBAC and service/operator metadata. * The new APIs are going to be supported in the openstackclient shell implementation * Action Items: * Reviewer attention needed for the changes to the metadata spec, and for new RBAC guarding operator metadata. == Manila UI updates == * vkmc, carloss and haixin presented the plan to update the UI's feature parity * We have two outreachy internship proposals around implementing new UX around share networks and for enhancing integration testing for manila-ui * Action items: * Outreachy contributor period is open, lookout for applicants seeking reviews * Identify trivial API features that can be supported with little effort for the Yoga cycle hack-a-thon == VirtIOFS == Etherpad: https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-yptg-october-20... * tbarron presented updates regarding the ongoing prototyping for nova's support of virtiofs. * There's a demo of how the feature's expected to work: https://asciinema.org/a/IZ7UrhwspxBN63XsOl9JrTcUX?speed=1.5 * The nova discussion (https://etherpad.opendev.org/p/nova-yoga-ptg) included mechanics of supporting read-only attachments, os-share library, mount tags and use cases for baremetal nodes. The specification will be refined to answer some of these questions. * This continues to be a multi-release effort as changes in libvirt, qemu, kvm were needed for live virtiofs attachments. * Action Items: * Review/Refine nova spec: https://review.opendev.org/c/openstack/nova-specs/+/813180 == Multiple share network subnets in an AZ == Etherpad: https://etherpad.opendev.org/p/ptg-multiple-subnet * nahimsouza and felipe_rodrigues presented the use case for share networks to allow multiple subnets per availability zone. * This proposal would make dual stack ipv4/ipv6 networking possible for DHSS=True * Users would also have the ability to modify share networks that were in use - new network allocations will be possible for existing share servers, however, network allocations cannot be deleted. * Concerns were raised regarding the user experience and error signalling when port allocations cannot be made from all relevant subnets. * Action items: * Determine what needs to happen when a subnet has run out of allocations * Propose a specification discussing the API and driver interface impact to accommodate this change == FIPS compatibility and compliance == Etherpad: https://etherpad.opendev.org/p/yoga-manila-FIPS * carloss, ashrod98 and ade_lee spoke of the cross project effort to get FIPS compatibility and compliance testing * We discussed manila's direct/indirect use of cryptographic libraries and FIPS compliant alternatives (md5 in code, and paramiko's use of non-fips compliant digests); manila-tempest-plugin needs fixes along the same lines since it relies on paramiko. * Currently, the team's writing new CI jobs to test compatibility - these should merge by the end of the Yoga release cycle; the goal for compliance would be the Zorilla release (yes, i said it). * Action items: * Work on FIPS compatibility jobs in the Yoga release cycle == Secure RBAC changes in Yoga == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-srbac * vhari and I rounded up the work done so far to update the default RBAC policies across manila APIs and highlighted known issues, and pending work items * Cross service arbitrations on behalf of a user are ongoing discussions elsewhere - examples of these include manila's generic driver where the user's namespace and quota are consumed to create the nas server, backing volume and networking * We are continuing to implement tempest tests and anticipate a large portion to be completed during the Yoga cycle. * We don't plan to support cloud profiles with the manilaclient shell. Users are encouraged to switch to the openstackclient shell to use cloud profiles. * Action items: * Close on known issues in manila code * Complete protection and tempest test coverage == Paying down some technical debt in Yoga == * python-manilaclient still uses keystoneclient instead of keystoneauth1 - vkmc and gouthamr will work on this early in the Yoga release cycle * sqlalchemy2.0 changes - ack'ing SADeprecationWarnings and switching to using the new db engine facade exposed by oslo.db - felipe_rodrigues and gouthamr will work on this during the Yoga cycle * these are wishlist items that need volunteers to drive them to completion: * the generic driver doesn't yet support online extensions - * the generic driver can support more than 26 volumes per share server - this is a wishlist item that needs a volunteer to drive it * we need to publish the container driver image to a container registry from its development within the manila-image-elements project == Backing up shares == Etherpad: https://etherpad.opendev.org/p/ptg-backup-manila * We were joined by operators and storage experts from SAP, CSI Piemonte, NetApp, Red Hat and CERN to discuss current use cases and methods to backing up manila shares * Existing data protection and disaster recovery tools within manila (creating and mounting snapshots, cloning snapshots to new shares, reverting snapshots in-place, replicating shares and snapshots) were compared against the need for scheduling, efficient, incremental, durable/ex-situ/non-homogenous backup destinations, whole container vs selective file backup and recovery. * Available DIY external tooling (restic, borg, urbackup, other) and wrappers were discussed * Creating a backup solution based off-of the manila-data service was considered in the past, the spec was abandoned. It could be revived; however, we could benefit from presenting the need, a state of affairs as they are before exploring solutions. * Action Items: * We'll write up a doc on data protection for manila shares and invite operators to review them and propose future plans; anyone interested in collaborating in this space can get in touch with felipe_rodrigues == OpenStackCLI updates == Etherpad: https://etherpad.opendev.org/p/manila-osc-yoga * Thanks to maaritamm's awesome work, and the enthusiastic hack-a-thon participation from the community, we're very close to parity between OSC and the manilaclient shell. So, the team decided to stop adding new features in the manilaclient shell as a way to gradually wean users off of it. * When using the manilaclient shell from the Yoga release, users will be shown a deprecation warning suggesting an eventual removal (looking at the "A" release for this one, thoughts are welcome). * maaritamm proposed a hack-a-thon for completing the functional testing around manilaclient's osc plugin. * The osc plugin also needs the api microversion negotiation bits that the manilaclient shell currently has. * Action items: * We assigned owners to pending reviews, and missing osc commands * Deprecate the native manilaclient shell. == Manila CSI updates == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-csi * gman0 and tbarron presented the state of the kitchen for manila-csi since the Xena PTG and shared future plans * share backup is now a focus area for pvs serviced by manila-csi - the design involves being able to mount manila snapshots as read only PVs on backup pods and extracting relevant files. * we discussed e2e testing that's being added to the cloud-provider-openstack repository and the results of the perf/scale testing with manila-csi on openshift == OpenStackSDK updates == Etherpad: https://etherpad.opendev.org/p/yoga-manila-openstacksdk-update * we've had several interns working on exposing manila APIs within the openstacksdk since the wallaby release * kafilat has numerous open changes, wrapped up a successful outreachy internship recently * megharth, Jiabo, tutkuna and rishabhdutta from Northeastern University picked up the implementation of the remaining API resources for the Yoga cycle * this continues to be a multi-cycle effort and the plan is to eventually use manila APIs via the openstacksdk within manila-ui, ansible-collections-openstack and manila's OSC plugin. * Action Items: * team will review open changes against the openstacksdk repository pertaining to manila Thanks for reading thus far. It's possible a lot can get lost in translation :) As a reminder, do check out the complete recordings on our Youtube channel! [2] -- Goutham Pacha Ravi PTL, OpenStack Manila [1] https://etherpad.opendev.org/p/yoga-ptg-manila [2] https://www.youtube.com/watch?v=wVAClI82Ths&list=PLnpzT0InFrqDhp1A3lBi_guLAmOZ4bAEc