[openstack-dev] Novaclient and Extensions
Monty Taylor
mordred at inaugust.com
Tue Dec 18 23:08:44 UTC 2012
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
>
More information about the OpenStack-dev
mailing list