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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev