| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-11 | |||
| 12:37:27 | sean-k-mooney | im not sure if this hardcoding is in that repo or in the tempest plugin repo | |
| 12:38:16 | efried | sean-k-mooney: https://github.com/intel/Intel-OpenStack-CI-jobs/blob/master/roles/upgrade-libvirt-qemu/tasks/main.yaml#L105-L108 | |
| 12:38:23 | efried | seems like a weird place for it, but whatevs. | |
| 12:38:37 | sean-k-mooney | ah that is why i have not found it it does not have pmem in the name | |
| 12:39:10 | sean-k-mooney | well the task has | |
| 12:40:09 | sean-k-mooney | ya there are btter ways to do that | |
| 12:40:11 | sean-k-mooney | oh | |
| 12:40:29 | sean-k-mooney | i wonder if we can use a pull request in the depens on | |
| 12:40:47 | sean-k-mooney | that should work if they have zuul set up correctlyly | |
| 12:41:14 | efried | brb | |
| 12:42:58 | stephenfin | efried: sean-k-mooney or mriedem are you people RE: InternalError or InvalidConfig. It was the former's comment but the latter agreed | |
| 12:43:08 | stephenfin | *your | |
| 12:43:54 | efried | stephenfin: Sorry, I'm failing to parse that | |
| 12:44:05 | efried | oh, got it. | |
| 12:44:30 | efried | sean-k-mooney: Could you please clarify your opinion on https://review.opendev.org/#/c/678453/27/nova/virt/libvirt/driver.py@447 -- should we use InternalError to be consistent, or go rogue and use InvalidConfig? | |
| 12:45:10 | sean-k-mooney | well its not an internal error but i dont really care | |
| 12:45:11 | stephenfin | bauzas: replied on https://review.opendev.org/#/c/675571 (tl;dr: I spotted it and removed it - should have been a different patch/called out in the commit message but it's done now) | |
| 12:45:19 | sean-k-mooney | we proably shoudl change them all to invalid config | |
| 12:45:27 | sean-k-mooney | we can do that in U | |
| 12:45:31 | stephenfin | efried: I vote do the new thing and fix the old things later | |
| 12:45:57 | efried | sigh | |
| 12:45:59 | sean-k-mooney | iternal error implies the something in nova broke and it did not. this is user error | |
| 12:46:26 | stephenfin | foolish consistency and all that | |
| 12:47:11 | efried | luyao: Looks like kashyap is outvoted ^ so please just fix the docstring and we'll move on. | |
| 12:47:14 | sean-k-mooney | efried: from a time perspecitve i dont think this is important but i also dont think internal error is correct for config errors | |
| 12:47:38 | sean-k-mooney | so ill be happy with whatever ye choose | |
| 12:47:42 | efried | sean-k-mooney: no argument that InvalidConfig is better. The only argument to use InternalError is consistency. | |
| 12:48:37 | openstackgerrit | Chris Dent proposed openstack/os-resource-classes master: WIP: Build pdf docs https://review.opendev.org/681463 | |
| 12:49:00 | kashyap | Yeah, maybe in this case being 'consistent' isn't worth it. I don't know - whoever has super strong opinion on it (seems like stephenfin has) | |
| 12:49:11 | sean-k-mooney | doing something consitenly wrong does not make it correct | |
| 12:49:37 | efried | no, it just makes it predictable for the operator | |
| 12:49:58 | sean-k-mooney | but two days before freatre freeze i dont really want to block on that | |
| 12:50:11 | sean-k-mooney | true | |
| 12:50:12 | kashyap | sean-k-mooney: Sure :-). I do see the good argument for doing the right thing with InternalConfig | |
| 12:50:22 | sean-k-mooney | if i was an operator i would want to see invalide config | |
| 12:50:32 | sean-k-mooney | because then i know it shte config thats broken not nova | |
| 12:51:34 | openstackgerrit | Chris Dent proposed openstack/os-resource-classes master: Update bug link in docs to point to storyboard https://review.opendev.org/681464 | |
| 12:51:56 | openstackgerrit | Chris Dent proposed openstack/os-traits master: WIP: Build pdf docs https://review.opendev.org/681465 | |
| 12:53:22 | efried | So all we have left is https://review.opendev.org/#/c/678455/ and for stephenfin to re+2 the whole pile. | |
| 12:56:31 | mriedem | might want to keep an eye on this https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_c0b/676972/18/check/nova-tox-functional/c0b03d1/testr_results.html.gz | |
| 12:56:43 | mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22DestinationDiskExists%3A%20The%20supplied%20disk%20path%20(path)%20already%20exists%2C%20it%20is%20expected%20not%20to%20exist.%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d | |
| 13:02:40 | stephenfin | sean-k-mooney: What do you think of https://review.opendev.org/#/c/678455/28/nova/virt/libvirt/driver.py@5468 ? | |
| 13:04:08 | sean-k-mooney | i dont like it but its what we said we would do a the PTG | |
| 13:04:27 | sean-k-mooney | i would prefer to actully give the guest a numa toplogy like we do with hugepages | |
| 13:04:38 | sean-k-mooney | but just not requrie the pmem namespace to be numa affined | |
| 13:04:45 | stephenfin | Me too | |
| 13:04:56 | sean-k-mooney | but i know some people want to supprot non numa guest with pmem | |
| 13:05:12 | stephenfin | But the spec says this "Persistent memory is by nature NUMA sensitive." | |
| 13:05:18 | sean-k-mooney | yes it is | |
| 13:05:23 | stephenfin | and also "Libvirt domain specification requires each virtual persistent memory to be associated with one guest NUMA node." | |
| 13:05:48 | sean-k-mooney | its litrally memory dimms that happen to not loose ther content on host reboot | |
| 13:06:23 | sean-k-mooney | yes so we are working around a qemu limitation by giving the guest a virtual numa toplogy of 1 numa node | |
| 13:06:38 | stephenfin | hmm, yeah, this should definitely have NUMA affinity enforced | |
| 13:06:39 | sean-k-mooney | then not affinig it to a host numa node to make it act like a floating vm | |
| 13:06:59 | stephenfin | via the NUMATopologyFilter, of course, until we have NUMA in placement | |
| 13:07:01 | sean-k-mooney | thats what i argued but again we chose not too | |
| 13:07:43 | sean-k-mooney | without reopentin the spec i think we have to just live with this in train | |
| 13:08:04 | sean-k-mooney | and kill it with fire in U | |
| 13:08:15 | stephenfin | idk. I'd like to see how hard it would be to do the NUMA affinity thing | |
| 13:08:17 | stephenfin | It seems easy | |
| 13:08:28 | stephenfin | just another conditional in numa_get_constraints | |
| 13:08:34 | sean-k-mooney | it would be | |
| 13:08:39 | sean-k-mooney | yep | |
| 13:09:05 | sean-k-mooney | the proable with that is it mean that you cant have geust with more cores then fit on one host numa node | |
| 13:09:11 | sean-k-mooney | without have a multi numa guest | |
| 13:09:21 | sean-k-mooney | and that is want people dont want to have to care about | |
| 13:09:34 | stephenfin | that's no different to huge pages and PCI devices | |
| 13:09:48 | sean-k-mooney | pci device does not creat a numa toplogy | |
| 13:09:55 | sean-k-mooney | hugepage does | |
| 13:09:56 | stephenfin | sorry, not PCI devices | |
| 13:09:59 | stephenfin | yeah | |
| 13:10:05 | sean-k-mooney | hugepages and cpu pinning | |
| 13:10:25 | sean-k-mooney | i would prefer not to special case pmem | |
| 13:10:49 | sean-k-mooney | if we were to special case pmem i would prefer to relax hugepages and cpu pinning to be the same | |
| 13:10:52 | stephenfin | So would I. We have way too many special corner cases as-is. We should be reducing that, not increasing it | |
| 13:10:58 | stephenfin | Yeah, that | |
| 13:11:08 | sean-k-mooney | e.g i have always wanted to decouple pinning/hugepages form numa | |
| 13:12:17 | stephenfin | oh, I'm well aware :) | |
| 13:13:01 | sean-k-mooney | so ya that is where i stand. im not going to block it but i consider it tech debth | |
| 13:14:09 | sean-k-mooney | stephenfin: at least im consitent on the topic :) | |
| 13:15:38 | sean-k-mooney | stephenfin: alex_xu luyao https://libvirt.org/formatdomain.html#elementsMemory | |
| 13:15:45 | sean-k-mooney | The node subelement configures the guest NUMA node to attach the memory to. The element shall be used only if the guest has NUMA nodes configured. | |
| 13:16:02 | sean-k-mooney | so it looks like not is optional in the target field | |
| 13:16:14 | sean-k-mooney | so lest just not set it | |
| 13:16:38 | sean-k-mooney | and get rid fo the virtual numa node. | |
| 13:16:58 | stephenfin | I see this above in the opening paragraph though: "Some hypervisors may require NUMA configured for the guest." | |
| 13:17:12 | stephenfin | If kvm/qemu one such hypervisor? | |
| 13:17:16 | sean-k-mooney | if the guest has a numa toplogy we could set it to 0 but i think that would be the default | |
| 13:17:51 | sean-k-mooney | no | |
| 13:17:56 | sean-k-mooney | https://github.com/qemu/qemu/blob/master/docs/nvdimm.txt | |
| 13:18:05 | sean-k-mooney | -machine pc,nvdimm | |
| 13:18:07 | sean-k-mooney | -m $RAM_SIZE,slots=$N,maxmem=$MAX_SIZE | |
| 13:18:09 | sean-k-mooney | -object memory-backend-file,id=mem1,share=on,mem-path=$PATH,size=$NVDIMM_SIZE | |
| 13:18:11 | sean-k-mooney | -device nvdimm,id=nvdimm1,memdev=mem1 | |
| 13:18:22 | sean-k-mooney | basic usage create an nvdim device with no numa node | |
| 13:18:39 | sean-k-mooney | efried_afk: alex_xu luyao ^ | |
| 13:19:11 | stephenfin | okay, if that's true I can definitely live with it | |
| 13:19:23 | stephenfin | remind me to go and convert the QEMU docs to rST sometime | |
| 13:19:30 | stephenfin | or Markdown or something | |
| 13:19:35 | luyao | sean-k-mooney: the vm can't run if no numa node | |