<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dmitry,<div class=""><br class=""></div><div class="">So this changes the workflow for the devopses, the fuel plugin repo creators under Openstack namespace.</div><div class=""><br class=""></div><div class="">As I understand, development of every new fuel plugin must be now started in a private github repo first, </div><div class="">and when a developer(s) decide they want to go level higher they request for a validation. </div><div class="">And only after successfull validation they should request a repository creation (via LP bug) for their plugin under Openstack NS, right? </div><div class="">I’m asking since its important for us to properly handle these kind of bugs [0].</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">[0] <a href="https://bugs.launchpad.net/fuel/+bug/1544536" class="">https://bugs.launchpad.net/fuel/+bug/1544536</a></div><div class=""><br class=""></div><div class=""><div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">--</div><div class="">Fuel DevOps</div><div class="">Mateusz Matuszkowiak</div></div><div class=""><br class=""></div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Feb 3, 2016, at 3:27 AM, Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com" class="">dborodaenko@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">It has been over a year since pluggable architecture was introduced in<br class="">Fuel 6.0, and I think it's safe to declare it an unmitigated success. A<br class="">search for "fuel-plugin" on GitHub brings up 167 repositories [0],<br class="">there's 63 Fuel plugin repositories on <a href="http://review.openstack.org" class="">review.openstack.org</a> [1], 25 Fuel<br class="">plugins are listed in the DriverLog [2].<br class=""><br class="">[0] <a href="https://github.com/search?q=fuel-plugin-" class="">https://github.com/search?q=fuel-plugin-</a><br class="">[1] <a href="https://review.openstack.org/#/admin/projects/?filter=openstack%252Ffuel-plugin-" class="">https://review.openstack.org/#/admin/projects/?filter=openstack%252Ffuel-plugin-</a><br class="">[2] <a href="http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel" class="">http://stackalytics.com/report/driverlog?project_id=openstack%2Ffuel</a><br class=""><br class="">Even though the plugin engine is not yet complete (there still are<br class="">things you can do in Fuel core that you cannot do in a plugin), dozens<br class="">of deployers and developers [3] used it to expand Fuel capabilities<br class="">beyond the limitations of our default reference architecture.<br class=""><br class="">[3] <a href="http://stackalytics.com/report/contribution/fuel-plugins-group/360" class="">http://stackalytics.com/report/contribution/fuel-plugins-group/360</a><br class=""><br class="">There's a noticeable bump in contributions around October 2015 after<br class="">Fuel 7.0 was released, most likely inspired by the plugin engine<br class="">improvements introduced in that version [4]. As we continue to expand<br class="">plugins capabilities, I expect more and more plugins to appear.<br class=""><br class="">[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" class="">https://git.openstack.org/cgit/openstack/fuel-docs/tree/pages/release-notes/v7-0/new_features/plugins.rst?h=stable/7.0</a><br class=""><br class="">The question of how useful exactly all those plugins are is a bit harder<br class="">to answer. DriverLog isn't much help: less than half of Fuel plugins<br class="">hosted on OpenStack infrastructure are even registered there, and of<br class="">those that are, only 6 have CI jobs with recent successful runs. Does<br class="">this mean that 90% of Fuel plugins are broken and unmaintained? Not<br class="">necessarily, but it does mean that we have no way to tell.<br class=""><br class="">An even harder question is: once we determine that some plugins are more<br class="">equal than others, what should we do about the less useful and the less<br class="">actively maintained?<br class=""><br class="">To objectively answer both questions, we need to define support levels<br class="">for Fuel plugins and set some reasonable expectations about how plugins<br class="">can qualify for each level.<br class=""><br class="">Level 3. Plugin is not actively supported<br class=""><br class="">I believe that having hundreds of Fuel plugins out there on GitHub and<br class="">elsewhere is great, and we should encourage people to create more of<br class="">those and do whatever they like with them. Even a single-commit "deploy<br class="">and forget" plugin is useful as an idea, a source of inspiration, and a<br class="">starting point for other people who might want to take it further.<br class=""><br class="">At this level, there should be zero expectations and zero obligations<br class="">between Fuel plugin writers and OpenStack community. At the moment, Fuel<br class="">plugins developers guide recommends [5] to request a Gerrit repo in the<br class="">openstack/ namespace and set up branches, tags, CI, and a code review<br class="">process around it, aligned with OpenStack development process. Which is<br class="">generally a good idea, except for all the cases where it's too much<br class="">overhead and ends up not being followed closely enough to be useful.<br class=""><br class="">[5] <a href="https://wiki.openstack.org/wiki/Fuel/Plugins#Repo" class="">https://wiki.openstack.org/wiki/Fuel/Plugins#Repo</a><br class=""><br class="">Instead of vague blanket recommendations, we should explictly state that<br class="">it's fine to do none of that and just stay on GitHub, and that if you<br class="">intend to move to the next level and actively maintain your plugin, and<br class="">expect support with that from Fuel developers and other OpenStack<br class="">projects, these recommendations are not optional and must be fulfilled.<br class=""><br class="">Level 2. Plugin is actively supported by its registered maintainers <br class=""><br class="">To support a Fuel plugin, we need to answer two fundamental questions:<br class="">Can we? Should we?<br class=""><br class="">I think the minimum requirements to say "yes" to both are:<br class=""><br class="">a) All of the plugin's source code is explicitly licensed under an<br class=""> OSI-approved license;<br class=""><br class="">b) The plugin source code repository does not contain binary artefacts<br class=""> such as RPM packages or ISO images (*);<br class=""><br class="">c) The plugin is registered in DriverLog;<br class=""><br class="">d) Plugin maintainers listed in DriverLog have confirmed the intent to<br class=""> support the plugin;<br class=""><br class="">e) Plugin repository on <a href="http://review.openstack.org" class="">review.openstack.org</a> has a voting CI job that is<br class=""> passing with the latest or, at least, previous major release of Fuel.<br class=""><br class="">f) All deviations from the OpenStack development process (alternative<br class=""> issue trackers, mailing lists, etc.) are documented in the plugin's<br class=""> README file.<br class=""><br class="">* Aside from purely technical issues we're getting because git is not<br class=""> suitable for tracking binary files [6], contaminating the source code<br class=""> with opaque binary blobs makes it impossible to ensure that the<br class=""> plugin remains compliant with the open source requirement (a).<br class=""><br class="">[6] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-January/083812.html" class="">http://lists.openstack.org/pipermail/openstack-dev/2016-January/083812.html</a><br class=""><br class="">In addition to above requirements, we need to set up graceful<br class="">transitions from level 3 to level 2 and back. Meeting the requirements<br class="">should be easy (well, except rewriting commit history to get rid of<br class="">binary blobs under .git, I think it's reasonable to require plugin<br class="">developers to do this where applicable), and if maintainers step down or<br class="">go MIA, we should stash the code in a common repository<br class="">(fuel-plugins-contrib) where it can recovered from later.<br class=""><br class="">Level 1. Plugin is actively supported by Fuel team<br class=""><br class="">As we expand plugin capabilities and move more functionality from Fuel<br class="">core into plugins, we will inevitably get to the point where some<br class="">plugins are required to successfully complete even a basic deployment<br class="">(aka "pass BVT"). Even before that, we may decide that some plugins are<br class="">important enough for our reference architecture to allow the state of<br class="">these plugins to affect our release cycle: allow Critical bugs in them<br class="">to affect Fuel release, cover them in acceptance testing for Fuel<br class="">releases and maintenance updates, and so on.<br class=""><br class="">Obviously, whole Fuel team is expected to support such plugins, and is<br class="">self-motivated to provide timely help to their maintainers to keep them<br class="">healthy. In addition to the expectations from the previous support<br class="">level, we should track the list of these release-critical plugins in the<br class="">policy section of fuel-specs [7].<br class=""><br class="">[7] <a href="https://git.openstack.org/cgit/openstack/fuel-specs/tree/policy" class="">https://git.openstack.org/cgit/openstack/fuel-specs/tree/policy</a><br class=""><br class="">Thoughts, comments, objections?<br class=""><br class="">-- <br class="">Dmitry Borodaenko<br class=""><br class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></div></blockquote></div><br class=""></div></body></html>