Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-11-13
21:00:24 s3rj1k hmm, lemme check
21:01:14 sean-k-mooney no rush can you update the bug wiht your finding either way
21:03:31 sean-k-mooney the revert is good to do anyway but i think im going to finish for today
21:06:31 s3rj1k sean-k-mooney: yep, fails without revert
21:06:52 s3rj1k i'll update bugreport
21:10:53 s3rj1k done https://bugs.launchpad.net/nova/+bug/2086867/comments/5
21:11:03 s3rj1k thanks Sean!
21:12:50 sean-k-mooney cool then lets proceed with the revert we can follow up with others to review tomrorow
21:13:21 s3rj1k I'll also will revalidate that after merge on clean DevStack, just in case :)
21:13:58 sean-k-mooney we may want to consider twakign ci to be able to test this but i think that is best left to a followup
#openstack-nova - 2024-11-14
05:38:26 opendevreview melanie witt proposed openstack/nova master: nova-manage: Add flavor scanning to migrate_to_unified_limits https://review.opendev.org/c/openstack/nova/+/924110
05:38:27 opendevreview melanie witt proposed openstack/nova master: Add [quota]unified_limits_required_resources list https://review.opendev.org/c/openstack/nova/+/924025
08:23:09 bauzas happy spec review day, folks
08:29:53 opendevreview Max proposed openstack/nova master: fix: leftover BDM after instance delete https://review.opendev.org/c/openstack/nova/+/934984
09:41:13 opendevreview Max proposed openstack/nova master: fix: leftover volume_attachment on instance delete https://review.opendev.org/c/openstack/nova/+/934984
10:43:24 opendevreview OpenStack Release Bot proposed openstack/nova master: reno: Update master for unmaintained/2023.1 https://review.opendev.org/c/openstack/nova/+/935117
10:43:53 opendevreview OpenStack Release Bot proposed openstack/os-vif master: reno: Update master for unmaintained/2023.1 https://review.opendev.org/c/openstack/os-vif/+/935119
10:44:33 opendevreview OpenStack Release Bot proposed openstack/osc-placement master: reno: Update master for unmaintained/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/935121
10:45:02 opendevreview OpenStack Release Bot proposed openstack/placement master: reno: Update master for unmaintained/2023.1 https://review.opendev.org/c/openstack/placement/+/935123
10:45:32 opendevreview OpenStack Release Bot proposed openstack/python-novaclient master: reno: Update master for unmaintained/2023.1 https://review.opendev.org/c/openstack/python-novaclient/+/935125
15:43:07 simondodsley How often are new Nova bugs looked at? I have a customer who raised a bug (https://bugs.launchpad.net/nova/+bug/2080531) on 09/12 and it hasn't been triagged by the looks of it.
15:55:05 artom Left a question about the need for a new microversion on https://review.opendev.org/c/openstack/nova/+/873901 - is gmann still our microversion guru?
15:57:21 gibi artom: is this transforming an unhandled exception to a handled exception on the API, if so then it does not need a microversion
15:57:50 gibi the addition of the possible new return code 409 is more gray area to me
15:58:22 artom gibi, yeah, that latter point is a gray area for me too.
15:58:45 artom And it's the crux of my question.
15:59:31 gibi According to the OpenStack API Working Group, a 500 Internal Server Error should NOT be returned to the user for failures due to user error that can be fixed by changing the request on the client side. This kind of a fix doesn’t require a change to the microversion.
15:59:36 gibi https://docs.openstack.org/senlin/ocata/developer/api_microversion.html
16:00:38 gibi so if it was a 500 then I would say according to the diagram we don't need a new microversion.
16:00:59 gibi but if we want to be safe then we can change the patch to return 400 instead of 409 and then it is not a new status code either
17:28:47 artom Yeah, I'm just not sure how to treat the fact that clients out there might not be equipped to deal with a 409 for that particular API
17:48:44 gibi then lets switch it to 400. 400 is generic so it is not a problem to return it, we just cannot return the most specific code we want
17:51:07 melwitt I'm not sure if we have to stick to only the 400's that are currently there. gmann can you remind me are we allowed to add say 409 to an API that already has 400 and 403 without a microversion? ^
17:51:47 sean-k-mooney i think this is in the microvertion doc we can go to 403
17:51:59 sean-k-mooney and we can go to any exsitng code use by that api
17:52:12 sean-k-mooney so if 409 is used for soemthign elce for that action then we can extend that
17:52:13 melwitt ok, so it has to be an existing code. I didn't remember that
17:52:34 sean-k-mooney well that im not sure of but i know we are allwoed to go form 500 to an existing code
17:52:44 sean-k-mooney and 401 and 403 are alwasy allowed in addtion to 400
17:52:52 sean-k-mooney 409 i not sure
17:53:11 melwitt ack
17:53:23 sean-k-mooney i alwasy have to look that last point up
17:53:38 sean-k-mooney https://docs.openstack.org/nova/latest/contributor/microversions.html
17:54:09 sean-k-mooney he exception to not needing a microversion when returning a previously unspecified error code is the 400, 403, 404 and 415 cases.
17:55:54 sean-k-mooney 400 is more correct anyway as its not a issue with the stae of things
17:56:18 sean-k-mooney its an issue wth the contet of the request
17:56:36 sean-k-mooney although i can see an argument for 409 on other grounds
17:56:59 sean-k-mooney i personlay argued for 409 before
17:57:23 sean-k-mooney but i didnt think we shoudl backport this then
17:58:00 sean-k-mooney if i recall when i reviewd this in the past i argued that it shold be a case sensieive check
17:59:16 sean-k-mooney we went back and forth on that bug a few times
19:10:09 sean-k-mooney by the way since its a spec review day https://review.opendev.org/c/openstack/nova-specs/+/934391 it would be nice to move forward with the unified limits spec
19:23:05 sean-k-mooney dansmith: ^ is that something you have time to look at today
20:19:09 mikal In terms of spec reviews, https://review.opendev.org/c/openstack/nova-specs/+/932387 should be relatively trivial too given it has a +2 and is largely unchanged from last time.
20:43:11 opendevreview Merged openstack/os-vif master: reno: Update master for unmaintained/2023.1 https://review.opendev.org/c/openstack/os-vif/+/935119
22:52:07 opendevreview Merged openstack/nova master: Clean up the remaining logic for Windows OS Support https://review.opendev.org/c/openstack/nova/+/932407
#openstack-nova - 2024-11-15
00:51:06 gmann melwitt: sean-k-mooney artom gibi, if we return 409 then it need microversion. Only way to avoid microversion is if we are returning existing error code (400, 403, 404 and 415 are always return from all APIs). I think returning 400 here as gibi mentioned is good candidate.
01:13:23 melwitt thanks gmann for confirming
03:10:02 opendevreview melanie witt proposed openstack/nova master: nova-manage: Add flavor scanning to migrate_to_unified_limits https://review.opendev.org/c/openstack/nova/+/924110
08:45:38 opendevreview Merged openstack/nova-specs master: Repropose spice-direct console support. https://review.opendev.org/c/openstack/nova-specs/+/932387
11:20:00 stephenfin gmann: sean-k-mooney: I wonder if you'd be able to take another look through the openapi series today/early next week. It starts here (Sean has already reviewed the first few) https://review.opendev.org/c/openstack/nova/+/915742
11:30:43 opendevreview Amit Uniyal proposed openstack/nova master: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/929858
13:21:34 opendevreview Rajesh Tailor proposed openstack/nova master: Fix case-sensitivity for metadata keys https://review.opendev.org/c/openstack/nova/+/873901
15:08:19 gibi I feel sad about https://bugs.launchpad.net/nova/+bug/1854844/comments/7
15:17:00 artom Yeah, that's not great UX
15:17:31 artom That being said, I think having an expectation that you can just plop a patch into a comment and have it magically fixed and merged by someone else is misplaced as well
15:18:01 dansmith yep
15:18:29 dansmith definitely unfortunate, but...
15:18:46 gibi sure they shown goodwill by sharing the patch but we shown goodwill to keeping nova alive
15:20:43 gibi so if they can have a limit the we can have it too
16:05:57 opendevreview Dmitriy Rabotyagov proposed openstack/nova master: Handle MAC dash-addresses during migration https://review.opendev.org/c/openstack/nova/+/919760
17:29:32 gmann stephenfin: ack, will check today or early next week
18:47:14 opendevreview melanie witt proposed openstack/nova master: nova-manage: Add flavor scanning to migrate_to_unified_limits https://review.opendev.org/c/openstack/nova/+/924110
#openstack-nova - 2024-11-16
02:43:19 opendevreview melanie witt proposed openstack/nova master: nova-manage: Add flavor scanning to migrate_to_unified_limits https://review.opendev.org/c/openstack/nova/+/924110
02:56:06 opendevreview Ghanshyam proposed openstack/nova master: Remove default override for config options policy_file https://review.opendev.org/c/openstack/nova/+/934578
#openstack-nova - 2024-11-17
18:22:42 opendevreview Artom Lifshitz proposed openstack/nova master: libvirt pwr mgmt: reproduce bug 2085122 https://review.opendev.org/c/openstack/nova/+/932922
18:22:43 opendevreview Artom Lifshitz proposed openstack/nova master: pwr mgmt: power down free PCPUS when updating compute node https://review.opendev.org/c/openstack/nova/+/932926
21:29:16 opendevreview Artom Lifshitz proposed openstack/nova master: pwr mgmt: power down free PCPUS when updating compute node https://review.opendev.org/c/openstack/nova/+/932926
#openstack-nova - 2024-11-18
08:57:49 gibi hi folks! Can I get a second core on the backport https://review.opendev.org/c/openstack/nova/+/934302 (and its parent)?
12:03:03 opendevreview Merged openstack/nova stable/2024.2: Reproduce bug 2085975 in functional https://review.opendev.org/c/openstack/nova/+/934301
12:45:14 sean-k-mooney gibi: that should merge shortly ill look at the next branch later but im sure its fine
12:45:50 gibi sean-k-mooney: thanks!
12:53:40 zigo https://buildd.debian.org/status/fetch.php?pkg=nova&arch=all&ver=2%3A30.0.0-2&stamp=1731930425&file=log
12:53:40 zigo I'm now hit by the crypt.crypt removal in Python 3.13:
12:54:08 zigo tkajinam: Do you think your patch here https://review.opendev.org/c/openstack/oslo.utils/+/931899 could be used for it?
12:56:35 zigo BTW, I don't think we should keep using md5 as algo, like the comment above https://github.com/openstack/nova/blob/master/nova/virt/disk/api.py#L634 says. Any distro still using md5 shouldn't be consider at this time and age.
13:01:57 zigo gibi: bauzas: sean-k-mooney: Would it be accepted by the team if I was to propose a patch that does SHA-512 instead, and drop support for MD5 ?
13:02:39 sean-k-mooney zigo: i dont have context but there are some places where we cant do that for upgrade reaons
13:03:08 zigo sean-k-mooney: I believe nova/virt/disk/api.py is the bit that is doing password injections in VMs.
13:03:18 zigo (I didn't check much, but should be...)
13:03:32 zigo The comment says md5, because some distro may be outdated.
13:04:07 gibi zigo: yeah that codepath generates the content of the shadow file so we need to make sure whathever we change there still works with old but not super old linux distros
13:04:13 zigo This was in 2012 ...
13:04:41 zigo gibi: Fast forward 12 years later, md5 is a security hole...
13:04:48 gibi I'm aware
13:04:59 zigo I'm sure you are.
13:05:14 zigo So question still is: is it ok if we drop support for distros with such security hole? :)
13:05:52 gibi OK, if you ask this way then it sounds right to say no, we should not support distros that uses md5 for the root password's hash
13:06:06 gibi I'm sold
13:06:19 zigo Thanks for confirming, I'll try to write a patch.

Earlier   Later