| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-07 | |||
| 17:52:28 | sean-k-mooney | but i dont know if that is healty or not | |
| 17:52:49 | sean-k-mooney | last release was a year ago "Jun 28, 2022" | |
| 17:53:27 | sean-k-mooney | it officlally supprot up to 3.9 but i dont knwo if we will start seeing issues with 3.11 | |
| 17:53:52 | sean-k-mooney | 3.10 and 3.11 started removing some deperecated features | |
| 22:21:31 | opendevreview | Merged openstack/python-novaclient master: Update master for stable/2023.2 https://review.opendev.org/c/openstack/python-novaclient/+/894077 | |
| #openstack-nova - 2023-09-08 | |||
| 09:28:45 | opendevreview | liwenjian proposed openstack/nova master: Fixed an error when caching multiple images in aggregate https://review.opendev.org/c/openstack/nova/+/894288 | |
| 18:52:04 | atmark | hello, I have 8 computes and all showed up I ran `nova-manage cell_v2 list_hosts` however, `nova-manage cell_v2 discover_hosts --verbose` showed only 6 computes | |
| 18:52:06 | atmark | https://paste.openstack.org/show/bGqEX1e8TPAsE2zHsEO1/ | |
| 18:53:03 | atmark | running stable/victoria | |
| 19:02:05 | dansmith | atmark: the list shows that they're mapped. if you run discover again, does it continue to show only six? I think it should show none now | |
| 19:10:46 | atmark | yes, it's still showing six | |
| 19:11:47 | atmark | I ran discover multiple times and returns six | |
| #openstack-nova - 2023-09-11 | |||
| 02:53:00 | opendevreview | Ghanshyam proposed openstack/nova master: Remove the Hyper-V driver https://review.opendev.org/c/openstack/nova/+/894466 | |
| 07:00:06 | frickler | the new oslo.log release seems to need changes in nova unit tests, please check https://review.opendev.org/c/openstack/requirements/+/892928 | |
| 08:22:00 | bauzas | frickler: looking | |
| 09:12:15 | sean-k-mooney | frickler: we are passed the non client lib freeze | |
| 09:12:25 | sean-k-mooney | why is there a 5.3.0 happening now | |
| 09:24:00 | bauzas | my bad, I thought it was related to https://bugs.launchpad.net/ironic/+bug/2030976 but actually no, so indeed this isn't an urgency, right? | |
| 09:24:24 | bauzas | anyway, this is u-c, not a nova change | |
| 09:24:29 | sean-k-mooney | it would break master when it becomes caracl | |
| 09:24:55 | sean-k-mooney | the reason im askin gis do then intend 5.3.0 to be part of bobcat or not | |
| 09:25:52 | sean-k-mooney | we have not cut RC1 yet | |
| 09:26:15 | sean-k-mooney | so we shoudl not really be merging any changes for this until after that is done | |
| 09:26:30 | bauzas | https://docs.openstack.org/releasenotes/oslo.log/unreleased.html | |
| 09:26:46 | bauzas | if this is just for deprecating os-win, meh | |
| 09:27:12 | sean-k-mooney | deprecations need to go out in a slurp anyway so i think this can wait | |
| 09:27:30 | bauzas | sean-k-mooney: but maybe frickler wants to merge this u-c change after RC1 ? | |
| 09:27:33 | sean-k-mooney | it must contain something else too | |
| 09:27:58 | sean-k-mooney | ya perhaps and that is fine | |
| 09:28:34 | sean-k-mooney | i woudl just prefer to hold this until RC1 is cut but once it is we can correect whatever the unit test fallout is | |
| 09:29:18 | sean-k-mooney | https://github.com/openstack/oslo.log/compare/5.2.0...5.3.0 | |
| 09:29:27 | bauzas | https://github.com/openstack/oslo.log/compare/5.3.0...5.2.0 | |
| 09:29:31 | bauzas | heh | |
| 09:29:46 | sean-k-mooney | https://github.com/openstack/oslo.log/commit/6abf69e194c9dac13d26bca3e7ac1f710f9e26a0 | |
| 09:29:58 | sean-k-mooney | so they are droping 3.8 support | |
| 09:30:02 | sean-k-mooney | that is why its breaking things | |
| 09:30:10 | sean-k-mooney | so this cant merge in bobcat | |
| 09:30:25 | bauzas | right | |
| 09:31:01 | bauzas | and the relnotes are actually silent, which is sad | |
| 09:32:35 | sean-k-mooney | i -1'd the uc patch | |
| 09:32:58 | sean-k-mooney | and linked to the relevent commits and upstream runtimes | |
| 09:34:20 | sean-k-mooney | funillay enough this failind in the py310 job | |
| 09:34:23 | sean-k-mooney | https://6bd5f66fe830a1e3af93-5011cbf696878119f18f8b3f0098ae5d.ssl.cf1.rackcdn.com/892928/1/check/cross-nova-py310/9f15891/testr_results.html | |
| 09:36:07 | bauzas | sorry for lagging but this morning, I'm switching from 4G to fiber (which is back, woohooo) and testing a few things | |
| 09:36:53 | bauzas | I have an unifi USG as my home gateway and I'm tempted to stick with a passive HA mode with 4G :) | |
| 09:37:02 | elodilles | bauzas sean-k-mooney : the release is part of bobcat and it was released in time. when the release is out, then a requirements patch (upper-constraint bumping patch) is generated, that tests compatibility. this seems to be failing now | |
| 09:37:24 | bauzas | elodilles: I don't disagree | |
| 09:37:31 | sean-k-mooney | elodilles: well as i noted that oslo tag increases the min python to 3.9 | |
| 09:37:40 | bauzas | elodilles: but we're just saying that we can't import it in our bobcat release | |
| 09:37:49 | sean-k-mooney | elodilles: so it cannot be inclucded in bobcat without reverting that | |
| 09:37:54 | bauzas | anyway, kids taxi for a couple of mins | |
| 09:38:57 | sean-k-mooney | on wait... | |
| 09:39:12 | sean-k-mooney | 2023.2 i bobcat | |
| 09:39:28 | sean-k-mooney | ok actully it can be incled but i would still consider this late | |
| 09:39:59 | elodilles | sean-k-mooney: it didn't drop py38 support. py38 is still the min python | |
| 09:40:17 | sean-k-mooney | no it did https://github.com/openstack/oslo.log/commit/6abf69e194c9dac13d26bca3e7ac1f710f9e26a0 | |
| 09:40:21 | sean-k-mooney | python_requires = >=3.9 | |
| 09:40:41 | sean-k-mooney | but 2023.2 is bobcat and bocat technially did drop 3.8 support | |
| 09:40:55 | sean-k-mooney | however we didnt put in a min python_requires in nova | |
| 09:41:17 | sean-k-mooney | we did attempt too but there was objections to that as it would break other porjects that did not have that change | |
| 09:41:39 | elodilles | sean-k-mooney: all the py38 patches were reverted. here i see: https://opendev.org/openstack/oslo.log/src/commit/b5b8c30b0d925aa3d31b58932c94586631827b62/setup.cfg#L9 | |
| 09:42:02 | elodilles | * py38 dropping patches | |
| 09:42:12 | sean-k-mooney | oh just reread the runtimes patch too """All Python-based projects must additionally target and test against following Python versions: | |
| 09:42:14 | sean-k-mooney | Python 3.8 (available as default in Ubuntu 20.04) | |
| 09:42:16 | sean-k-mooney | " | |
| 09:42:18 | sean-k-mooney | "" | |
| 09:42:35 | sean-k-mooney | ok so they reverted that | |
| 09:42:42 | elodilles | yepp | |
| 09:43:14 | sean-k-mooney | so im still trying to figure out why its failing as none of the failing test cases test/use oslo log fucntionality | |
| 09:43:24 | sean-k-mooney | i think this is actully breakign due to privsep somehosw | |
| 09:44:09 | elodilles | anyway, this needs to be sorted out together with oslo team, as Bobcat final release is in 3 weeks | |
| 09:44:53 | elodilles | I'd say if there is an easy fix in nova, then we should add that fix in nova ASAP, because it's easier then to invalidate a release | |
| 09:45:13 | elodilles | sean-k-mooney: thanks for looking into the issue | |
| 09:46:05 | sean-k-mooney | oh https://github.com/openstack/oslo.log/compare/5.2.0...5.3.0 is not in revers chronalogical order | |
| 09:46:22 | sean-k-mooney | so ya i see teh revert i was confued by that | |
| 09:47:00 | elodilles | ++ | |
| 09:47:44 | sean-k-mooney | im not seeing any change there that could cause this so i think it must be form a change in privsep | |
| 09:47:49 | sean-k-mooney | well | |
| 09:47:53 | sean-k-mooney | we do actully log her | |
| 09:47:57 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/privsep/utils.py#L43-L90 | |
| 09:48:40 | sean-k-mooney | in the failing test we are makign this raise an error https://github.com/openstack/nova/blob/master/nova/privsep/utils.py#L57 | |
| 09:49:11 | sean-k-mooney | specificaly value error | |
| 09:49:20 | sean-k-mooney | and we are expecting to take this path https://github.com/openstack/nova/blob/master/nova/privsep/utils.py#L76-L78 | |
| 09:50:28 | sean-k-mooney | we mock os.write and assert its not called here https://github.com/openstack/nova/blob/master/nova/privsep/utils.py#L61 | |
| 09:50:39 | sean-k-mooney | sorry off by one | |
| 09:50:41 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/privsep/utils.py#L62 | |
| 09:51:21 | sean-k-mooney | im wondering if the LOG.error in the excption block is somehow counting as a call to os.write | |
| 09:51:51 | sean-k-mooney | in the unit test we shoudl be using a stringIO buffer for logging in the test fixture | |
| 09:52:03 | sean-k-mooney | so there shoudl not be aby write calls to stdout or a file | |
| 09:52:36 | sean-k-mooney | ill see if i can repoduce it locally but it does not really make sesne why this would pass on 5.2.0 and not 5.3.0 | |
| 09:53:01 | frickler | sorry, was away for a bit. in general, new openstack library releases are not affected by requirements freeze I think. in particular if merging them is delayed by other projects | |
| 09:54:12 | frickler | so oslo.log 5.3.0 is part of the bobcat release and thus should make it into u-c as well if possible | |
| 09:55:11 | frickler | ah, elodilles said that in between already | |
| 10:04:09 | sean-k-mooney | frickler: the final release is ment to happen before FF | |
| 10:04:21 | sean-k-mooney | that why we have the non client freeze before it | |
| 10:04:50 | sean-k-mooney | so we do not expect to have any new non-client release in uc between FF and RC-1 unless its an RC-1 fix | |
| 10:05:31 | sean-k-mooney | it looks like the release was actully done 13 days ago | |
| 10:05:40 | sean-k-mooney | so that would have been before FF | |
| 10:05:57 | frickler | yes, it is just the u-c bump that is lagging | |
| 10:06:37 | sean-k-mooney | right which is not good because that kidn of defeats the reason for the eailer releas | |