Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-12
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 stephenfin you want either
16:29:29 dansmith which is a good thing, IMHO
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 sean-k-mooney this is not what i understood form the spec
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: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
16:48:30 sean-k-mooney i had tought that i convinced both efried_afk and alex_xu that we shoudl prefer the abstract form
16:48:41 sean-k-mooney e.g. hw:cpu_policy
16:49:01 stephenfin prefer, yes, but not limit to
16:49:03 sean-k-mooney i have not spoken to dansmith or jaypipes about it
16:49:11 stephenfin hw:cpu_policy is syntactic sugar
16:49:26 sean-k-mooney i dont think it should be jsut syntatic sugar
16:49:31 mriedem efried_afk: in case you didn't see i've created https://etherpad.openstack.org/p/nova-train-release-todo and added it to the meeting agenda
16:49:48 sean-k-mooney i was pretty sure we agree in the reve to explcitly not support resouce:PCPUs
16:50:21 sean-k-mooney this came up in the pmem seriese too
16:51:00 sean-k-mooney we are not infering pmem usage form pmem resocues:... extra specs
16:53:26 openstackgerrit melanie witt proposed openstack/nova master: Add user_id and project_id column to Migration https://review.opendev.org/673990
16:53:27 openstackgerrit melanie witt proposed openstack/nova master: Set user_id/project_id from context when creating a Migration https://review.opendev.org/679413
16:53:28 openstackgerrit melanie witt proposed openstack/nova master: Filter migrations by user_id/project_id https://review.opendev.org/674243
16:58:05 sean-k-mooney anyway i have more or less said my pieice but the final point i want to make is that if you use resouces:* you will either have to do a resize to a flaovr without if if that resouce moves in placmenet before upgrading or we will have to do an online data migration of all instance embeded flavor or the vm will not be able to cold/live migrate after an upgrade from on version of nova to another

Earlier   Later