[openstack-dev] Novaclient and Extensions

Monty Taylor mordred at inaugust.com
Mon Dec 17 20:40:12 UTC 2012



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

or something is not a positive experience for them. I know as a user of
some cloud right now, I would not personally enjoy that.

Monty



More information about the OpenStack-dev mailing list