[libvirt] Entering freeze for libvirt-2.3.0
Since nobody complained about my earlier message with the release plan, I tagged libvirt-2.3.0 candidate release 1 in git and pushed signed tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ As usual my limited testing is really not sufficient so please give it a try, I enjoy the view of a completely green https://ci.centos.org/view/libvirt-project/ :-) but that doesn't test portability to other platforms for example ! Then I will try to push rc2 on Thursday, that way the final release can happen during the week-end or on Monday if all goes well, thanks for testing it ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote:
Since nobody complained about my earlier message with the release plan, I tagged libvirt-2.3.0 candidate release 1 in git and pushed signed tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
As usual my limited testing is really not sufficient so please give it a try, I enjoy the view of a completely green https://ci.centos.org/view/libvirt-project/ :-) but that doesn't test portability to other platforms for example !
Then I will try to push rc2 on Thursday, that way the final release can happen during the week-end or on Monday if all goes well,
The rc1 looks good on Debians buildds: https://buildd.debian.org/status/package.php?p=libvirt&suite=experimental Cheers, -- Guido
On Fri, Sep 30, 2016 at 11:37:08AM +0200, Guido Günther wrote:
On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote:
Since nobody complained about my earlier message with the release plan, I tagged libvirt-2.3.0 candidate release 1 in git and pushed signed tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
As usual my limited testing is really not sufficient so please give it a try, I enjoy the view of a completely green https://ci.centos.org/view/libvirt-project/ :-) but that doesn't test portability to other platforms for example !
Then I will try to push rc2 on Thursday, that way the final release can happen during the week-end or on Monday if all goes well,
The rc1 looks good on Debians buildds:
https://buildd.debian.org/status/package.php?p=libvirt&suite=experimental
Cheers,
Thanks cool ! I didn't do rc2 yesterday, will try to push it today, as a result 2.3.0 will likely go out Monday evening ot Tuesday, thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On Fri, Sep 30, 2016 at 15:28:08 +0200, Daniel Veillard wrote:
On Fri, Sep 30, 2016 at 11:37:08AM +0200, Guido Günther wrote:
On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote:
Since nobody complained about my earlier message with the release plan, I tagged libvirt-2.3.0 candidate release 1 in git and pushed signed tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
As usual my limited testing is really not sufficient so please give it a try, I enjoy the view of a completely green https://ci.centos.org/view/libvirt-project/ :-) but that doesn't test portability to other platforms for example !
Then I will try to push rc2 on Thursday, that way the final release can happen during the week-end or on Monday if all goes well,
The rc1 looks good on Debians buildds:
https://buildd.debian.org/status/package.php?p=libvirt&suite=experimental
Cheers,
Thanks cool ! I didn't do rc2 yesterday, will try to push it today, as a result 2.3.0 will likely go out Monday evening ot Tuesday,
https://www.redhat.com/archives/libvir-list/2016-October/msg00074.html pointed out a pretty serious regression that we'd fail to start VM second time if the vcpu count is not fully allocated. This was caused by not running the post parse callbacks after copying the definition, which my code relied upon. I think that reverting those patches at this point is a safer option since the patch pointed out may be incomplete. Peter
On 04.10.2016 18:03, Peter Krempa wrote:
On Fri, Sep 30, 2016 at 15:28:08 +0200, Daniel Veillard wrote:
On Fri, Sep 30, 2016 at 11:37:08AM +0200, Guido Günther wrote:
On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote:
Since nobody complained about my earlier message with the release plan, I tagged libvirt-2.3.0 candidate release 1 in git and pushed signed tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
As usual my limited testing is really not sufficient so please give it a try, I enjoy the view of a completely green https://ci.centos.org/view/libvirt-project/ :-) but that doesn't test portability to other platforms for example !
Then I will try to push rc2 on Thursday, that way the final release can happen during the week-end or on Monday if all goes well,
The rc1 looks good on Debians buildds:
https://buildd.debian.org/status/package.php?p=libvirt&suite=experimental
Cheers,
Thanks cool ! I didn't do rc2 yesterday, will try to push it today, as a result 2.3.0 will likely go out Monday evening ot Tuesday,
https://www.redhat.com/archives/libvir-list/2016-October/msg00074.html
pointed out a pretty serious regression that we'd fail to start VM second time if the vcpu count is not fully allocated.
This was caused by not running the post parse callbacks after copying the definition, which my code relied upon.
I think that reverting those patches at this point is a safer option since the patch pointed out may be incomplete.
Agreed. However, we should really make this work. I mean, the idea that the domain def *copy* function also fills in some blanks, or prepares domain definition for something is really just combining two separate steps into one (that's why we ran into the issue I am fixing with those patches in the first place). What we should do is: 1) call virDomainDefCopy() to create live definition 2) call qemuPrepareDef() (or whatever the name is going to be) to fix up passed definition os vCPU hotplug (or just any other functionality) works. Michal
On Tue, Oct 04, 2016 at 18:25:32 +0200, Michal Privoznik wrote:
On 04.10.2016 18:03, Peter Krempa wrote:
On Fri, Sep 30, 2016 at 15:28:08 +0200, Daniel Veillard wrote:
On Fri, Sep 30, 2016 at 11:37:08AM +0200, Guido Günther wrote:
On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote:
[...]
Agreed. However, we should really make this work. I mean, the idea that the domain def *copy* function also fills in some blanks, or prepares domain definition for something is really just combining two separate steps into one (that's why we ran into the issue I am fixing with those patches in the first place).
Well the thing is that the domain def copy function should copy the domain definition. The domain definition as in the running program is a superset of the domain XML. If we had the deep copy function there wouldn't be a problem in this case since all members would be copied properly. The round trip through the XML is the problem.
What we should do is: 1) call virDomainDefCopy() to create live definition
Whether live or config, that does not matter really. You need to take the full transformation from XML to def if you are parsing a XML piece. And part of this transformation now is the post parse callback. Otherwise the code that does some modifications would need to be moved to the parser itself which is ridiculous. (Yes we still have a lot of logic in the parser.)
2) call qemuPrepareDef() (or whatever the name is going to be) to fix up passed definition os vCPU hotplug (or just any other functionality) works.
That won't help in this case. The missing piece causing the regression was in the global post parse callback. Since you did not describe your actual motivation to not call the post parse callbacks in the commit messages it was not clear to me what you need. Now from what I understand is that in some cases you don't have qemu caps since the migration destination XML may have a path to a different emulator not present at the source. In this case we should rather probably skip all the caps dependent code there. Peter As a side note, we should also probably exchange the def and newDef pointers when the definition is copied, so that such bugs get detected earliers.
On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote:
Then I will try to push rc2 on Thursday, that way the final release can happen during the week-end or on Monday if all goes well,
<grin/> I fogot. So you get RC2 today at the usual place signed tarball and rpms at: ftp://libvirt.org/libvirt/ also tagged in git. Thanks Guido for the feedback on the Debian builds for rc1, please give it more testing, I will try to push Monday evening or Tuesday morning unless something bad pops-up ! Thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On Sat, Oct 01, 2016 at 10:45:20PM +0200, Daniel Veillard wrote:
On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote:
Then I will try to push rc2 on Thursday, that way the final release can happen during the week-end or on Monday if all goes well,
<grin/> I fogot. So you get RC2 today at the usual place signed tarball and rpms at:
ftp://libvirt.org/libvirt/
also tagged in git.
Thanks Guido for the feedback on the Debian builds for rc1, please give it more testing, I will try to push Monday evening or Tuesday morning unless something bad pops-up !
rc2 built nice as well and passed the (although minimal) autopkgtests we ship for the package. Cheers, -- Guido
participants (4)
-
Daniel Veillard -
Guido Günther -
Michal Privoznik -
Peter Krempa