| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-28 | |||
| 17:39:31 | gmann | but is not that will be covered in normal grenade job from 2023.1 to 2023.2 ? or we want N-2 thing also due to libvirt bump ? and so does zed on jammy just because of grenade testing but main purpose is to check zed->2023.2 libvirt bump work fine or not? | |
| 17:40:38 | dansmith | not to test the libvirt bump specifically | |
| 17:40:53 | dansmith | but rather to keep us with a working N-2->N even though we don't *have* to support it | |
| 17:41:11 | dansmith | if we end up breaking something and have to drop the job, then fine, but I would rather highlight what breaks N-2 upgrades if we can | |
| 17:41:33 | gmann | ok | |
| 17:42:27 | gmann | i think it should work as zed was the edge when we move to jammy | |
| 17:42:38 | dansmith | yeah, will see | |
| 17:43:06 | opendevreview | Dan Smith proposed openstack/nova master: Add continuous skip-level job for nova https://review.opendev.org/c/openstack/nova/+/875773 | |
| 17:43:46 | gmann | so for that I will not filter out the 2023.2 from here (we filter out NON-SLURP here) which I do while release time https://github.com/openstack/grenade/blob/master/.zuul.yaml#L392 | |
| 17:44:16 | opendevreview | Dan Smith proposed openstack/nova master: Add continuous skip-level job for nova https://review.opendev.org/c/openstack/nova/+/875773 | |
| 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: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | |
| 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: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 | e naming process will help all of us to relate which release is “SLURP”." | |
| 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: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: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: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 | |