[Rdo-list] OPM downstream patches

[Gabriele Cerami]

On Tue, 2016-01-12 at 13:16 -0500, Emilien Macchi wrote:
> I have 2 proposals, maybe wrong but I wanted to share.
> 
> Solution #1 - Forks + Puppetfile
> 
> * Forking all our Puppet modules in 
> https://github.com/redhat-openstack/
> * Apply our custom patches in a specific branch for each module
> * Create a Puppetfile per RDO/OSP version that track SHA1 from repos
> * Create a script (with r10k for example) that checkout all modules
> and
> build RPM.
> 
> Solution #2 - Forks + one RPM per module
> * Forking all our Puppet modules in 
> https://github.com/redhat-openstack/
> * Apply our custom patches in a specific branch for each module
> * Create a RPM for each module

All upstream modules are already forked in 
https://github.com/rdo-puppet-modules, not under redhat-openstack
because of the way gerrithub deals with github replication.

Modules are forked, because of the way opm has been handled until now.

Here are some informations on these modules, and how CI handles them.

- Each fork branch {branch} is an exact and automatically updated copy
of upstream module branch {branch}
- Each fork may contain a {branch}-patches to host all the patches for
the branch {branch}
- Each fork is updated after every upstream change is submitted, and
after testing every time the result of the merge between {branch} and
{branch}-patches on a centos+rdo environment. From this successful and
tested merge, a {branch}-tag branch is updated, and can be taken to be
packaged.

So, in a way we already have the first two points of every proposal.
{branch}-patches for the modules should be populated with all the
needed patches though, but to do this it should be enough to propose
the patches as reviews in gerrithub for the corresponding project, on
the branch {branch}-patches. CI should do the rest (test merge with
{branch}, test results and update {branch}-tag, then submit)

Raw material is there and available for whatever packaging solution is
preferred, but I think at this point, one RPM per module with maybe a
metapackage to rule them all is the best solution, now that modules
update is automated.