<div dir="ltr">1) There is no cases that can come in my mind when some share backend can not be configured (separately from Manila) to destroy data for sure, like filling with zeros, etc... And it is OK to make share driver do it. <div>2) Agree that it is a problem. But Manila has no power on users to force them stop using share and then unmount it. Lets assume user uses some share constantly as storage for his application. Manila, potentially can discover presence of a user of a share, but can not make user's application stop using this share. So, it appears that it is completely up-to the user to think about safety of his mounts.</div><div><br></div><div>Regards,</div><div>Valeriy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 8, 2015 at 10:38 AM, Csaba Henk <span dir="ltr"><<a href="mailto:chenk@redhat.com" target="_blank">chenk@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm tossing in the term "dismantling" to indicate<br>
the act of making a share less available<br>
(deprovision (deny access to) / unmanage / delete<br>
it).<br>
<br>
I find it ambiguous what is to be done with<br>
the share's data('s accessibility) upon<br>
dismantling. Wrt. the concerns to follow below,<br>
I have these questions:<br>
- what is expected?<br>
- what is suggested?<br>
- what is acceptable?<br>
- what do existing drivers do?<br>
- should we explicitly specify/<br>
disambiguate the answer to<br>
these questions (in a less<br>
informal place than this thread)?<br>
- if there are multiple<br>
acceptable behaviors, should<br>
this variance be exposed to<br>
the users in any way?<br>
<br>
So the particular concerns:<br>
<br>
1. Upon deleting a share, should the share's data<br>
be shredded?<br>
<br>
A share delete request is usually passed down to the<br>
storage backend as its appropriate disallocation<br>
method. So far so good -- the dilemma is, beyond<br>
this, should we take extra measures to shred<br>
(irrecoverably destroy) the data contained in the<br>
share (to protect the privacy of the former tenant)?<br>
(Most likely it varies from backend to backed how<br>
close its basic deallocation method gets to<br>
"irrecoverable destruction".)<br>
<br>
2. Should share deprovisioning be disruptive?<br>
<br>
Let me introduce another ad-hoc term in the context<br>
of an authentication system -- disruptiveness of<br>
revoking access to some resource. The act of<br>
revoking access is disruptive if it takes immediate<br>
effect on all potential and actual accessors;<br>
non-distruptive if only further access attepts of<br>
potential accessors is affected.<br>
<br>
So if a certain venue comes with up a dress code as<br>
of which shorts are not allowed, then it shall be<br>
non-distruptive if wearing shorts is checked only at<br>
the gate; while it shall be disruptive if all<br>
people in the venue wearing shorts will be kicked<br>
out immediately. In computing, UNIX file access is<br>
non-disruptive while NFS exporting is disruptive (at<br>
least Linux with knfsd it is, as I just verified).<br>
<br>
I'm sorry to burden you with my terminological<br>
creativity, were there an established term for this;<br>
I just don't know of such.<br>
<br>
So I hope the question makes sense now -- a tenant<br>
gets access to a share, mounts it, starts to use it,<br>
then the tenant's access gets revoked. What should<br>
happen to the mount?<br>
<br>
Beyond pure disruptiveness (all further fops fail<br>
with EACCES) and pure non-disruptiveness (the mount<br>
can be used until unmounted), there is the<br>
unpleasant middle ground that all further fops<br>
will hang. While that sounds to be far from ideal,<br>
the question arises if it's acceptable.<br>
<br>
<br>
Regards<br>
Csaba<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Kind Regards<br>Valeriy Ponomaryov<br><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a><br><a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a><br></div></div>
</div>