Thursday, 2021-09-09

*** diablo_rojo is now known as Guest673301:00
*** amoralej|off is now known as amoralej06:48
*** ysandeep|out is now known as ysandeep07:00
opendevreviewSlawek Kaplonski proposed openstack/releases master: New releases of the Neutron stable versions
*** ysandeep is now known as ysandeep|lunch07:52
*** ysandeep|lunch is now known as ysandeep08:18
opendevreviewMerged openstack/releases master: [Glance] Xena milestone 3 release
opendevreviewMerged openstack/releases master: [oslo independent] release oslo.concurrency
opendevreviewMartin Kopec proposed openstack/releases master: Release Tempest 29.0.0 as Xena final release
*** ysandeep is now known as ysandeep|afk09:48
opendevreviewMartin Kopec proposed openstack/releases master: Add releasenotes link for Tempest 29.0.0
*** ysandeep|afk is now known as ysandeep11:28
fungihberaud: where did you have in mind for reviewing a design specification about a release metadata api? (ongoing the ml thread)12:09
*** amoralej is now known as amoralej|lunch12:13
*** amoralej|lunch is now known as amoralej13:13
hberaudfungi: I was thinking about doing that design through an openstack goal or something like that13:16
fungigoals are usually for when many projects need to be involved in implementing something13:18
fungii don't know that we need that level of cross-project coordination if the goal is to just serve release metadata in a more downstream-consumable manner13:19
hberaudyou are surely right this was more a suggestion, as I didn't see example of this kind of specification during my carreer on the release team13:20
hberaudI was thinking that the goal could be a good place to open the discussion13:21
fungiright, usually we've talked through things in irc/ml or ptg sessions and then started working on a prototype to review wherever it would be implemented13:21
hberaud"the goals"13:21
hberaudI see13:22
fungias far as release automation or features of the releases site are concerned13:22
hberaudyes, I think this is the case there (release feature)13:22
fungii do agree it would be good to gather some input from package maintainers of multiple distros to find out what specific information would be useful to them13:23
hberaudthe "goals".13:28
hberaudsorry ignore my previous question13:29
hberaudyes, it would be good to see the needs from the different sides13:29
fungihberaud: yes, in an informal sense we need to know what goals people have for the implementation. in the sense of formal i don't think it's a fit13:43
fungias the openstack-wide goals are about implementing or fixing things across many projects and teams13:44
hberaudI see13:44
fungithe openstack-wide goals process is also cumbersome, and a lot of overhead, useful when trying to coordinate and prioritize work across dozens of teams and hundreds of contributors/reviewers, but for something where we'd just be adding a looking with some release info in a central place that seems like extreme process overkill13:45
hberaudYou are right13:46
hberaudfungi: Thank you for all your useful thoughts. Let's wait a bit for their reply on your last email. After this point I'll summarize our discussion (^) to reorient the specification if needed. 14:23
opendevreviewMartin Kopec proposed openstack/releases master: Release bashate 3.0.0
opendevreviewMartin Kopec proposed openstack/releases master: Release devstack-tools 1.3.0
fungihberaud: sure, i've also been talking to them in #debian-openstack which is what prompted my question (they were asking me where they should post a spec)14:35
hberaudAh I see :)14:37
opendevreviewMartin Kopec proposed openstack/releases master: Release os-testr 3.0.0
toskya new os-testr O.o14:52
*** ysandeep is now known as ysandeep|mtg15:04
clarkbhberaud: fungi: I was thinking about that a bit and realized that if openstack used semver properly that should be a sufficent amount of info? unforatunetly that doesn't happen today aiui15:21
fungiclarkb: well, you can infer from semver whether a release after the cycle breaks backward compatibility or has explicit dependency version changes, but you can't easily differentiate those from "breaking" changes during the development cycle without some timeline mapping between independent releases and coordinated releases15:24
fungiit's most useful to consider the specific example from earlier in the thread: how do you know which version of taskflow should be used with openstack wallaby?15:25
fungimy argument is that independent release deliverables are effectively no different than external dependencies, in that regard15:25
clarkbright that is my argument too and I'm saying if you semver then its any version within the major release range set by upper constraints15:26
fungiand that the underlying question is how to know what version of openstack's (transitive) dependency set is recommended to be used for a given coordinated release of openstack15:26
clarkbunfortunately I don't think we are that disciplined about semver15:27
fungiwell, even if we're disciplined about semver, not all our external dependencies are15:27
clarkbthat is true though it seems zigos specific complaint is for libs we do control15:27
*** ysandeep|mtg is now known as ysandeep15:28
tkajinamhi. may I ask somebody from release team to remove old branches in storlets repo ? there are couple of patches merged recently to retire these branches15:32
tkajinamNewton and Ocata:
tkajinamP, Q, R and S
clarkbfungi: I'm slightly concerned that by creating a new API for this we're overlooking the tools that have existed for a long time to solve this simply because we don't use those tools properly15:32
clarkbtkajinam: I think elodilles_pto has been handling those.15:32
fungiyes, after the release change to tag those branches eol merges, elodilles_pto occasionally runs a batch script to delete the branches15:33
tkajinamah thanks. seems he is taking off now so I'll check with him once he comes back15:34
fungiclarkb: well, right that's more or less been my point as well. if you want to know what version of taskflow we recommend for wallaby, that's the version we test stable/wallaby changes with, and it's encoded in the upper-constraints.txt file in the stable/wallaby branch of openstack/requirements15:35
tkajinamclarkb, fungi,  thanks, both15:35
fungiclarkb: in theory newer versions of taskflow should be usable with stable/wallaby so long as they're patchlevel version increases, but since we treat independent deliverables the same as external dependencies, we basically freeze them in stable branch constraints lists15:40
clarkbfungi: but debian could give it a whirl and it would be a bug (that might not be fixed I guess) if a newer version that semver indicates is compat is not compat15:41
clarkbmaybe the underlying problem is "the bug might not be fixed"15:41
clarkband ya I don't have a good answer for that15:41
fungianyway, it seems like the "easy" solution would be when updating the releases site, one of the things we publish is a mashup of the latest versions from the structured data for the cycle-based deliverables and the upper constraints list for that branch15:44
fungii think part of what's not so easy to match up at the moment is the discrepancy between repository names and python package names. we have that info, so should include it along with the version numbers15:45
fungithat's probably one of the bigger headaches for distro package maintainers15:45
*** abhishekk is now known as abhishekk|afk15:45
clarkbbecause all of the control records are python centric ?15:47
fungithat's the impression i got at least15:57
*** marios is now known as marios|out15:57
*** ysandeep is now known as ysandeep|dinner16:10
*** amoralej is now known as amoralej|off16:11
*** ysandeep|dinner is now known as ysandeep16:38
hberaudfungi, clarkb: The API seems a flexible solution where each distros can use it and transform the results by applying their internal rules. As both you said semver interpretation is at the discretion of the different teams (openstack requirements, third party requirements, etc...), nothing is fully uniformized, and semver won't help so much there. So, flexibility and personal16:51
hberaudrepresentation and interpretation is a key element to manage this point. The API (the mashup) provide a flexible and consummable representation of the state of art at a precise moment.16:51
clarkbthe problem is that semver intends to fix this and we use tooling to do semver. We just don't actually do it. Maybe this is an indication we should16:53
fungithat seems like a longer-term effort to achieve (perhaps even a never-ending struggle), so some means of summarizing the set of things which make up "openstack wallaby" (including the versions of cycle-independent and external dependencies we've tested with) would probably be useful much sooner17:09
*** akekane__ is now known as abhishekk17:39
*** ysandeep is now known as ysandeep|out18:08
*** slaweq1 is now known as slaweq19:19
opendevreviewGoutham Pacha Ravi proposed openstack/releases master: [manila] Add Xena cycle highlights
gouthamrhi sorta noob question that i asked on
gouthamri was wondering if we can request a newer client release before we branch off stable/xena, or would that not be advised?19:32
gouthamrsmcginnis: ^ would you be able to help with this question?19:38
fungigouthamr: probably the biggest risk is if the new client destabilizes testing for projects which are interfacing with it. we generally try to freeze releases for shared libraries (which python-manilaclient is one, in addition to being a cli tool) earlier in the cycle than the services which import them, so that they don't need to worry about internals changing out from under them when19:38
fungithey're trying to close in on release candidates19:38
fungigouthamr: it looks from the commit message on the change you linked that the expected solution is to -1 it and propose a different commit to tag before tomorrow19:40
gouthamrfungi: ah, yes, the commit message made me think that was a possibility19:41
fungii won't speak for the release managers as to whether they'll consider an extension past tomorrow's deadline, and it's kindof late in the day for most of them now19:42
gouthamrfungi: thanks for clarifying - i agree there's a risk; but projects importing this sdk/cli are still testing with the main branch afaict19:42
gouthamrack i'll propose a release right away, and soft -1 this :)19:43
opendevreviewGoutham Pacha Ravi proposed openstack/releases master: Release python-manilaclient 3.1.0
smcginnisgouthamr: It's past client lib freeze and requirements freeze, so you would have to request a freeze exception on the mailing list.19:53
smcginnisRC1 is next week, so it really should be a stabilization period to make sure things are ready for that.19:54
smcginnisBut if there is a bug that needs to be addressed without a lot of other changes, then that may be fine.19:54
gouthamrsmcginnis: ah i see - that makes sense19:54
gouthamrsmcginnis: thanks for explaining this, smcginnis 19:55
smcginnisgouthamr: Some notes about requesting a requirements freeze exception here:
smcginnisNo problem!19:55
opendevreviewGhanshyam proposed openstack/releases master: Release Tempest 29.0.0 as Xena final release

Generated by 2.17.2 by Marius Gedminas - find it at!