[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