Open Stack

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.

-Craig V


On Mon, Dec 17, 2012 at 3:06 PM, Vishvananda Ishaya
<vishvananda at gmail.com>wrote:

>
> On Dec 17, 2012, at 12:40 PM, Monty Taylor <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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121218/35b2450a/attachment.html>