Open Stack

On 12/18/2012 03:29 PM, Matt Dietz wrote:
> Those two ideas aren't mutually exclusive. I believe that some of these
> extensions deserve to be core functionality, but we still need a way to
> clean up the ones that won't be (yet or ever)

Totally. I **FULLY** support vishy's plan for dealing with extensions.
I'm just additionally saying that (like John just said) while we're
cleaning them up, perhaps some of them should be promoted.

> From: John Griffith <john.griffith at solidfire.com
> <mailto:john.griffith at solidfire.com>>
> Reply-To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Tuesday, December 18, 2012 5:17 PM
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] Novaclient and Extensions
> 
> 
> 
> On Tue, Dec 18, 2012 at 4:08 PM, Monty Taylor <mordred at inaugust.com
> <mailto:mordred at inaugust.com>> wrote:
> 
>     Can we perhaps start promoting some of these extensions to core? I mean,
>     I'm all for freedom - but perhaps part of the problem is that some
>     ofActually
>     these things aren't (or shouldn't be) _truly_ extensions.
> 
>     On 12/18/2012 02:42 PM, Anne Gentle wrote:
>     >
>     > On Tue, Dec 18, 2012 at 1:26 PM, Matt Dietz <matt.dietz at rackspace.com <mailto:matt..dietz at rackspace.com>
>     > <mailto:matt.dietz at rackspace.com <mailto:matt.dietz at rackspace.com>>> wrote:
>     >
>     >     I agree with this
>     >
>     >     The only thing I would add is it would be ideal if the extensions
>     >     were treated explicitly as extensions. More specifically, if the
>     >     client documentation made it clear that extension X might not be
>     >     available across all openstack clouds. That the client currently
>     >     sorts the extensions docstrings in with the rest of the core
>     >     functionality could lead to some confusion down the road..
>     >
>     >
>     > Thinking about this, and what it really might look like to a user. I
>     > want to apply some hard data around this issue.
>     >
>     > There are 32 viable core "calls" for the Compute API. [1] There are over
>     > 90 viable extension calls.[2] I haven't done the complete audit yet for
>     > missing docs for extensions, but I know that there's about a 3 times
>     > factor of core calls to extension calls based on the doc work I've done
>     > and managed.
>     >
>     > Basically I need to point out that "make it clear in the docs" is not
>     > the best fix, and chasing true clarity is probably impossible knowing
>     > what's under the covers.
>     >
>     > What can we do beyond docs?
>     >
>     > Thanks,
>     > Anne
>     >
>     > 1. I'm calling a "call" a GET, PUT, POST, DELETE request with an
>     > associated URI. Basically I'm counting the number of <method
>     > name="GET|PUT|POST|DELETE"> elements in WADL files.
>     > 2. There are 97 extension methods documented if you don't count volume
>     > creation or attachment, 113 total if you do volumes through the Compute
>     > API extension, see
>     > https://docs.google.com/spreadsheet/ccc?key=0AhXvn1h0dcyYdExERVZ0elAtc1pWcGtfQWNlMEFNd1E
>     > for counts.
>     >
>     >
>     >     From: Craig Vyvial <cp16net at gmail.com <mailto:cp16net at gmail.com>
>     <mailto:cp16net at gmail.com <mailto:cp16net at gmail.com>>>
>     >
>     >     Reply-To: OpenStack Development Mailing List
>     >     <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>
>     >     <mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>>
>     >     Date: Tuesday, December 18, 2012 1:14 PM
>     >
>     >     To: OpenStack Development Mailing List
>     >     <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>
>     >     <mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>>
>     >     Subject: Re: [openstack-dev] Novaclient and Extensions
>     >
>     >     Ok i agree that the user should only have to know 1 thing. The entry
>     >     point.
>     >
>     >     Then the discovery of extensions by the client should be api driven
>     >     by the cloud entry point.
>     >
>     >
>     >     On Tue, Dec 18, 2012 at 6:03 AM, Christopher Yeoh <cyeoh at au1.ibm.com <mailto:cyeoh at au1.ibm.com>
>     >     <mailto:cyeoh at au1.ibm.com <mailto:cyeoh at au1..ibm.com>>> wrote:
>     >
>     >         On Mon, 17 Dec 2012 22:37:50 -0800
>     >         Monty Taylor <mordred at inaugust.com <mailto:mordred at inaugust.com>
>     >         <mailto:mordred at inaugust.com <mailto:mordred at inaugust.com>>> wrote:
>     >
>     >         > On 12/17/2012 10:20 PM, Craig Vyvial wrote:
>     >         > > I do not think making the client "smart" enough to be able to tell
>     >         > > which extensions are available is the right approach. It seems like
>     >         > > overkill for the client's responsibility.
>     >         > >
>     >         > > I maybe reading in to this to far but it seems like if you want to
>     >         > > install or enable an extension you should have to install to enable
>     >         > > it... aka install python-novaclient-security-groups.
>     >         > > Then each extension can be updated maintained separately.
>     >         > >
>     >         > > But i guess the main draw back I see with this is that then its a
>     >         > > pain to "test" this functionality between extensions and core code.
>     >         > > But I am sure people/companies have their own custom extensions that
>     >         > > have never made it into the core code or never will have already
>     >         > > felt some of these pains.
>     >         >
>     >         > Obviously, I agree with Vish here ... but I think that one of the
>     >         > places where you and I may be missing each other is in who the
>     >         > audience is we are talking about.
>     >         >
>     >         > When you say "if you want to install..." that implies a level of
>     >         > agency or understanding that I do not think we should expect from a
>     >         > public cloud user. Why would I, as a consumer of an OpenStack based
>     >         > public cloud ever "want" to install a novaclient extension module?
>     >         > How would I even know I want to do that?
>     >
>     >         +1
>     >
>     >         Most users would not know that they have to install an extension
>     >         and just finding out which extensions they should install would be
>     >         difficult for new and inexperienced users. They'd probably just
>     >         assume
>     >         that the functionality they want is not available.
>     >
>     >         So I agree we want the client to automatically detect what
>     >         extension capabilities can be used. Perhaps even an easy way for
>     >         them
>     >         to see what functionality they could have from nova client if the
>     >         corresponding server side support was installed.
>     >
>     >         Chris
>     >         --
>     >         cyeoh at au.ibm.com <mailto:cyeoh at au.ibm.com> <mailto:cyeoh at au.ibm.com
>     <mailto:cyeoh at au.ibm.com>>
>     >
>     >
>     >         _______________________________________________
>     >         OpenStack-dev mailing list
>     >         OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     >         <mailto:OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>>
>     >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     >
>     >     _______________________________________________
>     >     OpenStack-dev mailing list
>     >     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     >     <mailto:OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>>
>     >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> So one vote for moving things in to contrib as outlined by Vish, and
> another vote to support Monty's suggestion that perhaps some of these
> things aren't really *extensions* but core functionality.  Perhaps
> during the migration in to contrib we could have a closer look at what
> should perhaps be promoted?
> 
> John
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>