On 01/13/2016 11:36 AM, Lukas Bezdicka wrote:
On Tue, 2016-01-12 at 13:16 -0500, Emilien Macchi wrote:
> Also, the way we're packaging OPM is really bad.
>
> * we have no SHA1 for each module we have in OPM
/usr/share/openstack-puppet/Puppetfile
Nope, this file is not containing SHA1 for the actual modules we have in
OPM. This file was used (and is 100% useless now) by SpinalStack.
> * we are not able to validate each module
you have Puppetfile and our own patches as patches to tar
No, see my previous comment.
> * 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.
Tarballs are always taken from github releases:
https://github.com/redhat-openstack/openstack-puppet-modules/releases
You can't pull a tarball per module. Modules have been introduced by a
RAW copy-paste.
And yes, dropping single package and creating metapackage is the way
to
go.
I would like to see a more constructive reply from people actually
authors on OPM.
We want to build a plan for the future release that will radically
change the way we build & ship OPM.
>
> 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.
>
> 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(a)redhat.com
>>
https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
>>
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
--
Emilien Macchi