Yes, this is a reasonable way to handle repo creation requests, and we should update our wiki to reflect this: https://wiki.openstack.org/wiki/Fuel/Plugins#Repo
On Mon, Feb 15, 2016 at 05:01:39PM +0100, Mateusz Matuszkowiak wrote: > Dmitry, > > So this changes the workflow for the devopses, the fuel plugin repo creators > under Openstack namespace. > > As I understand, development of every new fuel plugin must be now started in > a private github repo first, Not necessarily github, any public git hosting should work just as well. > and when a developer(s) decide they want to go level higher they request for > a validation. > And only after successfull validation they should request a repository > creation (via LP bug) for their plugin under Openstack NS, right? > I’m asking since its important for us to properly handle these kind of bugs > [0]. > > Regards, > > [0] https://bugs.launchpad.net/fuel/+bug/1544536 > <https://bugs.launchpad.net/fuel/+bug/1544536> > > -- > Fuel DevOps > Mateusz Matuszkowiak > > > > On Feb 3, 2016, at 3:27 AM, Dmitry Borodaenko <dborodae...@mirantis.com> > > wrote: > > > > 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 > __________________________________________________________________________ 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
