openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Thu, May 17, 2012 at 4:32 PM, Andrew Bogott <abogott@xxxxxxxxxxxxx>wrote:

>    I would appreciate comments on the nascent Nova plugin framework that
> I'm working on.  My Nova code is in a fairly modern forked branch here:
>
> https://github.com/**andrewbogott/nova/tree/plugin<https://github.com/andrewbogott/nova/tree/plugin>
>
>    I've also written two example plugins, which live here:
>
> https://github.com/**andrewbogott/novawikiplugins<https://github.com/andrewbogott/novawikiplugins>
>
>    The two plugins in that repo implement actual features that we need
> here at Wikimedia Labs -- One of them is an implementation of shared
> volumes similar to the one I presented at the design summit.
>
>    Please let me know right away if I've messed up the permissions on
> either of those repos.  And, feel free to add your hopes and dreams under
> the 'use cases' section of the blueprint at http://wiki.openstack.org/**
> novaplugin <http://wiki.openstack.org/novaplugin>.
>

Nice! I posted a few comments on the plugin implementation changeset, but
had some more general comments that I thought would be easier to post here.

In the wikistatus plugin I notice that you modify the global FLAGS when
wikistatus.py is imported. Is that the right time to do that, or should it
happen during the on-load handler in the plugin class? Or maybe even in the
plugin manager, which could ask the plugin for the new options and then
modify FLAGS itself. It seems like lots of Nova code modifies FLAGS during
import, but having an explicit trigger for that (rather than depending on
import order) seems safer to me.

If the entry point for each plugin is given a unique name (instead of being
called "plugin", as the sharedfs plugin is) we would be able to log
"loading plugin X" as well as provide options to control which plugins are
activated. I don't know if that latter idea is a goal or not.


>
>
> == Long, rambling notes ==
>
> Goals:
>
> 1)  Provide rudimentary support code in Nova to help with the development,
> packing, and installation of custom features
>
> 2)  Provide a clear interface for third-party code to interact with Nova
>
> 3)  Establish some basic design patterns and examples for developing,
> packing, and installing custom features in Nova and/or Openstack.
>
>    I mention goal 2 in order to defend the 'Plugin' class in my code.  My
> hope is that we can expand on that class and use it as way to enforce that
> Nova provides a versioned, testable interface for third party code.
>    Alas, not all of the features that my plugin uses (in particular, the
> additional shell commands in the sharedfs plugin) pass through the plugin
> class currently.  So the scope of the plugin 'interface' is still evolving,
> and I welcome suggestions about where to draw the lines.
>
> Existing features:
>
> - Plugin loading via via setup.py and entrypoints
> - Plugin loading via nova.conf switches
> - Command-line extension (free, thanks to python-openstackclient)
> - Extension of the nova REST API
> - Installation additional notification drivers at runtime
> - Notification callbacks inherit authorization from the associated request
>
> Concerns:
>
> - Two different loading pathways -- is that useful or just confusing?
>

"One and only one obvious way to do it."


> - Should the plugin base class interpose itself between the plugin and
> python-openstackclient in order to enforce interface versioning?  Is that
> even possible?
>

We could probably figure out a way to do that, but I don't know why you
would want to. What did you have in mind? Which interface are you worried
about versioning, the CLI itself?


>
> Remaining tasks:
>
> - Extending rootwrap (or, specifically, getting gluster into sudo somehow)
> - Versioning
> - Describe best practices for modifying core Nova code when necessary
> (additional notifications and/or synchronous callbacks)
> - Add your desired features here!
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>