Open Stack

On 12/17/2012 10:20 PM, Craig Vyvial wrote:
> I do not think making the client "smart" enough to be able to tell which
> extensions are available is the right approach. It seems like overkill
> for the client's responsibility. 
> 
> I maybe reading in to this to far but it seems like if you want to
> install or enable an extension you should have to install to enable
> it... aka install python-novaclient-security-groups.
> Then each extension can be updated maintained separately.
> 
> But i guess the main draw back I see with this is that then its a pain
> to "test" this functionality between extensions and core code. 
> But I am sure people/companies have their own custom extensions that
> have never made it into the core code or never will have already felt
> some of these pains. 

Obviously, I agree with Vish here ... but I think that one of the places
where you and I may be missing each other is in who the audience is we
are talking about.

When you say "if you want to install..." that implies a level of agency
or understanding that I do not think we should expect from a public
cloud user. Why would I, as a consumer of an OpenStack based public
cloud ever "want" to install a novaclient extension module? How would I
even know I want to do that?

On the other hand, if you're talking about a private cloud, then sure -
the cloud consumers have a more specific knowledge than the general
walk-up consumer would, so might have more of an idea that they "want"
to install a particular extension.

For a public cloud user, I should need to know exactly one thing about
the cloud in question - the entry endpoint.

> On Mon, Dec 17, 2012 at 3:06 PM, Vishvananda Ishaya
> <vishvananda at gmail..com <mailto:vishvananda at gmail.com>> wrote:
> 
> 
>     On Dec 17, 2012, at 12:40 PM, Monty Taylor <mordred at inaugust.com
>     <mailto: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
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>