Open Stack

Hi,
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.

Ghe Rivero


On Thu, Apr 25, 2013 at 5:24 PM, Monty Taylor <mordred at inaugust.com> wrote:

>
>
> On 04/25/2013 11:15 AM, John Griffith wrote:
> > Hey Folks,
> >
> > With the growth of vendor activity in the form of driver submissions in
> > Cinder there's some concerns and challenges that I have and I'd like to
> > get some thoughts from the TC as I move forward.
> >
> > The short version here is:
> >     "What is our goal with OpenStack WRT API behavior and
> implementation?"
> >
> >
> >
> > The longer detailed version:
> >
> > With the increased activity from Vendors in Cinder adding their drivers
> > there's some conflicts regarding  what should be required for
> > acceptance.  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.
> >
> > In addition I feel that behaviors of the API should be standard
> > regardless of what driver is being used.  For example; a number of folks
> > have proposed that they should be able to do things like "delete a
> > parent volume of a snapshot" if the driver supports it, if the driver
> > doesn't then just return an error.
> >
> > My response to this has been NO WAY, because the result is different
> > behaviors and expectations based on what driver is currently in use.
>
> I agree with you 100% on this.
>
> >  This is very bad IMO because the whole point of Cinder from my
> > perspective is to abstract those differences and details out.  Adding
> > functionality and features on top of the reference implementation (via
> > extensions, types etc) is one thing, but deviating from the behavior is
> > a very bad idea IMO.  It would be one thing if there was no way to
> > achieve what the vendor would like to accomplish but the fact is in
> > almost every one of these cases that comes up there's a way to do what
> > they would like, it just doesn't use the vocabulary or semantics that
> > they would like.
> >
> > Anyway, I know we pushed the "what is OpenStack" back to the board at
> > one point and I don't recall ever seeing a clear response on that.  What
> > I'd like to do as a TC function is to actually define some sort of goal
> > or mission statement of what we are hoping to provide.  This doesn't
> > have to be a huge debate or a 1000 page manifesto, just a clear mission
> > statement on what an end user or provider should expect when they
> > install OpenStack projects and use the API.
>
> Actually, the important response here is that it's on the TC to define
> the technical characteristics. I believe your questions above are well
> within scope.
>
> I'll say this - the current stated value proposition for OpenStack is
> that multiple inter-operable clouds that run OpenStack provide value for
> the user by preventing vendor lock in.
>
> We have several programs running right now to work on doing
> interoperability definitions and testing.
>
> I think that it's safe to say that the emerging view point is that the
> user experience of using an OpenStack cloud should not be altered based
> on implementation choices. To that end, I believe you've been making the
> right call, and we need to continue pushing viewpoints such as that.
>
> > I can continue to make my own calls on this which is fine with me, but I
> > suspect that other projects either are dealing with, or will be dealing
> > with this same sort of issue.  It might be worth discussing and putting
> > some sort of concept around what our goal is here..
>
> I'd be in favor of making a more formal technical statement around what
> we think interoperability and API policy should look like here. You're
> WELL within your rights as PTL to just be making that call right now -
> but writing something down and being clear about it so that it doesn't
> keep coming up might be friendly to people.
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>



-- 
Pinky: "Gee, Brain, what do you want to do tonight?"
The Brain: "The same thing we do every night, Pinky—try to take over the
world!"

 .''`.  Pienso, Luego Incordio
: :' :
`. `'
  `-    www.debian.org    www.openstack.com

GPG Key: 26F020F7
GPG fingerprint: 4986 39DA D152 050B 4699  9A71 66DB 5A36 26F0 20F7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130425/3b94fe2e/attachment-0001.html>