[openstack-dev] [Fuel][Plugins] Rules for Fuel Plugins: short-term perspective action plan

Dmitry Borodaenko dborodaenko at mirantis.com
Sat Feb 27 00:33:09 UTC 2016


Irina,

Thanks for putting this plan together. Looks good to me with a few minor
corrections :)

On Wed, Feb 24, 2016 at 05:32:01PM +0300, Irina Povolotskaya wrote:
> Hi Dmitry,
> 
> I wanted to follow-up on the 'let's have some rules' email.
> For now, there are many requests on repo creation for Fuel Plugins and we
> need to think
> on the best way to proceed here.
> 
> In the long-term perspective;
> the theme of the rules for Fuel Plugins and transition manner between
> stages is more for a discussion on the OpenStack summit - would you agree?

I completely agree, I've added a plugins session to the agenda etherpad:
https://etherpad.openstack.org/p/fuel-austin-agenda

> As for the short-term perspective, we will speak about new and already
> existing plugins.
> 
> For new plugins, there needs to be the following flow from Fuel core team
> (on creating a repo):

"Fuel core team" is a confusing term, there really isn't such team:
there is just Fuel team (which includes every contributor to any Fuel
component), while each Fuel component has it's own list of core
reviewers, including non-core components that are not plugins (e.g.
fuel-virtualbox or fuel-stats).

I think the rightful owners of this process should be Fuel liaisons to
OpenStack Infra:
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Infra

By "owners" I mean the people ensuring that the process is followed by
plugin maintainers, not necessarily performing all the steps (which
wouldn't scale for hundreds of plugins, not even dozens that we have
already).

> 1) make sure the plugin has several maintainers and is intended for further
> maintenance (i.e. is not for the one and only Fuel release).

I think even one maintainer should be enough as long as they are active.

> 2) once repo is created,  request adding the plugin entry to DriverLog to
> have very specific personas in charge of this plugins' future
> 3) provide baseline information into README file to let everyone now about
> the plugin's functionality and add someone from Fuel core team to review

Once again, lets correct that to "add someone from Fuel Infra liaisons
to review".

> For already existing plugins:
> there needs to be a survey on already existing plugins that aren't updated
> any longer; their repos can be moved back into private ones or might be
> owned by new maintainers (if those willing to take up this regular task are
> present).

Instead of banishing such plugins from OpenStack altogether, I think we
should give plugin maintainers the option to move their code into
fuel-plugins-contrib if they don't want to maintain a private repo.

> Similar exercise was so far done when stackforge NS was becoming obsolete
> and the corresponding repo owners were asked to update the wiki page and
> add the repo entry into the corresponding list if they were willing to get
> their repo be moved to openstack NS (=if they were willing to continue
> working on specific project).
> 
> If the current plugin maintainers are not willing to work on their plugin
> any longer, they should post the corresponding request in openstack-dev ML
> and ask if any volunteers are present.
> 
> If no volunteers are in place, then the code should live in the private
> repo of the current maintainers, with README/DriverLog updated accordingly.
> 
> I would appreciate any extra ideas in terms of things to do right now.
> 
> Thanks.



More information about the OpenStack-dev mailing list