| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-25 | |||
| 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 | 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: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: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 | - admin role: to perform the actual operation | |
| 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 | 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: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 | |
| 11:37:00 | elodilles | sean-k-mooney: +2'd, thanks! | |
| 11:39:17 | sean-k-mooney | priteau: elodilles i have +2w'd the 2024.2 version and +2'd the 2024.1 version of those so once the former merges elod can upgrade there +1 on the latter and merge them | |
| 11:42:04 | elodilles | ACK, i'll take an eye on it | |
| 11:47:20 | sean-k-mooney | general quetion for folks. how woudl people feel about have ing "meta traits" taht are reported if an only iff all the cpu feature flags for x86-64 version profile are met | |
| 11:47:22 | sean-k-mooney | https://en.wikipedia.org/w/index.php?title=X86-64§ion=20#Microarchitecture_levels | |
| 11:48:20 | sean-k-mooney | basiclly the libvirt driver would addtionally report x86-64-v2 if all of the cpu feature flags requried for that were actully supported | |
| 11:48:31 | sean-k-mooney | same for v3 and v4 | |
| 11:49:13 | sean-k-mooney | that would mean if you had a rhel 10 iamge for example that can only run on v3 you coudl do a singel required trait x86-64-v3 | |
| 11:49:40 | sean-k-mooney | instead of listing all of the v3 ones indeviually | |
| 11:51:31 | sean-k-mooney | you could go one step futher and supprot defining meta traits in placement directly so you would not need to report them but coudl request them and it do the translation internally | |
| 11:52:00 | sean-k-mooney | that could be very useful eventually but i am not sure i want to go that far right now | |
| 11:53:48 | sean-k-mooney | how that woudl work would be creatign a new api to define a meta traits as a union of other triaits (possible even a set of requried/forbiden triat instead of a plain union of required) and placement woudl just pre process the allocation candiate string and replace any meta taits with the expanded set | |
| 11:54:37 | sean-k-mooney | that woudl allow admins to defien there own but im not sure we need that level of flexablity | |
| 12:12:41 | opendevreview | Merged openstack/nova stable/2024.2: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/945098 | |
| 12:55:09 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Separate volume, snapshot and volume attachments https://review.opendev.org/c/openstack/nova/+/952347 | |
| 12:55:10 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Only apply "soft" additionalProperties validation to requests https://review.opendev.org/c/openstack/nova/+/952936 | |
| 12:55:10 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Use valid UUIDs for cinder resources https://review.opendev.org/c/openstack/nova/+/952935 | |
| 13:00:42 | stephenfin | sean-k-mooney: Those functional tests are fixed now, if you're game to re-apply your +2/+W? ^ | |
| 13:02:16 | sean-k-mooney | done ill let gmaan hit https://review.opendev.org/c/openstack/nova/+/952347/9 but the next 2-3? have +2w | |
| 13:02:26 | opendevreview | Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584 | |
| 13:03:02 | sean-k-mooney | as we dicussed offline once that batch is in we can see if you need to rebase the rest or if they will just apply | |
| 13:57:56 | opendevreview | Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584 | |