[openstack-dev] [manila] share dismantling policies

Csaba Henk chenk at redhat.com
Wed Jul 8 07:38:33 UTC 2015


I'm tossing in the term "dismantling" to indicate
the act of making a share less available
(deprovision (deny access to) / unmanage / delete

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".)

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. 


More information about the OpenStack-dev mailing list