| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-24 | |||
| 12:09:37 | admin1 | nova migration-list shows the migration confirmed normally .. and virsh dumxml uuid all shows the migration went in fine | |
| 12:09:50 | admin1 | there is nothing running in hostA of that uuid | |
| 12:26:48 | opendevreview | Justas Poderys proposed openstack/nova-specs master: VirtIO PackedRing Configuration support https://review.opendev.org/c/openstack/nova-specs/+/868377 | |
| 14:11:39 | opendevreview | aarefiev proposed openstack/nova master: Doc: update live-migration cmd https://review.opendev.org/c/openstack/nova/+/875043 | |
| 15:08:59 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875095 | |
| 15:09:00 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875096 | |
| 15:09:01 | opendevreview | OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/os-vif/+/875097 | |
| 15:09:08 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/875098 | |
| 15:09:09 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/875099 | |
| 15:09:11 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/875100 | |
| 15:09:22 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875101 | |
| 15:09:23 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875102 | |
| 15:09:25 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875103 | |
| 15:26:15 | opendevreview | Takashi Natsume proposed openstack/placement master: Fix a wrong assertion method https://review.opendev.org/c/openstack/placement/+/861489 | |
| 15:52:39 | opendevreview | Merged openstack/python-novaclient master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/875103 | |
| 18:38:35 | gmann | bauzas: sorry I am little late for nova release highlights , should we mention about RBAC new defaults/scope are enabled by default now? This is important for operators to know. | |
| #openstack-nova - 2023-02-25 | |||
| 10:56:46 | sean-k-mooney | gmann: perhaps it would be better to do that in one place for all project that completed that phase | |
| 10:57:10 | sean-k-mooney | as an overall openstack feature highlight rahter then just for nova | |
| 10:57:42 | sean-k-mooney | there will be a callout for that anyway in teh features/upgrade section form the release note for the feature tooo | |
| 10:58:19 | sean-k-mooney | the other thing that woudl be good to call out at the opesntack level is declaring 2023.1 as the first SLU release | |
| 10:59:13 | sean-k-mooney | so that they know that we plan to supprot upgradign directly to 2024.1 skipping 2023.2 | |
| #openstack-nova - 2023-02-27 | |||
| 08:20:08 | bauzas | good morning Nova | |
| 09:52:39 | tobias-urdin | good morning o/ | |
| 09:53:28 | tobias-urdin | let's say I have hyperthreding enabled, is there any logic to schedule an dedicated pCPU instance to use one core and it's thread sibbling? to ensure no two instances are running on the same thread sibbling and shares that | |
| 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 | |