Open Stack

On Dec 17, 2012, at 12:40 PM, Monty Taylor <mordred at inaugust.com> wrote:

> 
> 
> On 12/17/2012 12:15 PM, Matt Dietz wrote:
>> All,
>> 
>> 	I've noticed recently that more and more extension specific code is going
>> into novaclient rather than a dedicated client extension, and that some of
>> the new code assumes other extensions are enabled in Nova proper. I wanted
>> to start the discussion of finally starting to treat extensions as they're
>> meant to be: extensions. Between Nova and novaclient, we have a lot of
>> code that makes assumptions about the existence of an extension, which
>> objectively means that particular object is no longer "extending"
>> anything. What would it take to get everyone to agree to the idea that
>> only core functionality belongs in the API, and that any references to
>> extension functionality doesn't?
>> 	I'm proposing we set about removing things like the checks for loaded
>> extensions in the nova API, and similarly, remove all extensions in the
>> novaclient and into their own client extension packages. I already started
>> this work with my blueprint for tenant networks
>> https://blueprints.launchpad.net/nova/+spec/tenant-networks, which adds a
>> new extension and moves the existing one into a different namespace. The
>> original patches I had written also removed the network command bits from
>> novaclient and replaced them with two new client extensions. However, when
>> attempting to merge those back in, I noticed code was added for a "scrub"
>> method, which assumes networks and security groups are available.
>> 	Unless there are any serious objections, I plan to remove the newly added
>> network functionality and the scrub functionality and place them in their
>> own extensions, because I'd like to set the precedent for returning
>> novaclient to it's core-API only status. Thoughts?
> 
> I'd be inclined to agree (since I was the one who moved the rackspace
> auth specific things into an extension a while back) ... but I do want
> to make sure that we don't make it unnecessarily hard for an end-user to
> do this:
> 
> pip install python-novaclient
> ** use cloud **
> 
> That said - I think that any "extension" to nova that is actually to be
> found in nova's tree should have corresponding extension code in the
> python-novaclient tree. HOWEVER, I think that novaclient should be able
> to figure out what extensions are there and only expose functionality
> that is appropriate for the cloud it's talking too.
> 
> I think that making a user do:
> 
> pip install python-novaclient python-novaclient-security-groups

Agreed. We already have a place for extension code to go in novaclient, we just
aren't using it. We need to start moving stuff there and add a check for novaclient
to actually check the extensions endpoint before displaying help so that only
usable command show up.

Vish