Open Stack

On 15.06.2015 13:59, Bogdan Dobrelya wrote:
> 
> I believe as a first steep, the contribution policy to Fuel library

Sorry, the step, it is not so steep.

> 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
> 

And the second step, as I can see it, is for Fuel build system to be
switched on upstream puppet modules plus custom patches - as it was
suggested above in this mail-thread. The similar way we do for the
fuel-library6.1 package by related bp [0].

Fuel library components should be bundled as packages, like
fuel-puppet-nova, fuel-puppet-neutron and so on. These packages should
be build from upstream repositories of corresponding release branches.
All custom changes in Fuel library should be applied atop of these
builds and be maintained (rebase, if build failed) by Fuel dev team,
until got contributed upstream and removed from custom patches. Here is
related blueprint for this step [1]

[0] https://blueprints.launchpad.net/fuel/+spec/package-fuel-components
[1]
https://blueprints.launchpad.net/fuel/+spec/build-fuel-library-from-upstream

> 
> 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