Open Stack

It has been over a year since pluggable architecture was introduced in
Fuel 6.0, and I think it's safe to declare it an unmitigated success. A
search for "fuel-plugin" on GitHub brings up 167 repositories [0],
there's 63 Fuel plugin repositories on review.openstack.org [1], 25 Fuel
plugins are listed in the DriverLog [2].

[0] https://github.com/search?q=fuel-plugin-
[1] https://review.openstack.org/#/admin/projects/?filter=openstack%252Ffuel-plugin-
[2] http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel

Even though the plugin engine is not yet complete (there still are
things you can do in Fuel core that you cannot do in a plugin), dozens
of deployers and developers [3] used it to expand Fuel capabilities
beyond the limitations of our default reference architecture.

[3] http://stackalytics.com/report/contribution/fuel-plugins-group/360

There's a noticeable bump in contributions around October 2015 after
Fuel 7.0 was released, most likely inspired by the plugin engine
improvements introduced in that version [4]. As we continue to expand
plugins capabilities, I expect more and more plugins to appear.

[4] https://git.openstack.org/cgit/openstack/fuel-docs/tree/pages/release-notes/v7-0/new_features/plugins.rst?h=stable/7.0

The question of how useful exactly all those plugins are is a bit harder
to answer. DriverLog isn't much help: less than half of Fuel plugins
hosted on OpenStack infrastructure are even registered there, and of
those that are, only 6 have CI jobs with recent successful runs. Does
this mean that 90% of Fuel plugins are broken and unmaintained? Not
necessarily, but it does mean that we have no way to tell.

An even harder question is: once we determine that some plugins are more
equal than others, what should we do about the less useful and the less
actively maintained?

To objectively answer both questions, we need to define support levels
for Fuel plugins and set some reasonable expectations about how plugins
can qualify for each level.

Level 3. Plugin is not actively supported

I believe that having hundreds of Fuel plugins out there on GitHub and
elsewhere is great, and we should encourage people to create more of
those and do whatever they like with them. Even a single-commit "deploy
and forget" plugin is useful as an idea, a source of inspiration, and a
starting point for other people who might want to take it further.

At this level, there should be zero expectations and zero obligations
between Fuel plugin writers and OpenStack community. At the moment, Fuel
plugins developers guide recommends [5] to request a Gerrit repo in the
openstack/ namespace and set up branches, tags, CI, and a code review
process around it, aligned with OpenStack development process. Which is
generally a good idea, except for all the cases where it's too much
overhead and ends up not being followed closely enough to be useful.

[5] https://wiki.openstack.org/wiki/Fuel/Plugins#Repo

Instead of vague blanket recommendations, we should explictly state that
it's fine to do none of that and just stay on GitHub, and that if you
intend to move to the next level and actively maintain your plugin, and
expect support with that from Fuel developers and other OpenStack
projects, these recommendations are not optional and must be fulfilled.

Level 2. Plugin is actively supported by its registered maintainers 

To support a Fuel plugin, we need to answer two fundamental questions:
Can we? Should we?

I think the minimum requirements to say "yes" to both are:

a) All of the plugin's source code is explicitly licensed under an
   OSI-approved license;

b) The plugin source code repository does not contain binary artefacts
   such as RPM packages or ISO images (*);

c) The plugin is registered in DriverLog;

d) Plugin maintainers listed in DriverLog have confirmed the intent to
   support the plugin;

e) Plugin repository on review.openstack.org has a voting CI job that is
   passing with the latest or, at least, previous major release of Fuel.

f) All deviations from the OpenStack development process (alternative
   issue trackers, mailing lists, etc.) are documented in the plugin's
   README file.

*  Aside from purely technical issues we're getting because git is not
   suitable for tracking binary files [6], contaminating the source code
   with opaque binary blobs makes it impossible to ensure that the
   plugin remains compliant with the open source requirement (a).

[6] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083812.html

In addition to above requirements, we need to set up graceful
transitions from level 3 to level 2 and back. Meeting the requirements
should be easy (well, except rewriting commit history to get rid of
binary blobs under .git, I think it's reasonable to require plugin
developers to do this where applicable), and if maintainers step down or
go MIA, we should stash the code in a common repository
(fuel-plugins-contrib) where it can recovered from later.

Level 1. Plugin is actively supported by Fuel team

As we expand plugin capabilities and move more functionality from Fuel
core into plugins, we will inevitably get to the point where some
plugins are required to successfully complete even a basic deployment
(aka "pass BVT"). Even before that, we may decide that some plugins are
important enough for our reference architecture to allow the state of
these plugins to affect our release cycle: allow Critical bugs in them
to affect Fuel release, cover them in acceptance testing for Fuel
releases and maintenance updates, and so on.

Obviously, whole Fuel team is expected to support such plugins, and is
self-motivated to provide timely help to their maintainers to keep them
healthy. In addition to the expectations from the previous support
level, we should track the list of these release-critical plugins in the
policy section of fuel-specs [7].

[7] https://git.openstack.org/cgit/openstack/fuel-specs/tree/policy

Thoughts, comments, objections?

-- 
Dmitry Borodaenko