| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-25 | |||
| 09:46:41 | Uggla | @gibi, yes I think I have reviewed them, unless I miss one. | |
| 10:02:01 | opendevreview | Kamil Sambor proposed openstack/nova master: [hacking] Improve N373 to catch also other primitives https://review.opendev.org/c/openstack/nova/+/958408 | |
| 10:09:13 | elodilles | gibi: the release patches merged, things should be available on pypi and tarball.o.o, tags, etc., in some minutes | |
| 10:09:17 | elodilles | Uggla: ^^^ | |
| 10:13:53 | gibi | elodilles: thanks! | |
| 10:15:14 | elodilles | np | |
| 13:02:41 | opendevreview | Kamil Sambor proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | |
| 13:13:16 | hayashino | Could someone review this patch? https://review.opendev.org/c/openstack/nova/+/942167 | |
| 13:52:40 | opendevreview | Kamil Sambor proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | |
| 16:01:17 | bryanfraschetti | Hello Nova team o/ | |
| 16:01:17 | bryanfraschetti | Hope you're all doing well. I'm just wondering the current state of this bug: https://bugs.launchpad.net/nova/+bug/2039803, where live migration fails across similar hosts due to the compareHypervisorCPU check, and the associated topic: https://review.opendev.org/q/topic:%22bp/cpu-selection-with-hypervisor-consideration%22. I noticed that there was a recent comment | |
| 16:01:17 | bryanfraschetti | https://bugs.launchpad.net/nova/+bug/2039803/comments/9, which mentioned that replacing the baselineCPU method is one of the remaining missing puzzle pieces but I don't have a lot of context on what's been done and what's needed. | |
| 16:01:17 | bryanfraschetti | It might be worth mentioning that that we're seeing this on Ubuntu Jammy / Caracal, which contains the other two commits mentioned in that same comment. | |
| 16:32:03 | sean-k-mooney | bryanfraschetti: ya so it depend on the specific cpu version you have | |
| 16:32:11 | sean-k-mooney | the root cause si effectivly this | |
| 16:32:47 | sean-k-mooney | for some cpus the diffent ebtween the capablities api and domcapabiltys api out can cause the migration check in nova to fail | |
| 16:33:14 | sean-k-mooney | there is a workaroudn config option to disable the nova check in pre-migration and rely on the much later libvirt check | |
| 16:33:36 | sean-k-mooney | that is much more costly to revert when it fails but ti will work in more cases | |
| 16:34:01 | sean-k-mooney | the other alternitive is to use an explcit custom model instead of host-model or leaving the cpu_mode empty | |
| 16:34:19 | sean-k-mooney | cpu_mode unset and host-model are almsot but not quite identical | |
| 16:35:01 | sean-k-mooney | they are ment to select teh virtual cpu model that supprot hte largest subset of the host cpu features | |
| 16:35:20 | sean-k-mooney | that should be the closest cpu model to the hsot i.e. the host-model | |
| 16:36:04 | sean-k-mooney | for soem intel cpus in particalr but also newer amd cpus the odl and new api may differ. | |
| 16:36:14 | sean-k-mooney | using the new api in all places coudl fix it | |
| 16:36:41 | sean-k-mooney | the only concern then woudl be makeign sure the havior fo host-model and unset remains the same | |
| 16:37:42 | sean-k-mooney | bryanfraschetti: given Feature Freeze for this cycle is on thrusday this is not currently a priorty for the core team however if someone has time to work on fixign it we wont boject | |
| 16:37:59 | sean-k-mooney | but we likely wont have time to review for a week or two | |
| 16:56:11 | bryanfraschetti | Thanks @sean-k-mooney for the explanation that clarifies things a lot actually. So the issue isn't so much the new approach of comparing hypervisors but rather that there's mixed usage of new and old approaches to check the capabilities, which can sometimes disagree - especially on new intel cpus. Consistently applying the new approach should resolve the discrepancies, which makes sense. | |
| 16:56:11 | bryanfraschetti | Quick Q about the workaround options which skip the pre-migration check. What happens if these are enabled (eg. skip_cpu_check_on_start and skip_check_on_dest), but the hypervisors truly are incompatible and migration fails? Will this be caught by the libvirt check, and will the migration roll back - effectively not migrating, or will the migration be left in a broken state? | |
| 16:58:43 | gmaan | sean-k-mooney: on service role, I was checking if neutron has documented that nova service user need 'service' role or not but I could not find. Cinder has documented it so that is good. | |
| 16:59:24 | gmaan | sean-k-mooney: and I am now thinking many operator might have not have 'service' role and might have configured only admin role in neutron.conf | |
| 17:00:19 | gmaan | and nova policy change to 'role:service' will break them. I am now re-thinking on keep allowing admin also for those service API at least for this cycle - https://review.opendev.org/c/openstack/nova/+/957578/comment/a097d558_fee01375/ | |
| 17:00:45 | gmaan | and this cycle I can update neutron doc and release notes about requiring 'service' role to nova user | |
| 17:02:18 | gmaan | when I objected on not allowing admin, I thought of only direct user usage of service APIs which should be blocked right away but did not know that neutron did not state about 'service' role for their service users | |
| 17:02:49 | gmaan | and new default enable by default makes nova change to break such neutron deployment which has only admin role on nova user | |
| 17:04:26 | gmaan | I know you are ok with admin-or-service role but just want to confirm that we are on same page as I spent lot of time on service token things in tempest, neutron, oslo.policy check side which I should not have if discussed with you in advance :( | |
| 17:04:46 | sean-k-mooney | gmaan: so that why i orginlly propsoed doing `service or admin` last cycle | |
| 17:04:52 | sean-k-mooney | for upgrades | |
| 17:05:16 | sean-k-mooney | in our installer we alwasy create the users for service with both admin and service roles | |
| 17:05:43 | gmaan | yeah, I know. I thought admin role given to service user was just in devstack because we implies those in our policy but agree now that operator can have same | |
| 17:06:28 | sean-k-mooney | no that how kolla etcra all do it | |
| 17:06:30 | gmaan | let me update my change and once that is merged I can update the spec document also to sync with implementation | |
| 17:06:46 | sean-k-mooney | im not sure if kolla give both admin and serivice or just admin today | |
| 17:07:15 | sean-k-mooney | i think it became more comment when we started requiring it for nova and cinder to talk to each other | |
| 17:07:25 | sean-k-mooney | but i ahve not checked in a long time | |
| 17:08:02 | gmaan | yeah, I am not sure if they have service role but maybe | |
| 18:00:54 | sean-k-mooney | gmaan: the have supprote for at least ironci https://github.com/openstack/kolla-ansible/commit/600e912400ab8b52ca422f007f63da9d4fcc0a69 | |
| 18:01:44 | sean-k-mooney | https://github.com/search?q=repo%3Aopenstack%2Fkolla-ansible++role%3A+%5C%22service%5C%22&type=code | |
| 18:02:14 | sean-k-mooney | it looks like kolla at least does provide teh service role to several services but not to all | |
| 18:02:30 | sean-k-mooney | ironic nova cidner | |
| 18:02:59 | gmaan | yeah, and for neutron too so nova will be ok | |
| 18:03:27 | JayF | sean-k-mooney: I am not certain Ironic documents to use a service scope/role user | |
| 18:03:33 | JayF | sean-k-mooney: even if we permit and support it | |
| 18:03:34 | sean-k-mooney | oh i missed neutron yes | |
| 18:03:52 | JayF | sean-k-mooney: so we should ensure, if we're changing the shape of this, not only to ask what's possible, but ask what is likely and what path we've been asking folks to take | |
| 18:04:20 | gmaan | yeah, that is what i am mainly checking because most of the place it is done like 'neutron need admin to talk to nova' which is ok but still add service role too | |
| 18:04:52 | sean-k-mooney | JayF: right so orginally i propeose haveing the policy rule be admin_or_service for 1 slurp and then service_only | |
| 18:05:14 | sean-k-mooney | but we are tryign to determin if that is actuly required or not | |
| 18:05:25 | JayF | there's no doubt in my mind the answer is "yes" | |
| 18:05:31 | sean-k-mooney | to be safe we proably shoudl but we dropted that form this release spec | |
| 18:05:39 | sean-k-mooney | because we tought it was not required | |
| 18:05:46 | gmaan | we could avoid it if we implemeted it before we switch to enable the global new defaults | |
| 18:06:04 | sean-k-mooney | well we already did that no? | |
| 18:06:14 | sean-k-mooney | i tougl we did that a release or two ago | |
| 18:06:21 | sean-k-mooney | as part of phase 1 | |
| 18:06:29 | gmaan | yes I mean if new defaults were disabled by default then admin was added via old default by oslo.policy | |
| 18:06:43 | sean-k-mooney | oh | |
| 18:07:13 | sean-k-mooney | ok well ya that bridge has sailed... /me bridges dont sail boats do.... | |
| #openstack-nova - 2025-08-26 | |||
| 02:41:02 | opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | |
| 03:11:54 | opendevreview | Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578 | |
| 03:12:13 | gmaan | sean-k-mooney: ^^ updated service role change - https://review.opendev.org/q/topic:%22bp/policy-service-role-default%22+status:open | |
| 03:14:58 | gmaan | sean-k-mooney: I updated the tempest tests also. it seems neutron, cinder (for server external event and volume swap) still needs to assign admin role also to service user because nova need to perform the background task like get server/volume of other project which service user do not have access too. basically service user will have: | |
| 03:14:58 | gmaan | - service role: for nova to check the policy if request is from service or not. ( API policy will be default to 'role:service' only (admin also for this cycle) ) | |
| 03:14:58 | gmaan | - admin role: to perform the actual operation | |
| 03:15:43 | gmaan | i will check gate result if anything failing but for safer side I am testing cinder, neutron, ironic also depends-no on nova change | |
| 03:15:56 | gmaan | complete set with testing changes are https://review.opendev.org/q/topic:%22bp/policy-service-role-default%22+status:open | |
| 09:19:59 | opendevreview | Kamil Sambor proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | |
| 09:43:43 | ralonsoh | Hi folks, quick question, if you know how to do it and if it is possible. Can Nova serve the metadata compressed? Context: https://bugs.launchpad.net/neutron/+bug/2120723 | |
| 09:47:29 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Fix the help for hw:cpu_policy flavor extra spec https://review.opendev.org/c/openstack/nova/+/958524 | |
| 10:51:22 | sean-k-mooney | ralonsoh: not that im aware of, althoguh technically if your runing the wsgi applcaition under apache or similar it can add compressions | |
| 10:51:34 | sean-k-mooney | ralonsoh: we do not have code to compress it in nova itslef | |
| 10:51:47 | sean-k-mooney | but apache or nginx coudl do it | |
| 10:52:17 | sean-k-mooney | if it did that would be refected in headers in the reponce | |
| 10:53:44 | sean-k-mooney | if they are going via a loadblancer like haproxy that could also do compression tecnially btu i dont think that would be typical. | |
| 10:54:11 | sean-k-mooney | ralonsoh: my advice wodl be do not treat it as text but a binary string | |
| 10:54:23 | ralonsoh | sean-k-mooney, yeah, the problem is the metadata proxy in neutron | |
| 10:54:37 | ralonsoh | we are doing exactly that: treating the http content as text | |
| 11:13:04 | elodilles | sean-k-mooney: i've looked at the watcher release patch and i have a question there: https://review.opendev.org/c/openstack/releases/+/958468 | |
| 11:19:28 | sean-k-mooney | elodilles: replied its technically a bugfix bump not a patch bump but i can elevate it to a Feature/Minor bump if you like | |
| 11:19:42 | sean-k-mooney | the external api behavior should remain effectivly the same | |
| 11:20:20 | sean-k-mooney | i added translation code to make swap effectivly be migrate so even if you request swap it will now use migrate and be semanticly the same effect | |
| 11:20:54 | sean-k-mooney | elodilles: but i dont have a stong prefernce here so if you would like me to respin i can do that quickly just let me know either way | |
| 11:21:37 | elodilles | sean-k-mooney: neither have i :) | |
| 11:22:30 | sean-k-mooney | shall i update to minor? it will take like 5 mins | |
| 11:22:49 | sean-k-mooney | otherwise ill go back to code reivew :) | |
| 11:24:50 | elodilles | sean-k-mooney: i've upgraded to +2 then, but feel free to edit if you changed your mind o:) | |
| 11:27:28 | sean-k-mooney | we have elevated other secuirty patches to feature bumps in the past os for visiblity im torn. bugfix patches everyone shoudl basiclly take sometime folks are less inclined to take minor bumps but i still have the change open in emacs so let me quickly edit it and ill update teh commit message too | |
| 11:29:52 | priteau | Hello. Sorry to bother you again, we're still looking for approval for these stable backports: https://review.opendev.org/c/openstack/nova/+/945098 and https://review.opendev.org/c/openstack/nova/+/945099 | |
| 11:33:19 | sean-k-mooney | elodilles: updated | |
| 11:33:54 | sean-k-mooney | priteau: sure no worries i keep opening those and not finsihing revieing them ill do it now | |