[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] cpuset / numa and qemu in TCG mode



Quoting Guido Günther (agx sigxcpu org):
> On Tue, May 12, 2015 at 11:14:09AM +0200, Martin Kletzander wrote:
> > On Tue, May 12, 2015 at 05:27:34PM +1000, Tony Breeds wrote:
> > >On Mon, May 11, 2015 at 01:14:58PM +0200, Martin Kletzander wrote:
> > >
> > >>Determining this by version might not be reliable, but more
> > >>importantly working around bug in underlying software is something
> > >>that shouldn't be done at all IMHO.  Let the maintainers backport
> > >>whatever needs to be done.
> > >
> > >I agree with you in an ideal world but there are times when we do need
> > >to add work arounds in $project_x to work around issues in $project_y.
> > >
> > >>>Ther nova side will be pretty easy regardless.
> > >>>
> > >>>I'd say the best solution would be to back port the 'fix' but that seems like a
> > >>>lot of effort given the number of distros and libvirt versions potentiall
> > >>>involved.
> > >>>
> > >>
> > >>If you want the fix to be distro-agnostic, there's nothing easier than
> > >>back-porting the fix into our upstream maintenance branches.  Those
> > >>should make the life of distro maintainers easy (although it looks
> > >>like not many distros use it).
> > >
> > >And this is part of the problem.  If I understand correctly Ubuntu cloud-archive
> > >is using libvirt 1.2.12 which is *NOT* a maintenance release so that leaves us
> > >with doing an additional backport to 1.2.12 and getting the cloud-archive team
> > >to take it[1]  or Adding a hack to nova.  And that's just Ubuntu It's hard to
> > >say for sure that some vendor isn't running libvirt 1.2.12 also.
> > >
> > >>Having said that I'm not sure which commit(s) are those that need to
> > >>be back-ported.  Having known your libvirt version, it shouldn't be
> > >>too hard looking for the differences and finding the right commit.
> > >>When back-porting request is made on the list, it is usually acted
> > >>upon.  If you can't find the exact commit, let me know and I'll do my
> > >>best to help.
> > >
> > >So a git bisect points at:
> > >---
> > >commit a103bb105c0c189c3973311ff1826972b5bc6ad6
> > >Author: Daniel P. Berrange <berrange redhat com>
> > >Date:   Tue Feb 10 15:59:57 2015 +0000
> > >
> > >   qemu: fix setting of VM CPU affinity with TCG
> > >---
> > >
> > >A small amount of reading implies to me that we'd be looking at backporting
> > >a103bb105c0c189c3973311ff1826972b5bc6ad6 to any maintenance branch that contains
> > >b07f3d821dfb11a118ee75ea275fd6ab737d9500.  Which I think is 1.2.13 only, but I
> > >could be wrong.
> > >
> > 
> > 1.2.13 has the commit already in the release and 1.2.12-maint has it
> > as a first back-port right after release.  The problem is that there
> > was no maintenance release of 1.2.12 yet.  Maybe they would use
> > 1.2.12.1 if it existed.
> > 
> > I Cc'd Guido as an upstream debian maintainer, maybe he'll have some
> > insights.  @Guido: would it help if we created a maintenance release
> > from the v1.2.12-maint branch?  Or is the only thing missing the fact
> > that the launchpad bug is not moved to libvirt?

Thanks guys, I'm going to cherrypick that patch into vivid right now.  (It
should be in wily as that is 1.2.15).

> Basically Ubuntu takes the version that is in Debian testing, unstable
> or experimental at time of their release and adds pathes. There's little
> to no sync unfortunately (except for the awesome efforts to sync the
> apparmor stuff)
> 
> Debian itself is not using 1.2.12 anywhere. Current stable has 1.2.9 +
> maintenance patches (which I intend to switch over to the maintenance
> releases soonish and support hopefully Cole with these), oldstable has
> 0.9.12.3 and unstable/sid has 1.2.15 (and will keep following the
> releases).
> 
> I've added Serge since he might to jump onto 1.2.12.1 maintenance
> relasese.

If you mean contributing by adding patches that we add to vivid, I'm
definately willing to do that.  Note that vivid has a pretty short
lifecycle so it wouldn't go on for very long.  If people are willing
to tag patches with '[1.2.12.1-maint]' on this list I'm willing to
support this longer.

> I'm happy about any additional notifications for things that should go
> into distributions.
> 
> Cheers,
>  -- Guido
> 

Thanks!

-serge


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]