We are building with GnuTLS everywhere because GnuTLS is widely
available. Also, it is desirable to prefer cryptographically
strong PRNG over "/dev/urandom" which is just a fallback.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 configure.ac      | 2 --
 m4/virt-gnutls.m4 | 4 ----
 2 files changed, 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5378e49c0b..e25bf0a6ec 100644
--- a/configure.ac
+++ b/configure.ac
@@ -216,7 +216,6 @@ fi
 # RPC, we don't need several libraries.
 if test "$with_remote" = "no" ; then
   with_libvirtd=no
-  with_gnutls=no
   with_ssh2=no
   with_sasl=no
   with_libssh=no
@@ -250,7 +249,6 @@ LIBVIRT_ARG_DBUS
 LIBVIRT_ARG_FIREWALLD
 LIBVIRT_ARG_FUSE
 LIBVIRT_ARG_GLUSTER
-LIBVIRT_ARG_GNUTLS
 LIBVIRT_ARG_HAL
 LIBVIRT_ARG_LIBPCAP
 LIBVIRT_ARG_LIBSSH
diff --git a/m4/virt-gnutls.m4 b/m4/virt-gnutls.m4
index 426a1a0348..6829ca55cf 100644
--- a/m4/virt-gnutls.m4
+++ b/m4/virt-gnutls.m4
@@ -17,10 +17,6 @@ dnl License along with this library.  If not, see
 dnl <http://www.gnu.org/licenses/>.
 dnl
 
-AC_DEFUN([LIBVIRT_ARG_GNUTLS],[
-  LIBVIRT_ARG_WITH_FEATURE([GNUTLS], [gnutls], [check], [3.2.0])
-])
-
 AC_DEFUN([LIBVIRT_CHECK_GNUTLS],[
   LIBVIRT_CHECK_PKG([GNUTLS], [gnutls], [3.2.0])
 
-- 
2.16.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Jun 05, 2018 at 01:55:54PM +0200, Michal Privoznik wrote:
> We are building with GnuTLS everywhere because GnuTLS is widely
> available. Also, it is desirable to prefer cryptographically
> strong PRNG over "/dev/urandom" which is just a fallback.
> 
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>  configure.ac      | 2 --
>  m4/virt-gnutls.m4 | 4 ----
>  2 files changed, 6 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 06/05/2018 02:04 PM, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 01:55:54PM +0200, Michal Privoznik wrote:
>> We are building with GnuTLS everywhere because GnuTLS is widely
>> available. Also, it is desirable to prefer cryptographically
>> strong PRNG over "/dev/urandom" which is just a fallback.
>>
>> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
>> ---
>>  configure.ac      | 2 --
>>  m4/virt-gnutls.m4 | 4 ----
>>  2 files changed, 6 deletions(-)
> 
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Thanks, I've pushed these.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2018-06-05 at 14:38 +0200, Michal Privoznik wrote:
> On 06/05/2018 02:04 PM, Daniel P. Berrangé wrote:
> > On Tue, Jun 05, 2018 at 01:55:54PM +0200, Michal Privoznik wrote:
> > > We are building with GnuTLS everywhere because GnuTLS is widely
> > > available. Also, it is desirable to prefer cryptographically
> > > strong PRNG over "/dev/urandom" which is just a fallback.
> > > 
> > > Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> > > ---
> > >  configure.ac      | 2 --
> > >  m4/virt-gnutls.m4 | 4 ----
> > >  2 files changed, 6 deletions(-)
> > 
> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> 
> Thanks, I've pushed these.

Well, this is awkward:

  https://ci.centos.org/view/libvirt/job/libvirt-master-build-website/124/systems=libvirt-centos-6/console

We don't actually build libvirt on CentOS 6 anymore, just the
documentation and release archives, ie. what's necessary to keep
libvirt.org (which is still on that OS) running; still, after this
patch the configure step will very understandably fail, and I can't
imagine things going over much better on the actual live instance
of the website: no nightlies[1] today, I'm afraid!

I'm likewise afraid I don't have any bright ideas on how to solve
this, so any input on the matter will be very much appreciated.


[1] Assuming anyone actually uses those.
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Jun 05, 2018 at 06:50:53PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-06-05 at 14:38 +0200, Michal Privoznik wrote:
> > On 06/05/2018 02:04 PM, Daniel P. Berrangé wrote:
> > > On Tue, Jun 05, 2018 at 01:55:54PM +0200, Michal Privoznik wrote:
> > > > We are building with GnuTLS everywhere because GnuTLS is widely
> > > > available. Also, it is desirable to prefer cryptographically
> > > > strong PRNG over "/dev/urandom" which is just a fallback.
> > > > 
> > > > Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> > > > ---
> > > >  configure.ac      | 2 --
> > > >  m4/virt-gnutls.m4 | 4 ----
> > > >  2 files changed, 6 deletions(-)
> > > 
> > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> > 
> > Thanks, I've pushed these.
> 
> Well, this is awkward:
> 
>   https://ci.centos.org/view/libvirt/job/libvirt-master-build-website/124/systems=libvirt-centos-6/console
> 
> We don't actually build libvirt on CentOS 6 anymore, just the
> documentation and release archives, ie. what's necessary to keep
> libvirt.org (which is still on that OS) running; still, after this
> patch the configure step will very understandably fail, and I can't
> imagine things going over much better on the actual live instance
> of the website: no nightlies[1] today, I'm afraid!
> 
> I'm likewise afraid I don't have any bright ideas on how to solve
> this, so any input on the matter will be very much appreciated.

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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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 :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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.

Either way it seems pretty clear that we're not going to take
back making GnuTLS mandatory (neither I think we should), so the
CI job running on CentOS 6 is entirely useless now. I'll post
patches to get rid of it.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, Jun 06, 2018 at 11:44:37 +0200, 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.

Well, so we need to be able to run configure so that we can create
makefiles which build the docs.

If we extract the steps to build the docs from makefile into a
standalone script called by the makefile we still can build the web
without the need to configure everything.

Doing containers and stuff seems to be quite a waste just to process
some html files.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, 2018-06-06 at 11:54 +0200, Peter Krempa wrote:
> Well, so we need to be able to run configure so that we can create
> makefiles which build the docs.
> 
> If we extract the steps to build the docs from makefile into a
> standalone script called by the makefile we still can build the web
> without the need to configure everything.
> 
> Doing containers and stuff seems to be quite a waste just to process
> some html files.

We also need to be able to run 'make dist' in order to produce
nightly snapshots.

Whether those are actually useful to anyone in $currentyear is of
course up for debate, but as long as we need to produce them then
we can't really get away with a standalone script.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, Jun 06, 2018 at 12:05:28PM +0200, Andrea Bolognani wrote:
> On Wed, 2018-06-06 at 11:54 +0200, Peter Krempa wrote:
> > Well, so we need to be able to run configure so that we can create
> > makefiles which build the docs.
> > 
> > If we extract the steps to build the docs from makefile into a
> > standalone script called by the makefile we still can build the web
> > without the need to configure everything.
> > 
> > Doing containers and stuff seems to be quite a waste just to process
> > some html files.
> 
> We also need to be able to run 'make dist' in order to produce
> nightly snapshots.
> 
> Whether those are actually useful to anyone in $currentyear is of
> course up for debate, but as long as we need to produce them then
> we can't really get away with a standalone script.

We could perhaps just utilize jenkins for creating the nightly
snapshots ?  IIUC, you can publish artifacts from builds, so
we could have a job building a dist and publish that. Even without
the GNULTS/CentOS6 problem I thnk using jenkins would be a better
approach that a cronjob shell script, as we know exactly what
environment we'd be creating the dist in.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, 2018-06-06 at 11:20 +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 06, 2018 at 12:05:28PM +0200, Andrea Bolognani wrote:
> > We also need to be able to run 'make dist' in order to produce
> > nightly snapshots.
> > 
> > Whether those are actually useful to anyone in $currentyear is of
> > course up for debate, but as long as we need to produce them then
> > we can't really get away with a standalone script.
> 
> We could perhaps just utilize jenkins for creating the nightly
> snapshots ?  IIUC, you can publish artifacts from builds, so
> we could have a job building a dist and publish that. Even without
> the GNULTS/CentOS6 problem I thnk using jenkins would be a better
> approach that a cronjob shell script, as we know exactly what
> environment we'd be creating the dist in.

So we'd have a cron task on libvirt.org fetching the latest archive
from Jenkins every hour? Or would we just point people to Jenkins
directly? Either look feasible, but the latter would cause the URL
to change.

Note that we're currently only publishing hourly snapshots for
libvirt itself, not for any of the dozen plus projects that are
hosted on libvirt.org alongside it. Doesn't that kinda show that
they're not that useful after all?  Do we have download statistics
proving people actually care about them?

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, Jun 06, 2018 at 11:54:41AM +0200, Peter Krempa wrote:
> On Wed, Jun 06, 2018 at 11:44:37 +0200, 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.
> 
> Well, so we need to be able to run configure so that we can create
> makefiles which build the docs.
> 
> If we extract the steps to build the docs from makefile into a
> standalone script called by the makefile we still can build the web
> without the need to configure everything.

Yeah, we could try to create a sepearate Makefile.inc that
holds the website build pieces, and include that from the main
automake generated Makefile.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, 2018-06-06 at 11:21 +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 06, 2018 at 11:54:41AM +0200, Peter Krempa wrote:
> > If we extract the steps to build the docs from makefile into a
> > standalone script called by the makefile we still can build the web
> > without the need to configure everything.
> 
> Yeah, we could try to create a sepearate Makefile.inc that
> holds the website build pieces, and include that from the main
> automake generated Makefile.

We'd lose the ability to use autotools features, though.

Another thing to keep in mind is that moving the website build to
a CentOS 7 container would allow us to remove the last remnants
of CentOS 6 support from libvirt-jenkins-ci.git and delete the
corresponding virtual machine from the CentOS CI environment,
freeing up resources for other tasks.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, 2018-06-06 at 12:45 +0200, Andrea Bolognani wrote:
> Another thing to keep in mind is that moving the website build to
> a CentOS 7 container would allow us to remove the last remnants
> of CentOS 6 support from libvirt-jenkins-ci.git and delete the
> corresponding virtual machine from the CentOS CI environment,
> freeing up resources for other tasks.

I've started building Docker containers with all libvirt build
dependencies already installed[1], mainly for use in Travis CI;
the CentOS 7 container could easily be used to also solve the
issue at hand.

I've already tried building libvirt inside said container on a
CentOS 6 host running Docker from EPEL without encountering any
issue; all that's left to do is install Docker on libvirt.org
and script the integration, which shouldn't be too difficult.

Does that sound like a sensible way forward?


[1] https://www.redhat.com/archives/libvir-list/2018-June/msg00920.html
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Jun 12, 2018 at 12:24:14PM +0200, Andrea Bolognani wrote:
> On Wed, 2018-06-06 at 12:45 +0200, Andrea Bolognani wrote:
> > Another thing to keep in mind is that moving the website build to
> > a CentOS 7 container would allow us to remove the last remnants
> > of CentOS 6 support from libvirt-jenkins-ci.git and delete the
> > corresponding virtual machine from the CentOS CI environment,
> > freeing up resources for other tasks.
> 
> I've started building Docker containers with all libvirt build
> dependencies already installed[1], mainly for use in Travis CI;
> the CentOS 7 container could easily be used to also solve the
> issue at hand.
> 
> I've already tried building libvirt inside said container on a
> CentOS 6 host running Docker from EPEL without encountering any
> issue; all that's left to do is install Docker on libvirt.org
> and script the integration, which shouldn't be too difficult.
> 
> Does that sound like a sensible way forward?

AFAIK, Docker is explicitly unsupported on CentOS 6 now.

  https://github.com/moby/moby/issues/14365

I was actually intending to take a simpler approach - just compile a
newer gnutls into /opt and let the website build use that.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2018-06-12 at 11:41 +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 12, 2018 at 12:24:14PM +0200, Andrea Bolognani wrote:
> > I've started building Docker containers with all libvirt build
> > dependencies already installed[1], mainly for use in Travis CI;
> > the CentOS 7 container could easily be used to also solve the
> > issue at hand.
> > 
> > I've already tried building libvirt inside said container on a
> > CentOS 6 host running Docker from EPEL without encountering any
> > issue; all that's left to do is install Docker on libvirt.org
> > and script the integration, which shouldn't be too difficult.
> > 
> > Does that sound like a sensible way forward?
> 
> AFAIK, Docker is explicitly unsupported on CentOS 6 now.
> 
>   https://github.com/moby/moby/issues/14365

Yeah, the Docker version available in CentOS 6 EPEL is fairly old
and I doubt it's getting a lot of updates these days.

That said, we would be using it exclusively with images we've
crafted ourselves starting from official (and thus arguably
trustworthy) base images, and only to run build jobs locally, so
I'm not sure there's much to be concerned about security-wise.

> I was actually intending to take a simpler approach - just compile a
> newer gnutls into /opt and let the website build use that.

Sure, that would probably do the trick as far as libvirt.org itself
is concerned; however, we would not only have to keep CentOS 6
around in the CentOS CI environment, but also figure out a way to
reproduce the same hack there if we want to make sure changes in
libvirt don't accidentally break building the website.

That doesn't sound too attractive overall, and more specifically
I'm not sure it would be much better than running an unsupported
Docker version.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Jun 12, 2018 at 01:26:05PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-06-12 at 11:41 +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 12, 2018 at 12:24:14PM +0200, Andrea Bolognani wrote:
> > > I've started building Docker containers with all libvirt build
> > > dependencies already installed[1], mainly for use in Travis CI;
> > > the CentOS 7 container could easily be used to also solve the
> > > issue at hand.
> > > 
> > > I've already tried building libvirt inside said container on a
> > > CentOS 6 host running Docker from EPEL without encountering any
> > > issue; all that's left to do is install Docker on libvirt.org
> > > and script the integration, which shouldn't be too difficult.
> > > 
> > > Does that sound like a sensible way forward?
> > 
> > AFAIK, Docker is explicitly unsupported on CentOS 6 now.
> > 
> >   https://github.com/moby/moby/issues/14365
> 
> Yeah, the Docker version available in CentOS 6 EPEL is fairly old
> and I doubt it's getting a lot of updates these days.
> 
> That said, we would be using it exclusively with images we've
> crafted ourselves starting from official (and thus arguably
> trustworthy) base images, and only to run build jobs locally, so
> I'm not sure there's much to be concerned about security-wise.
> 
> > I was actually intending to take a simpler approach - just compile a
> > newer gnutls into /opt and let the website build use that.
> 
> Sure, that would probably do the trick as far as libvirt.org itself
> is concerned; however, we would not only have to keep CentOS 6
> around in the CentOS CI environment, but also figure out a way to
> reproduce the same hack there if we want to make sure changes in
> libvirt don't accidentally break building the website.

I'd just drop the CI job and we'll deal with problems with the
website build if and when we find them

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2018-06-12 at 13:22 +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 12, 2018 at 01:26:05PM +0200, Andrea Bolognani wrote:
> > > I was actually intending to take a simpler approach - just compile a
> > > newer gnutls into /opt and let the website build use that.
> > 
> > Sure, that would probably do the trick as far as libvirt.org itself
> > is concerned; however, we would not only have to keep CentOS 6
> > around in the CentOS CI environment, but also figure out a way to
> > reproduce the same hack there if we want to make sure changes in
> > libvirt don't accidentally break building the website.
> 
> I'd just drop the CI job and we'll deal with problems with the
> website build if and when we find them

In that case, going for the local GnuTLS build on libvirt.org is
perfectly fine with me.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, 2018-06-06 at 12:51 +0200, Michal Privoznik wrote:
> On 06/06/2018 11:44 AM, Andrea Bolognani wrote:
> > 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.

Of course it is. We're talking stop-gap measures here :)

> 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.

If that doesn't end up looking *too* disgusting it's certainly
a possiblity.

I still like the container route better because, as mentioned
elsewhere in the thread, it would allow us to drop CentOS 6
entirely from the CI environment.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list