| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-11 | |||
| 12:26:44 | efried | sean-k-mooney: I have no idea. | |
| 12:26:47 | sean-k-mooney | i mean that fine but if there is we could porbaly fix it | |
| 12:26:56 | kashyap | efried: And I agree with your point there, in a future commit, it can be changed | |
| 12:27:22 | efried | sean-k-mooney: https://github.com/intel/Intel-OpenStack-CI-jobs/ | |
| 12:27:46 | luyao | kashyap: okay, I'll change it cake to InternalError. :) | |
| 12:28:08 | sean-k-mooney | ok its not mnaged via gerrit so we cant use depens on to test job changes | |
| 12:28:17 | sean-k-mooney | unless they are using gerrithub | |
| 12:29:26 | sean-k-mooney | that woudl be a no | |
| 12:29:29 | kashyap | luyao: Thanks | |
| 12:32:00 | luyao | efried, sean-k-mooney: Rui told me just now, them have a patch, but they have no permission to merge it into CI , waiting for matt to merge, then we can appy the latest patches and do the tests | |
| 12:32:35 | efried | luyao: Matt who? Merge where? | |
| 12:32:45 | sean-k-mooney | ok i was just looking at the repo to see if i could write one | |
| 12:32:49 | sean-k-mooney | i did not see it in that repo | |
| 12:33:11 | luyao | efried: Merge ti CI-jobs I think? I don't know about CI | |
| 12:33:14 | sean-k-mooney | any way we coudl get efried or alex_xu added to the people that can merge to it if its going to run against nova | |
| 12:34:29 | luyao | efried: Matt is helping setup CI, I saw he is the intel ci job repo owner | |
| 12:35:01 | efried | Matt who? (Last name?) | |
| 12:35:21 | sean-k-mooney | efried: https://github.com/matt-welch | |
| 12:35:31 | efried | okay. | |
| 12:35:59 | efried | sean-k-mooney: how does one find out who's got merge perms on a github repo? | |
| 12:36:01 | sean-k-mooney | i dont see the hardcoding in that repo | |
| 12:36:20 | sean-k-mooney | no idea buyt that is the mat that has merged things | |
| 12:36:22 | luyao | efried: Matt Welch | |
| 12:36:24 | sean-k-mooney | you can see it in the org | |
| 12:36:32 | sean-k-mooney | but im not a memebr of the intel org anymore | |
| 12:36:35 | efried | looks like he's the only one who has merged things. | |
| 12:37:06 | efried | ugh, and he's west coast, which probably means he won't be up for another several hours. | |
| 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 | |