Open Stack

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-2021
* 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