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
* we are not able to validate each module
you have Puppetfile
and our own patches as patches to tar
* 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
And yes, dropping single package and creating metapackage is the way to
go.
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