Thursday, 2022-04-07

*** amoralej|off is now known as amoralej07:21
fricklerthe kolla team would like to provide more regular (like maybe monthly) stable releases, is there some existing tooling that could be used e.g. to propose release patches in a (semi)automated way?08:42
elodillesfrickler: well, it depends. if they are not using the new-release command, then it will ease a bit their release :) if they are using already, then the answer is no o:)09:17
fricklerelodilles: thx, I didn't know that tool yet, it might at least help a bit, thx. I guess doing more automation would be hindered by the problem of deciding whether to do bugfix vs. feature release09:24
elodillesfrickler: yes, that is the case. though if i'm not mistaken deployments projects are not following strictly semver, so actually they bump MAJOR versions between series, and bumping MINOR version whenever they release another stable version (if i remember correctly...)09:38
fricklerelodilles: latest kolla xena release is 13.0.1, so that doesn't seem to be true in general.09:40
fricklerbut I can discuss that within the team09:40
opendevreviewMarios Andreou proposed openstack/releases master: Make final tripleo repos release for stable/victoria before EM
elodillesfrickler: hmm, i see. actually there is not so much deliverables for Kolla team, so it shouldn't be a big problem to follow SemVer09:43
elodillesfrickler: actually there is the '09:44
elodillesreno -q semver-next'09:45
fricklerelodilles: yes, the situation is certainly different than when having umpteen puppet modules or cookbooks09:45
elodillesthat *suggests* a version bump too, based on the release notes09:45
elodillesthat is usually a good pointer, but it should not be blindly followed09:45
elodillesfor example it suggests a MAJOR version bump in case of 'upgrade notes' as it usually needed when there is a change that an operator needs to be aware of / take actions -- i.e. something probably not backward compatible09:47
fricklerelodilles: oh, cool, another thing to learn, seems I've been using some pretty old reno so far that didn't even know about that option09:47
elodillesbut there are teams that adds extra info in their upgrade notes and for them it is usually not really signals for a backward compatibility09:48
elodillesanyway, it is still a good pointer :)09:48
elodilles(not talking about that fact, that on stable, according to stable policy, shouldn't be any 'new feature', i.e. MINOR version bump)09:49
elodillesbut still, there are changes that we considering as requires MINOR version bump on stable branch09:50
elodillesoh, and some cases 'reno -q semver-next' gives completely false numbers (numbers, less than the previous release) OR ends up in an exception o:) so there are bugs as well :/09:52
mgoddardHi elodilles, can we merge ?09:53
mgoddardthe flag discussion could be continued in another patch, if you wish09:54
elodillesmgoddard: i'd rather leave out that flag if the release works without it. can we wait a bit until this patch merges? >>>
elodillesfungi clarkb : can you please review this patch? >> 09:59
elodillesmgoddard: of course, if this cannot merge soon, then let's just merge your patch.10:00
elodillesmgoddard: is this OK for you?10:00
mgoddardelodilles: ok, thanks. Let's try to get it merged today one way or the other10:02
elodillesmgoddard: ++10:28
mgoddardelodilles, frickler: considering the automatic releases discussion, the simplest option to me seems to be a minor bump every time10:34
mgoddardthe benefit of frequent releases to me outweighs strict use of minor/patch versions10:35
mgoddard(given the alternative of very infrequently releasing after GA)10:35
fricklerelodilles: mgoddard: guess I can fast-track that patch, wasn't aware that it is blocking10:43
frickleralso agree on the minor bump10:45
mgoddardthanks frickler 11:00
opendevreviewMark Goddard proposed openstack/releases master: Release kolla, kolla-ansible and ansible-collection-kolla Yoga RC1
*** dviroel|afk is now known as dviroel\11:13
*** dviroel\ is now known as dviroel11:13
fricklermgoddard: elodilles: seems that didn't help with the release type error11:26
elodillesfrickler: indeed :/11:27
elodillesthen let's use either 'artifact-link-mode: none' or 'no-artifact-build-job'11:28
elodillesto tell you the truth i don't know which is better. both make the validation pass.11:29
elodillesopenstack-ansible uses 'artifact-link-mode: none' and kayobe uses 'no-artifact-build-job'11:29
elodillesand the descriptons tell me nothing:
elodillesi thought adding ansible-collection-kolla to projects.yaml would help :/11:34
opendevreviewMark Goddard proposed openstack/releases master: Release kolla, kolla-ansible and ansible-collection-kolla Yoga RC1
*** amoralej is now known as amoralej|lunch12:11
opendevreviewMerged openstack/releases master: Final Designate release for Victoria
elodilleshberaud ttx : if you have time, could you please revisit this:
elodillesunfortunately the flag is still needed after we have added the project to project-config's projects.yaml12:29
elodillesthx \o/12:29
opendevreviewMerged openstack/releases master: Release kolla, kolla-ansible and ansible-collection-kolla Yoga RC1
mgoddardThanks elodilles & ttx. Yoga here we come12:41
*** amoralej|lunch is now known as amoralej13:04
elodillesmgoddard: \o/13:14
*** dviroel is now known as dviroel|ruck14:14
*** dviroel|ruck is now known as dviroel|ruck|lunch15:28
tkajinamhi. may I ask for some suggestions about ? this is needed to fix the broken Yoga release.15:57
*** dviroel|ruck|lunch is now known as dviroel|ruck16:13
*** amoralej is now known as amoralej|off17:08
elodillestkajinam: i've commented on it, these kind of releases are not allowed in stable branches, though I understand the issue and tend to accept an exception for this. but I also need to double-check with the rest of the team17:14
elodilles(also, the situation is a bit easier (in my opinion) as we are removing a dependency and not adding)17:18
*** dviroel|ruck is now known as dviroel|afk20:39

Generated by 2.17.3 by Marius Gedminas - find it at!