| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-27 | |||
| 09:53:57 | tobias-urdin | i can only find that we can select cpu thread policy but not to isolate actual usage of thread sibblings | |
| 09:55:02 | sean-k-mooney | tobias-urdin: only if you are not usign cpu in placement | |
| 09:55:10 | opendevreview | Ilya Popov proposed openstack/nova stable/xena: compute: Update volume_id within connection_info during swap_volume https://review.opendev.org/c/openstack/nova/+/874921 | |
| 09:55:11 | opendevreview | Ilya Popov proposed openstack/nova stable/xena: Add regression test for bug #1943431 https://review.opendev.org/c/openstack/nova/+/875374 | |
| 09:55:15 | sean-k-mooney | we deprecated that functionality a few release ago | |
| 09:55:24 | sean-k-mooney | ~train ish | |
| 09:56:05 | sean-k-mooney | well actully it depend on what you want | |
| 09:56:21 | sean-k-mooney | if you use thread policy require then we require hyperthread siblings to be used | |
| 09:56:52 | sean-k-mooney | i.e a 4 core vm will use 2 phsyical cores and use both hyperthread form each core to provided the 4 pinned cpus | |
| 09:57:00 | sean-k-mooney | that still works today even with placmeent | |
| 09:57:08 | sean-k-mooney | the isolate poicy is what chagned. | |
| 09:57:54 | sean-k-mooney | without pcpu in placementit made each flavor.vcpu be pinnded to a speerate core (and if it had hyperthreadig it reserved the hyperthread so nothing could use it.) | |
| 09:58:09 | sean-k-mooney | with pcpus in placement isolate means find cores without hyperthread | |
| 09:58:15 | tobias-urdin | sean-k-mooney: hm, so if thread policy=required and using even numbers (4 cores, 8 cores) etc we always assume that thread sibblings for those 2 or 4 cores are assigned to only one instance? | |
| 09:58:38 | tobias-urdin | and that would be honored for live migration as well if we set vcpu_pin_set to same on all nodes? | |
| 09:58:40 | sean-k-mooney | tobias-urdin: yes i belive so | |
| 09:59:06 | sean-k-mooney | well it does not have to be the same | |
| 09:59:20 | sean-k-mooney | we update the pinning on migration as of train | |
| 09:59:35 | tobias-urdin | ah | |
| 09:59:43 | sean-k-mooney | so they can be slightly differnt vcpu_pin_sets | |
| 10:00:10 | sean-k-mooney | just make sure you include both hypertherad siblings in vcpu_pin_set or cpu_dedicated_set | |
| 10:00:52 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/numa-aware-live-migration.html | |
| 10:01:03 | sean-k-mooney | ^ that fixed live migration | |
| 10:01:11 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/cpu-resources.html | |
| 10:01:25 | sean-k-mooney | and that explains how placement aware cpu pinning works if you use it | |
| 10:03:05 | tobias-urdin | ack, I think you answered my question but will read above! thanks, wanted to make sure that we could safetly have ht enabled if using dedicated | |
| 10:03:26 | sean-k-mooney | tobias-urdin: the old way of doign cpu pinning with vcpu_pin_set has been deprecated for a couple of years now. we will likely delete it in 2023.2 or 2024.1 | |
| 10:03:42 | sean-k-mooney | you want to prevent inter tenant side channel attacks | |
| 10:04:06 | sean-k-mooney | if so then yes use required/isolate in all flavors to ensure to vms form different tenants dont overlap | |
| 10:04:12 | tobias-urdin | so i will set cpu_policy=dedicated cpu_thread_policy=required on flavor and make sure cpu_dedicated_set is set and including sibblings | |
| 10:04:38 | opendevreview | Merged openstack/os-vif master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875097 | |
| 10:04:39 | tobias-urdin | make sure flavors use even amount of cores, so it gets distributed between core and thread (4 = 2 core, 2 thread, 8 = 4 core, 4 thread etc) | |
| 10:04:46 | tobias-urdin | that sounds reasonable? | |
| 10:05:09 | sean-k-mooney | more or less but read the upgrade section fo the cpu tracking in placemnt doc carefully | |
| 10:05:48 | tobias-urdin | we're on xena moving to yoga in a couple of weeks btw if that makes any difference | |
| 10:06:09 | sean-k-mooney | by the way i generally recommend seting hw:cpu_sockets=<the number of numa nodes> and hw:cpu_thread=2 | |
| 10:06:57 | sean-k-mooney | not really just that we planned to delete the old pinning code around wallaby but stephenfin moved team and we just didnt get around to it | |
| 10:07:36 | sean-k-mooney | the upgrade impact is the same regardless of when you actuly do the upgrade form old pining to placment aware pinning | |
| 10:08:33 | sean-k-mooney | with the slight simplifciation that at least you know all your nodes already have support for it in code | |
| 10:14:02 | tobias-urdin | sean-k-mooney: not sure i follow about what is legacy and not | |
| 10:14:56 | tobias-urdin | it should be tracked in placement already but do you we mean we should probably disable the fallback path for pcpu? | |
| 10:15:28 | tobias-urdin | or do you mean you want to get rid of the hw: aliases and use PCPU etc resource directly in flavor properties to affect placement? | |
| 10:21:40 | sean-k-mooney | useing vcpu_pin_set for pinning is deprecated | |
| 10:22:00 | sean-k-mooney | we will likely remove that config option sooner rather then later | |
| 10:22:22 | sean-k-mooney | PCUPs are only tracked in placment as a sperate inventory if you use cpu_dedicated_set | |
| 10:22:39 | tobias-urdin | that makes sense, thanks | |
| 10:22:41 | sean-k-mooney | there will be no changes to the hw: extra specs | |
| 10:22:47 | tobias-urdin | ack | |
| 10:23:45 | sean-k-mooney | once we remvoe the vcpu_pin_set we can remove the old code for the legacy isolate behavior (asinging one ht siblibing to the vm and reserving the other) | |
| 10:24:13 | sean-k-mooney | that will allow use to simplify that code a little | |
| 10:25:33 | sean-k-mooney | right now any time we want to extend pinned cpus in some way we have to desgin arond the placement natiave and pre placement behavior which is a bit of a pain | |
| 10:26:08 | sean-k-mooney | the code is pretty stable at this point but its still a maintance burden becuase we have to think about both sets anythime we are changing anything | |
| 10:26:45 | tobias-urdin | sean-k-mooney: i see, but using cpu_dedicated_set should that also honor numa_nodes? i understand, a lof of complexity involved with this amount of options that affect each other | |
| 10:27:12 | tobias-urdin | i.e i set hw:num_nodes=1 on a flavor | |
| 10:27:33 | bauzas | cores, needs a quick slap on https://review.opendev.org/c/openstack/nova/+/874103 (max microversion for Antelope) | |
| 10:28:11 | sean-k-mooney | -2 it is then :p | |
| 10:28:19 | sean-k-mooney | lets see | |
| 10:28:39 | sean-k-mooney | yep makes sense | |
| 10:28:48 | sean-k-mooney | that was trivial enough that you could have single core approved that | |
| 10:28:51 | bauzas | sean-k-mooney: we need it every cycle end | |
| 10:29:23 | sean-k-mooney | right but its a mechanical patch and pretty easy to see its correct | |
| 10:29:25 | bauzas | gmann: saw your ping, when you're up, let's discuss about the RBAC stuff for the prelude | |
| 10:29:31 | sean-k-mooney | anyway its on its way | |
| 10:30:02 | sean-k-mooney | although the main delta this time is 2023.1 Antelope | |
| 10:30:11 | bauzas | sean-k-mooney: sure, but I prefer to ask for another review, and in case I don't have a second core, I can +W it | |
| 10:30:13 | sean-k-mooney | i.e. using both the number and the code name | |
| 10:31:10 | bauzas | sean-k-mooney: not sure I understand your concern, takashi used both the number and the code name | |
| 10:31:24 | sean-k-mooney | its not a concern | |
| 10:31:28 | sean-k-mooney | i prefer having both | |
| 10:31:39 | sean-k-mooney | rather then just 2023.1 or antelope | |
| 10:32:07 | sean-k-mooney | that was the one thing i wanted to make sure was done in that patch | |
| 10:32:15 | sean-k-mooney | so the patch is correct | |
| 10:33:14 | sean-k-mooney | we listed the offical release name "2023.1" and the code name "Antelope" and listed teh offical release name "2023.1" first. | |
| 10:34:20 | bauzas | don't disagree here https://governance.openstack.org/tc/reference/release-naming.html | |
| 10:34:57 | sean-k-mooney | we are very close to being in violent agreement i think :) | |
| 10:37:47 | sean-k-mooney | tobias-urdin: cpu_dedicated_set supports numa yes | |
| 10:38:29 | sean-k-mooney | hw:numa_nodes was unaffected by the cpu tracking in placement spec | |
| 10:38:49 | sean-k-mooney | we do eventually want to supprot modeling numa in placment but its quite difficult | |
| 10:39:10 | sean-k-mooney | we have instead decided to track all resouces we can in placement first without numa | |
| 10:39:20 | sean-k-mooney | and then add numa at the end | |
| 10:39:34 | tobias-urdin | sean-k-mooney: ack, thanks for all your help – extremely helpful :) | |
| 10:39:34 | tobias-urdin | sean-k-mooney: ack, thanks for all your help – extremely helpful :) | |
| 10:40:07 | sean-k-mooney | the pci devices in placement spec added one of the builing block features we will need for numa in placment (the ablity for filters to filter on allcoations candiates) | |
| 10:40:38 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add the 2023.1 Antelope prelude section https://review.opendev.org/c/openstack/nova/+/875380 | |
| 10:41:18 | sean-k-mooney | lol i tought you had written that but that was the release highlights | |
| 10:41:59 | sean-k-mooney | did we land the spice console compressiong feature | |
| 10:42:12 | bauzas | yes | |
| 10:42:22 | opendevreview | Jorge San Emeterio proposed openstack/nova master: Moving privsep profiles to nova/__init__.py https://review.opendev.org/c/openstack/nova/+/872010 | |
| 10:42:22 | sean-k-mooney | good good | |
| 10:44:37 | sean-k-mooney | i reviewed the spec for that and planned to review the feature i just ran out of time to do that im glad it landed | |
| 11:28:38 | opendevreview | Merged openstack/nova master: doc: mark the max microversion for 2023.1 Antelope https://review.opendev.org/c/openstack/nova/+/874103 | |
| 12:23:07 | opendevreview | Merged openstack/python-novaclient stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875101 | |
| 12:26:51 | opendevreview | Rajesh Tailor proposed openstack/nova stable/xena: Fix rescue volume-based instance https://review.opendev.org/c/openstack/nova/+/875343 | |
| 12:27:56 | opendevreview | Rajesh Tailor proposed openstack/nova stable/wallaby: Fix rescue volume-based instance https://review.opendev.org/c/openstack/nova/+/875344 | |
| 12:28:38 | opendevreview | Merged openstack/os-vif stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875095 | |
| 12:28:40 | opendevreview | Merged openstack/os-vif stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875096 | |
| 12:29:21 | opendevreview | Merged openstack/osc-placement stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/875098 | |
| 12:29:29 | opendevreview | Rajesh Tailor proposed openstack/nova stable/xena: Handle InstanceInvalidState exception https://review.opendev.org/c/openstack/nova/+/875345 | |
| 12:30:13 | opendevreview | Rajesh Tailor proposed openstack/nova stable/wallaby: Handle InstanceInvalidState exception https://review.opendev.org/c/openstack/nova/+/875346 | |
| 12:30:38 | opendevreview | Merged openstack/python-novaclient stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875102 | |