| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-01 | |||
| 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 | |
| 11:05:22 | bauzas | folks, placement-rc1 tag is done, master is now on Bobcat and Antelope is branched for Placement, I repeat, Antelope is branched for Placement | |
| 11:55:58 | gibi | bauzas: \0/ | |
| 12:00:02 | sean-k-mooney | a day ahead of schdule and all :P | |
| 12:00:08 | sean-k-mooney | but cool | |
| 12:01:06 | sean-k-mooney | the non client libs like os-vif and os-traits are also already branched | |
| 12:01:49 | sean-k-mooney | well at least os-vif is but i assume the same is true for the rest | |
| 13:00:34 | bauzas | sean-k-mooney: indeed, I approved https://review.opendev.org/c/openstack/releases/+/874450 | |
| 15:07:39 | dansmith | bauzas: so my skip-level job failed because we can't ssh to the guest | |
| 15:07:53 | dansmith | it's clearly working (reachable) but rejecting maybe the key or something | |
| 15:08:04 | dansmith | can you think of what about running on jammy would affect that? | |
| 15:12:03 | sean-k-mooney | could it be related to sha1/rsa keys | |
| 15:12:15 | sean-k-mooney | i think tempest is using ec keys now | |
| 15:12:24 | sean-k-mooney | but thats a guess | |
| 15:12:36 | dansmith | that's what I was thinking too, but we're generating the keys with osc | |
| 15:13:02 | dansmith | oh, but maybe jammy as the host refuses to use them? | |
| 15:13:30 | dansmith | I would think that if we needed a change, that'd be wrapped up in grenade already though... | |
| 15:13:34 | sean-k-mooney | fedora reject rsa keys. osc will only generate rsa keys because that all nova does | |
| 15:13:56 | sean-k-mooney | so unless its gnereated in tempest itself it would fail if jammy rejects them | |
| 15:14:17 | sean-k-mooney | with that said im expecting that job to still use tempest master right | |
| 15:14:29 | dansmith | this is pre-tempest, this is grenade resource creation | |
| 15:14:30 | sean-k-mooney | we dont pin it or anything strange for grenade | |
| 15:14:57 | bauzas | dansmith: lemme look at your change | |
| 15:15:19 | dansmith | sean-k-mooney: https://github.com/openstack/grenade/blob/master/projects/70_cinder/resources.sh#L186 | |
| 15:15:29 | dansmith | sean-k-mooney: https://github.com/openstack/grenade/blob/master/projects/70_cinder/resources.sh#L121 | |
| 15:15:48 | dansmith | and when we try to ssh: | |
| 15:15:49 | dansmith | 2023-02-28 20:55:58.894 | debug1: Will attempt key: /opt/stack/save/cinder_key.pem explicit | |