<div dir="ltr"><div style>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. </div>
<div style><br></div><div style>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 <span style="font-family:arial,sans-serif;font-size:13px">python-novaclient-security-</span><span style="font-family:arial,sans-serif;font-size:13px">groups.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px">Then each extension can be updated maintained separately.</span><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px">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. </span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px">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. </span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">-Craig V</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Dec 17, 2012 at 3:06 PM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Dec 17, 2012, at 12:40 PM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br>
<br>
><br>
><br>
> On 12/17/2012 12:15 PM, Matt Dietz wrote:<br>
>> All,<br>
>><br>
>>      I've noticed recently that more and more extension specific code is going<br>
>> into novaclient rather than a dedicated client extension, and that some of<br>
>> the new code assumes other extensions are enabled in Nova proper. I wanted<br>
>> to start the discussion of finally starting to treat extensions as they're<br>
>> meant to be: extensions. Between Nova and novaclient, we have a lot of<br>
>> code that makes assumptions about the existence of an extension, which<br>
>> objectively means that particular object is no longer "extending"<br>
>> anything. What would it take to get everyone to agree to the idea that<br>
>> only core functionality belongs in the API, and that any references to<br>
>> extension functionality doesn't?<br>
>>      I'm proposing we set about removing things like the checks for loaded<br>
>> extensions in the nova API, and similarly, remove all extensions in the<br>
>> novaclient and into their own client extension packages. I already started<br>
>> this work with my blueprint for tenant networks<br>
>> <a href="https://blueprints.launchpad.net/nova/+spec/tenant-networks" target="_blank">https://blueprints.launchpad.net/nova/+spec/tenant-networks</a>, which adds a<br>
>> new extension and moves the existing one into a different namespace. The<br>
>> original patches I had written also removed the network command bits from<br>
>> novaclient and replaced them with two new client extensions. However, when<br>
>> attempting to merge those back in, I noticed code was added for a "scrub"<br>
>> method, which assumes networks and security groups are available.<br>
>>      Unless there are any serious objections, I plan to remove the newly added<br>
>> network functionality and the scrub functionality and place them in their<br>
>> own extensions, because I'd like to set the precedent for returning<br>
>> novaclient to it's core-API only status. Thoughts?<br>
><br>
> I'd be inclined to agree (since I was the one who moved the rackspace<br>
> auth specific things into an extension a while back) ... but I do want<br>
> to make sure that we don't make it unnecessarily hard for an end-user to<br>
> do this:<br>
><br>
> pip install python-novaclient<br>
> ** use cloud **<br>
><br>
> That said - I think that any "extension" to nova that is actually to be<br>
> found in nova's tree should have corresponding extension code in the<br>
> python-novaclient tree. HOWEVER, I think that novaclient should be able<br>
> to figure out what extensions are there and only expose functionality<br>
> that is appropriate for the cloud it's talking too.<br>
><br>
> I think that making a user do:<br>
><br>
> pip install python-novaclient python-novaclient-security-groups<br>
<br>
</div></div>Agreed. We already have a place for extension code to go in novaclient, we just<br>
aren't using it. We need to start moving stuff there and add a check for novaclient<br>
to actually check the extensions endpoint before displaying help so that only<br>
usable command show up.<br>
<br>
Vish<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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><br></div>