openstack team mailing list archive

[Andrew Bogott <abogott@xxxxxxxxxxxxx>]

    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

    I've also written two example plugins, which live here:

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.


== 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?
- Should the plugin base class interpose itself between the plugin and 
python-openstackclient in order to enforce interface versioning?  Is 
that even possible?

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!