Hello, stackers. Here's a summary with some context on the topics we discussed, as well as the decisions and action items we took during the 2026.2 Hibiscus PTG. In case you would like to revisit those discussions, the sessions were recorded and are available in the OpenStack Manila Youtube channel [1] and all notes and topics are available in the PTG etherpad [17]. *All things CephFS [2]* ================= *CephFS QoS - opted for qos types approach* --------------------------------------------------------------- CephFS NFS QoS will be implemented as a driver-only change leveraging Manila's existing QoS Types framework (v2.94+) to support bandwidth and IOPS throttling at the NFS-Ganesha level. The implementation will support three simplified spec keys (max_read_bw, max_write_bw, max_iops) and apply QoS after NFS export creation. Implementation is currently blocked awaiting upstream Ceph MGR PR merges, requiring testing with bleeding-edge Ceph builds. We are planning a PoC for this feature possibly in the 2026.2 Hibiscus release. *Erasure coded pools* ----------------------------- Erasure Coded pool support will be enabled through a new cephfs:data_pool share type extra-spec that passes pool_layout to Ceph's subvolume creation command. This allows operators to leverage EC pools for capacity-sensitive workloads (large files, streaming, archival) while maintaining replicated pools for metadata and small-file workloads. With k=4,m=2 configuration, this can potentially double usable capacity compared to 3-way replication while maintaining the same fault tolerance, requiring no API, database, or scheduler changes. The Manila team is working on the testing and the necessary changes for enabling this feature, having 2026.2 Hibiscus as a target. *BYOK encryption* ------------------------ BYOK encryption support is in exploratory phase to test end-to-end at-rest encryption workflows with an open-source driver. The main challenge is integrating CephFS's fscrypt model, which lacks built-in KMS interaction and operates per-subvolume without the concept of share servers, with Manila's current encryption framework. The team is evaluating whether Manila can orchestrate secret handover (simple but exposes user secrets) or whether KMS knowledge should be added to Ceph itself. We would like to take the design choices to the Ceph community. *DNS Configuration for SVM in DHSS=True Mode [3]* *=========================================* In DHSS=True mode, the NetApp ONTAP driver doesn't configure DNS on newly created SVMs, causing share encryption to fail because the SVM cannot resolve Barbican/Keystone endpoint hostnames needed for key retrieval. The NetApp team is proposing two approaches: one introducing manila.conf configuration options for the DNS entry creation in the SVMs and a share network subnet metadata approach. We shared our concerns regarding the UX around the second approach, considering that users should not fix infrastructure issues. We agreed that we will introduce the configuration options for addressing this behavior. The NetApp team is currently working on it. *NetApp AFX Integration [4]* *======================* NetApp AFX is a disaggregated NAS platform with a shared storage pool (SAZ) architecture requiring REST-only API access, targeting high-performance AI/ML workloads with ONTAP 9.17.1+. The team discussed whether to create a separate driver for AFX or extend the existing NetApp ONTAP driver, considering the implications on share migration; the plan is to update the current driver with platform detection, though share migration is not feasible for AFX due to its single-pool architecture and the current driver's limitation to intra-cluster migrations only. *Eventlet Removal* =============== We covered the progress we made in the Gazpacho release with both introducing the option to run oslo.threading instead of eventlet and all the changes that were needed, as well as the testing we did so far. For 2026.2 Hibiscus, our plan is to - Look to test with at least one other WSGI server alternatives (gunicorn). - Complete privsep migration to address the rootwrap incompatibility with eventlet - Switch the default execution mode to disable eventlet and monkey patching - Merge the new rally job that does compares eventlet based execution to native threading mechanism [5] - Increase our test coverage and introduce new test scenarios - Be ready for the removal in 2027.1 "I". *Share migration graduation* *=======================* We discussed what should be done and the testing needed for making the share migration feature (implemented years ago) transition away from an experimental status. We also discussed about the need for our team to create guidelines for feature graduation. AI: the Manila team will come up with a plan and documentation and set a target to how long APIs can remain in "experimental" state. *Weka driver [6]* *============* In this topic, we discussed integrating Weka parallel filesystem with OpenStack Manila for GPU clusters. The approach consists of creating a "Mosaic" bridge component that maps Manila's share model to Weka's filesystem model using a "fileset" abstraction. We shared the requirements and how to introduce new supported share protocols. We suggested that this should be added as a new third party driver with a CI system for testing. The contributors will check the requirements but will also weigh in if this should be a whole new OpenStack service altogether. *Manila NetApp Driver: ZAPI-to-REST Migration Gaps [7]* *=============================================* The NetApp engineering team has been working on a multi cycle effort to migrate the calls to NetApp storages away from a proprietary tool, directing them to REST calls. Such migration resulted in some gaps both for incompatibilities in modes and unavailability in the REST mode for NetApp. In this topic, the NetApp team shared a detailed analysis on the gaps, comparing the urgency of each issue and what needs fixing in the storage. *Enhancing health checks in Manila [8]* *===============================* We discussed implementing lightweight in-process HTTP health endpoints (/health) for Manila services that passively track real service capabilities (database, RPC, backend drivers) instead of just heartbeat liveness, enabling better Kubernetes probes and monitoring. This approach is similar to what the Nova team is working on. AI: fpantano will propose a specification for it. *Graceful shutdowns [9]* *===================* The manila team is planning on enhancing the shutdown mechanisms. As part of this topic, gouthamr presented enhancement plans for auto-recovering shares and resources stuck in transient states (creating, deleting, migrating, etc.) when manila-share crashes mid-operation, using startup/periodic reconciliation to check backend reality and either complete or error-out abandoned operations. The team shared feedback on this approach and asked for a possibility of giving drivers more control over the process. AI: gouthamr will propose a specification. *New Manila Driver for HPE Storage [10]* *================================* We discussed driver requirements and addressed questions from HPE engineers. The HPE storage in question lacks read-only access (RW-only) and share quotas (unbounded growth). Read-write only is acceptable initially, but for quotas: the team shared the feature should be available in ~3 months in HPE. We advised waiting on the next storage release to avoid breaking UX changes later, and use granular access states instead of erroring out entire update_access calls. The driver can be iterated through on gerrit in the meantime. Target: Hibiscus cycle. *Netapp SnapMirror Active sync support (share server replication) [11]* *=========================================================* We discussed constraints for introducing share server replication API support in OpenStack Manila, as well as support for it in the NetApp ONTAP driver through SnapMirror Active Sync (SMAS), enabling zero RPO/RTO share server-level replication with new APIs/CLIs for replica management (create, promote, resync). We agreed that this feature should be admin-only, following other share server APIs, to avoid breaks in the UX and workflows, as well as smooth and transparent changes in the promotion process. gireesh, Anoop_Shukla_ and KumarT will incorporate the feedback to the proposal and propose a spec. *Cross project session with Nova* *===========================* We discussed the progress we made with regards to the share attachment feature (VirtioFS) and shared our plans for the upcoming cycles. We recently merged the remaining SDK [12] and OSC [13] changes, making the OSC commands available for consumption. The Manila team also worked on implementing scenario (end to end) tests [14] and proposed them in a new gerrit change. Our plans for 2026.2 Hibiscus include merging the hot attachment [14], live migration [15] and cold migration [16] specs and start working on the implementation. [1] https://www.youtube.com/@openstackmanila [2] https://etherpad.opendev.org/p/hibiscus-ptg-manila-cephfs [3] https://etherpad.opendev.org/p/DNS_Configuration_for_SVM_in_DHSS_True_Mode [4] https://etherpad.opendev.org/p/manila-netapp-afx-support [5] https://review.opendev.org/c/openstack/rally-openstack/+/974559 [6] https://etherpad.opendev.org/p/weka-driver [7] https://etherpad.opendev.org/p/manila-netapp-rest-gaps [8] https://etherpad.opendev.org/p/manila_healthcheck [9] https://etherpad.opendev.org/p/manila_healthcheck#L310 [10] https://etherpad.opendev.org/p/manila-hpe-storage [11] https://etherpad.opendev.org/p/netapp-manila-active-sync-support [12] https://review.opendev.org/c/openstack/openstacksdk/+/880056 [13] https://review.opendev.org/c/openstack/python-openstackclient/+/881540 [14] https://review.opendev.org/c/openstack/nova-specs/+/983816 [15] https://review.opendev.org/c/openstack/nova-specs/+/983801 [16] https://review.opendev.org/c/openstack/nova-specs/+/985738 [17] https://etherpad.opendev.org/p/hibiscus-ptg-manila Thank you, carloss