Open Stack

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)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121218/37b60b5a/attachment.html>