Open Stack

Well, so one way around that is to provide an "os-novaclient" extension
that simply installs all the bits we deem necessary to "use cloud." I
definitely agree with the sentiment that it's not an optimal experience to
have to install a bunch of packages to get to that point. With that said,
I think the broken window here is that the extensions exist in the Nova
tree at all, though that's may be too big a topic to tackle here, as much
as I'd like that to change.

-----Original Message-----
From: Monty Taylor <mordred at inaugust.com>
Reply-To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Date: Monday, December 17, 2012 2:40 PM
To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Novaclient and Extensions

>
>
>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
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev