Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-08-25
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
14:12:57 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
14:30:49 bauzas dansmith: can you just +2/+W that very old Flamingo patch that modifies the support envelope for our non-SLURP release ? https://review.opendev.org/c/openstack/nova/+/944018
14:30:56 bauzas this is too way overdue
14:32:32 dansmith bauzas: I thought we were sticking with two releases always to make sure we always support skip-level?
14:33:07 bauzas nope, we always set the minimum object version to N-1 if we are on a non-SLURP as we don't support skip-level for ops
14:33:21 dansmith ...but we run grenate-skip-level-always
14:33:35 dansmith I'm not sure why that didn't fail though (logs are gone)
14:33:37 bauzas indeed, but that's again not our support envelope
14:33:49 bauzas skip-level changes the option and bypasses that value then
14:33:58 dansmith does it?
14:34:00 bauzas (IIRC)
14:34:19 bauzas yeah, IIRC we have a flag that says "I gonna skip the min version"
14:34:26 bauzas for something we called FFU way long before
14:34:43 bauzas the beast is gone but the flag remains
14:34:44 dansmith if so I don't know where that is
14:35:31 bauzas https://review.opendev.org/c/openstack/nova/+/913890 was the one we merged for Dalmatian
14:36:22 dansmith yeah, I see, but .. I'm not sure that's right
14:36:22 bauzas NOVA_ENABLE_UPGRADE_WORKAROUND is the tempest flag if I'm not mistaken
14:38:07 bauzas https://opendev.org/openstack/grenade/src/branch/master/projects/60_nova/upgrade.sh#L77
14:38:20 dansmith I'm not sure skip-level-always actually does a multinode and leaves a node behind.. from the code I don't see how this would not break a skip level
14:38:22 bauzas that's the thing we did from Antelope and older
14:38:41 bauzas skip-level was turning the object version check off
14:39:02 bauzas but we always said that our support envelope was N-1

Earlier   Later