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