<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 12:58 PM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div><div class="h5">On Thu, Apr 25, 2013 at 10:07 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div><div>On Thu, Apr 25, 2013 at 11:24 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
<br>
On 04/25/2013 11:15 AM, John Griffith wrote:<br>
> Hey Folks,<br>
><br>
> With the growth of vendor activity in the form of driver submissions in<br>
> Cinder there's some concerns and challenges that I have and I'd like to<br>
> get some thoughts from the TC as I move forward.<br>
><br>
> The short version here is:<br>
> "What is our goal with OpenStack WRT API behavior and implementation?"<br>
><br>
><br>
><br>
> The longer detailed version:<br>
><br>
> With the increased activity from Vendors in Cinder adding their drivers<br>
> there's some conflicts regarding what should be required for<br>
> acceptance. My position on this has been pretty simple (albeit<br>
> unpopular) that if it's supported by the reference implementation (LVM<br>
> Driver) and it's a core API call then those are your requirements.<br>
><br>
> In addition I feel that behaviors of the API should be standard<br>
> regardless of what driver is being used. For example; a number of folks<br>
> have proposed that they should be able to do things like "delete a<br>
> parent volume of a snapshot" if the driver supports it, if the driver<br>
> doesn't then just return an error.<br>
><br>
> My response to this has been NO WAY, because the result is different<br>
> behaviors and expectations based on what driver is currently in use.<br>
<br>
</div>I agree with you 100% on this.<br>
<div><br>
> This is very bad IMO because the whole point of Cinder from my<br>
> perspective is to abstract those differences and details out. Adding<br>
> functionality and features on top of the reference implementation (via<br>
> extensions, types etc) is one thing, but deviating from the behavior is<br>
> a very bad idea IMO. It would be one thing if there was no way to<br>
> achieve what the vendor would like to accomplish but the fact is in<br>
> almost every one of these cases that comes up there's a way to do what<br>
> they would like, it just doesn't use the vocabulary or semantics that<br>
> they would like.<br>
><br>
> Anyway, I know we pushed the "what is OpenStack" back to the board at<br>
> one point and I don't recall ever seeing a clear response on that. What<br>
> I'd like to do as a TC function is to actually define some sort of goal<br>
> or mission statement of what we are hoping to provide. This doesn't<br>
> have to be a huge debate or a 1000 page manifesto, just a clear mission<br>
> statement on what an end user or provider should expect when they<br>
> install OpenStack projects and use the API.<br>
<br>
</div>Actually, the important response here is that it's on the TC to define<br>
the technical characteristics. I believe your questions above are well<br>
within scope.<br>
<br>
I'll say this - the current stated value proposition for OpenStack is<br>
that multiple inter-operable clouds that run OpenStack provide value for<br>
the user by preventing vendor lock in.<br>
<br>
We have several programs running right now to work on doing<br>
interoperability definitions and testing.<br>
<br>
I think that it's safe to say that the emerging view point is that the<br>
user experience of using an OpenStack cloud should not be altered based<br>
on implementation choices. To that end, I believe you've been making the<br>
right call, and we need to continue pushing viewpoints such as that.<br></blockquote><div><br></div></div></div><div>I agree with the goal, but we also have to be careful not to define the pre and post conditions of the API endpoints based on assumptions derived from the capabilities of a single backend/driver (whether from a vendor or an open source project) in a way that restricts the feature set of OpenStack as a whole. For example, if we assume that snapshots always have a parent volume because some part of OpenStack core (not a driver) wants to do something with that volume, that's one thing. But if we assume that the parent volume is always there because a particular driver requires it not be deleted, maybe that's not something we need to bake into the API definition. (Disclaimer: I'm not a block storage expert, so take that as an example rather than an argument for/against this specific decision.)</div>
</div></div></div></blockquote><div><br></div></div></div><div>Fair point, and I'm not saying we limit anybody in what they can provide, but I am saying it seems wrong to allow everybody to have their own definition and implementation. I think there's a clear difference between core API/Functionality and extras as you mention.</div>
</div></div></div></blockquote><div><br></div><div style>We seem to be agreeing. :-) My main point was that "extensions" or legitimate differences in behavior will not always mean new API calls, and that in a lot of cases that may be OK as long as those differences aren't changes to the fundamental expectations of the user.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>Another way to handle interoperability for "optional" features/behaviors is to provide an API for the client to learn what is supported by a given implementation. That way at least the app calling the API can decide what to allow before trying something and getting an error.</div>
</div></div></div></blockquote><div><br></div></div><div>Sure, but in the case of Cinder or multiple back-ends you have no expectation on what the behaviors or characteristics are. This seems contradictory to me to say "API for the client to learn what's supported" and to use the term interoperability. That means interoperability if you implement OpenStack exactly the same way with the same options and back-end devices. </div>
</div></div></div></blockquote><div><br></div><div style>True, the definitions of "features" would have to be taken on a case-by-case basis. I'm not saying we let every driver and deployment do whatever they want, but for cases where it doesn't matter to the core of OpenStack, we can afford some flexibility.</div>
<div style><br></div><div style>Doug</div><div style><br></div><div style>PS - Thierry mentioned moving this to the dev list. I don't mind if someone wants to move the thread with the next reply, or if John wants to just start a new thread over there.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<span><font color="#888888">
<div><br></div><div>Doug</div></font></span><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
> I can continue to make my own calls on this which is fine with me, but I<br>
> suspect that other projects either are dealing with, or will be dealing<br>
> with this same sort of issue. It might be worth discussing and putting<br>
</div>> some sort of concept around what our goal is here..<br>
<br>
I'd be in favor of making a more formal technical statement around what<br>
we think interoperability and API policy should look like here. You're<br>
WELL within your rights as PTL to just be making that call right now -<br>
but writing something down and being clear about it so that it doesn't<br>
keep coming up might be friendly to people.<br>
<br>
_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org" target="_blank">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>
</blockquote></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org" target="_blank">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></div><br></div></div>
</blockquote></div><br></div></div>