<div dir="ltr"><div>Hi,<br>Another issue I see at medium/long term is the proliferation of drivers/plugins/whatever that every company is trying  to get merged into openstack in order to have it porduct supported (sell). All of them going to survive/be interested to continue its development? So far, openstack-network now has 9 "commercial" plugins. Lovely to see too much effort from companies but, at long term, we can have a bunch of old and nor supported code inside openstack. <br>
<br></div>Ghe Rivero<br><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 5:24 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><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 class="im"><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>
<div class="im"><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">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><br><br clear="all"><br>-- <br>Pinky: "Gee, Brain, what do you want to do tonight?"<br>The Brain: "The same thing we do every night, Pinky—try to take over the world!"<br><br> .''`.  Pienso, Luego Incordio  <br>
: :' : <br>`. `'  <br>  `-    <a href="http://www.debian.org" target="_blank">www.debian.org</a>    <a href="http://www.openstack.com" target="_blank">www.openstack.com</a><br><br>GPG Key: 26F020F7<br>GPG fingerprint: 4986 39DA D152 050B 4699  9A71 66DB 5A36 26F0 20F7
</div></div></div></div>