Earlier  
Posted Nick Remark
#openstack-nova - 2026-05-20
20:06:05 sean-k-mooney but 401 is not about roles or permeison
20:06:13 sean-k-mooney its about is the token exprie/valid
20:06:37 melwitt I thought that would include roles too though, no?
20:06:52 sean-k-mooney a 401 is an indtication to the client that it should reauthicate
20:06:59 sean-k-mooney adn retry
20:07:05 sean-k-mooney but you do not retyr a 403
20:07:29 sean-k-mooney form https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401
20:07:40 sean-k-mooney A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.
20:08:26 sean-k-mooney and form https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403 """Clients that receive a 403 response should expect that repeating the request without modification will fail with the same error. Server owners may decide to send a 404 response instead of a 403 if acknowledging the existence of a resource to clients with insufficient privileges is not
20:08:28 sean-k-mooney desired."""
20:09:16 sean-k-mooney melwitt: in general no
20:09:38 sean-k-mooney it can
20:09:44 gmaan so in this case, token is considered as invalid right
20:09:47 sean-k-mooney but it more the retry behvior diffent
20:09:58 sean-k-mooney the token is valid
20:10:04 sean-k-mooney but it has insufffenct privldages
20:10:19 melwitt 401 maybe you need to re-auth as a different project or role
20:11:24 sean-k-mooney i guess a client could choose to do that
20:12:01 sean-k-mooney eveutlly nova shoudl just be callign cidner with its own token with the service role on the user token
20:12:05 gmaan I think it is different from service token perspective. what keystonemiddlware consider a serviec token a valid if it has all requried role
20:12:23 sean-k-mooney and we shoudl not be lookign at the service_token at all for permsions in this case
20:12:28 gmaan otherwise a user token which is valid can always be a valid token but that is not the case if we see that as a serviec token
20:13:03 sean-k-mooney maybe
20:13:05 gmaan it just validate if service token send has required role to be consider as 'service' and if not then it is invalid "SERVICE TOKEN"
20:13:26 sean-k-mooney well
20:13:27 gmaan from suer tokjen perspective i agree on 401 vs 403
20:13:43 sean-k-mooney it need to do 2 things, validate it has the expecte roles adn that it has not expired
20:13:56 sean-k-mooney if both are ture the the service token is valid
20:14:04 gmaan yes
20:14:44 sean-k-mooney anyway did i understnad the fix in tempest is to accpet either 401 or 403
20:14:53 sean-k-mooney so that you can tolerate either behvior
20:14:54 gmaan yes
20:15:22 gmaan it was only 403 previously bcz service token roles were not validated before
20:15:30 sean-k-mooney that fair you have a few whit space issue by th ewya
20:15:52 sean-k-mooney well yes and no it was optional and off by default
20:15:55 sean-k-mooney but for the cve
20:16:08 sean-k-mooney we added validation in the code spereate from the policy layer
20:16:28 gmaan i thought of adding a new config option to check 401 but that will be unnecessary as service_token_roles_required os a temp config option and should be removed at the end
20:16:55 gmaan it was added for migration purpose and never got moment to be default to True and then removed
20:17:06 gmaan same as enforce_scope in RBAC
20:17:21 sean-k-mooney same as the fallback for threaing pcpus as vcpus
20:17:39 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/975779
20:17:43 gmaan yeah, i do not know if it is good to be less aggressive on those things or bad :)
20:18:57 sean-k-mooney well ^ was deprecated in nova 20.0.0
20:19:57 sean-k-mooney which was trian
20:20:18 sean-k-mooney i think that one os more then overdue to be disabel by default and we proably shoudl delete it :)
20:21:25 sean-k-mooney we have a habbit of not cleaing up these migrtion path for many many many years after they were ment to be removed
20:23:59 gmaan yeah
20:24:36 gmaan and by then they become a valid thing for operators than just migration path :)
20:25:19 gmaan I will be more than happy if i can remove enforce_scope this cycle but I know it will fail many project tests and they will not fix it on time
20:25:44 gmaan and breaking them might be the only option to proceed
20:35:03 sean-k-mooney gmaan: if you do it kinder to do it early
20:35:15 sean-k-mooney i.e. at m1 or m2
20:37:37 gmaan m1 was too early to fix the things so i sent m2 as deadline in ML
20:38:30 gmaan doing it in m1 could be better but then it would not give time for projects to fix tests or change default who still disable it
20:40:21 sean-k-mooney thats fair. on the otherhadn the default was change in oslo a few cycles ago right
20:40:28 sean-k-mooney that was ment to be the time to adapt
20:40:31 gmaan yes
23:21:59 opendevreview Masanori Ueno proposed openstack/nova master: NUMA live-migration: ensure allocation_ratio is respected https://review.opendev.org/c/openstack/nova/+/989378
23:22:54 opendevreview Merged openstack/nova master: Add reproducer test for bug 2105896 https://review.opendev.org/c/openstack/nova/+/946945
#openstack-nova - 2026-05-21
02:18:34 opendevreview Ghanshyam Maan proposed openstack/nova-specs master: Spec for the graceful shutdown part2: Task tracking https://review.opendev.org/c/openstack/nova-specs/+/986447
03:04:18 gmaan melwitt: gibi_off ^^ graceful shutdown spec is ready for review
04:01:37 opendevreview Merged openstack/nova master: Fix error when multiple security group in a project with same name https://review.opendev.org/c/openstack/nova/+/970337
04:01:51 opendevreview Merged openstack/nova master: tests: Filter out (more) eventlet deprecation warnings https://review.opendev.org/c/openstack/nova/+/974686
04:44:04 opendevreview Merged openstack/nova master: console: Fix type error https://review.opendev.org/c/openstack/nova/+/974687
06:56:17 opendevreview Pierre Riteau proposed openstack/nova master: Fix typo in log message https://review.opendev.org/c/openstack/nova/+/989482
07:03:44 priteau Hello Uggla, do you think you could backport https://review.opendev.org/c/openstack/nova/+/946945 and https://review.opendev.org/c/openstack/nova/+/970337? Gerrit won't let me do it because not Signed-off-by author/committer/uploader in message footer
07:08:49 opendevreview Merged openstack/nova master: Do not log metadata proxy shared secret https://review.opendev.org/c/openstack/nova/+/988501
07:46:27 Uggla priteau, I'm gonna have a look. But it might be possible. Do you want to backport to 2026.1 or older branches ?
08:26:58 priteau Uggla: 2026.1 first, then 2025.2 and 2025.1
08:27:10 priteau I think the issue was introduced on 2025.1
10:47:39 frickler priteau: iiuc you can edit the commit message in the cherry-pick UI and add your sign-off there?
11:50:28 opendevreview Stephen Finucane proposed openstack/nova master: Add ruff-check https://review.opendev.org/c/openstack/nova/+/974441
11:50:29 opendevreview Stephen Finucane proposed openstack/nova master: Replace use of datetime.timezone.UTC https://review.opendev.org/c/openstack/nova/+/989515
12:04:30 priteau frickler: of course I can also submit with my own Signed-off footer, just felt a bit weird to add my name to a patch I wasn't involved with
12:18:45 opendevreview ribaudr proposed openstack/nova master: Fix outdated docstring in PciDevTracker.update_devices_from_hypervisor_resources https://review.opendev.org/c/openstack/nova/+/989518
12:26:24 opendevreview ribaudr proposed openstack/nova stable/2026.1: Add reproducer test for bug 2105896 https://review.opendev.org/c/openstack/nova/+/989519
12:26:25 opendevreview ribaudr proposed openstack/nova stable/2026.1: Fix error when multiple security group in a project with same name https://review.opendev.org/c/openstack/nova/+/989520
12:46:07 Uggla Reminder: Today is spec review day 1
13:01:37 opendevreview ribaudr proposed openstack/nova stable/2025.2: Add reproducer test for bug 2105896 https://review.opendev.org/c/openstack/nova/+/989529
13:01:38 opendevreview ribaudr proposed openstack/nova stable/2025.2: Fix error when multiple security group in a project with same name https://review.opendev.org/c/openstack/nova/+/989530
13:49:11 opendevreview ribaudr proposed openstack/nova stable/2025.1: Add reproducer test for bug 2105896 https://review.opendev.org/c/openstack/nova/+/989535
13:49:12 opendevreview ribaudr proposed openstack/nova stable/2025.1: Fix error when multiple security group in a project with same name https://review.opendev.org/c/openstack/nova/+/989536
13:59:19 Uggla priteau ^ fyi backports to the wished branches
15:37:00 priteau Uggla: many thanks!
15:40:11 priteau Unfortunately tox-cover seems to be unreliable on 2026.1 :(
16:04:20 opendevreview Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376
17:14:12 opendevreview Elod Illes proposed openstack/nova stable/2025.1: DNM: grenade job test https://review.opendev.org/c/openstack/nova/+/989579
17:38:52 melwitt gmaan: ack will look
19:02:22 opendevreview melanie witt proposed openstack/nova stable/2026.1: [openstack-tox-cover]Increase timeout further https://review.opendev.org/c/openstack/nova/+/989605
20:41:02 opendevreview melanie witt proposed openstack/nova stable/2026.1: Increase wait retries for resize reschedule functional test https://review.opendev.org/c/openstack/nova/+/989619
21:12:11 melwitt priteau: I think this is the flakiness you are seeing on 2026.1 ^ I have seen this particular test fail multiple times in openstack-tox-cover build history on the branch
21:13:01 melwitt I think the coverage instrumentation exacerbates the issue as the test waits a fairly low amount of time before timing out the wait for state change
22:24:36 melwitt sean-k-mooney[m]: small question on https://review.opendev.org/c/openstack/nova/+/975872 on the debug logging, the rest looks great thanks
#openstack-nova - 2026-05-22
03:01:47 opendevreview Merged openstack/nova master: Refactor get_flavor_by_flavor_id() to require context https://review.opendev.org/c/openstack/nova/+/987723
04:34:48 opendevreview Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633
05:25:19 opendevreview Goutham Pacha Ravi proposed openstack/nova-specs master: Add virtiofs cold migration spec https://review.opendev.org/c/openstack/nova-specs/+/985738
06:17:15 opendevreview Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633
06:19:23 opendevreview Goutham Pacha Ravi proposed openstack/nova master: Support cold migration with virtiofs shares https://review.opendev.org/c/openstack/nova/+/989633
14:55:28 tstachecki Hi, I can come discuss on the next Nova weekly, but wanted to see if anyone had any feedback on us working with Ceph upstream to add an additional field to 'ceph mon dump' output to include FQDNs instead of IP addresses. The FQDN would be a new field in the mon dump so we don't break existing OpenStack users using IP addresses or using an older version of Ceph.

Earlier   Later