| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-03 | |||
| 14:44:05 | sean-k-mooney | stephenfin: VMs? | |
| 14:44:13 | stephenfin | VFs, sorry | |
| 14:44:28 | stephenfin | Heh, "-su: echo: write error: Function not implemented" | |
| 14:45:12 | sean-k-mooney | stephenfin: you could just change your whitelisnt to onely have 02:00:00 address | |
| 14:45:27 | openstackgerrit | sahid proposed openstack/nova stable/rocky: hardware: fix memory check usage for small/large pages https://review.openstack.org/599413 | |
| 14:47:01 | sean-k-mooney | stephenfin: gibi anyway it sounds like the patch is working as expect in terms of fixing the direct case. the macvtap case likely will work if the nic was correctly configured | |
| 14:51:27 | openstackgerrit | sahid proposed openstack/nova stable/rocky: libvirt: Always escape IPv6 addresses when used in migration URI https://review.openstack.org/599419 | |
| 14:55:12 | gibi | stephenfin, sean-k-mooney: thanks for the extra check. I'm a lot more confident to +A that patch | |
| 15:06:44 | bauzas | stephenfin: I was looking at https://review.openstack.org/#/c/588570/2 | |
| 15:07:10 | bauzas | stephenfin: maybe because it's changing a lot of tech debt, that's why people wonder if that's a feature backport | |
| 15:07:17 | bauzas | while not, of course | |
| 15:07:35 | bauzas | after all, the change is hairy, you know | |
| 15:07:53 | bauzas | and https://review.openstack.org/#/c/588570/2/nova/objects/numa.py is a bit concerning | |
| 15:08:01 | stephenfin | bauzas: Yeah, I get that. Unfortunately it's pretty much unavoidable though :( | |
| 15:09:02 | stephenfin | bauzas: Is it? None of those functions are stored in a DB so there's no issues around versioning | |
| 15:10:28 | bauzas | stephenfin: yup, we're not changing the RPC API | |
| 15:10:33 | sean-k-mooney | stephenfin: well we could greatly simply that code by rewriting it in a declarive/fuctional style with filters and transforms instead of the imperitive stily that is currently used for numa affinity | |
| 15:11:00 | bauzas | stephenfin: I meant, when someone provides a backport change asking to modify an o.vo object, we need to look more | |
| 15:11:17 | sean-k-mooney | so the complexity is not entirely due to the problem statement however that is not backportable in anyway | |
| 15:11:27 | bauzas | and why it's taking me a long time to look at it | |
| 15:11:31 | stephenfin | bauzas: Yup, that's fair :) I figured as much | |
| 15:12:06 | bauzas | sean-k-mooney: well, it would be an only-stable change, then ? | |
| 15:12:24 | bauzas | if so, that's difficult | |
| 15:12:39 | stephenfin | Hmm, I wonder how I can resolve the issue, in that case. We could stick on more sellotape but I haven't even thought how I'd do that | |
| 15:12:39 | kashyap | Hey folks, can anyone do a small test for me: Boot a Nova instance with Q35 machine type, and post the complete guest XML somewhere, please | |
| 15:12:54 | kashyap | You can set Q35 in two ways: either vai the Nova config: `hw_machine_type=x86_64=q35`, or on the Glance image image: `openstack image set --property hw_machine_type=x86_64=q35 Fedora28Template` | |
| 15:12:57 | stephenfin | kashyap: What properties would I need to set to do that? | |
| 15:12:58 | stephenfin | Ah :) | |
| 15:13:04 | sean-k-mooney | bauzas: rewriting the numa code to be fucntional instead of imperitve. i was talking generally not for this specific patch | |
| 15:13:17 | stephenfin | sean-k-mooney: oh, gotcha | |
| 15:13:51 | sean-k-mooney | stephenfin: for this patch the only object change i see is a new property | |
| 15:13:55 | stephenfin | Yeah, all that code is crufty af. I might look to take that "track CPUs in placement" spec from jaypipes this cycle, assuming he's oversubscribed as usual | |
| 15:14:10 | stephenfin | ...though I don't really want to wade into the great placement war of 2018 | |
| 15:14:51 | kashyap | stephenfin: Thank you! | |
| 15:15:14 | sean-k-mooney | stephenfin: well we could clean up that code without ever touching placement but thats a different topic. e.g. keep existing functionality jsut do it differently | |
| 15:16:04 | bauzas | sean-k-mooney: oh well, sure we could do it | |
| 15:16:18 | bauzas | or use Haskell :p | |
| 15:16:30 | kashyap | stephenfin: I need to head to my Dutch class (starts afresh) in a few; when you get to it, post it here, I'll take a look. Gracias! | |
| 15:16:48 | bauzas | (FWIW, I *love* Haskell) | |
| 15:16:53 | sean-k-mooney | stephenfin: bauzas anyway back to https://review.openstack.org/#/c/588570/2 the only object change there is a syntasied property that will now be included in teh serialisation of the object so i think this is backportable as there is no rpc change right? | |
| 15:17:00 | kashyap | (s/starts afresh/new level starts today) | |
| 15:17:08 | bauzas | sean-k-mooney: I feel so | |
| 15:17:34 | sean-k-mooney | bauzas: that explains a lot .... | |
| 15:18:14 | bauzas | very simple | |
| 15:18:36 | stephenfin | bauzas: I studied Haskell in NZ and adored it (helped me grasp recursion at long last). Alas, it's not something I've had the chance to work with since | |
| 15:18:41 | stephenfin | Prolog, on the other hand. Ick | |
| 15:19:11 | sean-k-mooney | stephenfin: python has really good fuctional programing supprot built in by they way. | |
| 15:19:15 | bauzas | sean-k-mooney: since we're adding a new property, that's not chaning what we pass over RPC | |
| 15:19:25 | bauzas | sean-k-mooney: my only concern is on the left side | |
| 15:19:29 | bauzas | ie.what we remove | |
| 15:20:07 | stephenfin | kashyap: Here's the output of 'virsh dumpxml' http://paste.openstack.org/show/729345/ | |
| 15:20:29 | bauzas | anyway, time for wrapping off | |
| 15:20:58 | kashyap | stephenfin: Nice, /me clicks | |
| 15:21:06 | stephenfin | kashyap: and here are the commands I ran to get there http://paste.openstack.org/show/729348/ | |
| 15:21:18 | bauzas | today was school's back for my daughters, so I want to take time to discuss with them | |
| 15:21:27 | bauzas | so, calling it a day \o | |
| 15:21:40 | sean-k-mooney | bauzas: as you should. o/ | |
| 15:21:43 | stephenfin | kashyap: That's using commit 90cdf807503f94bfbd3ae9a62a9bfe466a18bcad (so about two month old cold) | |
| 15:21:47 | stephenfin | bauzas: Enjoy o/ | |
| 15:21:48 | kashyap | stephenfin: Nice. Can I ask one more, since you have the env? Also related to PCIe | |
| 15:21:56 | stephenfin | kashyap: shoot | |
| 15:22:45 | kashyap | stephenfin: Set the 'num_pcie_ports=2' in nova.conf, restart the Compute service, and again boot an instance afresh, and post the guest XML | |
| 15:22:56 | kashyap | Thanks a for the quick response :-) | |
| 15:23:24 | stephenfin | kashyap: num_pcie_ports ? That's not a nova.conf option, is it? | |
| 15:23:25 | sean-k-mooney | kashyap: wait why is that a nova conf setting and not a flavor extra spec | |
| 15:23:46 | stephenfin | Oh, what do you know, so it is | |
| 15:23:57 | kashyap | sean-k-mooney: Hehe, I haven't checked if there's a flavor extra spec for it or not. | |
| 15:24:00 | sean-k-mooney | stephenfin: really that sucks. | |
| 15:24:14 | sean-k-mooney | stephenfin: that is going to make live migration even more of a pain | |
| 15:24:45 | stephenfin | sean-k-mooney: I think it's like TX/RX queue size. The expectation would be that every node would have the same value (managed by Ansible or whatever other tool you're using) | |
| 15:25:03 | stephenfin | kashyap: With or without the q35 flag? | |
| 15:25:05 | sean-k-mooney | stephenfin: i think setting this suff in the nova conf is a serios antipatern | |
| 15:25:14 | kashyap | stephenfin: With, please. | |
| 15:25:22 | kashyap | stephenfin: Also - PCIe goodies are 'q35' _only_, BTW. | |
| 15:25:40 | sean-k-mooney | stephenfin: that kind of assumtion make upgrading a pain as once set you can never safly change it | |
| 15:26:22 | kashyap | sean-k-mooney: Before we forget, perhaps we should file a bug to revisit the PCIe root ports thingie? | |
| 15:26:51 | sean-k-mooney | which one. the auto allocation of a pcie route per numa node? | |
| 15:28:35 | stephenfin | kashyap: http://paste.openstack.org/show/729349/ | |
| 15:28:52 | stephenfin | sean-k-mooney: Fortunately for you, I have zilch on my plate rn. Send em my way | |
| 15:29:33 | sean-k-mooney | ill create an ether pad with them the issue is i have not got around to filing/writing them all. | |
| 15:31:44 | sean-k-mooney | stephenfin: im not sure that is correct for num_pcie_ports=2 | |
| 15:33:04 | sean-k-mooney | stephenfin: your machine type is pc-i440fx-bionic so you are not enableing q35 chipset so no pcie at all | |
| 15:33:57 | stephenfin | I don't think so either. I was expecting to see a <pci model='pcie-root-port'> element | |
| 15:34:45 | stephenfin | Sorry - <controller type='pci' model='pcie-root-port'> | |
| 15:35:01 | stephenfin | So why didn't that property get applied... | |
| 15:35:35 | sean-k-mooney | well currently everything in that xml is connect to the pci bus not pcie. also as i sad you are not using the q35 chipset so no pcie is available | |
| 15:35:52 | stephenfin | Oh yeah, I meant the 'hw:machine_type' property | |
| 15:36:17 | sean-k-mooney | i think its only read for arm... | |
| 15:36:50 | stephenfin | waaaait | |
| 15:36:56 | sean-k-mooney | it should be read on all archs but just going on the glance metadata docs i think its ignored on x86. i would prefer if it was not | |
| 15:37:09 | stephenfin | I misread kashyap's comments. You can't do this with extra specs | |
| 15:41:10 | stephenfin | kashyap: I misread your instructions. Here's the q35-only output http://paste.openstack.org/show/729350/ | |
| 15:44:38 | stephenfin | kashyap: And with the addition of the num_pcie_ports option http://paste.openstack.org/show/729351/ | |
| 15:44:45 | sean-k-mooney | stephenfin: kashyap that also looks incorrect but for different reasons. you asked for 2 pcie-root-ports and have 4 | |
| 15:44:46 | stephenfin | sean-k-mooney: That looks better ^ | |
| 15:45:05 | stephenfin | sean-k-mooney: Nope, first one is without that option | |
| 15:45:54 | sean-k-mooney | stephenfin: that still has 4 pcie-root-ports | |
| 15:46:06 | stephenfin | Indeed. I'd expect to see 3 | |
| 15:46:27 | sean-k-mooney | why 3 didnt you request 2? | |
| 15:46:58 | stephenfin | because someone can't count :) https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5114-L5119 | |