| gmann | elodilles: regarding patrole QA deliverables release, this project is not much active and I am going to retire it soon after discussion in PTG. There is no change merged after last release in zed. should we skip to release now in this cycle or release with same has as of last release ? | 02:33 |
|---|---|---|
| opendevreview | Riccardo Pittau proposed openstack/releases master: Release ironic-prometheus-exporter 4.1.0 for antelope https://review.opendev.org/c/openstack/releases/+/874824 | 08:07 |
| opendevreview | Riccardo Pittau proposed openstack/releases master: Release ironic-python-agent-builder 5.1.0 for antelope https://review.opendev.org/c/openstack/releases/+/874825 | 08:09 |
| opendevreview | Riccardo Pittau proposed openstack/releases master: Release ironic-ui 6.1.0 for antelope https://review.opendev.org/c/openstack/releases/+/874826 | 08:11 |
| opendevreview | Riccardo Pittau proposed openstack/releases master: Release networking-baremetal 6.1.0 for antelope https://review.opendev.org/c/openstack/releases/+/874827 | 08:13 |
| opendevreview | Riccardo Pittau proposed openstack/releases master: Release networking-generic-switch 8.0.0 for antelope https://review.opendev.org/c/openstack/releases/+/874828 | 08:15 |
| gthiemonge | Hey Folks, we would like to merge this commit https://review.opendev.org/c/openstack/python-octaviaclient/+/874553 in python-octaviaclient for Antelope | 08:38 |
| gthiemonge | so it means that we would create a new release (3.4.0) and we would update this release patch https://review.opendev.org/c/openstack/releases/+/874451 with the new tag | 08:39 |
| gthiemonge | is it ok? | 08:39 |
| *** amoralej|off is now known as amoralej | 08:41 | |
| elodilles | hi gthiemonge , well, it's a bit late and requires FFE and RFE | 09:19 |
| elodilles | but i'm OK with it if you signal this on ML | 09:20 |
| elodilles | hberaud ttx : your opinion? | 09:20 |
| hberaud | same thing, I'm ok if you signal this on ML | 09:25 |
| gthiemonge | elodilles: hberaud: ack, thank you | 09:35 |
| gthiemonge | elodilles: hberaud: I think we can propose a new python-octaviaclient release anyway, right? | 09:36 |
| elodilles | gthiemonge: yes, and link that in the above mentioned mail to ML | 09:45 |
| gthiemonge | elodilles: ok, thanks | 09:46 |
| opendevreview | Gregory Thiemonge proposed openstack/releases master: Release python-octaviaclient 3.4.0 for Antelope https://review.opendev.org/c/openstack/releases/+/874864 | 10:01 |
| gthiemonge | elodilles: hberaud: email sent | 10:08 |
| hberaud | thx | 10:09 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: Add Neutron highlights (Antelope release) https://review.opendev.org/c/openstack/releases/+/874754 | 11:09 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/releases master: ironic-ui antelope release https://review.opendev.org/c/openstack/releases/+/874912 | 11:48 |
| *** amoralej is now known as amoralej|lunch | 12:04 | |
| frickler | elodilles: hberaud: assuming 874864 merges, that would unblock half of the openstacksdk bump in u-c that is still pending, the other half is still in progress here https://review.opendev.org/c/openstack/kuryr-kubernetes/+/874571/4 . assuming that that went through, we would likely need another ffe for the sdk? | 12:18 |
| frickler | (https://review.opendev.org/c/openstack/requirements/+/873598) | 12:19 |
| elodilles | frickler: oh, thanks for the info | 12:23 |
| elodilles | frickler: though i only see the kuryr-kubernetes patch that is blocking the openstacksdk bump in u-c | 12:26 |
| frickler | hmm, there was an cross-osc-tox-docs failure earlier. my understanding was that the octaviaclient bump would fix it, but it seems it got resolved in some other fashion | 12:33 |
| gtema | Thanks fricler for mentioning it here. From SDK pov it is important to finally merge u-c stuff. We had R1. release on schedule, it is just due to dependencies in Octaviaclient and some more patch couldn't be merged | 13:14 |
| *** amoralej|lunch is now known as amoralej | 13:35 | |
| elodilles | gtema frickler : i would also suggest to set the kuryr job non-voting until its fix merges | 14:08 |
| gtema | +1 from me | 14:08 |
| elodilles | just to speed up things a bit | 14:08 |
| elodilles | we are very close to the final release date | 14:09 |
| frickler | ack, let me propose a change for that | 14:15 |
| frickler | https://review.opendev.org/c/openstack/requirements/+/874924, and sdk bump rebased on top | 14:22 |
| elodilles | frickler: thanks! | 14:28 |
| bauzas | elodilles: you're good to go with merging both cycle-highlights from nova; the doc patch landed https://review.opendev.org/q/topic:nova_antelope_highlights | 14:30 |
| abhishekk_ | can we have review on; | 14:30 |
| abhishekk_ | https://review.opendev.org/c/openstack/releases/+/874542 | 14:30 |
| abhishekk_ | https://review.opendev.org/c/openstack/releases/+/874587 | 14:30 |
| * bauzas wonders whether he should propose next cycle a released milestone when comparing to other projects | 14:31 | |
| bauzas | at least nova would show up in https://releases.openstack.org/antelope/ | 14:31 |
| bauzas | that being said, rc1 is at the door | 14:32 |
| bauzas | maybe not worth it | 14:32 |
| hberaud | now no | 14:32 |
| hberaud | rc1 are next week | 14:32 |
| hberaud | however next cycle may you can propose a beta somewhere between M2 and M3 | 14:33 |
| elodilles | or even at every milestone, like some other projects do :) | 14:35 |
| elodilles | so yes, there is the possibility | 14:36 |
| bauzas | hberaud: yes no worries I know rc1 is next week | 14:40 |
| bauzas | when I say 'at the door', I was meaning it was close | 14:40 |
| * bauzas gets enough reminder emails : | 14:41 | |
| hberaud | yeah np | 14:41 |
| bauzas | :p | 14:41 |
| bauzas | + me already hassles too much his nova peers with release timings | 14:41 |
| bauzas | elodilles: we did delivered a milestone release | 14:41 |
| bauzas | elodilles: I'm just debating the benefts | 14:42 |
| bauzas | benefits | 14:42 |
| bauzas | if the distros like getting a nightly build in advance, I can surely try to make a release earlier than rc1 | 14:42 |
| bauzas | but before m3, this is a bit meaningless | 14:43 |
| elodilles | indeed. it depends on the content that a beta would have. | 14:44 |
| bauzas | maybe a question for our deployers | 14:49 |
| bauzas | I'll try to keep it in mind | 14:49 |
| JayF | Is it possible to get an exception to EM release policy to cut a release for Ironic wallaby? https://storyboard.openstack.org/#!/story/2010537 exists in our final wallaby release, it's impacting customers... the fix is in git but we've been asked to release it | 15:38 |
| dtantsur | To be clear on the impact. The latest release has a regression that breaks Ironic with all Dell machines with the latest firmware. | 15:39 |
| elodilles | JayF dtantsur : i understand the need, but once something is in EM we can't release anymore :/ so this is something that vendors need to handle with a downstream release | 15:44 |
| elodilles | it was also discussed regarding a recent CVE as well | 15:45 |
| dtantsur | elodilles: not everyone has a vendor.. | 15:45 |
| JayF | It makes sense to me because we've done things when it went em that would be weird to undo -- e.g. tagging wallaby-em | 15:45 |
| JayF | dtantsur: if we unpublished a release would it put us in a better place? | 15:45 |
| JayF | dtantsur: it's unclear to me if this is an *ironic* or a *dell* regression | 15:45 |
| dtantsur | JayF: we'll miss other bug fixes then | 15:46 |
| dtantsur | it's a sushy regression, but it came with a bunch of other fixes | 15:46 |
| elodilles | dtantsur: i understand. from one hand, everyone wants to keep things open and maintained forever. from the other hand, developers, maintainers don't have time to keep maintained everything for ages. it's a trade off of (even) Extended Maintenance. | 15:47 |
| dtantsur | JayF: check https://docs.openstack.org/releasenotes/sushy/wallaby.html. we'll need to yank up and including 3.7.4 | 15:47 |
| JayF | elodilles: Does it make a difference that sushy is a library and not part of the integrated release? I presume not... | 15:47 |
| dtantsur | it actually does a ton of difference, because without releases EM is pointless for libraries | 15:47 |
| JayF | That is not true in all cases; I've consumed EM releases of libraries downstream before | 15:48 |
| dtantsur | EM releases of libraries don't happen? | 15:48 |
| JayF | but you're right that it does mean that most users won't get the value | 15:48 |
| dtantsur | at least per elodilles right now | 15:48 |
| elodilles | JayF: no difference | 15:48 |
| JayF | dtantsur: I mean, em forks -- e.g. building our own packages | 15:48 |
| JayF | from the em git repo | 15:48 |
| dtantsur | right, that's what we do. but that assumes a sophisticated downstream | 15:48 |
| dtantsur | people using, say, bifrost are out in the cold | 15:49 |
| JayF | yeah; but EM is intended to be a place for sophisticted downstreams to coordinate | 15:49 |
| JayF | not really for openstack to keep doing releases | 15:49 |
| JayF | like don't get me wrong, this is a bad situation and I'm not happy about it | 15:49 |
| JayF | but I understand the tensions on both sides that make it hard | 15:49 |
| dtantsur | yeah, me too. but I feel this is a gap in how we're treating EMs | 15:49 |
| JayF | If it's a gap; it's logical and not policy. The policy is pretty clear, and we can't like fix it retroactively. If it's not the best way to do things, we can hit the list and have a bigger discussion about moving forward | 15:50 |
| JayF | but that's probably going to also need to come with hands to help out the releases team if the scope would be extended | 15:50 |
| dtantsur | Yep and yep. I guess the only lesson here is that we should actively stop calling EM branches supported releases of OpenStack. Or making this impression. | 15:52 |
| dtantsur | I'm afraid (judging by the very fact of this conversation), this is not really obvious even to (some?) ironic cores. | 15:52 |
| JayF | https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance the policy is basically best effort with no releases | 15:52 |
| JayF | at least that's how I've always read it | 15:52 |
| JayF | I hoped that in an exceptional case an exception could be made, but that's not my call and a no is a no | 15:53 |
| noonedeadpunk | I there a reason why you want to have sushi not as independant? | 15:55 |
| noonedeadpunk | *is | 15:55 |
| noonedeadpunk | as usually libraries like that are independant and thus don't have such limitations | 15:55 |
| noonedeadpunk | well, you was asking how to fix past, but maybe let's at least see how to prevent same in future... | 15:56 |
| JayF | I don't know the answer to that question; but what you're saying makes some sense to me | 15:57 |
| JayF | especially given in #openstack-ironic we were just talking about pulling in a newer-than-wallaby version of that package as a workaround for this release not happening | 15:57 |
| JayF | dtantsur: wdyt about noonedeadpunk's suggestion to consider making sushy indepedent release cycle? | 15:57 |
| dtantsur | JayF: it will increase our load wrt maintaining branches and releases? | 16:02 |
| elodilles | for the record: being independent could cause similar problems: it's good that a new version can be always released and used whatever branch you need that deliverable. but the same situation could happen: you cannot use the new release on an old branch, because meanwhile things changed under the deliverable and it cannot be installed anymore to an old environment | 16:02 |
| dtantsur | correct | 16:02 |
| elodilles | we had this situation recently with some oslo library and the result was to move back from independent to cycle with series releases (even if there are not that many changes in these libraries) | 16:04 |
| noonedeadpunk | well, It kind of depends on type of dependencies | 16:18 |
| noonedeadpunk | And if sushi is really tighten to coordinated releases. | 16:18 |
| noonedeadpunk | I'm not ironic expert, but it seemed like a library for communication with redfish, that should not bring regressions for older releases... | 16:19 |
| noonedeadpunk | But yeah, again that's in theory | 16:19 |
| JayF | sushy maintains semver pretty strongly for itself generally | 16:25 |
| JayF | because Ironic is not the only consumer (openstack projects might be the only consumers though) | 16:25 |
| JayF | I will add this as an item for Ironic to discuss at the PTG; it'd be nice if elodilles or some other expert would be there to help us with any "gotchas" (like the catch with being independent) | 16:26 |
| elodilles | these are also sometimes on the agenda of release team sessions as well :) and as it can be guessed, even there, we are not sure, what is best to follow :/ | 16:32 |
| JayF | putting it on our list doesn't actually mean it'll happen either, just a good way of sticking a pin in it so we don't forget | 16:35 |
| JayF | but I don't wanna spend all day pondering releases :) | 16:35 |
| opendevreview | Merged openstack/releases master: [winstackers] Create 2023.1 branch for client and non-client libs https://review.opendev.org/c/openstack/releases/+/874462 | 17:34 |
| *** amoralej is now known as amoralej|off | 18:00 | |
| gmann | elodilles: did you get chance to see my question on Patrol release ? | 19:08 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!