[openstack-dev] Novaclient and Extensions

Dean Troyer dtroyer at gmail.com
Wed Dec 19 20:01:24 UTC 2012


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



More information about the OpenStack-dev mailing list