Happy to share my opinions on this as well.
My most compelling motivator for this (and it should serve multiple interests) is to be able to build based off an upstream patch and include it in a live deployment in OPNFV. Reducing that turnaround time to minutes from pushing a source patch and have the OPNFV CI running a job to validate it would be awesome. Requires us to be able to package up the desired components or pull from a source packager that will fulfill our needs which are not available/integrated currently… / Chris From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of Alexandru Avadanii <alexandru.avada...@enea.com> Date: Sunday 25 September 2016 at 15:19 To: Luke Hinds <lhi...@redhat.com> Cc: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] OPNFV Packaging CI Hi, Luke, My experience so far included mostly DEB packages, which fell in 3 categories for Armband: - Backported from newer distro (lots of Ubuntu Xenial arm64 DEBs backported to Trusty) - Patched until upstream pulls our fixes (lshw is a good example, it’s broken in all arm64 Ubuntus - all distros) - Divergent functionality (we roll our own grub2, based on an Ubuntu pacakge, but with added patches from Fedora and OpenSUSE – it’s hard to fiind a grub2 package that satifies all conditions for integrating with our Cobbler integration approach) As for RPMs, we built only 2 custom packages, which I’m sure won’t be upstreamed soon: - qemu-user-static for CentOS7 (implied building some static libs as well, including libc), which is used by Fuel to cross-build images (e.g. arm64 chroots on a x86 machine); - cobbler-grub-aarch64 (contains a single EFI-compatible arm64 binary of grub2-efi-arm64 standalone, used by cobbler as the netloader of choice for Armband) In my opinion, handlng the above by hand or using obscure external procedures (most Fuel plugins build some DEBs and/or RPMs, each in a different way) is prone to error and code duplication over time. Also, and maybe I should have started with this, consider the case where the ISO build process is tied to x86 (like Fuel currently is), and the artifacts are expected to contain packages for different architectures (AArch64?), which cannot be locally built [easily], in which case fetching some precompiled packages from an OPNFV public repo would be nice. BR, Alex From: Luke Hinds [mailto:lhi...@redhat.com] Sent: Sunday, September 25, 2016 11:51 AM To: Alexandru Avadanii Cc: opnfv-tech-discuss@lists.opnfv.org Subject: Re: [opnfv-tech-discuss] OPNFV Packaging CI Hi Alex, What constitutes CI? If you could give one specific case of what you see as needing packaging, that would be useful. Cheers, Luke On Fri, Sep 23, 2016 at 6:07 PM, Alexandru Avadanii <alexandru.avada...@enea.com> wrote: Hi, I started a very small etherpad for gathering ideas about packaging CI in OPNFV, see [1]. I am aware our purpose is upstreaming our changes, but this is not always possible or effective, hence the need for some form of our own package distribution systems. Hopefully, this could be a nice addition, and not something encouraging spinning distro forks of CentOS/Ubuntu etc. Looking forward to your thoughts on this one. BR, Alex [1] https://etherpad.openstack.org/p/OPNFV_packaging_CI _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss -- Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat e: lhi...@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44 12 52 36 2483 _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
