Manila has a long standing design flaw that I'd like to address in Queens. We've discussed this as previous PTGs and will cover it in detail as the upcoming PTG but because of the potential for impacting users I wanted to bring it up here too.

In short, Manila allows potentially incompatible access rules to be added to shares. We handle this by allowing the driving to fail to apply the rule and reporting that error back to the user by marking the access rule as being in an error state.

This history of this design is that at the very beginning of the project, we didn't have a strong sense of what kind of access rules would be used in practice, or implemented by vendors, and we didn't want to design the API to limit what users were allowed to request. In retrospect, this attempt at flexibility was misguided because it's now very hard for users to know what is supported on any given cloud and we have a complete lack of standardization.

Informally, we've settled on the idea that each protocol has exactly 1 access type that must be supported, and I'd like to formalize that notion by changing the API to enforce the agreed upon standard. This raises the specter of "backwards incompatibility" because such an API change would block requests that were previously allowed. My feeling about this specific case is that the requests were going to result in an error eventually, so making them result in an error earlier is an improvement.

The concern is whether there might be any legitimate cases for using the nonstandard access methods that could be broken by the proposed change. In particular, I'd like to know if anyone actually uses IP-based access for CIFS or User-based access for NFS and what that looks like -- in particular which driver and what is the use case for it. My current assumption is that these are effectively broken and removing them will hurt nobody. If legitimate cases can be found, then we need to find a way to support them in a more standardized, discoverable fashion.

-Ben Swartzlander

OpenStack Development Mailing List (not for usage questions)

Reply via email to