[openstack-dev] Novaclient and Extensions

Matt Dietz matt.dietz at rackspace.com
Mon Dec 17 20:15:14 UTC 2012


	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?


More information about the OpenStack-dev mailing list