Open Stack

You're right, good point re: difference between vendor created and
packaged/repo materials. My viewpoint is that the difference is mostly
semantic. Whether the delta is extension based or version based, the end
result is the cloud I'm running is different from the cloud you're
running. To the end users we're attempting to appeal to, they won't know
or care about the difference. It's difficult to argue when the difference
still exists in an Openstack world without API extensions.

Also, I didn't say ignore the voices, but rather that we should be
prepared to have a moderate answer to the craziness from both sides of the
fence. If you notice, I also agreed mostly with Monty. The only thing I
wanted to point out is while we're shaving yaks about what an ideal world
looks like, more debt is being added to the pile. No one is saying the
idealists should take their ball and go home.

As to the last point, I feel like I'm missing something. How are they core
API if they're still modular/optional? What I think the argument has
boiled down to here is consistent user experience, which to me means that
everyone at the very least should be prepared to run the Core API and all
that it entails. If you aren't capable or unwilling to support it, that's
no better than a random selection of extensions being being made
available. Being able to selectively choose but still be "core" doesn't
sound like it solves anything as far as I'm concerned.


Don't be misled into thinking that I'm advocating we break more windows. I
want everyone running the best cloud because it's the way Openstack wins.
Let's have our idealist viewpoints, and a mechanism prepared to mitigate
the agenda-seekers.


In any case, the original point was whether or not extensions belong in
the client or externally, and it sounds like there's enough consensus for
them going into contrib under the client tree. I'm still not 100%
convinced it's optimal, but if it's what the community wants, that's where
I'll put mine.


-----Original Message-----
From: Dean Troyer <dtroyer at gmail.com>
Reply-To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Date: Wednesday, December 19, 2012 2:01 PM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Novaclient and Extensions

>On Wed, Dec 19, 2012 at 12:58 PM, Matt Dietz <matt.dietz at rackspace.com>
>wrote:
>> upstream code base. Put differently, just because a feature is rejected
>>by
>> the community doesn't mean that vendor stops working on something they
>> think will sell, which means you usually need an extension to present
>>that
>> feature. The problem is further exacerbated by the fact that very few
>> vendors are publicly running the exact same version of the code base in
>> terms of releases; we're running more or less trunk, others are several
>> releases behind, and thus the client has moved ahead of those vendors.
>
>There is a difference between something that is vendor-created and the
>stuff that comes in the repo/packages.  OpenStack releases play a
>small part in this but the projects have made a commitment to be
>backward compatible so that should only be an issue with old clients.
>(IIRC that actually starts with the Essex release, I don't recall how
>much of Diablo is broken with the current clients).
>
>> In other words, it's going to happen despite the best intentions of the
>> community, so we're better off trying to come up with a good way of
>> managing things (and we've had good suggestions so far) than getting
>> defensive when people don't conform to our idealism.
>
>The danger here is that by not having the extreme wacko idealists
>voices being heard then the perception of 'moderate' shifts toward the
>vendor-fragmentation view of OpenStack as a whole.  What would the
>Free Software movement look like without rms's screeds?
>
>I totally agree with Monty regarding the absurd user experience just
>to use supposedly production OpenStack clouds without needs to get
>vendor-specific pieces.  This is starting to feel like 1980's UNIX all
>over again.  (Is it a coincidence that our foundations initials are
>OSF?)
>
>Regarding the extensions themselves, I am starting to believe that the
>majority of the existing nova extensions should be brought in to the
>core v3 api but continue to be modular and allow vendors to turn them
>off if necessary.  The discovery mechanism will allow the clients to
>detect that configuration just as is being proposed now but the
>standard clients will be more inclusive, much as they are now.  Users
>download a single and bigger client (basically what we have today) but
>have a better experience because most of what they need to operate is
>present by default.
>
>dt
>
>-- 
>
>Dean Troyer
>dtroyer at gmail.com
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev