Open Stack

> On 06/12/2015 07:58 AM, Bogdan Dobrelya wrote:
> 
> I'm actually happy to hear from you, since we were discussing together
> about that over the last 2 summits, without real plan between both groups.

I believe as a first steep, the contribution policy to Fuel library
should be clear and *prevent new forks of upstream modules* to be
accepted in future.  This will prevent the technical dept and fork
maintain cost to be increased in the future even more.

I suggested few changes to the following wiki section [0], see "Case B.
Adding a new module". Let's please discuss this change as I took
initiative and edited the current version just in-place (good for me,
there is a history in wiki). The main point of the change is to allow
only pulling in changes to existing forks, and prohibit adding of new
forks, like [1] or [2] (related revert [3]).

There was also a solution suggested for new upstream modules should be
added to Fuel as plugins [4] and distributed as packages. Any emergency
custom patches may be added as usual patches for packages.
Submodules could be also an option.

[0]
https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Adding_new_puppet_modules_to_fuel-library
[1] https://review.openstack.org/#/c/190612/
[2] https://review.openstack.org/#/c/128575/
[3] https://review.openstack.org/#/c/191769/
[4] https://wiki.openstack.org/wiki/Fuel/Plugins

> 
> 
> Good feedback from the patch's author.
> 
> 
> Sounds like another plan here, which sounds great.
> 
> 
> Can you clarify what must be done by upstream manifests?

The OpenStack should be deployed from upstream packages with the
help of upstream puppet modules instead of forks in Fuel library, we
should go a bit further in acceptance criteria, that is that I mean.

-- 
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando