| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-01 | |||
| 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 | |
| 15:15:49 | dansmith | 2023-02-28 20:55:58.897 | debug1: SSH2_MSG_SERVICE_ACCEPT received | |
| 15:15:59 | dansmith | ahh | |
| 15:16:04 | dansmith | 2023-02-28 20:55:58.902 | sign_and_send_pubkey: no mutual signature supported | |
| 15:16:06 | dansmith | there ^ | |
| 15:16:52 | dansmith | but surely grenade is running on jammy nodes already, so I'm not sure why it wouldn't have been configured to support the old keys | |
| 15:18:28 | sean-k-mooney | dansmith: proably not | |
| 15:18:42 | sean-k-mooney | for antelop i think it used focal | |
| 15:18:48 | dansmith | looks like not yeah | |
| 15:19:00 | dansmith | okay, well, I can fix that then I guess | |
| 15:19:08 | sean-k-mooney | so likely we jsut need to call ssh-keygen directly | |
| 15:19:12 | sean-k-mooney | instead of osc | |
| 15:19:33 | bauzas | wait | |
| 15:19:36 | dansmith | well, I was going to configure the host to allow that key type | |
| 15:19:38 | bauzas | https://github.com/openstack/grenade/blob/master/projects/70_cinder/resources.sh#L121 | |
| 15:19:47 | bauzas | we no longer support this by Zed | |
| 15:20:11 | bauzas | oh no, sorry | |
| 15:20:14 | dansmith | bauzas: but it works if you use the old microversion, which osc is doing right? | |
| 15:20:17 | bauzas | you're passing the key | |
| 15:20:32 | bauzas | dansmith: ah right too | |
| 15:20:41 | dansmith | also that :) | |
| 15:20:48 | bauzas | but I wonder, that's probably why we have a problem with rsa | |
| 15:21:14 | bauzas | could we maybe try to create ed keys ? | |