<div dir="ltr">Hi,<div><br></div><div>I have some comments on CI for plugins, currently there is a good instruction on how to install your own CI and using fuel-qa write your own tests [0], since just running BVT is not enough to make sure that plugin works, we should provide a way for a plugin developer to easily extend checks/asserts which are done during BVT by just putting python files into plugin-name/tests directory. This way will be able to install plugin (enable it) and perform plugin specific checks.</div><div><br></div><div>Thanks,</div><div><br></div><div>[0] <a href="https://wiki.openstack.org/wiki/Fuel/Plugins#CI">https://wiki.openstack.org/wiki/Fuel/Plugins#CI</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 5:27 AM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It has been over a year since pluggable architecture was introduced in<br>
Fuel 6.0, and I think it's safe to declare it an unmitigated success. A<br>
search for "fuel-plugin" on GitHub brings up 167 repositories [0],<br>
there's 63 Fuel plugin repositories on <a href="http://review.openstack.org" rel="noreferrer" target="_blank">review.openstack.org</a> [1], 25 Fuel<br>
plugins are listed in the DriverLog [2].<br>
<br>
[0] <a href="https://github.com/search?q=fuel-plugin-" rel="noreferrer" target="_blank">https://github.com/search?q=fuel-plugin-</a><br>
[1] <a href="https://review.openstack.org/#/admin/projects/?filter=openstack%252Ffuel-plugin-" rel="noreferrer" target="_blank">https://review.openstack.org/#/admin/projects/?filter=openstack%252Ffuel-plugin-</a><br>
[2] <a href="http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel" rel="noreferrer" target="_blank">http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel</a><br>
<br>
Even though the plugin engine is not yet complete (there still are<br>
things you can do in Fuel core that you cannot do in a plugin), dozens<br>
of deployers and developers [3] used it to expand Fuel capabilities<br>
beyond the limitations of our default reference architecture.<br>
<br>
[3] <a href="http://stackalytics.com/report/contribution/fuel-plugins-group/360" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/fuel-plugins-group/360</a><br>
<br>
There's a noticeable bump in contributions around October 2015 after<br>
Fuel 7.0 was released, most likely inspired by the plugin engine<br>
improvements introduced in that version [4]. As we continue to expand<br>
plugins capabilities, I expect more and more plugins to appear.<br>
<br>
[4] <a href="https://git.openstack.org/cgit/openstack/fuel-docs/tree/pages/release-notes/v7-0/new_features/plugins.rst?h=stable/7.0" rel="noreferrer" target="_blank">https://git.openstack.org/cgit/openstack/fuel-docs/tree/pages/release-notes/v7-0/new_features/plugins.rst?h=stable/7.0</a><br>
<br>
The question of how useful exactly all those plugins are is a bit harder<br>
to answer. DriverLog isn't much help: less than half of Fuel plugins<br>
hosted on OpenStack infrastructure are even registered there, and of<br>
those that are, only 6 have CI jobs with recent successful runs. Does<br>
this mean that 90% of Fuel plugins are broken and unmaintained? Not<br>
necessarily, but it does mean that we have no way to tell.<br>
<br>
An even harder question is: once we determine that some plugins are more<br>
equal than others, what should we do about the less useful and the less<br>
actively maintained?<br>
<br>
To objectively answer both questions, we need to define support levels<br>
for Fuel plugins and set some reasonable expectations about how plugins<br>
can qualify for each level.<br>
<br>
Level 3. Plugin is not actively supported<br>
<br>
I believe that having hundreds of Fuel plugins out there on GitHub and<br>
elsewhere is great, and we should encourage people to create more of<br>
those and do whatever they like with them. Even a single-commit "deploy<br>
and forget" plugin is useful as an idea, a source of inspiration, and a<br>
starting point for other people who might want to take it further.<br>
<br>
At this level, there should be zero expectations and zero obligations<br>
between Fuel plugin writers and OpenStack community. At the moment, Fuel<br>
plugins developers guide recommends [5] to request a Gerrit repo in the<br>
openstack/ namespace and set up branches, tags, CI, and a code review<br>
process around it, aligned with OpenStack development process. Which is<br>
generally a good idea, except for all the cases where it's too much<br>
overhead and ends up not being followed closely enough to be useful.<br>
<br>
[5] <a href="https://wiki.openstack.org/wiki/Fuel/Plugins#Repo" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Fuel/Plugins#Repo</a><br>
<br>
Instead of vague blanket recommendations, we should explictly state that<br>
it's fine to do none of that and just stay on GitHub, and that if you<br>
intend to move to the next level and actively maintain your plugin, and<br>
expect support with that from Fuel developers and other OpenStack<br>
projects, these recommendations are not optional and must be fulfilled.<br>
<br>
Level 2. Plugin is actively supported by its registered maintainers<br>
<br>
To support a Fuel plugin, we need to answer two fundamental questions:<br>
Can we? Should we?<br>
<br>
I think the minimum requirements to say "yes" to both are:<br>
<br>
a) All of the plugin's source code is explicitly licensed under an<br>
OSI-approved license;<br>
<br>
b) The plugin source code repository does not contain binary artefacts<br>
such as RPM packages or ISO images (*);<br>
<br>
c) The plugin is registered in DriverLog;<br>
<br>
d) Plugin maintainers listed in DriverLog have confirmed the intent to<br>
support the plugin;<br>
<br>
e) Plugin repository on <a href="http://review.openstack.org" rel="noreferrer" target="_blank">review.openstack.org</a> has a voting CI job that is<br>
passing with the latest or, at least, previous major release of Fuel.<br>
<br>
f) All deviations from the OpenStack development process (alternative<br>
issue trackers, mailing lists, etc.) are documented in the plugin's<br>
README file.<br>
<br>
* Aside from purely technical issues we're getting because git is not<br>
suitable for tracking binary files [6], contaminating the source code<br>
with opaque binary blobs makes it impossible to ensure that the<br>
plugin remains compliant with the open source requirement (a).<br>
<br>
[6] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-January/083812.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-January/083812.html</a><br>
<br>
In addition to above requirements, we need to set up graceful<br>
transitions from level 3 to level 2 and back. Meeting the requirements<br>
should be easy (well, except rewriting commit history to get rid of<br>
binary blobs under .git, I think it's reasonable to require plugin<br>
developers to do this where applicable), and if maintainers step down or<br>
go MIA, we should stash the code in a common repository<br>
(fuel-plugins-contrib) where it can recovered from later.<br>
<br>
Level 1. Plugin is actively supported by Fuel team<br>
<br>
As we expand plugin capabilities and move more functionality from Fuel<br>
core into plugins, we will inevitably get to the point where some<br>
plugins are required to successfully complete even a basic deployment<br>
(aka "pass BVT"). Even before that, we may decide that some plugins are<br>
important enough for our reference architecture to allow the state of<br>
these plugins to affect our release cycle: allow Critical bugs in them<br>
to affect Fuel release, cover them in acceptance testing for Fuel<br>
releases and maintenance updates, and so on.<br>
<br>
Obviously, whole Fuel team is expected to support such plugins, and is<br>
self-motivated to provide timely help to their maintainers to keep them<br>
healthy. In addition to the expectations from the previous support<br>
level, we should track the list of these release-critical plugins in the<br>
policy section of fuel-specs [7].<br>
<br>
[7] <a href="https://git.openstack.org/cgit/openstack/fuel-specs/tree/policy" rel="noreferrer" target="_blank">https://git.openstack.org/cgit/openstack/fuel-specs/tree/policy</a><br>
<br>
Thoughts, comments, objections?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dmitry Borodaenko<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>