Open Stack

On 12/18/2012 11:48 AM, Vishvananda Ishaya wrote:
> 
> On Dec 18, 2012, at 11:26 AM, Matt Dietz <matt.dietz at rackspace.com
> <mailto:matt.dietz at rackspace.com>> wrote:
> 
>> I agree with this
>>
>> The only thing I would add is it would be ideal if the extensions were
>> treated explicitly as extensions. More specifically, if the client
>> documentation made it clear that extension X might not be available
>> across all openstack clouds. That the client currently sorts the
>> extensions docstrings in with the rest of the core functionality could
>> lead to some confusion down the road. 
> 
> I think we are on the same page here. I'd like to outline a few steps:
> 
> a) Add some logic in novaclient to only show extensions which have a
> matching endpoint if nova help is called with credentials
> b) Move all existing extension functionality into the
> novaclient/v1_1/contrib/ dir
> c) Update the client documentation to make it clear which functionality
> is extension based.
> 
> This should be fairly easy for the large blocks of extension
> functionality (e.g. os-networks) but it will be tricky for the
> extensions that add extra parameters to existing commands. We may be
> able to figure out how to tag which options are enabled by which
> extensions, but if not we could at the very least add some comments to
> the help text like (requires os-keypairs extension)
> 
> We should be careful about moving around classes for people using
> python-novaclient as a library as well.

I would like to raise my hand on behalf of the OpenStack CI
infrastructure as a user of python-novaclient as a library. All of the
devstack-gate nodes are spun up using python-novaclient as a library.
Please no breaky! :)

Monty