| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-12 | |||
| 16:12:55 | mriedem | so we stopped doing it, | |
| 16:12:57 | mriedem | and, | |
| 16:12:58 | stephenfin | understandable. That's why I was thinking Queens | |
| 16:13:01 | melwitt | mriedem: I'm +1 on the top patch of brinzhang's set and I see you are +1 on the middle patch. I'm wondering if I should fix up the bottom patch since I doubt brin is around the rest of today | |
| 16:13:03 | stephenfin | rather than Train or something more recent | |
| 16:13:13 | mriedem | the amount of new schema migrations we do compared to the old days is nowhere close | |
| 16:13:22 | dansmith | also true | |
| 16:13:33 | dansmith | we chewed through a ton early on, but it's rare today | |
| 16:13:54 | stephenfin | I bring it up because I'm deploying on a machine locally and they're taking forever | |
| 16:13:59 | mriedem | dan prince had a schema diff tool thing since he was the one that used to do it but i'm not sure if that works anymore | |
| 16:14:27 | stephenfin | but that machine is using a HDD so that could be a limiting factor | |
| 16:14:51 | mriedem | melwitt: i've got an appointment this afternoon and haven't been back on the api change itself yet, so i'm not sure i'm going to be able to get that done today, | |
| 16:15:00 | mriedem | melwitt: you could fix up the bottom change though yeah it's just simple testing | |
| 16:15:25 | mriedem | i also have a patch i've been meaning to update and get into placement this release that i need to spend some time on | |
| 16:16:13 | melwitt | mriedem: ack. I'll do it just in case but won't expect you'll be able to be back to it today | |
| 16:17:24 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] cpu pinning testing https://review.opendev.org/681807 | |
| 16:19:17 | sean-k-mooney | ok i think ^ is correct | |
| 16:19:35 | sean-k-mooney | stephenfin: can you check https://review.opendev.org/#/c/681807/1/playbooks/nfv/pinning.yaml | |
| 16:19:41 | stephenfin | sure | |
| 16:19:58 | sean-k-mooney | those flavors are correct right? | |
| 16:20:53 | sean-k-mooney | i need to start makeing the other 2 version vcpu_pin_set only where i will have to drp the expcitly resouce request and cpu_dedicated_set only which shuld just work | |
| 16:21:01 | sean-k-mooney | e.g. no flavor changes needed | |
| 16:21:05 | stephenfin | sean-k-mooney: the first one has vcpus=1 but '--property hw:cpu_threads=2' | |
| 16:21:13 | stephenfin | that'll conflict, surely | |
| 16:21:21 | sean-k-mooney | actully ya it might | |
| 16:21:28 | sean-k-mooney | it previously had 2 vcpus | |
| 16:21:35 | sean-k-mooney | ill fix that | |
| 16:21:40 | sean-k-mooney | anything else | |
| 16:21:45 | stephenfin | Personally I'd just drop the CPU topology stuff since it's not relevant to this | |
| 16:21:46 | stephenfin | looking | |
| 16:22:09 | sean-k-mooney | i just did | |
| 16:22:10 | stephenfin | '--property hw:cpu_policy=dedicated --property resources:PCPU=2' | |
| 16:22:12 | stephenfin | that'll fail | |
| 16:22:22 | sean-k-mooney | that shoudl not | |
| 16:22:26 | stephenfin | you've to do one or the other. We enforce that at the API | |
| 16:22:34 | sean-k-mooney | oh ok | |
| 16:22:49 | sean-k-mooney | but wait no that does not make sense | |
| 16:23:02 | sean-k-mooney | if you just did --property resources:PCPU=2 | |
| 16:23:07 | sean-k-mooney | then you would not get cpu pinning | |
| 16:23:21 | sean-k-mooney | so why would we ever allow that | |
| 16:23:22 | stephenfin | you will - PCPU == a pinned CPUs | |
| 16:23:33 | sean-k-mooney | we should not allow that | |
| 16:23:51 | stephenfin | 'hw:cpu_policy=dedicated' is syntactic sugar for 'resources:PCPU=$(flavor.vcpus)' | |
| 16:23:53 | sean-k-mooney | didnt we say we woudl only do pinning if you had dedicated | |
| 16:24:14 | stephenfin | A PCPU is a resource for dedicated CPUs | |
| 16:24:15 | sean-k-mooney | yes but we dont want to supprot people useing --property resources:PCPU=2 long term | |
| 16:24:21 | dansmith | sean-k-mooney: why? | |
| 16:24:26 | dansmith | that's exactly what I want | |
| 16:24:37 | sean-k-mooney | because you have to change your flavors if we change how we modle it in placement | |
| 16:24:50 | dansmith | I'm fine with that | |
| 16:24:57 | sean-k-mooney | also it will break if you enable multiple numa nodes in the image | |
| 16:25:19 | stephenfin | break how? | |
| 16:25:21 | stephenfin | or when? | |
| 16:25:46 | sean-k-mooney | when numa is modles in palcmeent. it will add the request to the un numbered group | |
| 16:26:13 | sean-k-mooney | but if you had hw_numa_nodes=2 in the image and resources:PCPU=2 in the falvor it would fial | |
| 16:26:25 | sean-k-mooney | you would have to use teh numbered resouce request synatx | |
| 16:26:31 | sean-k-mooney | in the flavor instead | |
| 16:27:01 | stephenfin | in a future where NUMA is in placement, yes, you would need to use a different syntax | |
| 16:27:03 | sean-k-mooney | so we dont want to encurage resources:PCPU as it leaks implmeantion details of placmenet via the nova api | |
| 16:27:21 | stephenfin | but that's the same for requesting resource:VCPU if you use NUMA without placement | |
| 16:27:25 | stephenfin | and we already support that | |
| 16:27:31 | stephenfin | (requesting resources:VCPU) | |
| 16:27:38 | sean-k-mooney | yes that is also bad | |
| 16:27:41 | stephenfin | mainly for ironic but anyone can use it | |
| 16:27:50 | sean-k-mooney | i get why this raw syntax exists | |
| 16:27:52 | sean-k-mooney | but its fragile | |
| 16:28:07 | sean-k-mooney | and leaking placmenet detail via nova api | |
| 16:28:34 | stephenfin | that's a fair opinion | |
| 16:28:39 | stephenfin | but going back to the original point | |
| 16:28:51 | stephenfin | "--property hw:cpu_policy=dedicated --property resources:PCPU=2" is a no-no | |
| 16:29:04 | stephenfin | as is "-property resources:PCPU=2 --property hw:cpu_thread_policy=prefer" | |
| 16:29:12 | sean-k-mooney | i expect that to work if the PCPUs match the flavor.vcpus | |
| 16:29:17 | melwitt | fwiw when we have unified limits users are going to know all about placement resources, that's how they set limits | |
| 16:29:29 | dansmith | which is a good thing, IMHO | |
| 16:29:29 | stephenfin | you want either | |
| 16:29:34 | sean-k-mooney | stephenfin: that shoudl definetly work | |
| 16:29:36 | melwitt | yeah, just saying | |
| 16:29:46 | sean-k-mooney | stephenfin: prefer is the most relaxed policy | |
| 16:30:04 | stephenfin | it's not the prefer bit that's the issue | |
| 16:30:07 | sean-k-mooney | if you say nothing its a stricter requirement | |
| 16:30:27 | stephenfin | it's the fact that you're mixing the old way of doing this and the new way | |
| 16:30:58 | stephenfin | I want to be very clear and say you either do things with resources:PCPU and traits:HW_CPU_HYPERTHREADING | |
| 16:30:58 | sean-k-mooney | this is not what i understood form the spec | |
| 16:31:11 | stephenfin | or with hw:cpu_policy and hw:cpu_thread_policy | |
| 16:31:35 | mriedem | we should probably start an etherpad for post-FF release todos huh....like documenting PCPUs | |
| 16:31:38 | sean-k-mooney | ill change the tst to work but i think this is a problem | |
| 16:32:05 | dansmith | so, | |
| 16:32:10 | dansmith | we're not sure how to use it | |
| 16:32:17 | dansmith | and there are some concerns about how to use it | |
| 16:32:28 | dansmith | so we should merge it, figure it out later and then document? :) | |
| 16:32:48 | stephenfin | that's not very fair | |
| 16:32:52 | mriedem | i've started https://etherpad.openstack.org/p/nova-train-release-todo | |
| 16:32:57 | stephenfin | I don't know how to use BW-aware scheduling | |
| 16:33:05 | dansmith | stephenfin: I think you know how to use it, which is why I said we :) | |
| 16:33:07 | mriedem | it's documented | |
| 16:33:14 | stephenfin | I'm not blocking that because I don't personally understand it | |
| 16:33:21 | mriedem | the bw stuff was documented in stein | |
| 16:33:50 | stephenfin | So's this. There's a not insignificant spec for the thing | |
| 16:34:04 | stephenfin | and I don't think me not documenting things is a concern | |
| 16:34:21 | sean-k-mooney | when i get the jobs running ill review the api checks | |