Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-12
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
16:34:49 dansmith stephenfin: sean-k-mooney is one of the people you included in the "are testing it manually" crew, so I think being a little concerned is not unreasonable
16:37:53 openstackgerrit sean mooney proposed openstack/nova master: [DNM] cpu pinning testing https://review.opendev.org/681807
16:38:19 sean-k-mooney stephenfin: is that more to your likeing
16:38:46 stephenfin perfect
16:38:53 sean-k-mooney i think the second flavor should result in no cpus pinning and an api error personally but that should work as you suggest
16:43:15 openstackgerrit sean mooney proposed openstack/nova master: [DNM] test with dedicated cpus only https://review.opendev.org/681827
16:45:31 stephenfin sean-k-mooney: I'll try not to rathole on it, but what do you think requesting 'resources:PCPU=N' should imply, out of curiosity?
16:46:09 stephenfin It sounds like your objections to that would apply equally to 'resources:VCPU=N'
16:46:31 sean-k-mooney it should be an error if hw:cpu_policy is not set to dedicated and if it is set to dedicated it shoudl be compared to the flavor.vcpu
16:47:05 sean-k-mooney i dont think operators shoudl use either
16:47:09 stephenfin but I was told we wanted to get away from those request specs to the more generic 'resources' syntax
16:47:20 sean-k-mooney by who
16:47:35 stephenfin jaypipes, efried, dansmith (above)
16:47:36 sean-k-mooney because i rememebr talking about this with alex_xu and efried_afk

Earlier   Later