My name is Goutham Pacha Ravi and I am a core contributor for the OpenStack Manila project. Below is a feature request that was reported by an operator who would like to remain anonymous. Luckily, the operator engaged with the upstream OpenStack community and this feature has been delivered in OpenStack 2023.2, nicknamed the Bobcat release.
An operator reported to the OpenStack Manila team that a user deleted a share from Manila without realizing that the action would be irrevocable. The user later realized that an application was actively writing data into the share, and it crashed when the share was deleted. Unlike block storage volumes, shared file systems do not track connected clients, so there was no pre-condition that prevented the share to be deleted. The user did not perform a “soft-deletion” that would have relegated the share to a recycle bin for a specified duration, they had requested a permanent deletion. The user did not use the OpenStack Dashboard GUI (Horizon) which would have presented a confirmation dialog for the deletion. The user hadn’t taken a snapshot of the share from which the data could have been restored. Unintentional actions like this could jeopardize business continuity. So, Manila’s resource locks were designed to avoid such situations. They allow building a safety hatch on top of the limitation in traditional shared file systems and track in-use shares. Users may create any number of locks for any number of reasons on a given share, thereby preventing actions that may be detrimental to their use case.
A resource lock can currently protect shares and their access control rules from deletion. Since a shared file system is built for concurrent access from multiple OpenStack users within a project, multiple locks can be created. While creating a lock, the user provides the action they would like to prevent and a reason for the lock. The resource lock is then treated as a precondition that the API checks for when completing an action. If there are any locks that prevent an action, the action is aborted and the user requesting the action is provided an appropriate feedback.
Resource locks can also be applied to hide sensitive fields within access control lists of shared file systems. Normally, access control lists are available to all project users. However, there may be situations where a user wants to prevent other project users from gathering the access secret keys or a client identifier, such as the IP address of the hosts that are provided access. By placing a visibility lock during the access rule creation, the user can ensure that this data stays hidden to other users in their project. You can access the resource lock specifications here and here.
At the OpenInfra Summit Project Teams Gathering (PTG), we received a lot of interest for an upcoming feature in OpenStack Nova, VirtIOFS attachments. Through VirtIOFS, shared file systems from OpenStack Manila can be connected to virtual machine instances in a secure, hypervisor-mediated manner akin to block storage volumes. Nova would need to place a deletion lock on the share while it is attached to a virtual machine. It was hence important for resource locks to be introduced in Manila. VirtIOFS is a much anticipated feature in particular for public cloud operators who helped us prioritize its delivery in the upcoming cycle. Independently, the Manila team plans to continue extending the resource locks framework to other API resources and actions in the upcoming releases.
“The VirtIOFS feature is something that we at Cleura have been looking forward to, as this will make the architecture much better for us as an operator of public clouds. It also makes the user experience and resource efficiency much better for the end users, creating the same look and feel as working with block storage volumes. The resource lock feature is crucial here as well to get that great user experience. With these features in place we feel confident in bringing Manila into production and make the much requested functionality of shared file systems as a service available to our customers. We are really greatful for the good collaboration with the community, and the Manila team in particular, it really shows how important the collaboration between operators and developers is, and how we together can do great things with that collaboration.” – Tobias Rydberg, head of design and architecture at Cleura
Thank you to the contributors who joined me in delivering this feature for the OpenStack Bobcat release, Rene Ribaud, Software Engineer at Red Hat and Carlos Eduardo da Silva, Software Engineer at Red Hat.
The discussion will continue at the upcoming virtual PTG (October 23-27) where operators and developers will discuss Manila features and bug requests planned for the OpenStack 2024.1, Caracal release.
Learn more about OpenStack Bobcat, the 28th release of OpenStack, that was released on October 4, 2023.
Leave a Reply