On 06/06/2018 11:44 AM, Andrea Bolognani wrote: > On Wed, 2018-06-06 at 09:45 +0100, Daniel P. Berrangé wrote: >> On Wed, Jun 06, 2018 at 08:24:59AM +0200, Andrea Bolognani wrote: >>> On Tue, 2018-06-05 at 18:03 +0100, Daniel P. Berrangé wrote: >>>> We can't use docker on centos6 either and believe it or not the host >>>> doesn't have hardware virt either. >>>> >>>> I could possibly setup libvirt lxc to run the jobs though. >>> >>> I believe running build jobs on libvirt.org in a CentOS 7 container >>> was one of the approaches I mentioned when we initially discussed >>> dropping CentOS 6 support, so if you could make that happen it >>> would certainly be okay with me :) >> >> A more radical option would be to move libvirt.org off onto openshift, >> but that comes with the complexity that I'd need to transparently >> proxy back to real libvirt.org to make /git and /sources URLs continue >> to work > > As long as we need to keep the current box running any part of > libvirt.org, that looks like it would only increase complexity. > > The lxc route sounds like a decent stop-gap measure until either > the current box is upgraded or everything is moved off to a new > box running CentOS 7, whenever that might be. I think this is actually the right solution. To either upgrade old box to CentOS 7 or to move to new box running it. Another idea that I had was to not require GnuTLS-3.2.0 every time. I mean, what are the reasons we want GnuTLS? For better TLS in general (where it makes sense to require 3.2.0 or newer) and for PRNG (where 1.2.0 or what is it that CentOS 6 has is sufficient). So what I am suggesting is loosen the minimal requirement to whatever version CentOS 6 has unless remote/qemu drivers are built in which case 3.2.0 or newer is required. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
