Earlier  
Posted Nick Remark
#openstack-nova - 2025-06-04
11:57:46 sean-k-mooney if we manage to get master workign with 3.13 we can access if we need to backprot stuff to epoxy
11:57:54 sean-k-mooney we do get clean unit and functional tests
11:58:08 sean-k-mooney so i dont think things are massively borken in nova
11:58:34 sean-k-mooney i.e. if the eventlet bugs were fix openstack might "just work" without code changes on expoxy
12:00:48 gibi we are the eventlet maintainers
12:01:07 sean-k-mooney kind of
12:01:30 gibi you can talk to hberaud about it
12:02:16 sean-k-mooney to me 3.13 supprot is not really optional
12:02:18 gibi if zigo could help maintaining eventlet in py313 that is a win for sure
12:02:56 sean-k-mooney by ya its partly a prioty probelm
12:03:27 sean-k-mooney gibi: there is currently a python discsion happenig about addign virtual tread to core pyton started by the gevent folks
12:03:28 gibi I think the reality is that we have limited eventlet internal knowledge to maintain it even if we find the time
12:04:21 zigo Hervé is in PTO this week, so I can't talk to him until Monday.
12:04:43 gibi zigo: yepp I know
12:39:38 Uggla stephenfin, thanks finding this bug. I'll fix it asap.
14:23:07 Uggla gibi, fyi I have reviewed the first patch of your eventlet serie and left comments/questions.
14:27:01 gibi Uggla: thanks a lot. I will reply you probably tomorrow
14:29:43 Uggla gibi, sure no hurries. As I mentioned it took me a while to review this first patch, I just hope I have not asked too much silly questions ?
14:31:25 gibi all questions are usefull :)
14:31:28 gibi so no worries
17:47:19 opendevreview Dan Smith proposed openstack/nova master: Remove contrib/clean-on-delete.py https://review.opendev.org/c/openstack/nova/+/950592
#openstack-nova - 2025-06-05
01:07:39 gmaan stephenfin
01:08:15 gmaan stephenfin: when you have time, can you please check these specs https://review.opendev.org/c/openstack/nova-specs/+/937650 https://review.opendev.org/c/openstack/nova-specs/+/951218
10:11:11 stephenfin gmaan: ack, will do
10:12:06 stephenfin gmaan: let me know if you want to discuss https://review.opendev.org/c/openstack/nova/+/936368 too. I'm *very* surprised there's been so much pushback on that, since it seems a no-brainer and is spec-compliant. I suspect you (and Uggla) might be missing something and that I haven't explained it properly
13:21:25 opendevreview Merged openstack/nova-specs master: Re-propose API policy service role spec https://review.opendev.org/c/openstack/nova-specs/+/951218
13:54:11 gibi Uggla: thanks for the review on the eventlet-removal series. I replied. I will respin the series based on you comments as there are points that worth to mention in the commit messages / doc tests
13:55:49 Uggla gibi, you're welcome. I have not continue reviewing the serie today, but I will try tomorrow or next week.
13:56:37 gibi cool
14:06:25 Uggla Maybe I should recommend for reviewers to read your latest blog post, before reviewing the first patch. It clarifies the context and the "service worker" bug.
14:08:06 gibi yeah the blog is there to give more context that is hard to give via a single commit message as it is not related to a single commit but a series of commits / events
14:32:16 stephenfin Uggla: Got another one for you to revisit when you have a chance https://review.opendev.org/c/openstack/nova/+/937047
15:10:42 gmaan stephenfin: thanks for review specs. for 936368, I will ping you top of hr, hope that is not late for u.
15:10:54 stephenfin ack
16:43:30 gmaan stephenfin: I read your reply, let me check some test for non-string as part of jsonschema as whole. I agree not to include those in format-checker tests
16:46:14 opendevreview Pierre Riteau proposed openstack/nova master: doc: Fix Caracal release number https://review.opendev.org/c/openstack/nova/+/951883
17:22:19 gmaan stephenfin: I am good on 936368, found the testing in controller tests which is what I was looking for
17:23:31 gmaan sean-k-mooney: in case you forgot :), manager role spec is ready https://review.opendev.org/c/openstack/nova-specs/+/937650
17:29:08 sean-k-mooney ill take a look later this evening
17:29:55 sean-k-mooney ah you renamed the file so i cant just see what chagned between v5 and v9 no worreis
17:46:37 gmaan for v5, yes it is renamed but you can see from ps7-ps9 (your last +1 ) https://review.opendev.org/c/openstack/nova-specs/+/937650/7..9
18:02:19 sean-k-mooney ack im writing something up which will take me about anouther hour or so. ill try an take a look after that
20:14:26 opendevreview Merged openstack/nova master: Remove contrib/clean-on-delete.py https://review.opendev.org/c/openstack/nova/+/950592
20:14:48 opendevreview Merged openstack/nova master: doc: Fix Caracal release number https://review.opendev.org/c/openstack/nova/+/951883
#openstack-nova - 2025-06-06
08:00:10 opendevreview Friedrich Hiekel proposed openstack/nova master: Fix nova-scheduler placement error https://review.opendev.org/c/openstack/nova/+/951936
09:42:49 stephenfin sean-k-mooney: Could you add this follow-up to your review queue? https://review.opendev.org/c/openstack/nova/+/951640/
09:43:18 sean-k-mooney im still going though my emilas this morning so i can review it now
09:43:48 sean-k-mooney ok so its a followup to api: Stop using wsgi.Controller.api_version to switch between API versions
09:44:53 stephenfin yup
09:45:01 stephenfin per gmaan's comments on same
09:47:09 sean-k-mooney cool done
09:47:51 sean-k-mooney assumign the parent pass ci this time it should be mergable when ever it gets to that point
10:39:28 opendevreview Stephen Finucane proposed openstack/nova master: api: Address issues with hypervisors APIs https://review.opendev.org/c/openstack/nova/+/950867
10:45:47 opendevreview Stephen Finucane proposed openstack/nova master: api: Address issues with instance actions API https://review.opendev.org/c/openstack/nova/+/951941
11:31:10 opendevreview Balazs Gibizer proposed openstack/nova master: Remove unused config options https://review.opendev.org/c/openstack/nova/+/951945
11:32:56 gibi sean-k-mooney: stephenfin: a follow up for WSGIServer removal ^^
11:33:39 sean-k-mooney didnt you propose that before i tough i reveied it
11:33:42 stephenfin I love deleting code
11:33:45 stephenfin done
11:33:56 gibi thanks
11:34:20 sean-k-mooney oh there are more cases we missed.
11:34:42 gibi yepp, I just detected them when I started looking at the deeventletification of nova-api
11:36:27 sean-k-mooney ok that going to conflcit with my pre-commit updates but ill approve and i cna update the last patch for bandit
11:36:52 sean-k-mooney stephenfin: since your about mind looking at https://review.opendev.org/q/topic:%22update-precommit%22
11:39:39 stephenfin done to
11:39:40 stephenfin *too
11:40:58 sean-k-mooney thanks, ill need to rebase the bandit one later but ill do that after the other changes have merged
11:56:05 stephenfin gmaan: sean-k-mooney: gibi: If any of you have the time/inclination, I could do with some thoughts on how to approach https://github.com/stephenfin/nova/commit/2d14a58f6310861b426359d71fba085e924e0538 (not pushed yet to avoid overwhelming Gerrit more than I have already)
11:56:38 stephenfin the tl;dr: is that our use of the "soft" additionalProperties validator doesn't work when oneOf is used
11:57:46 sean-k-mooney ... 4/6 just for servers. better then all in one but that going to be fun to review...
11:58:29 stephenfin That validator deletes unrecognised ("additional") keys from the input data. That's all fine and dandy normally, but when you're using 'oneOf' with 2 or more subschemas with non-overlapping keys, then keys that are invalid for an earlier schema but which are valid for a later schema will end up getting deleted
11:58:35 sean-k-mooney stephenfin: so it nice an short but is there a specic point you want input on
11:59:06 stephenfin yeah: how on earth do we work around this? 😅
11:59:24 sean-k-mooney jsut reading now
11:59:33 sean-k-mooney so ok were are you using onof there
12:00:06 sean-k-mooney ah
12:00:23 sean-k-mooney so either we get teh reservation_id
12:00:36 sean-k-mooney or the fulll server responce?
12:01:09 stephenfin yup
12:01:18 sean-k-mooney can we set addtionalProperties true in the reservation_id path
12:01:21 gibi stephenfin: I'm a bit low on context. Why does the validator delete keys based on earlier schemas?
12:01:26 stephenfin I didn't know that was a thing until I'd to write the schema for it
12:01:36 stephenfin gibi: sean-k-mooney: Here's a much smaller example https://paste.opendev.org/show/bpifVj7I2TTaQtFwVj4T/
12:02:03 sean-k-mooney stephenfin: reservation id is only used in multi create
12:02:09 stephenfin gibi: https://github.com/openstack/nova/blob/master/nova/api/validation/validators.py#L182
12:02:44 stephenfin first added here https://github.com/openstack/nova/commit/4fefd25c807c087694a0e66f4d91fe0e64ef3f18
12:03:16 sean-k-mooney let me try something locally for one sec
12:03:48 stephenfin gibi: the idea behind that appears to be to allow users to specify provide additional properties in requests when using the legacy v2 API, but to strip them out and ignore them so that e.g. they can't accidentally trigger code paths for newer API versions
12:04:02 stephenfin s/specify provide/provide/
12:05:34 stephenfin but if you apply that to that minimal reproducer I just shared, and make a request that satisfies the second subschema (e.g. {"bar": "hello, world"}) but not the first, we attempt to match against the first one and strip out properties that are not permitted by that
12:05:34 gibi stephenfin: I see so this is only for the legacy v2 compatible mode
12:05:38 stephenfin yes
12:06:42 gibi so the rule would be to strip out only those properties that are not in the oneOf branch that eventually matched. But I guess this is not easy to impelement in that context
12:06:51 stephenfin I've been sitting on this for a few months, and now that things are merging rapidly (thanks sean-k-mooney, gmaan), it's properly time to figure out a solution 😅
12:07:36 stephenfin no, unfortunately not
12:08:24 stephenfin jsonschema iterates through the oneOf entries and processes each subschema separately, so we have no visibility into anything "above" the subschema, if that makes senes
12:08:25 stephenfin *sense
12:09:49 gibi then the best we can do is that for those schemas that has oneOf we relax the current rule and always preserve additional properties
12:10:44 stephenfin Yeah, that's where I'm thinking we'll end up too. I just don't know the consequences of same
12:11:27 gibi this is a compatibility layer that should not really used any more

Earlier   Later