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 :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel