On 03/03/2017 12:42 PM, Fabien Boucher wrote: > Hi, > > Le 03/03/2017 à 12:20, Javier Pena a écrit : >> >> >> ----- Original Message ----- >>> Hi >>> >>> Le 27/02/2017 à 17:50, Fabien Boucher a écrit : >>>> Hello, >>>> >>>> As we have started the effort to have all components, bundled in the SF >>>> image, packaged >>>> we are figuring out that EPEL and RDO repo are helpful as a bunch of >>>> dependencies are >>>> available there. Unfortunately on a SF installation if yum is freely usable >>>> then >>>> an operator can break its SF deployment if EPEL or RDO lands something that >>>> break >>>> an ABI. >>>> >>>> Usually it should not happen with EPEL as explain in the upgrade policy: >>>> https://fedoraproject.org/wiki/EPEL_Updates_Policy >>>> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies >>>> >>>> RDO have stable releases that should not introduce ABI breakages over the >>>> time. >>>> >>>> Relying on both EPEL and RDO can increase the risk so it may be better to >>>> only >>>> rely on one of them and RDO includes stuff we care about like olso, >>>> openstack clients ... (+ a lot of pkg from EPEL) so better to only rely on >>>> RDO IMO. >>>>
Agreed, and there is also optools that we should start consuming for ELK and monitoring. Moreover this enables an extra layer of testing for those SIGs which sounds like a bigger deal imo. >>>> Also there's the solution of only relying on base centos managing the >>>> deps by ourself but the work seems quite huge for a small team ... ? >>> This would requires quite some micro managing, in particular for security issues... Not sure that is worthy compared to fixing/pinning if/when things break :) >>> What about, in that case, having the distro.yaml file that describes the >>> SRPM >>> list >>> like : >>> >>> extra-srpms: >>> - >>> >>> http://cbs.centos.org/kojifiles/packages/python-pecan/1.1.2/1.el7/noarch/python2-pecan-1.1.2-1.el7.noarch.rpm >>> - >>> >>> http://cbs.centos.org/kojifiles/packages/python-oslo-policy/1.18.0/1.el7/src/python-oslo-policy-1.18.0-1.el7.src.rpm >>> - ... >>> >>> That way we will have a self-sufficient SF RPM repo, like RDO where only >>> base >>> and update centos >>> repo are needed. >>> Having the few bits we use from epel listed as extra-srpms sounds like a good idea, like that we avoid duplicate dependencies already provided by rdo. Also note that dependencies we packaged should be proposed in epel and then simply listed as extra-srpms too, so that we only keep distgit that are core to sf. -Tristan >>> We will need to take care of also adding the Build and Runtime deps for what >>> we include in extra-srpms. >>> >>> A job, well a script, must fetch the srpms and build them in the specific >>> target. If a srpms is already >>> referenced in the target simply skip. If one has change (version changed) >>> then: >>> - koji remove-pkg >>> - koji build >> >> I think this would work fine. I'm only concerned at how long will the srpm >> files stay in CBS, do you know if they are purged when they are old? >> >> Javier > > Good question. This can be a blocker if a target need to be rebuilt later. > I just checked on cbs and koji.fedoraproject.org and: > > As id are incremental > > http://cbs.centos.org/koji/buildinfo?buildID=10 > https://koji.fedoraproject.org/koji/buildinfo?buildID=10 > > Both have a working srpm link. The latter is a task of 2007. > So I guess by default there isn't any policies for cleaning them. > > Fabien > >>> >>>> Also after discussing with Nico it can be safer to only enable >>>> centos-update and >>>> sf RPM repos and disable the rest at the end of the built of the image to >>>> avoid eventual unexpected pkg bumps from RDO or even EPEL according to our >>>> choice. >>>> >>>> Cheers, >>>> Fabien >>>> >>> >>> _______________________________________________ >>> Softwarefactory-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/softwarefactory-dev >>> > > _______________________________________________ > Softwarefactory-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/softwarefactory-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
