| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-28 | |||
| 17:44:31 | stephenfin | Got it. It's late binding https://stackoverflow.com/q/3431676/ Sigh, TIL | |
| 17:45:02 | dansmith | gmann: oh hmm, that's just the thing that prevents it from running on stable right? | |
| 17:45:20 | gmann | yeah | |
| 17:45:42 | gmann | because it is in integrated gate template also | |
| 17:45:54 | dansmith | yeah, so that's okay for now right? we only care about master | |
| 17:47:11 | gmann | yes, we can adjust the integrated template not to run it for other projets does not want to run and keep generic job able-to-run-everywhere | |
| 17:48:01 | gmann | and that is good so that project can control if they want to run or skip instead of we stop it for everyone | |
| 17:48:04 | dansmith | gmann: well, I just inherited it for nova ^ | |
| 17:48:39 | dansmith | if other projects want to do the same, we can add it to grenade and not the integrated jobs, but if not, we might as well keep it in nova for now right? | |
| 17:49:10 | gmann | dansmith: ohk it need to run on jammy otherwise default one will run on focal | |
| 17:49:20 | dansmith | right | |
| 17:51:01 | gmann | dansmith: in that case let me filter out the base job for 2023.2 not to run so that it does not run by default as part of integrated gate and you can override 'branches' variant in nova inherited job to run on 2023.2 (master) | |
| 17:53:05 | dansmith | gmann: yeah I assumed that was what you would do once 2023.2 opens right? | |
| 17:53:35 | gmann | dansmith: yeah | |
| 17:55:39 | dansmith | gmann: ubuntu-jammy is not the right nodeset? | |
| 17:56:49 | opendevreview | Dan Smith proposed openstack/nova master: Add continuous skip-level job for nova https://review.opendev.org/c/openstack/nova/+/875773 | |
| 17:56:51 | gmann | dansmith: openstack-single-node-jammy in devstck set the controller things more than just ubuntu-jammy so for devstck based job openstack-single-node-jammy will work | |
| 17:57:04 | dansmith | okay | |
| 17:57:06 | gmann | https://github.com/openstack/devstack/blob/master/.zuul.yaml#L11 | |
| 17:57:58 | dansmith | I copied from tempest-tox-plugin-sanity-check which I guess is not a devstack job | |
| 17:58:13 | opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | |
| 17:58:50 | bauzas | dansmith: sean-k-mooney: just updated the next-after-rc1 patch for make grenade-skip-level voting on both check and gate pipes | |
| 18:04:15 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add service version for Antelope https://review.opendev.org/c/openstack/nova/+/874932 | |
| 18:04:15 | opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | |
| 18:04:31 | bauzas | sean-k-mooney: dansmith: and did the cleanups for the antelope patch | |
| 18:49:56 | sean-k-mooney | "Nova does now currently support the | |
| 18:49:58 | sean-k-mooney | coexistence of N and N+2 or greater | |
| 18:50:00 | sean-k-mooney | " | |
| 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 | |