| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-28 | |||
| 18:50:05 | sean-k-mooney | that a little clunky | |
| 18:52:20 | sean-k-mooney | """ As of OpenStack 2023.1 (Antelope), Nova enables the | |
| 18:52:22 | sean-k-mooney | coexistence of N and N-2 (zed) | |
| 18:52:24 | sean-k-mooney | """ | |
| 18:52:33 | sean-k-mooney | ill comment that inline but this is how i woudl write that. | |
| 18:53:08 | sean-k-mooney | however while we are treating this as a dress rehersal im not sure i agree with avocating this. | |
| 18:53:30 | sean-k-mooney | we expect it to work | |
| 18:53:46 | sean-k-mooney | but i dont know if we want to comit to fixing issues with yoga to antelope | |
| 18:54:08 | sean-k-mooney | i think we should consider it experimental rather then something you should use in production in general | |
| 18:54:24 | dansmith | I haven't reviewed yet, but agree, we should make it clear that it's a best-effort thing, but I'd also be in favor of just explaining that we don't *fail* on N-2, but not go so far as saying we support it or that it's a good idea | |
| 18:57:39 | sean-k-mooney | bauzas: comments inline https://review.opendev.org/c/openstack/nova/+/874932/4/doc/source/admin/upgrades.rst | |
| 20:28:10 | opendevreview | Merged openstack/nova master: Fix logging in MemEncryption-related checks https://review.opendev.org/c/openstack/nova/+/873388 | |
| #openstack-nova - 2023-03-01 | |||
| 08:45:02 | bauzas | morning folkks | |
| 09:27:19 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add the 2023.1 Antelope prelude section https://review.opendev.org/c/openstack/nova/+/875380 | |
| 09:35:51 | sean-k-mooney | bauzas: https://review.opendev.org/c/openstack/nova/+/875380/2..3/releasenotes/notes/antelope-prelude-4a99907b00e739f8.yaml is still tecnilaly not correct | |
| 09:36:09 | sean-k-mooney | 2024.1 is the first SLURP release offically for all project | |
| 09:36:12 | bauzas | no | |
| 09:36:37 | sean-k-mooney | yes | |
| 09:36:40 | bauzas | see the TC resolution | |
| 09:37:18 | bauzas | 2023.1 is the first 'SLURP release' but upgrade from yoga is considered a test | |
| 09:37:41 | bauzas | we indeed need to guarantee 2023.1 to 2024.1 upgrades | |
| 09:37:50 | bauzas | but both are 'officially' SLURP releases | |
| 09:38:02 | sean-k-mooney | calling it a SLURP release imples its supproted by all project form yoga | |
| 09:38:06 | sean-k-mooney | which was never a requirement | |
| 09:38:19 | bauzas | the resolution is clear about the requirements | |
| 09:38:41 | bauzas | but there is a TC meeting today, we can clarify the resolution there | |
| 09:38:51 | sean-k-mooney | the requirement is to support upgrades form A->C | |
| 09:39:01 | sean-k-mooney | but that means C is the first SLURP release | |
| 09:39:37 | sean-k-mooney | its the release you are upgrading too that has to support it | |
| 09:39:40 | bauzas | "Communication: We will use “SLURP” word to designate a SLURP release in release page, release notes page or any other place we want to communicate it. We can also use its full form “Skip Level Upgrade Release Process” if needed. A “not-SLURP” release will not be designated with anything and not having “SLURP” word is enough to communicate that this is not “SLURP” release. Also, the number schema in the releas | |
| 09:39:40 | bauzas | e naming process will help all of us to relate which release is “SLURP”." | |
| 09:40:04 | bauzas | " Testing: Just as we test and guarantee that upgrades are supported between adjacent releases today, we will also test and guarantee that upgrades between two “SLURP” releases are supported. Upgrades are tested for most projects today with grenade. A skip-level job will be maintained in the grenade repository that tests a normal configuration between the last two “SLURP” releases. The job will be updated on every new | |
| 09:40:04 | bauzas | “SLURP” release, and there will always be a regular single-release grenade job testing between the previous release and current one, as we have today." | |
| 09:40:10 | sean-k-mooney | that why i made the disticiton wiht A being the first __base__ release you upgrade form to the first SLURP release | |
| 09:40:20 | bauzas | so we need to guarantee between *two* SLURP releases | |
| 09:40:48 | bauzas | Yoga being *not* a SLURP release, we don't need to guarantee it, despite 2023.1 *is* a SLURP release | |
| 09:41:14 | bauzas | " Our letter-based release naming scheme is about to wrap back around to A, so the proposal is that the “new A” release be the first one where we enforce this scheme. Y->A should be a “dress rehearsal” where we have the jobs enabled to help smoke out any issues, but where hard guarantees are not yet made." | |
| 09:41:24 | sean-k-mooney | again i disagre not on the funtionalty but that the resolution is clear an the terminology is defiend properly | |
| 09:41:56 | sean-k-mooney | yes i read that and that does not make A a SLURP release | |
| 09:42:01 | bauzas | As a reminder, OpenStack 2023.1 is our first `Skip-Level-Upgrade Release`__ (starting from now, we name it a `SLURP release`) where you can rolling-upgrade your compute services from OpenStack Yoga as an experimental feature. Next SLURP release will be 2024.1. | |
| 09:42:17 | bauzas | I just said two informations : | |
| 09:42:27 | bauzas | 1/ 2023.1 *is* a SLURP release | |
| 09:42:45 | bauzas | 2/ upgrade from Yoga is not guaranteed | |
| 09:43:04 | bauzas | IIUC, you disagree on #1 | |
| 09:43:26 | bauzas | but IMHO the resolution is quite clear | |
| 09:43:42 | bauzas | https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html#example-sequence even shows it | |
| 09:43:44 | sean-k-mooney | correct with the caveat that 2024.1 is a slurp relase and upgrade will be guarenteed form 2023.1 | |
| 09:44:06 | bauzas | I don't disagree on your last sentence | |
| 09:44:29 | bauzas | both are SLURP releases, but the only guaranteed skip-level upgrade is from 2023.1 to 2024.1 | |
| 09:44:36 | sean-k-mooney | for me a SLURP release guarnetes upgrade of more then one release | |
| 09:45:00 | bauzas | that's what I disagree, based on my reading of the TC resolution :) | |
| 09:45:03 | sean-k-mooney | that the thing the guarentee is a majory part of the definiton fo a slurp release | |
| 09:45:12 | sean-k-mooney | if we dont have that in my book its wrong to call it one | |
| 09:45:26 | sean-k-mooney | which is why i dont think we should call 2023.1 a SLURP release | |
| 09:45:29 | bauzas | the 'P' is important | |
| 09:45:43 | bauzas | 2023.1 is in the process of a skip-level-upgrade | |
| 09:46:01 | sean-k-mooney | it is the base releae for a skiplevel upgrade | |
| 09:46:06 | bauzas | yes | |
| 09:46:18 | sean-k-mooney | but it is not a skip level upgrade release its self | |
| 09:46:39 | bauzas | it's a 'SLURP release' as per the TC charter :) | |
| 09:46:48 | sean-k-mooney | i think there is ambiguity in the wrodign and the curent statement is controditory | |
| 09:47:29 | bauzas | hence me saying that the rollingupgrade feature is officially experimental | |
| 09:47:42 | bauzas | it clarifies the expectations | |
| 09:47:50 | bauzas | this is just a demo showcase | |
| 09:48:01 | sean-k-mooney | if A cant guarentee a skip level upgrade form a previos release i dont think it can be considerd a slurp release so i think "Deployments wishing to move to a one year upgrade cycle will synchronize on a “SLURP” release, and then skip the following “not-SLURP” release, upgrading when the subsequent “SLURP” is released" is not sufficent | |
| 09:48:04 | bauzas | since Yoga *isn't* a SLURP release | |
| 09:48:20 | bauzas | well, | |
| 09:48:41 | bauzas | "we will also test and guarantee that upgrades between two “SLURP” releases are supported. " is the key information | |
| 09:48:46 | sean-k-mooney | i think that sentance should be changed and we should add 2 new deffintion to the details section | |
| 09:49:03 | bauzas | that's a TC amendment, feel free to drop a patch | |
| 09:49:25 | bauzas | I don't disagree this can be confusing, but I think I avoided it by the prelude | |
| 09:49:43 | sean-k-mooney | i can but as it stand i dont think the prelude is correct. i wont block it but i think its a little misleading | |
| 09:50:02 | bauzas | sean-k-mooney: and honestly, we have an internal meeting conflicting at the same time of the TC meeting, but I'd like to attend this TC call then to clarify the wordings | |
| 09:50:43 | bauzas | lemme ask the TC folks in their chan what they think about the namings | |
| 09:53:08 | bauzas | sean-k-mooney: feel free to drop again a comment on my prelude patch | |
| 09:53:14 | bauzas | I'll show it to the TC folks | |
| 09:57:26 | bauzas | sean-k-mooney: anyway, pointed it out in the TC chan | |
| 10:01:15 | sean-k-mooney | i am going to push a patch to the governace repo for review | |
| 10:01:33 | bauzas | cool thanks | |
| 10:02:26 | bauzas | sean-k-mooney: the odds of reno make me think that we should merge the prelude without waiting for the TC clarification | |
| 10:03:00 | bauzas | but if the TC agrees on saying 'A isn't a SLURP release' then we could later modify the prelude | |
| 10:03:29 | bauzas | given the first commit will be included in the 2023.1 branch, we won't miss it | |
| 10:06:28 | sean-k-mooney | https://review.opendev.org/c/openstack/governance/+/875853 | |
| 10:06:52 | sean-k-mooney | yes we can backport a change to the prelude | |
| 10:12:47 | bauzas | sean-k-mooney: fwiw, said +1 to placement rc1 https://review.opendev.org/c/openstack/releases/+/875452 even if I know that we have a concurrent db cleanup patch | |
| 10:19:12 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add service version for Antelope https://review.opendev.org/c/openstack/nova/+/874932 | |
| 10:19:13 | opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | |
| 10:22:52 | opendevreview | 周众 proposed openstack/nova master: Instance unexpected shutdown when source node startup https://review.opendev.org/c/openstack/nova/+/875859 | |
| 10:25:39 | opendevreview | 周众 proposed openstack/nova master: Instance unexpected shutdown when source node startup https://review.opendev.org/c/openstack/nova/+/875859 | |
| 10:27:46 | sean-k-mooney | bauzas: ah the unique constatit one | |
| 10:28:22 | sean-k-mooney | ya that is an existing issue that was not intoduced in this release so it woudl not be an RC candiate bug anyway | |
| 10:28:31 | sean-k-mooney | it can be backported after we do the release | |
| 10:28:52 | sean-k-mooney | so im fine with the +1 there | |
| 10:30:08 | opendevreview | zhouzhong proposed openstack/nova master: Instance unexpected shutdown when source node startup https://review.opendev.org/c/openstack/nova/+/875859 | |
| 10:32:38 | opendevreview | zhouzhong proposed openstack/nova master: Instance unexpected shutdown when source node startup https://review.opendev.org/c/openstack/nova/+/875859 | |
| 10:33:00 | opendevreview | zhouzhong proposed openstack/nova master: Instance unexpected shutdown when source node startup https://review.opendev.org/c/openstack/nova/+/875859 | |
| 10:50:35 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/placement/+/875873 | |
| 10:50:38 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/placement/+/875874 | |
| 10:50:42 | opendevreview | OpenStack Release Bot proposed openstack/placement master: Update master for stable/2023.1 https://review.opendev.org/c/openstack/placement/+/875875 | |
| 10:58:35 | opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Have schema for 'lock' action be applied to all microversions. https://review.opendev.org/c/openstack/nova/+/875653 | |