| opendevreview | Brian Rosmaita proposed openstack/releases master: Release cinder RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979521 | 01:55 |
|---|---|---|
| opendevreview | Gregory Thiemonge proposed openstack/releases master: Release octavia-dashboard RC2 for Gazpacho https://review.opendev.org/c/openstack/releases/+/980661 | 08:26 |
| elodilles | release-team: see gouthamr comment on vitrage RC1 patches: https://review.opendev.org/c/openstack/releases/+/979621 | 10:04 |
| elodilles | release-team: we are way over Gazpacho-2 milestone where release process requires to solidify the release content... so what do you say? | 10:05 |
| opendevreview | Merged openstack/releases master: Release tacker RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979609 | 10:18 |
| opendevreview | Elod Illes proposed openstack/releases master: Release keystone RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979536 | 10:22 |
| opendevreview | Merged openstack/releases master: Release keystone RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979536 | 12:24 |
| ttx | Yeah I agree it's a bit late to drop it as at this point we built the expectation it would be in the release | 12:33 |
| ttx | In the past we did issue a last release for a just-inactive project | 12:34 |
| ttx | unless it's utterly broken, I think we should have it | 12:34 |
| ttx | but it's not that luch of a big deal to remove it if the TC prefers it that way | 12:35 |
| ttx | much* | 12:35 |
| frickler | ttx: can you get venus and vitrage deleted from the openstack.org map anyway? also I'm not sure what really defines what is part of the release. is https://opendev.org/openstack/releases/src/branch/master/deliverables/gazpacho/vitrage.yaml existing the promise that it will be released this cycle? | 12:39 |
| opendevreview | Takashi Kajinami proposed openstack/releases master: Release heat RC1 for 2026.1 Gazpacho https://review.opendev.org/c/openstack/releases/+/979535 | 12:46 |
| ttx | We have a freeze at milestone-2 for what deliverables are part of the release | 12:50 |
| ttx | The map is updated around release time based on what's in it | 12:50 |
| ttx | we ask that deliverable files are added or removed before milestone-2 | 12:52 |
| ttx | but then people keep on adding or removing things after that... I'm fine with changing the rule if that's what the TC wants to do. The rule was there to give downstream packagers of openstack some visibility | 12:53 |
| ttx | so that they know what they need to package and what not | 12:54 |
| *** haleyb|out is now known as haleyb | 13:02 | |
| elodilles | ACK, thanks, i've commented on the patches. https://review.opendev.org/c/openstack/releases/+/979621 | 14:16 |
| zigo | What's the Cinder status? Is RC1 comming "soon" (whateve this means...) ? | 15:04 |
| zigo | And Barbican, and Heat, in fact ... :/ | 15:43 |
| fungi | zigo: https://review.opendev.org/q/status:open+project:openstack/releases has open release requests for gazpacho rc1, for example https://review.opendev.org/c/openstack/releases/+/979521 for cinder was updated over the weekend with "we are running late ... have some driver patches that we're trying to merge before the RC is cut" and was then revised early utc today so looks | 16:30 |
| fungi | ready? | 16:30 |
| zigo | Ah, nice, thanks ! :) | 16:30 |
| fungi | yeah, looks like rosmaita updated it to a newer commit id, so presumably that contains what they wanted in rc1 | 16:32 |
| * zigo saves the URL for Hibiscus ... :P | 16:32 | |
| fungi | elodilles: ttx: frickler: gouthamr: i commented as much on the vitrage rc1 change, but i think there was some process disconnect. both it and venus were set to inactive at the start of the current cycle long before the deadline so i guess it just missed pushing a similar change to releases once that happened? | 16:35 |
| elodilles | fungi: ah, i see. we definitely need to sync with governance / release processes | 16:49 |
| ttx | If it was inactive since start of cycle I support not releasing it | 17:04 |
| gouthamr | ah, this governance<-->release sync is manual? | 17:39 |
| gouthamr | (i see release liaisons quite outdated too, and was feeling for elodilles's pings going unanswered by release liaisons that are no longer associated with several projects) | 17:39 |
| gouthamr | I don't see any content in venus, venus-dashboard or vitrage worth releasing. the bot changes to update constraints/reno/gitreview etc aren't ack'ed. These projects are definitely abandoned. i can bring this up in tomorrow's TC meeting if we can wait to make the decision then.. | 17:43 |
| tobias-urdin | questions about gpg signing keys for releases, checking the epoxy release key that has expired 2025-05-20 but initial release for epoxy was 2025-04-02, that doesn't seems correct? we have recent releases such as cinder 26.2.0 that was made 2025-10 but those cannot be verified since the key has expired? | 18:59 |
| tobias-urdin | (data was signed after key expired?) | 18:59 |
| fungi | tobias-urdin: it's the epoxy cycle key, not the epoxy branch key | 19:01 |
| fungi | recent changes are signed with the gazpacho signing key if they were made during the gazpacho cycle timeframe, even if they were signing tags and tarballs for an older stable branch | 19:02 |
| fungi | https://releases.openstack.org/#cryptographic-signatures lists the effective date ranges when those keys were used | 19:02 |
| fungi | so the epoxy key should only have signed anything between 2024-10-07 and 2025-04-07 | 19:03 |
| fungi | then the flamingo key between 2025-04-07 and 2025-10-06 | 19:03 |
| fungi | anything signed after 2025-10-06 used the gazpacho key and will continue to do so until 2026-04-06 when we'll rotate it out for the hibiscus key | 19:04 |
| fungi | traditionally we've timed signing key rotations to take place on the monday after the coordinated release for the past few years | 19:04 |
| fungi | the keys are prepared and published in advance, so for example you can load the hibiscus key now in preparation for verifying signatures that will be coming in april | 19:05 |
| fungi | hopefully that makes sense? | 19:06 |
| fungi | i've always tried to include "cycle" in the key descriptions to make it more obvious they're time-based not branch-based | 19:06 |
| tobias-urdin | ah, that explains it – i could successfully verify signature for cinder 26.2.0 with the gazpacho cycle key | 19:07 |
| fungi | in part because we'd rather avoid having to extend key expirations and replace them, but we can't easily predict when stable branches will actually reach end-of-maintenance, while we are able to predict our coordinated release dates and cycle start/end accurately months ahead of rotation | 19:08 |
| tobias-urdin | is there any consumable file, yaml or such, that i can consume to get a list of the keys for each release? | 19:08 |
| fungi | does rst count? | 19:08 |
| tobias-urdin | :D | 19:09 |
| fungi | https://releases.openstack.org/ is built from https://opendev.org/openstack/releases/raw/branch/master/doc/source/index.rst | 19:09 |
| tobias-urdin | the series_status.yaml in openstack/releases (and all deliverables) are great for everything, except me trying to find the correct key to verify with, i'll see if i can parse the doc or just do it manually for now | 19:11 |
| fungi | tobias-urdin: alternatively, you can just pull new key copies from https://opendev.org/openstack/releases/src/branch/master/doc/source/static since they have comments in them indicating which cycle they belong to, though that doesn't get you the dates they were rotated into use | 19:11 |
| fungi | i'm open to alternative ways of encoding all this too, so long as the end result isn't a bunch of duplication that will get out of sync | 19:12 |
| fungi | we could do a sphinx extension to render that section of the document into rst from some yaml instead | 19:12 |
| fungi | similar to how we render security advisories from yaml data on security.openstack.org | 19:13 |
| fungi | as the years go by, it has gotten a bit unweildy to manage directly in rst and clutters that file, so embedding it in yaml would allow us to reduce duplication (every key id appears 3x in the rst) and clean up the index.rst at the same time | 19:15 |
| opendevreview | Tobias Urdin proposed openstack/releases master: Move and generate signing key doc from series_status https://review.opendev.org/c/openstack/releases/+/980831 | 21:59 |
| tobias-urdin | fungi: ^ that was a fun mini project :) | 21:59 |
| fungi | thanks! i can't promise i'll have time to review it soon, but will get to it | 22:01 |
| fungi | i've starred it in gerrit to remind me | 22:01 |
| tobias-urdin | ack, thanks | 22:02 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!