Open Stack

On Tue, Dec 18, 2012 at 4:08 PM, Monty Taylor <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 of
> 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>> 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>>
> >
> >     Reply-To: OpenStack Development Mailing List
> >     <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>>
> >     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>> wrote:
> >
> >         On Mon, 17 Dec 2012 22:37:50 -0800
> >         Monty Taylor <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>
> >
> >
> >         _______________________________________________
> >         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
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > 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
> 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/24ef1fa2/attachment.html>