[Rdo-list] OPM downstream patches

[Jason Guiditta]

On 14/01/16 01:54 +0100, Gabriele Cerami wrote:
>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}
I could be wrong, but I think this is consistent with what opm _used_
to do, which itself was _inconsistent_ with the rest of rdo (not sure
how, or if this relates to pure upstream).  So, for liberty, for
example, we have upstream-liberty, which is _exactly_ what was in
stable/liberty for the various openstack puppet modules at the time of
the last (yes, manual) sync.  Then we (opm) have stable/liberty, which
has everything from upstream-liberty, with whatever patches have been
added on top of  it.  If I am correct that is needed for rdo, but
inconsistent with what you have described, how hard would it be to
alter the rdo-puppet-modules stuff to work with the new reality?

>- 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.
>
+1000 to individual packages, and opm as metapackage only.

-j