| Message ID | 22385.19515.932317.523181@mariner.uk.xensource.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.jackson@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.Jackson@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
Daniel P. Berrange writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"):
> On Mon, Jun 27, 2016 at 04:54:35PM +0100, Ian Jackson wrote:
> > 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
I picked them by searching my mail archives for osstest `tolerable'
push gate flights - ie, passes in our CI system.
That minimises the risk that the selected versions are themselves
troublesome for some reason, needing another round of adjustment.
It might indeed be better to convert them to nearby release tags.
However:
mariner:libvirt> git-describe 9a0c7f5f834185db9017c34aabc03ad99cf37bed
v1.3.2-202-g9a0c7f5
mariner:libvirt> git-describe 33fb8ff185846a7b4974105d2c9400690a6f95cf
v1.3.2-rc2-1-g33fb8ff
mariner:libvirt> git-describe cda1cc170f07b45911b3dad03e42c8ebfc210fa1
v1.3.1-262-gcda1cc1
mariner:libvirt> git-describe eac167e2610d3e59b32f7ec7ba78cbc8c420a425
v1.3.5-318-geac167e
mariner:libvirt> git-describe 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc
v1.3.5-129-g1a41ed5
mariner:libvirt>
So in most cases these hashes are well away from a release tag.
Does libvirt have stable release branches ? One approach would be to
have osstest track a suitable libvirt stable release branche for each
Xen stable release branch.
That would involve setting up a push gate for each of the chosen
libvirt stable branches. That would be worthwhile if we expect those
stable branches to acquire commits which break Xen, and which we could
like to be told about. But I'm not sure that's the case.
Ian.
On Mon, Jun 27, 2016 at 05:12:52PM +0100, Ian Jackson wrote: > Daniel P. Berrange writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"): > > On Mon, Jun 27, 2016 at 04:54:35PM +0100, Ian Jackson wrote: > > > 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 > > I picked them by searching my mail archives for osstest `tolerable' > push gate flights - ie, passes in our CI system. > > That minimises the risk that the selected versions are themselves > troublesome for some reason, needing another round of adjustment. > > It might indeed be better to convert them to nearby release tags. > However: > > mariner:libvirt> git-describe 9a0c7f5f834185db9017c34aabc03ad99cf37bed > v1.3.2-202-g9a0c7f5 > mariner:libvirt> git-describe 33fb8ff185846a7b4974105d2c9400690a6f95cf > v1.3.2-rc2-1-g33fb8ff > mariner:libvirt> git-describe cda1cc170f07b45911b3dad03e42c8ebfc210fa1 > v1.3.1-262-gcda1cc1 > mariner:libvirt> git-describe eac167e2610d3e59b32f7ec7ba78cbc8c420a425 > v1.3.5-318-geac167e > mariner:libvirt> git-describe 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc > v1.3.5-129-g1a41ed5 > mariner:libvirt> > > So in most cases these hashes are well away from a release tag. > > Does libvirt have stable release branches ? One approach would be to > have osstest track a suitable libvirt stable release branche for each > Xen stable release branch. Yep, there is a vN.N.N-maint branch for every release NB, with our new numbering that'll be changing nto vN.N-maint instead. > That would involve setting up a push gate for each of the chosen > libvirt stable branches. That would be worthwhile if we expect those > stable branches to acquire commits which break Xen, and which we could > like to be told about. But I'm not sure that's the case. Stuff goes onto the stable branches on an as-needed basis - mostly coming from the distro maintainers response to bug fixes from their users. There's probably not a whole lot that's touching xen on a regular basis and we're quite strict in what we accept for stable. Regards, Daniel
On 06/27/2016 10:12 AM, Ian Jackson wrote: > Daniel P. Berrange writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"): >> On Mon, Jun 27, 2016 at 04:54:35PM +0100, Ian Jackson wrote: >>> 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 > I picked them by searching my mail archives for osstest `tolerable' > push gate flights - ie, passes in our CI system. > > That minimises the risk that the selected versions are themselves > troublesome for some reason, needing another round of adjustment. > > It might indeed be better to convert them to nearby release tags. > However: > > mariner:libvirt> git-describe 9a0c7f5f834185db9017c34aabc03ad99cf37bed > v1.3.2-202-g9a0c7f5 > mariner:libvirt> git-describe 33fb8ff185846a7b4974105d2c9400690a6f95cf > v1.3.2-rc2-1-g33fb8ff > mariner:libvirt> git-describe cda1cc170f07b45911b3dad03e42c8ebfc210fa1 > v1.3.1-262-gcda1cc1 It seems odd that Xen 4.5 would use an older libvirt release than Xen 4.3. > mariner:libvirt> git-describe eac167e2610d3e59b32f7ec7ba78cbc8c420a425 > v1.3.5-318-geac167e > mariner:libvirt> git-describe 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc > v1.3.5-129-g1a41ed5 > mariner:libvirt> > > So in most cases these hashes are well away from a release tag. > > Does libvirt have stable release branches ? One approach would be to > have osstest track a suitable libvirt stable release branche for each > Xen stable release branch. I see Daniel already answered this question. > > That would involve setting up a push gate for each of the chosen > libvirt stable branches. That would be worthwhile if we expect those > stable branches to acquire commits which break Xen, and which we could > like to be told about. But I'm not sure that's the case. I occasionally backport Xen bug fixes to -maint branches. Cole has also grabbed some Xen bug fixes when making a stable release of a -maint branch. But such backports should be trivial and obvious bug fixes that shouldn't cause build or runtime breakage with Xen. Regards, Jim
Jim Fehlig writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"):
> On 06/27/2016 10:12 AM, Ian Jackson wrote:
> > Does libvirt have stable release branches ? One approach would be to
> > have osstest track a suitable libvirt stable release branche for each
> > Xen stable release branch.
>
> I see Daniel already answered this question.
>
> >
> > That would involve setting up a push gate for each of the chosen
> > libvirt stable branches. That would be worthwhile if we expect those
> > stable branches to acquire commits which break Xen, and which we could
> > like to be told about. But I'm not sure that's the case.
>
> I occasionally backport Xen bug fixes to -maint branches. Cole has
> also grabbed some Xen bug fixes when making a stable release of a
> -maint branch. But such backports should be trivial and obvious bug
> fixes that shouldn't cause build or runtime breakage with Xen.
OK. Thanks for the feedback. I'll go ahead with my plan with the
git commit ids named in my earlier email.
Thanks,
Ian.
>>> On 27.06.16 at 18:54, <ian.jackson@eu.citrix.com> wrote: > Jim Fehlig writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver > breakage -- where to define LIBXL_API_VERSION?"): >> On 06/27/2016 10:12 AM, Ian Jackson wrote: >> > Does libvirt have stable release branches ? One approach would be to >> > have osstest track a suitable libvirt stable release branche for each >> > Xen stable release branch. >> >> I see Daniel already answered this question. >> >> > >> > That would involve setting up a push gate for each of the chosen >> > libvirt stable branches. That would be worthwhile if we expect those >> > stable branches to acquire commits which break Xen, and which we could >> > like to be told about. But I'm not sure that's the case. >> >> I occasionally backport Xen bug fixes to -maint branches. Cole has >> also grabbed some Xen bug fixes when making a stable release of a >> -maint branch. But such backports should be trivial and obvious bug >> fixes that shouldn't cause build or runtime breakage with Xen. > > OK. Thanks for the feedback. I'll go ahead with my plan with the > git commit ids named in my earlier email. The only (hopefully highly theoretical) problem I see with this is that we may end up picking a libvirt commit which subsequently (e.g. via a libxl backport) turns out to have an issue. Such a problem could be dealt with in the suggested the stable branch tracking model (or any other model not dealing with something completely frozen). Jan
Jan Beulich writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"):
> On 27.06.16 at 18:54, <ian.jackson@eu.citrix.com> wrote:
> > OK. Thanks for the feedback. I'll go ahead with my plan with the
> > git commit ids named in my earlier email.
>
> The only (hopefully highly theoretical) problem I see with this is that
> we may end up picking a libvirt commit which subsequently (e.g. via
> a libxl backport) turns out to have an issue. Such a problem could be
> dealt with in the suggested the stable branch tracking model (or any
> other model not dealing with something completely frozen).
I don't think there is anything stopping us manually updating one of
these frozen "branches", should such a situation occur.
Ian.
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
(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 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.jackson@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.Jackson@eu.citrix.com> --- cr-daily-branch | 6 ++++++ 1 file changed, 6 insertions(+)