<div dir="ltr">Reviewing this discussion before the meeting, I had a few thoughts I want to share.<div><br></div><div style>1) I completely agree, drivers should have a true "IS-A" relationship with the driver interface. So variations in significant side effects among drivers is not okay. (To me, a side effect is "Significant" if it is detectable through the interface itself. So for example, I can detect that a Square is different from a Rectangle, but I cannot detect that a HashMap is different from a ListMap.)</div>
<div style><br></div><div style>2) The particular case you cited was whether or not you can delete the parent volume of a snapshot. I wonder if maybe the core interface of cinder just isn't rich enough to incorporate all the significant side effects we should expect. If I understand, the issue here is that some drivers implement snapshots as differentials off of a parent volume. Similarly, I could imagine some drivers implement snapshots such that the parent volume becomes a differential off of the snapshot. And of course, some drivers might implement snapshots as true clones, where the original volume and the snapshot are completely independent once the action is completed.</div>
<div style><br></div><div style>Broadly, it seems like this interface needs a refactoring so that you can pick a single set of semantics that all drivers are mostly okay with, and strictly enforce compliance. More narrowly, one possible solution would be to add attributes to volumes & snapshots to fully represent the hierarchy between them, and require drivers to publish that information up through the API. Another solution might be to have more verbs than just "snap" to capture the possibilities of cloning, redirect-on-write, and copy-on-write implementations, and to say that its "okay" if some drivers always return NotSupported for certain verbs.</div>
<div style><br></div><div style>My naivete alarm is going off as I reread my specific proposals, but do you think a solution like this might be able to be found?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Apr 25, 2013 at 2:26 PM, Michael Still <span dir="ltr"><<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">On Fri, Apr 26, 2013 at 1:15 AM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>></span> wrote:<div><br></div><div>[snip]</div>
<div><br><div><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>My position on this has been pretty simple (albeit unpopular) that if it's supported by the reference implementation (LVM Driver) and it's a core API call then those are your requirements.</div>
</div></blockquote><div><br></div></div><div>[snip]</div><div><br></div><div>You guys sure have fun while I am asleep!</div><div><br></div><div>I agree with what seems to be the concensus here... Its important for core functionality to work similarly across drivers as much as is technically possible. We need to focus on the user experience here, and consistency is what they want -- its less surprising when they move environments. Also, if behaviour changes between drivers, doesn't that massively increase the amount of documentation we need to write?</div>
<div><br></div><div>Finally, I think we need to remind the driver authors that there might be more than one storage vendor in a simple implementation. This makes consistency even more important.</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>Michael</div></font></span></div></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org">OpenStack-TC@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
<br></blockquote></div><br></div>