Open Stack

On Tue, Nov 20, 2012 at 10:40 AM, Russell Bryant <rbryant at redhat.com> wrote:

> Greetings,
>
> There is currently a patch in the review queue for nova that adds hooks.
>
> https://review.openstack.org/#/c/16336/
>
> I like the concept, but I think it could benefit from some design
> discussion.  That's difficult on gerrit and much better suited for the
> mailing list, so here we are.
>
> My biggest design comment on this has been that I think it needs to
> support loading custom modules that register hooks.  I also would like
> to minimize how much of this we have to expose to the configuration.
> Here's the general functionality I have in mind:
>
>    I want to hook into nova at the defined 'foo' hook point.  I write a
>    hook module and drop it into the predefined directory
>    /path/to/nova/modules/.  Nova should automatically import everything
>    in this custom module directory and the hooks get registered.
>
>    The registration mechanism could either be the modules calling an API
>    to register their hooks at load time, or nova could scan the module
>    for hooks and register them automatically.  Whichever is more
>    Pythonic is fine with me.
>

> The only configuration option I see that would be needed here is the
> ability to customize with directory (or directories) are used for
> loading custom modules.
>
> There are some related efforts going on here that need to be considered,
> as well:
>
> 1) nova/loadables.py
>
> This is used in the patch right now.  Some comments on this approach:
>
>  - It means nova scans the module and automatically registers hook
>    classes that are of the right type.  I think that makes sense, but
>    is that the most Pythonic approach for this kind of thing?
>
>  - This will need to be extended if we want to support a directory of
>    user provided modules that have hooks in them.  I think that's
>    pretty important for the primary hook use case.
>
> 2) nova/openstack/common/pluginmanager.py
>

At the summit Monty proposed using Stevedore and entry points for loading
dynamic code in nova (I think that patch is waiting for some attention to
make the tests run more quickly).

In addition to the DriverManager Monty was using, Stevedore has a
HookManager for exactly this use case of running hooks (
http://stevedore.readthedocs.org/en/latest/managers.html#hookmanager). Using
the HookManager loads only the plugins necessary for a given hook. The
steps for loading and invoking are separate, allowing hooks to be loaded at
application startup to avoid runtime penalties from loading code
dynamically the first time a method is called.

In addition to the developer benefits of using entry points, they provide
some important deployment benefits. For example, there's no need to deploy
code from multiple unrelated OS packages into the same directory, which is
a common source of complaints from packagers. It also avoids the need to
configure "a" search path, since anything visible on the python import path
can provide a plugin. We've used entry points to good effect in ceilometer,
especially when allowing deployers to provide custom meters or pollsters.

Doug


>
> I haven't looked into this lately, but at a high level, there seems to
> be some overlap here.  I'd like to see this analyzed for how it could
> apply to hooks.  If it doesn't fit, that's fine, I just want to make
> sure it's considered and the results documented.
>
> Thanks,
>
> --
> Russell Bryant
>
> _______________________________________________
> 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/20121120/abe3aa4c/attachment.html>