Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-12
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
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
16:58:41 sean-k-mooney well or a resize to the new flavor with the updated extra specs
16:58:51 sean-k-mooney reflectign the toplogy change
16:59:11 stephenfin aye, that'll be the same for vGPU too, unfortunately
16:59:19 stephenfin I'd rather like to provide a flavor migration tool in the future
16:59:36 stephenfin Migrate all flavors included embedded ones, as a way of deprecating old extra specs
16:59:41 stephenfin but I haven't really thought it throuhg
16:59:44 sean-k-mooney we could but its still not a good thing to encurage people to use
16:59:55 mriedem melwitt: i'm +2 on those bottom 2 changes now
16:59:56 stephenfin We'll do it in U, eh :)
17:00:05 mriedem if the api change doesn't make train at least the data will start flowing
17:00:09 sean-k-mooney i hope not
17:00:21 sean-k-mooney i dont think we should be deprecating those extrapecs
17:00:38 mriedem stephenfin: heh https://review.opendev.org/#/c/637217/
17:01:04 mriedem "This code can be removed in Queens"
17:01:13 melwitt mriedem: ack thanks
17:02:03 sean-k-mooney anyway that not an somthing we are doing today
17:02:07 stephenfin \o/
17:03:02 stephenfin I have the nova-network series ready to go once U opens up
17:05:35 sean-k-mooney stephenfin: what you crurrtly hav is inline with the spec https://specs.openstack.org/openstack/nova-specs/specs/train/approved/cpu-resources.html#example-flavor-configurations so i guess that is what we are stuck with.
17:06:18 stephenfin yeah, I haven't pulled the rug out from anyone here
17:06:27 stephenfin jaypipes wanted the resources-style syntax
17:06:35 stephenfin you wanted the hw:cpu_policy-style
17:07:02 sean-k-mooney yes we have both i would have hoped we could use both together if they dont conflict
17:08:07 openstackgerrit sean mooney proposed openstack/nova master: [DNM] legacy vcpu_pin_set pinning with shared emulator threads https://review.opendev.org/681840

Earlier   Later