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