| *** amoralej|off is now known as amoralej | 06:37 | |
| opendevreview | Elod Illes proposed openstack/releases master: Create Zed branch for devstack plugins https://review.opendev.org/c/openstack/releases/+/857264 | 06:50 |
|---|---|---|
| opendevreview | Merged openstack/releases master: Heat: Create RC2 release https://review.opendev.org/c/openstack/releases/+/859204 | 07:06 |
| opendevreview | Merged openstack/releases master: Create Zed branch for devstack plugins https://review.opendev.org/c/openstack/releases/+/857264 | 10:49 |
| opendevreview | Artem Goncharov proposed openstack/releases master: Cut new OpenStackSDK release to resolve OSC dependency https://review.opendev.org/c/openstack/releases/+/859546 | 10:51 |
| *** dviroel|afk is now known as dviroel | 11:22 | |
| frickler | can we proceed with https://review.opendev.org/q/topic:pike-eol now? would be good to keep the number of periodic jobs from increasing now that zed is to be added | 11:58 |
| elodilles | frickler: i think yes, as soon as senlin, mistral and murano are eol'd. I've already +2'd their pike-eol change. | 12:00 |
| stephenfin | elodilles: As a general point, is there any reason there isn't an antelope (or 2023.1 (?) directory in the 'deliverables' directory for openstack/release | 12:01 |
| stephenfin | I mean, there's nothing else blocking us from releasing stuff on 'master' now, right? | 12:01 |
| stephenfin | gtema: ^ | 12:01 |
| elodilles | stephenfin: the deliverable/<new_series> is always created the week after the final release | 12:02 |
| stephenfin | I'm more curious whether it would be possible than anything else. "We don't have bandwidth to do that" is a suitable excuse :) | 12:02 |
| stephenfin | could it technically be done sooner? | 12:02 |
| elodilles | stephenfin: good question :) | 12:02 |
| stephenfin | to avoid the lame duck period between starting a new release and actually releasing it | 12:03 |
| elodilles | the directory structure is one thing, the other is whether it interfere somewhere with our tooling | 12:03 |
| elodilles | and that i don't know | 12:03 |
| elodilles | so i would stay on the safe side and wait one week o:) | 12:04 |
| stephenfin | heh, okay, wfm | 12:04 |
| gtema | sad | 12:04 |
| stephenfin | would be a good one to investigate for B though | 12:04 |
| stephenfin | or we go independent, gtema | 12:04 |
| stephenfin | which might make sense since we're supposed to support all releases ever | 12:05 |
| gtema | yes, right | 12:05 |
| gtema | who can remember me what is the procedure to go independent? | 12:05 |
| gtema | is it simply moving data file to _independent folder? cause I haven't found any other places | 12:06 |
| stephenfin | looks like it https://review.opendev.org/c/openstack/releases/+/764624 | 12:06 |
| stephenfin | I don't think we should do that this week. I can wait. I'd be game to do it as soon as zed is out though | 12:07 |
| stephenfin | (don't need to create more work for the release team right now) | 12:07 |
| gtema | but at least I can send out patch for going independent right now - we were discussing it few cycles already including the release team (in some former PTG) | 12:07 |
| opendevreview | Elod Illes proposed openstack/releases master: Adding Barbican Cycle Highlights for Zed https://review.opendev.org/c/openstack/releases/+/858479 | 12:09 |
| stephenfin | yup, makes sense | 12:09 |
| gtema | if I see mentioned patch correct we should propose move to _independent and not simply adding new file now in the independent and leaving zena. Right? | 12:10 |
| stephenfin | the only downside I see is that once we do this, we won't have stable branches automatically created for us | 12:10 |
| stephenfin | so if we want to do bugfixes for older releases, we can't really do them without creating special release branches | 12:10 |
| stephenfin | this is relevant right now. See gibi's email to openstack-dev titled "[release][requirements][oslo][nova] How to fix a bug and release the fix in oslo.concurrency 4.5.x series" | 12:11 |
| gtema | yes, seen that | 12:11 |
| gtema | but we promise to be always backward compatible, (whatever it means) - and test on older devstack releases with master | 12:12 |
| * gibi perks up | 12:12 | |
| stephenfin | true, though we will invariable introduce changes like dropping older Python versions | 12:16 |
| stephenfin | *invariably | 12:16 |
| gtema | hmm, but we should not really block ourselves because of that | 12:19 |
| *** amoralej is now known as amoralej|lunch | 12:29 | |
| *** diablo_rojo is now known as Guest1621 | 13:05 | |
| dmendiza[m] | Hey, y'all. I need to cut an RC2 for barbican, but for some reason, zuul doesn't seem to be running on the stable/zed branch: https://review.opendev.org/q/project:openstack%252Fbarbican+branch:stable%252Fzed | 13:31 |
| *** amoralej|lunch is now known as amoralej | 13:41 | |
| opendevreview | Thierry Carrez proposed openstack/releases master: Release Magnum Zed RC2 https://review.opendev.org/c/openstack/releases/+/859612 | 13:50 |
| ttx | dmendiza[m]: you might need https://review.opendev.org/c/openstack/barbican/+/858205 backported | 13:51 |
| opendevreview | Thierry Carrez proposed openstack/releases master: Release Neutron Zed RC2 https://review.opendev.org/c/openstack/releases/+/859614 | 13:54 |
| opendevreview | Thierry Carrez proposed openstack/releases master: Relsae Skyline-Console Zed RC2 https://review.opendev.org/c/openstack/releases/+/859615 | 13:55 |
| dmendiza[m] | ttx: yep, that's the one. thanks! | 13:59 |
| opendevreview | Thierry Carrez proposed openstack/releases master: Release Cinder Zed RC2 https://review.opendev.org/c/openstack/releases/+/859617 | 13:59 |
| ttx | In retrospect that queue change deprecation did create a lot of release churn that could have been avoided | 14:04 |
| fungi | well, the deprecation didn't (that went into effect in zuul 4.1.0 with the merging of 720182 on 2021-02-25) | 14:26 |
| fungi | but no amount of reminding people they need to fix something for 18 months straight will be 100% effective | 14:26 |
| fungi | and we provided increasingly stern reminders on mailing lists over the course of the entire zed cycle too | 14:27 |
| fungi | along with lists of the projects which would be impacted | 14:28 |
| ttx | Yeah... no amount of warning will get them to pay attention, but pushing the breaking change between stable/zed creation and final release pushed back the problem on the release team hands | 14:28 |
| ttx | while waiting until post-release would have broken future backports instead | 14:29 |
| ttx | but I understand we are not the only stakeholder in that equation | 14:29 |
| fungi | right, i think that's a clear risk with the both the opendev collaboratory and zuul no longer being part of openstack. things will happen on schedules independent of openstack's release activities, and the project will need to pay closer attention to notifications of impending changes | 14:29 |
| ttx | I mean, I read the change but had no idea so many projects had broken job definitions | 14:30 |
| fungi | but i think an 18-19 month deprecation period along with months after months of directed warnings ought to be more than enough | 14:30 |
| fungi | there are currently 446 config errors listed for the openstack tenant (many are for unrelated configuration errors people also never bother to fix) | 14:32 |
| *** marios is now known as marios|out | 14:32 | |
| fungi | i get that sifting through them all is a lot of work, but it gets increasingly worse when nobody bothers to fix them | 14:33 |
| fungi | on an unrelated note, it sounds like moving oslo.concurrency to the independent release model has proved problematic... the maintainers want to add stable branches for backporting fixes | 14:35 |
| ttx | yeah I suspected that decision would come back to us and bite us | 14:45 |
| elodilles | if treat oslo.concurrency as external dependencies, then the question is whether we can use oslo.concurrency 5.0.1 instead of the currently constrained 4.5.0 in stable/yoga | 14:47 |
| elodilles | * if we treat | 14:47 |
| elodilles | in that case we don't need a new 'stable' branch | 14:48 |
| elodilles | maybe we need to add some kind of stable/<MAJOR-version> branch mechanism to release repo to avoid this issue | 14:49 |
| elodilles | in that case we can change to independent model for low-activity projects while we could release bugfixes even if a new MAJOR version bump (breaking change) is there | 14:50 |
| elodilles | if i remember correctly we cannot release from bugfix/<version> branches via the repo (bugfix/<version> example from ironic's yaml: https://opendev.org/openstack/releases/src/branch/master/deliverables/zed/ironic.yaml#L25 ) | 14:56 |
| opendevreview | Merged openstack/releases master: Release Magnum Zed RC2 https://review.opendev.org/c/openstack/releases/+/859612 | 15:13 |
| clarkb | ttx: I tried to list all of the affected repos in my email (though apparently we missed some that were impacted via project-config). We also asked people to address it months in advance of the removal. And I even pushed changes to a number of projects myself | 15:17 |
| clarkb | yes the timing was not ideal, but we really did try here | 15:18 |
| clarkb | fungi: re the config errors in the openstack tenant one of my specific frustrations with that is a large number of them originate from project rename requests from openstack. It feels like openstack is happy to rename things as long as someone else does all the work | 15:20 |
| fungi | the project-config queue fix, while missed in the earlier audits, was identified and solved within minutes of symptoms being noticed (basically first thing monday after the weekend automatic restart) | 15:22 |
| *** dviroel is now known as dviroel|lunch | 15:29 | |
| opendevreview | Douglas Mendizábal proposed openstack/releases master: Release Barbican Zed RC2 https://review.opendev.org/c/openstack/releases/+/859649 | 16:24 |
| *** dviroel|lunch is now known as dviroel | 16:35 | |
| *** amoralej is now known as amoralej|off | 16:48 | |
| opendevreview | Elod Illes proposed openstack/releases master: Add missing release note links for Zed https://review.opendev.org/c/openstack/releases/+/859690 | 18:47 |
| *** dviroel is now known as dviroel|walk | 19:54 | |
| *** dviroel|walk is now known as dviroel | 20:44 | |
| *** dviroel is now known as dviroel|out | 21:37 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!