820 lines
44 KiB
Plaintext
820 lines
44 KiB
Plaintext
{
|
|
"comments": [
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "a776c65a_4f0884b6",
|
|
"filename": "/COMMIT_MSG",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 24,
|
|
"author": {
|
|
"id": 29313
|
|
},
|
|
"writtenOn": "2024-02-21T13:30:48Z",
|
|
"side": 1,
|
|
"message": "Hi. I\u0027m fine with removing Node.js from the runtime. We can follow a similar approach to what we do for the Django version in Horizon, such as supporting the current LTS version of nodejs.",
|
|
"range": {
|
|
"startLine": 21,
|
|
"startChar": 0,
|
|
"endLine": 24,
|
|
"endChar": 33
|
|
},
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "95e95d3b_495d9e47",
|
|
"filename": "/COMMIT_MSG",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 24,
|
|
"author": {
|
|
"id": 29313
|
|
},
|
|
"writtenOn": "2024-02-21T14:13:53Z",
|
|
"side": 1,
|
|
"message": "So there is no need to mention it as a runtime here.",
|
|
"parentUuid": "a776c65a_4f0884b6",
|
|
"range": {
|
|
"startLine": 21,
|
|
"startChar": 0,
|
|
"endLine": 24,
|
|
"endChar": 33
|
|
},
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "3ccab2be_3dca4313",
|
|
"filename": "/COMMIT_MSG",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 24,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-21T20:46:21Z",
|
|
"side": 1,
|
|
"message": "thanks for ack and confirmation.",
|
|
"parentUuid": "95e95d3b_495d9e47",
|
|
"range": {
|
|
"startLine": 21,
|
|
"startChar": 0,
|
|
"endLine": 24,
|
|
"endChar": 33
|
|
},
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "64285322_39120949",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-12T20:39:02Z",
|
|
"side": 1,
|
|
"message": "Adding Horizon team for checking Nodejs removal from testing runtime.",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "a8c145fd_dbdd2041",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 10342
|
|
},
|
|
"writtenOn": "2024-02-13T03:55:20Z",
|
|
"side": 1,
|
|
"message": "Is there a reason we do not have python 3.12 in this?",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "32b05a11_fcac1cab",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 23851
|
|
},
|
|
"writtenOn": "2024-02-13T08:33:09Z",
|
|
"side": 1,
|
|
"message": "Python 3.12 is out since October 2023 so we should have it IMHO",
|
|
"parentUuid": "a8c145fd_dbdd2041",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "4087a85d_aad0df19",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 935
|
|
},
|
|
"writtenOn": "2024-02-13T15:50:05Z",
|
|
"side": 1,
|
|
"message": "Worth noting that Ubuntu 24.04 will have Python 3.12 as the default Python runtime.",
|
|
"parentUuid": "32b05a11_fcac1cab",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "3c06c8c1_8be36b36",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-13T18:48:11Z",
|
|
"side": 1,
|
|
"message": "Ubuntu 24.04 is not coming before this development cycle start so not sure if we can add python 3.12 testing target in this. unless we want to test it from source installation or any distro have it",
|
|
"parentUuid": "4087a85d_aad0df19",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "137d0624_093a23fb",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 7166
|
|
},
|
|
"writtenOn": "2024-02-15T13:44:57Z",
|
|
"side": 1,
|
|
"message": "Slight additions for Ubuntu 22.04 and py3.12 but I do strongly oppose myself on removing python 3.9 support. Projects have very limited resources to address backwards-incompatible changes and the more we can continue to support a release, the longer it gives the projects the necessary time to do the necessary adaptations.",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "483cea2a_6b3ece4d",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 13252
|
|
},
|
|
"writtenOn": "2024-02-17T13:50:41Z",
|
|
"side": 1,
|
|
"message": "If you want to require python3.12 support, IMO you need to create some working test jobs first. Like at least a tox-py312 job, but possibly even some functional/devstack jobs. It doesn\u0027t make sense for me to demand something that cannot be tested. \n\nWe also can add py312 as optional, non-voting testing first, like we did for py311, in order to allow some smoother transition for projects. That would avoid delaying this runtime decision too much, though I\u0027m not sure how the actual deadline does look like.",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "25d52b49_223194a7",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-20T18:28:16Z",
|
|
"side": 1,
|
|
"message": "Yes, this is right path. adding it non voting is good idea otherwise we endup like breaking things for a good amount of time in next cycle",
|
|
"parentUuid": "483cea2a_6b3ece4d",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "f63016f2_ef5e34c3",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 13252
|
|
},
|
|
"writtenOn": "2024-02-21T12:06:41Z",
|
|
"side": 1,
|
|
"message": "to move this forward, I\u0027m voting to proceed with this patch is it stands",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "7bfde7c8_07cfd88e",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-21T20:47:43Z",
|
|
"side": 1,
|
|
"message": "even though I am author but I would like to vote on the current version. main concern raised here is to add py3.12 which I feel we should test as nv first and when we have a way to install it. 2025.1 will be good/suitable target to make py3.12 mandatory.",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": false,
|
|
"key": {
|
|
"uuid": "547072cc_9a05121c",
|
|
"filename": "/PATCHSET_LEVEL",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 0,
|
|
"author": {
|
|
"id": 10342
|
|
},
|
|
"writtenOn": "2024-02-23T18:13:17Z",
|
|
"side": 1,
|
|
"message": "RC+1 because, the policy as written matches what I think is OK, even if in a perfect world we\u0027d revise it. Specifically I think there\u0027s value in noting, for future readers of the platform doc, why we chose not to support python 3.12/ubuntu 24.04.",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "3f1db237_52896d28",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 935
|
|
},
|
|
"writtenOn": "2024-02-13T15:51:31Z",
|
|
"side": 1,
|
|
"message": "As Ubuntu 24.04 will have released in April should the Ubuntu target not move forward as well?",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "e8fcb042_d8512c8c",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2024-02-13T19:05:59Z",
|
|
"side": 1,
|
|
"message": "i would expect use to start making the move to 24.04 in 2024.2 even we don\u0027t complete it.\n\nit will be sufficently early in the cycle that i think its worth consdiering with 22.04 added to an addtional testing for smooth upgrades\n\nwith that said we do normally require that the disto is release before hte master banch is opened for the release that will happen mid march",
|
|
"parentUuid": "3f1db237_52896d28",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "634df0e2_75e0963b",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2024-02-15T11:00:01Z",
|
|
"side": 1,
|
|
"message": "https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/ has 24.04\nalpha images with cloud init for x86 by the way.\n\nthey still have 3.11 but that will bump to 3.12 in beta and for the final release as far as i understand so we can start adding support in disk image build for that so we can get an early image aviable via node pool.\n\n\ndib expext a tar of the root fs\n\nhttps://github.com/openstack/diskimage-builder/blob/master/diskimage_builder/elements/ubuntu/root.d/10-cache-ubuntu-tarball#L16\n\nso we might have to use \n\nhttps://cdimage.ubuntu.com/ubuntu-server/daily-live/current/noble-netboot-amd64.tar.gz\n\ninstead but that should be doable today if someone was so inclined.\n\ncloud-init is in the pre-installed image and we can always install it or glean with dib anyway to make it useable for ci so it would be possibel to have an early integration image before the start of the 2024.2 cycle whchi could get replaced by an offical released image in april.",
|
|
"parentUuid": "e8fcb042_d8512c8c",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "b1d66daa_d8feac22",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 7166
|
|
},
|
|
"writtenOn": "2024-02-15T13:44:57Z",
|
|
"side": 1,
|
|
"message": "See my comment below, I think this should be placed in the next section.",
|
|
"parentUuid": "634df0e2_75e0963b",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "37ce187b_08e68b96",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-21T20:46:21Z",
|
|
"side": 1,
|
|
"message": "It depends when it will be released in April. If that is after the next cycle 2024.2 start (April 3rd https://releases.openstack.org/dalmatian/schedule.html) then we cannot include that in 2024.2 runtime.\n\nIt might be little hectic schedule to test/migrate to new version during the dev cycle. This is how we did for 22.04 case also as it was released I think a few weeks after zed cycle was started.",
|
|
"parentUuid": "b1d66daa_d8feac22",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "1b9e6a76_74e9b88d",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 935
|
|
},
|
|
"writtenOn": "2024-02-23T09:46:59Z",
|
|
"side": 1,
|
|
"message": "Noble releases on 23 April:\n\nhttps://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649",
|
|
"parentUuid": "37ce187b_08e68b96",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "45f99314_cb5e8381",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-23T17:42:12Z",
|
|
"side": 1,
|
|
"message": "yeah, that is after the D cycle start which is why it is difficult to consider that for D cycle as mandatory at this stage.",
|
|
"parentUuid": "1b9e6a76_74e9b88d",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "4908c40c_e5a8ab59",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 10342
|
|
},
|
|
"writtenOn": "2024-02-23T18:13:17Z",
|
|
"side": 1,
|
|
"message": "So there are a couple of things here worth noting that haven\u0027t been mentioned yet:\nUbuntu Jammy, 22.04, continues to get security updates through April 2027 (longer if you pay). Dalmation is scheduled to be released on October, 2024. This means that we can cover the full 18 month support period of Dalmation inside Jammy\u0027s support window. This reduces pressure on us, with upstream hats on, to support Jammy.\n\nHowever, as mentioned in the python 3.9 support thread -- we like working with downstream partners to ensure work that needs to happen will happen upstream rather than downstream. This means I suspect that there may be efforts at Canonical to run OpenStack 2024.2 on 24.04 regardless of if we support it or not. That makes me wish we could offer a best-effort support here.\n\nI think I\u0027d be -1 to making 24.04 a required target for this release, just because it seems unfair to put OpenDev/infra/QA/devstack teams under that kind of time crunch -- however, I\u0027d be a big fan of us enabling projects to flip this testing on during the cycle if they want. Like I say below; I\u0027d rather that work to support 24.04 happen upstream for the community than downstream in spite of it.\n\n\n\n\nAside: whether we support it or not; it\u0027d be extremely valuable to indicate that we know Ubuntu 24.04 exists here, and indicate why we are not supporting it. I suspect that may help some operators who might miss that it\u0027s an older LTS (from their perspective, post-release).",
|
|
"parentUuid": "45f99314_cb5e8381",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "59a8247b_63903e27",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 10,
|
|
"author": {
|
|
"id": 935
|
|
},
|
|
"writtenOn": "2024-02-24T13:09:50Z",
|
|
"side": 1,
|
|
"message": "To confirm you suspicion - Ubuntu 24.04 is the base for Caracal already (although Canonical are also backporting to 22.04 via the Ubuntu Cloud Archive), so will be a target for 24.02.\n\nFor Ubuntu 22.04 I was able to convince the Ubuntu Foundations team of the value of providing backports of newer Pythons to 22.04 (rather than newer Pythons just being in the interim releases) - I\u0027d like todo the same for 24.04 to enable easier enablement of new check/gates for OpenStack projects going forward.\n\nI agree that its unreasonable to make Ubuntu 24.04 a hard requirement for the upcoming cycle - but I would also like to help ensure that we have this version of the distro available as soon as possible so that any bug fixing for newer Pythons can be done upstream in OpenStack first, avoiding the need for extended periods with compatibility patches in the Ubuntu packages.",
|
|
"parentUuid": "4908c40c_e5a8ab59",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "efa69947_b0ee930a",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 16,
|
|
"author": {
|
|
"id": 7166
|
|
},
|
|
"writtenOn": "2024-02-15T13:44:57Z",
|
|
"side": 1,
|
|
"message": "There you could mention the next Ubuntu LTS version (24.04) with a slight note that we shouldn\u0027t be testing it until it goes GA.",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "6060df3c_7cfc75aa",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 16,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2024-02-19T18:15:41Z",
|
|
"side": 1,
|
|
"message": "we normlaly use this for when we are removing a release but i guess it work in both directions\n\nso yes we can do that",
|
|
"parentUuid": "efa69947_b0ee930a",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "c1d19869_689ec701",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 16,
|
|
"author": {
|
|
"id": 13252
|
|
},
|
|
"writtenOn": "2024-02-21T12:06:41Z",
|
|
"side": 1,
|
|
"message": "Even additional testing would be considered mandatory I guess? so I don\u0027t think this should be added at a time where neither the distro release is ready nor the needed support in devstack and opendev infra.",
|
|
"parentUuid": "6060df3c_7cfc75aa",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "4ffd6428_b3e889e1",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 16,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-21T20:46:21Z",
|
|
"side": 1,
|
|
"message": "Yeah, I am little concern on adding the distro version which is not released yet and we never know when it will be released. Devstack/infra support is also good point.\n\nbets we can do, once we have 24.04 released and we add infra/devstack support then we can discuss to add it in additional testing (even that is in middle of cycle but with additional testing effort it will be less work than moving all CI to it).",
|
|
"parentUuid": "c1d19869_689ec701",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "e4cc0d51_4704b68d",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 32755
|
|
},
|
|
"writtenOn": "2024-02-13T12:26:11Z",
|
|
"side": 1,
|
|
"message": "While it sounds nice to say \"It doesn\u0027t hurt to try and still maintain compatibility with Python 3.9\", I disagree ...\n\nOpenStack is either run on supported distros (which have Python \u003e\u003d3.10) or in containers that can contain any Python release that\u0027s suitable.\n\nTargeting any lower version than provided by the reference distributions actually limits the language level to that of Python 3.9. To me this kind of compatibility is not best-effort or helpful, but actually and actively hindering modernization of the code base. By requiring (or even suggesting) that all code has to be compatible with 3.9 newer language features cannot be fully utilized.",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "aa09ada1_a21426ce",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2024-02-13T19:05:59Z",
|
|
"side": 1,
|
|
"message": "well 3.9 is the runtim of centos and rocky which are supproted distos\n\nthey are just not required for all project to test on those distos.\n\nwhen centos 10 stream is rlease that will move the python version used there to 3.12\n\nthe upstream branching and bootstrapping of centos 10 stream has started in fedora\n\nhttps://github.com/fedora-eln/eln/issues/179\n\nbut i dont belive it will be usabel until the 2025.1 cycle.\n\ni would epect use to considder moving cetos 9 stream to the dditional testing for a smooth upgrade in 2025.1 and replace it with centos 10 stream.",
|
|
"parentUuid": "e4cc0d51_4704b68d",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "ea3bcbc7_addb3bc3",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 32755
|
|
},
|
|
"writtenOn": "2024-02-14T11:11:40Z",
|
|
"side": 1,
|
|
"message": "Are we not discussing the \"officially\" supported distros for the \u003enext\u003c OS release \"D\"? When can a distro be dropped off the list of suitable targets for an upcoming OpenStack release? All older ones (to which people are slow to upgrade to I believe) are still supported.\n\nBe it as it may, RHEL 9.2 / Rocky Linux 9.2 actually both have Python 3.11 available (see [1], [2]). And that\u0027s for a good reason: More and more Python packages in very recent versions like Python \u003e\u003d3.10 better and people wanted to upgrade. And, as you said 10.x is still a way out and 9.x will be around for years.\nAnd if OpenStack is packaged by the so have the required Python packages then.\n\nComparing the RedHat ecosystem in regards to OS with Ubuntu, I am wondering if there is not such thing as the Ubuntu Cloud Archive (UCA) [3] which packages newer, 3rd party requirements such as python-libs or libvirt even in a more recent version than provided by the base distro and which can be used as additional repo. This enables OpenStack to move forward with its requirements, while still supporting upgrading onto the N-1 LTS release. But this stops as soon as a new Ubuntu LTS is out. Then the next OS release will only work on this new LTS and operators are expected to upgrade. Not that I am saying that this is solves all problems (see below about using containers to distro-independently move to more recent software), but it would still be an option for RedHat.\n\nWith containers (be it Kolla-Ansible (Docker/Podman), OpenStack-Ansible (LXC) or the newly curated Helm Charts for Kubernetes (CRI via e.g. containerd) the native packaging of OpenStack for a certain distro might be less important that years ago.\n\nThe best-effort section above smells a little like technical debt for the OpenStack ecosystem, but with no real promises or guarantees for operators. Not to be misunderstood, sounds good and it is good socially to not just drop support for something without thinking twice. \n\nBut is it a good technical decision? \n\nWhat does it help any deployment to know a project \"did its best\" to support an older distro / Python version. To me it\u0027s better to state clearly that for \"D\" operators are expected to upgrade their OS or Python version (or switch to an architecture using some sort of containerization). This is to me what \"governance\" is about: Balancing those decisions and even making hard ones if the benefits outweigh the trade-offs. Talking about trade-offs:\n\nSupporting too many different distros + versions, Python versions, deployment architectures and tooling while also supporting all sorts of 3rd party drivers and integrations which are in-tree is a burden. To me, with OS projects being dev / reviewer constrained pretty much everywhere, it might be a wise decision to focus and tighten the technical spectrum for future release a little more.\nJust like old branches are now \"unsupported\", let\u0027s call older Python versions just \"unsupported\". In the end OpenStack is open-source software. Distributions of any kind (Linux or commercial OpenStack) may still try to run OpenStack \"D\" on Python 3.8 or 3.9, but please don\u0027t take this out on the projects and make this some half-baked best-effort.\n\n\n[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.2_release_notes/new-features#new-features-dynamic-programming-languages-web-and-database-servers\n[2] https://docs.rockylinux.org/release_notes/9_2/\n[3] https://ubuntu.com/about/release-cycle#openstack-release-cycle\n[4] https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases",
|
|
"parentUuid": "aa09ada1_a21426ce",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "198e5435_6afe8f85",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2024-02-15T10:24:23Z",
|
|
"side": 1,
|
|
"message": "they have the interperter in the software collections repos.\nthose repos are not supprotedd for you in redhat products in general and are not used for Openstack because they do not have full support.\n\nredhat is currently in the process of writhing a new installer to delever our next productised verson of opensack based on antelope and that will be based on python 3.9 that should be the last productised release based on python 3.9 but it will be based on 3.9\n\nwe are not taking this out on anyone. we have policies for how we add/remote python version.\n\nthe current one for removing a python version is only to do so when it goes EOL upstream. that means we should be keeping 3.9 for one more year and adding 3.12 this cycle.\n\nin termes of offically supported distos centos is one of them as is ubuntu and debian. previoulsy suse was also on that list.\n\nthe title best effort is refelctive of the fact that centos testing is not required by porject but the disto is as supproted as ubuntu is in terms of determining python version support.\n\nunder our current policy once centos 10 stream is relesae it 9 should be moved to the smoth upgrade secation and 10 should be added instead then after one slurp (the 2025.1 cycle centos 9 should be removed in 2025.2\nthen in 2025.2 we can raise our min python version to 3.10",
|
|
"parentUuid": "ea3bcbc7_addb3bc3",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "730c615c_b83e6363",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 7166
|
|
},
|
|
"writtenOn": "2024-02-15T13:44:57Z",
|
|
"side": 1,
|
|
"message": "I strongly disagree with the idea to try to stick with the release cadence of upstream Python.\nWhile the Python community has their own reasons to do this roll of versions very quickly, I hereby want to address the fact that removals eventually impact us and force us to dedicate resources (time not being the most difficult one) to address the necessary changes. \nDistros also have their own paces, and I do appreciate that their own Python support is quite different.",
|
|
"parentUuid": "198e5435_6afe8f85",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "d584b807_b5df7401",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 32755
|
|
},
|
|
"writtenOn": "2024-02-19T08:57:05Z",
|
|
"side": 1,
|
|
"message": "@sean: \n\u003e productised verson of opensack based on antelope and that will be based on python 3.9\n\nThat sounds like you want be needing Python 3.9 support in \"D\" then or am I misreading this?\n\n\u003e I hereby want to address the fact that removals eventually impact us and force us \n\u003e to dedicate resources (time not being the most difficult one) to address the \n\u003e necessary changes. Distros also have their own paces, and I do appreciate that \n\u003e their own Python support is quite different.\n\n@Sylvain:\n\nIt\u0027s not about just using the latest greatest, but to actually to avoid running a Python version and is barely supported upstream and will soon be EoL. The focus of the greater community around Python, base language / interpreter as well as libraries is on the more recent versions. I believe you are actually overestimating the independent \"support\" distros can and do provide for older Python versions and especially their libraries. They provide e.g. security support for the status quo yes. But running and depending on this for newly and to be developed software should be able to take advantage of more recent (not latest) language improvements like type annotations and improved performance. Also libraries might break their support for older Python versions for exactly this reason.\n\nRefactoring / reworking code to remove deprecation should be a continuous process.\nBy introducing new versions early and removing older ones actually only \"forces\" you to fix just the breaking issues. But in return it enables you to do as much as you can fit in your time.\n\nPlease kindly let me reference a recent thread on the ML about modernizing the Python stack in general: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/4V63CHMZ4GPC4IYN7JCJPVKHLZAHN5BL/\n\n\nPeople that are, for whatever reason, forced to run Python 3.9 likely are not the ones running the latest OpenStack release. But be it as it may, Caracal is coming with Python 3.9 support and is, once released, supported for \u003e\u003d18 months.\nI doubt it\u0027s ruining anyone\u0027s party if \"D\" will then require an upgrade of your OS or at least Python version.",
|
|
"parentUuid": "730c615c_b83e6363",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "fb0d82fe_77e7fc1f",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2024-02-19T18:15:41Z",
|
|
"side": 1,
|
|
"message": "yes i pushed ot raise the min to py39 last cycle and we decieded not to \n\nin this cycle we would need to keep it as we still supprot centos/rocky 9\nand it will need to be supproted until its either EOL upstream or we have a release of centos 10 stream\n\nAlternatively we would have to remove them as supported distos but that is not being proposed.\n\nif we were to remove them the would need to be kept for at least 1 release if not 1 entrire slurp based on the stable stable upgrade rules since centos 9 stream will be supproted fully for caracal on py 39",
|
|
"parentUuid": "d584b807_b5df7401",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "35a65e8a_538abce4",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 32755
|
|
},
|
|
"writtenOn": "2024-02-20T14:45:55Z",
|
|
"side": 1,
|
|
"message": "Can you explain this a little more? \nWhy can the supported distro not be changed for a new release and support must be kept for one more release after removing it? There are plenty of bridge releases \n\nBecause what you wrote sounds like it\u0027s really important to remove a distro forcing OpenStack to keep itself compatible with the soon to be EoL Python 3.9 one release in advance.\n\nSo to ask some plainer questions: \n\n* CentOS 9 is supported for Caracal yes. But why can it not be removed for Dalmatian?\n* How does the SLURP or \"stable stable\" upgrade policy come into play here? So you mean there has to be a new distro version that is introduced first, to serve as a bridge release for OpenStack? This would mean CentOS (Stream) 10, planned for sometime 2025 would need to be released and supported by some OpenStack release BEFORE CentOS 9 can be removed as supported distro? \n\nThat could mean the \"E\" release might still support CentOS 9 and Python 3.9?",
|
|
"parentUuid": "fb0d82fe_77e7fc1f",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "2f8febe3_cbab8b26",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 32755
|
|
},
|
|
"writtenOn": "2024-02-20T14:49:45Z",
|
|
"side": 1,
|
|
"message": "sorry, scratch the sentence: \"There are plenty of bridge releases\". I mean to say ... \n\nthere are many OpenStack releases that could serve as bridge releases. But that is not true as they would need to receive support for a new distro after they have been released (e.g. Dalmatian would need to receive support for CentOS 10 AFTER release). And that, I believe, is not usually happening?",
|
|
"parentUuid": "35a65e8a_538abce4",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "30f74f00_72485575",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 4393
|
|
},
|
|
"writtenOn": "2024-02-21T15:53:11Z",
|
|
"side": 1,
|
|
"message": "I\u0027m very much in favor of us chasing the trailing edge of python releases and not the leading one. The new syntax stuff that gets introduced breaks us on older releases and those are the ones that are in the stable distros we care about. Openstack is a mature project and integrating the new hotness language features as soon as they\u0027re available in upstream python is not the right approach, IMHO.",
|
|
"parentUuid": "2f8febe3_cbab8b26",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "a45ccc69_75055e23",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-21T20:46:21Z",
|
|
"side": 1,
|
|
"message": "I agree that keeping lower python version compatibility as long as we can does not harm anyone. As we mentioned in many places, our min version does not restrict us to move to latest version. So I am not seeing any downside of it than a little maintenance in upstream (which is nothing as we run only unit tests on those for code compatibility). I consider it as a extra testing/support we do.",
|
|
"parentUuid": "30f74f00_72485575",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "62182f7a_df6c716c",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 43,
|
|
"author": {
|
|
"id": 10342
|
|
},
|
|
"writtenOn": "2024-02-23T18:13:17Z",
|
|
"side": 1,
|
|
"message": "I am +1 to keeping python 3.9 in the compatibility lists, but I do think there are some interesting things said here which are worthy of reply anyway.\n\nI\u0027m going to make a few comments here, as a general reply without specifically replying to any given thing.\n- There *is* a major downside to continuing to support python 3.9: we have to avoid using features/libraries/etc which only exist in python 3.10+. I believe this is a reasonable price to pay, but we shouldn\u0027t downplay it. (Christian has made this point; I believe)\n- Supporting newer pythons sooner is not creating new, additional work for project teams; it just is changing the timeline for it. There are not a lot of ways to get around the fact that we *must* support newer pythons eventually, whether it\u0027s done in \"D\" or \"E\" it\u0027s hard for me to imagine the amount of work changes, only when it\u0027s done.\n- I appreciate the explicit acknowledgement that we\u0027re helping downstreams like Redhat keep their products working on python 3.9 in alignment with upstream. This helps us all out by ensuring RH developers can spend their time working upstream instead of working out kinks that they\u0027d only experience downstream. I don\u0027t know details about internal redhat policies, but I suspect the question isn\u0027t if \"D\" will support python 3.9; the question is will that work to support python 3.9 be done upstream, in the community, or be done downstream in service of RH\u0027s product. I prefer it to be done upstream.",
|
|
"parentUuid": "a45ccc69_75055e23",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "51e18999_883f9425",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 65,
|
|
"author": {
|
|
"id": 11604
|
|
},
|
|
"writtenOn": "2024-02-13T19:05:59Z",
|
|
"side": 1,
|
|
"message": "please add pythone 3.12 as a required runtime",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "31753c0a_2db371a2",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 65,
|
|
"author": {
|
|
"id": 7166
|
|
},
|
|
"writtenOn": "2024-02-15T13:44:57Z",
|
|
"side": 1,
|
|
"message": "Agreed with Sean, distros now ship that release and we need to test it, in order to do the required modifications way in advance and in a timely manner (which wouldn\u0027t be and shouldn\u0027t be urgency)",
|
|
"parentUuid": "51e18999_883f9425",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "3f0017e5_221cbb74",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 65,
|
|
"author": {
|
|
"id": 13252
|
|
},
|
|
"writtenOn": "2024-02-21T12:06:41Z",
|
|
"side": 1,
|
|
"message": "none of the infra supported distros ship py3.12 afaict, also it seems that there are some blockers still (just saw something about taskflow). so what we can and should do is add non-voting testing first, but this should not get added in this document (and hasn\u0027t been done for py3.11 previously).",
|
|
"parentUuid": "31753c0a_2db371a2",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "14ca8a1b_3fa5fcb6",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 65,
|
|
"author": {
|
|
"id": 4393
|
|
},
|
|
"writtenOn": "2024-02-21T15:53:11Z",
|
|
"side": 1,
|
|
"message": "I\u0027m not sure we really need 3.9, 3.10 *and* 3.11. Personally, I\u0027m concerned about changes in 3.12 and so while I agree with frickler that it\u0027s early to start requiring testing on it, I also would like to be ahead of that curve. Assuming it\u0027s going to be available in 22.04 and that 22.04 will be available soon in the cycle, I\u0027d definitely be in favor of expecting at least functional and unit tests to run on 3.12 by the end of the cycle. Sort of like we did for 3.8 for the previous cycle. We have a best-effort category for OS runtimes, and that sort of fits here. If we could put 22.04 in there with a note here about unit/functional on 3.12 I think that would cover it.",
|
|
"parentUuid": "3f0017e5_221cbb74",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "5b189528_ce8a2044",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 65,
|
|
"author": {
|
|
"id": 8556
|
|
},
|
|
"writtenOn": "2024-02-21T20:46:21Z",
|
|
"side": 1,
|
|
"message": "yes, until it is not there in any of the distro and we have not tested that in advance as nv, it might be a lot of work or hectic schedule for us to adopt it in next cycle.\n\nI agree to give a shot on this if we can do via 22.04 or 24.02(once it is released) and try adding as a nv job to give projects time to fix the things if failing.",
|
|
"parentUuid": "14ca8a1b_3fa5fcb6",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
},
|
|
{
|
|
"unresolved": true,
|
|
"key": {
|
|
"uuid": "5a8e941e_bd1e0c17",
|
|
"filename": "reference/runtimes/2024.2.rst",
|
|
"patchSetId": 1
|
|
},
|
|
"lineNbr": 65,
|
|
"author": {
|
|
"id": 10342
|
|
},
|
|
"writtenOn": "2024-02-23T18:13:17Z",
|
|
"side": 1,
|
|
"message": "So I am of two minds here:\n- If I had *zero* technical knowledge of python 3.12 issues; I would be +1 to adding this support.\n- ...but I do have that knowledge 😞\n\nIn order for *anything* using oslo_service + sslutils to provide a TLS WSGI server to move to python 3.12, major changes will need to be made to oslo_service -- the ssl.wrap_socket() interface doesn\u0027t work in python 3.12 (IPA is one example of where this is done; I\u0027ve yet to look for others). I am extremely nervous to add python 3.12 as a supported runtime with the knowledge that the SSL stdlib changes have degraded the support in eventlet to a point where I\u0027d feel *much* more comfortable supporting python 3.12 after the eventlet migration is complete.\n\nAdditionally, this is the \"midpoint\" of a SLURP release, so skipping python 3.12 for Dalmatian is only a 6 month delay, not a yearlong one.\n\nI would be +1 for us adding a python 3.12 job, nonvoting, for projects that want to provide best-effort support and prepare for the future; but I am worried promising python 3.12 support for Dalmation may be too much of a technical lift without an eventlet migration plan in place.",
|
|
"parentUuid": "5b189528_ce8a2044",
|
|
"revId": "b3fd16b14083542709d272feed47548ecafb7153",
|
|
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
|
|
}
|
|
]
|
|
} |