Open Stack

"We should all of us want to stand on the rooftops and shout "check it
out, our cloud is based on OpenStack, so you do not need any specific
knowledge about it from us - it will work in exactly the way you expect
a cloud based on OpenStack to work!" Because in this day and age of
fragmented online user experience, both at the B2B level and at the
direct consumer level - it's an AMAZING possibility."

Monty: The problem with this is that it's possible, and dramatically
easier, for anyone to write an extension that *doesn't* live in the
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.

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.

To Vish: I like this suggestion, but it's worth noting what Anne pointed
out; there are a lot of extensions, it may still be information overload,
so I do we need Monty's suggestion of promoting extensions as well.



-----Original Message-----
From: Vishvananda Ishaya <vishvananda at gmail.com>
Reply-To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Date: Wednesday, December 19, 2012 12:11 PM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Novaclient and Extensions

>
>On Dec 19, 2012, at 9:51 AM, Thomas Duesing
><thomas.duesing at RACKSPACE.COM> wrote:
>
>> Product guy here.  Long time listener, first time caller.
>> 
>> I am all for splitting the extensions out of core novaclient.  The
>>problem I see now is the extra functionality in novaclient that we don't
>>expose to our customers - mostly the admin stuff.  Seeing extra
>>functionality is confusing to our customers, especially since there's no
>>obvious way to tell which novaclient commands work in our environment
>>and which don't.
>> 
>
>I have a thought for this. Essentially we can modify the /extensions
>endpoint to do a policy check and only show the extensions that the
>current credentials can see. If we combine that with the method of only
>showing help for extensions that are installed on the other end, then I
>think we improve this user experience a lot. If you call nova --help with
>admin credentials then you see all of the admin commmands and with user
>credentials they are hidden.
>
>Vish
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev