On 07/08/2015 03:38 AM, Csaba Henk wrote:
Hi,I'm tossing in the term "dismantling" to indicate the act of making a share less available (deprovision (deny access to) / unmanage / delete it). I find it ambiguous what is to be done with the share's data('s accessibility) upon dismantling. Wrt. the concerns to follow below, I have these questions: - what is expected? - what is suggested? - what is acceptable? - what do existing drivers do? - should we explicitly specify/ disambiguate the answer to these questions (in a less informal place than this thread)? - if there are multiple acceptable behaviors, should this variance be exposed to the users in any way? So the particular concerns: 1. Upon deleting a share, should the share's data be shredded? A share delete request is usually passed down to the storage backend as its appropriate disallocation method. So far so good -- the dilemma is, beyond this, should we take extra measures to shred (irrecoverably destroy) the data contained in the share (to protect the privacy of the former tenant)? (Most likely it varies from backend to backed how close its basic deallocation method gets to "irrecoverable destruction".)
The contract for deletion is that one a share is deleted, its data should never be accessible to that user/tenant or any other user/tenant again. This would seem to be an obvious requirement but it's actually violated by cinder in the case of deleting volumes on the LVM driver in the normal mode, and you have to turn on a slow-delete option to make the LVM driver meet the expected delete contract.
Note that it's not required that deleted shares are not accessible by an administrator. Such a requirement would be kind of silly because administrators can always read the contents of shares if they want to. So it would be acceptable to do lazy deletions of shares so long as the deleted shares are never accessible to any user without administrator intervention.
Some people are interested in secure deletion (cryptographic data shredding). Such a feature would be perfectly acceptable to implement using an optional extra spec / share type for those that want the extra security.
2. Should share deprovisioning be disruptive? Let me introduce another ad-hoc term in the context of an authentication system -- disruptiveness of revoking access to some resource. The act of revoking access is disruptive if it takes immediate effect on all potential and actual accessors; non-distruptive if only further access attepts of potential accessors is affected. So if a certain venue comes with up a dress code as of which shorts are not allowed, then it shall be non-distruptive if wearing shorts is checked only at the gate; while it shall be disruptive if all people in the venue wearing shorts will be kicked out immediately. In computing, UNIX file access is non-disruptive while NFS exporting is disruptive (at least Linux with knfsd it is, as I just verified). I'm sorry to burden you with my terminological creativity, were there an established term for this; I just don't know of such. So I hope the question makes sense now -- a tenant gets access to a share, mounts it, starts to use it, then the tenant's access gets revoked. What should happen to the mount? Beyond pure disruptiveness (all further fops fail with EACCES) and pure non-disruptiveness (the mount can be used until unmounted), there is the unpleasant middle ground that all further fops will hang. While that sounds to be far from ideal, the question arises if it's acceptable.
Access deny should always result in immediate loss of access to the share. It's not okay for a client to continue reading/writing data to a share after access has been denied. The semantics for what should happen on the client side after access is denied are undefined and left up to the client. Many clients cache data and may continue to run from their cached copies until they find out that their access has been cut off, then return some application error. The important thing is that from the server's point of view, no writes/reads are serviced from clients without access.
Regards Csaba __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
