On Mon, Jun 27, 2016 at 04:54:35PM +0100, Ian Jackson wrote:
> (Adding Jan Beulich)
>
> Ian Jackson writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver
> breakage -- where to define LIBXL_API_VERSION?"):
> > It seems that the libvirt LIBXL_API_VERSION is now rather higher, at
> > 0x040400, since libvirt#fccf27253ced
> > libxl: switch to using libxl_domain_create_restore from v4.4 API
> >
> > One unfortunate effect of this is to break the osstest tests of the
> > Xen 4.3 stable branch, which for the moment is still allegedly in
> > security support.
> >
> > I can't really see a way that this kind of problem could be avoided
> > in principle, without
> > - providing a more sophisticated way for libxl callers to set the
> > requested version
> > - providing more compatibility code in libvirt, too, and retaining
> > it for some time
> >
> > I think instead that it would probably be better for osstest to
> > "freeze" the version of libvirt that it is using, every time we branch
> > Xen.
> >
> > So Xen 4.4 would be tested with whatever libvirt we were using when
> > the stable branch for Xen 4.4 was made, and so on.
> >
> > Does that sound sensible ?
>
> In the assumption that it is, I have:
>
> Created the following branch refs on xenbits in the toplevel
> libvirt.git:
>
> osstest/frozen/xen-4.3-testing 9a0c7f5f834185db9017c34aabc03ad99cf37bed
> osstest/frozen/xen-4.4-testing 33fb8ff185846a7b4974105d2c9400690a6f95cf
> osstest/frozen/xen-4.5-testing cda1cc170f07b45911b3dad03e42c8ebfc210fa1
> osstest/frozen/xen-4.6-testing eac167e2610d3e59b32f7ec7ba78cbc8c420a425
> osstest/frozen/xen-4.7-testing 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc
How did you pick those hashes ? Would it make more sense to pick the
nearest libvirt release tag ? eg v1.3.2 instead of 33fb8ff18584 ?
>
> These were those tested by the following `tolerable' osstest push gate
> flights for the corresponding Xen tree:
>
> xen-4.3-testing 9a0c7f5f8341 86673
> xen-4.4-testing 33fb8ff18584 85031
> xen-4.5-testing cda1cc170f07 83135
> xen-4.6-testing eac167e2610d 96031
> xen-4.7-testing 1a41ed5af5e1 95728
>
> And I have prepared the patch below, which (together with a
> prerequisite, in my tree) will implement this in osstest.
>
> Ian.
>
> From 5d1c91d3c53b580305e96d62f8ca84f85f8d3011 Mon Sep 17 00:00:00 2001
> From: Ian Jackson <ian.jack...@eu.citrix.com>
> Date: Mon, 27 Jun 2016 16:49:52 +0100
> Subject: [OSSTEST PATCH] cr-daily-branch: libvirt: use frozen version on
> stable branches
>
> libvirt master might increase its LIBXL_API_VERSION. When this feeds
> through osstest it can cause the push gates of Xen stable branches to
> break.
>
> So for stable Xen branches do not track libvirt upstream. Instead,
> use a frozen revision. (Only for main push gate tests of stable Xen
> branches.)
>
> The frozen branch is never going to be updated so it is not suitable
> for other kinds of uses. In particular it won't get security fixes.
> So we call the refs osstest/frozen/xen-K.L-testing to discourage
> users from using them.
>
> Deployment note: The Xen release checklist needs a new item "add this
> frozen libvirt branch".
>
> Signed-off-by: Ian Jackson <ian.jack...@eu.citrix.com>
> ---
> cr-daily-branch | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/cr-daily-branch b/cr-daily-branch
> index 8b7c789..21780b8 100755
> --- a/cr-daily-branch
> +++ b/cr-daily-branch
> @@ -186,6 +186,12 @@ if [ "x$REVISION_OVMF" = x ]; then
> fi
> fi
> if [ "x$REVISION_LIBVIRT" = x ]; then
> + case "$xenbranch" in
> + xen-[0-9]*-testing)
> + BASE_TAG_LIBVIRT=osstest/frozen/$xenbranch
> + export BASE_TAG_LIBVIRT
> + ;;
> + esac
> determine_version REVISION_LIBVIRT libvirt LIBVIRT
> export REVISION_LIBVIRT
> fi
Overall I think your approach makes sense.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
