3:14 p.m.
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
4:37 a.m.
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=experime...
Cheers,
-- Guido
8:28 a.m.
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=experime...
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
11:03 a.m.
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=experime...
>
> 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
11:25 a.m.
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=experime...
>>
>> 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
2:25 a.m.
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.
3:45 p.m.
New subject: [libvirt] Release candidate 2 of 2.3.0 is available
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
10:35 a.m.
New subject: [libvirt] [Libvirt-announce] Release candidate 2 of 2.3.0 is available
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
3003
days inactive
3011
days old
7 comments
4 participants
participants (4)
-
Daniel Veillard -
Guido Günther -
Michal Privoznik -
Peter Krempa