[openstack-dev] [Manila] Access rule types for protocols
ben at swartzlander.org
Thu Jul 27 14:51:44 UTC 2017
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
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.
More information about the OpenStack-dev