Open Stack

Reviewing this discussion before the meeting, I had a few thoughts I want
to share.

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

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.

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.

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?


On Thu, Apr 25, 2013 at 2:26 PM, Michael Still <mikal at stillhq.com> wrote:

> On Fri, Apr 26, 2013 at 1:15 AM, John Griffith <
> john.griffith at solidfire.com> wrote:
>
> [snip]
>
> 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.
>>
>
> [snip]
>
> You guys sure have fun while I am asleep!
>
> 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?
>
> 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.
>
> Michael
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130430/ccb3a3d1/attachment.html>