Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-29
14:55:51 sdague http://paste.openstack.org/show/604672/
14:55:56 EmilienM awesome, thx again
14:56:00 sdague no prob
15:27:33 mdbooth dansmith: Did you see this change, btw: https://review.openstack.org/#/c/445142/
15:28:10 mdbooth It's not incredibly important itself, although I think it's useful, but it illustrates the idea of using object contexts
15:28:18 dansmith mdbooth: yes, but I've been completely swamped with other stuff
15:28:36 mdbooth dansmith: Ok, cool. Just wondered if it had hit your radar.
15:28:45 openstackgerrit Sujitha proposed openstack/nova master: Adding tags field to InstancePayload https://review.openstack.org/407228
15:39:36 jaypipes sfinucan: hmm, weird. for some reason I was under the impression that emulator threads would all be pinned to the same physical CPU core (when emulator thread policy was ISOLATE)
15:40:09 jaypipes sfinucan: since, my impression was that the emulator threads were actually pretty lightly loaded in a RT environment
15:40:53 sfinucan jaypipes: Not per my understanding, no - emulator cores aren't really any different to instance cores
15:41:28 sfinucan the only difference is that emulator cores are always on node 0
15:41:31 jaypipes sfinucan: ok, no worries. just a bad recollection of mine, I guess :)
15:41:42 sfinucan plus how they're tracked is totally different :)
15:41:45 sfinucan cool cool
15:42:08 jaypipes sfinucan: you good on https://review.openstack.org/#/c/400877/?
15:42:18 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: remove *_topic config opts https://review.openstack.org/433924
15:42:52 sfinucan jaypipes: Hmm, don't know why I missed that. Checking now
15:57:26 openstackgerrit Sujitha proposed openstack/nova master: Adding tags field to InstancePayload https://review.openstack.org/407228
15:57:51 mriedem lyarwood: first thing i noticed right away https://review.openstack.org/#/c/439520/
15:59:48 johnthetubaguy mriedem: dam it, I -1ed for that in a previous version
16:01:10 mriedem sure you did, sure you did
16:01:12 mriedem :P
16:04:12 mdbooth mriedem: Incidentally, I also wanted to highlight this patch to you: https://review.openstack.org/#/c/445142/
16:04:46 mdbooth As I said to dansmith, it's not that important itself, but it demonstrates using object context when you've got a bunch of instances from different cells
16:04:49 vks1 hi, how does nova configure tag for VM ports ?
16:05:12 mdbooth So as well as being less error prone, it can also be more efficient
16:05:36 vks1 I see for 2 ports of a network on different compute has different tag.
16:06:33 vks1 is this valid ? can someone point to the document for the behavior ?
16:07:29 mriedem vks1: you want to talk to artom
16:07:42 mriedem mdbooth: https://review.openstack.org/#/c/439520/ is my goal for the week
16:07:56 artom vks1, heya
16:08:04 artom vks1, I don't understand your question :(
16:08:04 vks1 mriedem: thanks
16:08:07 mdbooth mriedem: You mean the actual detach calls, right? ;)
16:08:59 clarkb kashyap: mdbooth: hello, right now three of the four top bugs tracked by elastic-recheck originate in libvirt http://status.openstack.org/elastic-recheck/index.html#1643911 http://status.openstack.org/elastic-recheck/index.html#1638982 http://status.openstack.org/elastic-recheck/index.html#1646779 I know kashyap has poked at these in the past, but would it be possible to try and figure out these
16:09:01 clarkb issues? ianw started working on getting devstack to collect core dumps (though those aren't thought to be of help here) and was going to try running libvirt under electric fence. Maybe we can get a small group of people to coordinate around this and work together?
16:09:02 vks1 artom: I have 2 VMs launched on 2 different compute. When I see the tap ports on OVS , on one compute I see tag:1 and on other compute its tag:3
16:09:24 vks1 artom: both the VMs are of same n/w
16:09:33 kashyap clarkb: Hi there, I've seen yours and Ian's responses in the Inbox, but I still haven't had a chance to act on them
16:09:44 kashyap clarkb: Yeah, core dumps won't help in this case
16:09:58 artom vks1, err, you set the tags yourself at instance create?
16:10:00 kashyap clarkb: At least that's what the libvirt dev involved (Michal Privoznik) said
16:10:06 vks1 artom: no
16:10:19 artom vks1, err, which tags are you talking about then?
16:10:29 mdbooth clarkb: Couple of things, I posted an update to ianw 's patch which enables efence and also works on Fedora: https://review.openstack.org/#/c/451430/
16:10:33 clarkb kashyap: ianw figured it was something devstack should do anyways so wouldn't hurt to have it, then we can actually rule it out as not being helpful
16:10:48 vks1 Interface "tap319bae97-0b"
16:10:48 vks1 tag: 1
16:10:48 vks1 artom: Port "tap319bae97-0b"
16:10:49 mdbooth clarkb: Secondly, I think we have to treat this as a downstream Ubuntu bug
16:10:52 mriedem mdbooth: i want to get that refactor merged this week
16:10:56 kashyap clarkb: Oh that's certainly true -- having a coredump ready, it's super easy with systemd :-)
16:11:06 artom vks1, what is that the output of?
16:11:09 kashyap clarkb: I mean, having them available in general
16:11:15 mdbooth clarkb: The Ubuntu maintainers need to look at this
16:11:16 clarkb mdbooth: it certainly affects ubuntu (I don't have evidence of it affecting fedora or centos), but that doesn't necessarily mean its their bug
16:11:17 vks1 artom: ovs-vsctl show
16:11:20 artom vks1, I have a feeling you're talking about vlan ids...
16:11:27 vks1 artom: yeah
16:11:35 clarkb mdbooth: the last time we had a similar situation it was very clearly libvirts bug once someone from libvirt actually looked at it (instead of blaming ubuntu)
16:11:49 mdbooth clarkb: As I said in some LP bug somewhere, upstream libvirt aren't going to be that interested in this, because it's not the latest stable release
16:11:54 artom mriedem, you volunteered me for the wrong thing dude ;)
16:12:12 mdbooth clarkb: A libvirt maintainer has already looked, and doesn't think it's broken in the latest stable release
16:12:15 mriedem artom: redirect to vladikr?
16:12:15 artom vks1, so... different ports have different vlans?
16:12:28 mriedem artom: delegation is the sign of true leadership :)
16:12:28 vks1 artom: yeah
16:12:39 artom mriedem, *proper* delegation ;)
16:12:52 artom vks1, so is that bad? What's your expectation?
16:12:57 openstack Launchpad bug 1673483 in libvirt (Ubuntu) "libvirt: test_attach_volume_shelved_or_offload_server times out waiting for device detach (which fails)" [Medium,Triaged]
16:12:57 kashyap mdbooth: To answer your question from earlier in the day -- it's not actually the same bug as this one (https://bugs.launchpad.net/nova/+bug/1673483)
16:12:59 vladikr :)
16:13:05 kashyap mdbooth: Where danpb identified the missing patches
16:13:19 vks1 artom: thanks vladikr is here
16:13:21 clarkb mdbooth: ok, this is frustrating because have had had similar issues in the past with the same exact attitude from upstream and the end result was libvirt had a terrible bug in it that affected every version since the code went in
16:13:33 clarkb and it took months to get fixed because no one would look at it for more than 5 minutes
16:13:42 vks1 artom: vlan tagging should be same
16:13:45 clarkb I'm not saying thats the case here, but that attitude hasn't been productive in the past
16:13:47 vks1 vladikr: hi
16:14:19 kashyap mdbooth: Because, the Nova stack traces are different from both bugs, that's why we didn't close them as duplicates
16:14:25 mdbooth clarkb: Well, we're running our CI on unmaintained, unsupported infrastructure
16:14:25 openstackgerrit Sujitha proposed openstack/nova master: Adding tags field to InstancePayload https://review.openstack.org/407228
16:14:47 vks1 vladikr: I have 2 VMs launched on 2 different compute. When I see the tap ports on OVS , on one compute I see tag:1 and on other compute its tag:3 . both the VMs are of same n/w.
16:14:49 mdbooth clarkb: Support for that is always going to be frustrating
16:14:51 vladikr vks1, Hi, let me just read up.
16:14:59 kashyap clarkb: Speaking of attitudes, I'd argue (not the first one) that Virt maintainance on Ubuntu is a joke
16:15:18 clarkb where do I find the list of supported versions of libvirt?
16:15:27 mdbooth clarkb: To be clear... what kashyap said
16:15:57 clarkb https://libvirt.org/downloads.html#maintenance ?
16:15:57 openstack Launchpad bug 1673483 in libvirt (Ubuntu) "libvirt: test_attach_volume_shelved_or_offload_server times out waiting for device detach (which fails)" [Medium,Triaged]
16:15:57 kashyap clarkb: BTW, even for this bug -- https://bugs.launchpad.net/nova/+bug/1673483
16:15:59 mriedem clarkb: https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
16:16:08 mriedem mdbooth: what do you mean we're running on unmaintained infra?
16:16:14 mriedem we're running on 16.04 LTS right?
16:16:15 kashyap clarkb: I had to spend a good half a day talking to upstream libvirt, who identified what exact commits Ubuntu should backport
16:16:25 mdbooth mriedem: Sure. Lets file a bug there.
16:16:41 kashyap So they don't even bother to look at what's breaking, and simply apply the available bug fixes
16:16:41 clarkb kashyap: that bug doesn't seem to be one of the ones we are tracking though?
16:17:09 mdbooth mriedem: I just think it's unreasonable to expect upstream libvirt to spin their wheels on this.

Earlier   Later