[Rdo-list] OPM downstream patches

Emilien Macchi emilien at redhat.com
Tue Jan 12 21:53:30 UTC 2016



On 01/12/2016 01:16 PM, Emilien Macchi wrote:
> Also, the way we're packaging OPM is really bad.
> 
> * we have no SHA1 for each module we have in OPM
> * we are not able to validate each module
> * package tarball is not pure. All other OpenStack RPMS take upstream
> tarball so we can easily compare but in OPM... no way to do it.
> 
> Those issues are really critical, I would like to hear from OPM folks,
> and find solutions that we will work on during the following weeks.

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

Of course, I don't take in consideration CI work so I'm willing to
suggestions.

Feedback is welcome here!

> Thanks
> 
> On 01/12/2016 12:37 PM, Emilien Macchi wrote:
>> So I started an etherpad to discuss why we have so much downstream
>> patches in Puppet modules.
>>
>> https://etherpad.openstack.org/p/opm-patches
>>
>> In my opinion, we should follow some best practices:
>>
>> * upstream first. If you find a bug, submit the patch upstream, wait for
>> at least a positive review from a core and also successful CI jobs. Then
>> you can backport it downstream if urgent.
>> * backport it to stable branches when needed. The patch we want is in
>> master and not stable? It's too easy to backport it in OPM. Do the
>> backport in upstream/stable first, it will help to stay updated with
>> upstream.
>> * don't change default parameters, don't override them. Our installers
>> are able to override any parameter so do not hardcode this kind of change.
>> * keep up with upstream: if you have an upstream patch under review that
>> is already in OPM: keep it alive and make sure it lands as soon as possible.
>>
>> UPSTREAM FIRST please please please (I'll send you cookies if you want).
>>
>> If you have any question about an upstream patch, please join
>> #puppet-openstack (freenode) and talk to the group. We're doing reviews
>> every day and it's not difficult to land a patch.
>>
>> In the meantime, I would like to justify each of our backports in the
>> etherpad and clean-up a maximum of them.
>>
>> Thank you for reading so far,
>>
>>
>>
>> _______________________________________________
>> Rdo-list mailing list
>> Rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>
> 
> 
> 
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscribe at redhat.com
> 

-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20160112/c9c45d1a/attachment.sig>


More information about the dev mailing list