Re: [opnfv-tech-discuss] OPNFV Packaging CI

2016-09-27 Thread Alexandru Avadanii 
Hi, Luke, Leif,

Thank you for your feedback!



I do not have any preferences towards the method we use, if we can use 
something as-is, I'm all for it.

I was not aware of COPR, but I'll try to get up to speed and add it to the 
etherpad.



As for PPA, that is an interesting approach I haven’t thought about … any 
thoughts on using a private PPA for each OPNFV project?

Ideally, end-users should also be able to submit fixes/patches that we can 
easily check into our packaging source tree – not sure PPA fits very well this 
requirement (?).



If you have any other suggestions for a DEB alternative, I really want to hear 
them, so far the most interesting solution would be Perestroika from Mirantis, 
shipped as part of Fuel@OPNFV.

So far, we used git-buildpackage and custom scripts for DEB building, but that 
is neither easy to maintain, nor is it an integrated, ready-to-use solution.



BR,

Alex


From: Luke Hinds [mailto:lhi...@redhat.com]
Sent: Tuesday, September 27, 2016 1:20 PM
To: Leif Madsen
Cc: Alexandru Avadanii; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] OPNFV Packaging CI



On Tue, Sep 27, 2016 at 1:55 AM, Leif Madsen 
<lmad...@redhat.com<mailto:lmad...@redhat.com>> wrote:
On Sun, Sep 25, 2016 at 01:19:21PM +, Alexandru Avadanii wrote:
> 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.

Do you have a particular method in mind here? I think my biggest
issue would be around building yet another system to build packages. For
example, for RPMs, it would be almost trivial to employ the COPR build
system and host any custom packages in that namespace.

What I would hate to see, would be a set of custom scripts or
applications to build packages, and then host them within the OPNFV
namespace, along with having to maintain that whole pipeline.

I assume there is some sort of DEB equivalent of COPR where those
packages could be hosted, and packages build on a remote service?

There is PPA ():

https://help.launchpad.net/Packaging/PPA


--
Leif Madsen | Partner Engineer - NFV & CI
NFV Partner Engineering
Red Hat
GPG: (D670F846) BEE0 336E 5406 42BA 6194 6831 B38A 291E D670 F846


___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] OPNFV Packaging CI

2016-09-27 Thread Luke Hinds 
On Tue, Sep 27, 2016 at 1:55 AM, Leif Madsen  wrote:

> On Sun, Sep 25, 2016 at 01:19:21PM +, Alexandru Avadanii wrote:
> > 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.
>
> Do you have a particular method in mind here? I think my biggest
> issue would be around building yet another system to build packages. For
> example, for RPMs, it would be almost trivial to employ the COPR build
> system and host any custom packages in that namespace.
>
> What I would hate to see, would be a set of custom scripts or
> applications to build packages, and then host them within the OPNFV
> namespace, along with having to maintain that whole pipeline.
>
> I assume there is some sort of DEB equivalent of COPR where those
> packages could be hosted, and packages build on a remote service?
>
>
There is PPA ():

https://help.launchpad.net/Packaging/PPA



> --
> Leif Madsen | Partner Engineer - NFV & CI
> NFV Partner Engineering
> Red Hat
> GPG: (D670F846) BEE0 336E 5406 42BA 6194 6831 B38A 291E D670 F846
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] OPNFV Packaging CI

2016-09-26 Thread Leif Madsen 
On Sun, Sep 25, 2016 at 01:19:21PM +, Alexandru Avadanii wrote:
> 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.

Do you have a particular method in mind here? I think my biggest
issue would be around building yet another system to build packages. For
example, for RPMs, it would be almost trivial to employ the COPR build
system and host any custom packages in that namespace.

What I would hate to see, would be a set of custom scripts or
applications to build packages, and then host them within the OPNFV
namespace, along with having to maintain that whole pipeline.

I assume there is some sort of DEB equivalent of COPR where those
packages could be hosted, and packages build on a remote service?

-- 
Leif Madsen | Partner Engineer - NFV & CI
NFV Partner Engineering
Red Hat
GPG: (D670F846) BEE0 336E 5406 42BA 6194 6831 B38A 291E D670 F846
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] OPNFV Packaging CI

2016-09-25 Thread Alexandru Avadanii 
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<mailto: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<mailto: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<mailto: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] OPNFV Packaging CI

2016-09-23 Thread Alexandru Avadanii 
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