Friday, 2020-09-18

*** armax has quit IRC00:17
*** armax has joined #openstack-release00:21
*** ricolin has quit IRC00:22
*** armax has quit IRC00:34
*** armax has joined #openstack-release01:12
*** dave-mccowan has quit IRC03:16
*** ricolin has joined #openstack-release03:23
*** ricolin_ has joined #openstack-release03:42
*** ykarel|away has joined #openstack-release04:01
*** ianychoi has quit IRC04:29
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-release04:33
*** openstackgerrit has joined #openstack-release04:36
openstackgerritTim Burke proposed openstack/releases master: Swift 2.26.0 release and stable/victoria branch
*** ykarel|away is now known as ykarel05:00
*** vishalmanchanda has joined #openstack-release05:34
*** sboyron has joined #openstack-release06:01
*** slaweq has joined #openstack-release06:14
*** andrein has quit IRC06:53
*** mwhahaha has quit IRC06:53
*** johnsom has quit IRC06:53
*** vdrok has quit IRC06:53
*** rpittau|afk has quit IRC06:53
*** nicolasbock has quit IRC06:53
*** rm_work has quit IRC06:53
*** masayukig has quit IRC06:53
*** TheJulia has quit IRC06:53
*** abelur has quit IRC06:54
*** andrein has joined #openstack-release06:55
*** nicolasbock has joined #openstack-release06:55
*** vdrok has joined #openstack-release06:56
*** mwhahaha has joined #openstack-release06:56
*** masayukig has joined #openstack-release06:56
*** rpittau|afk has joined #openstack-release06:56
*** abelur has joined #openstack-release06:56
*** TheJulia has joined #openstack-release06:57
*** johnsom has joined #openstack-release06:57
*** jbadiapa has joined #openstack-release06:59
*** rm_work has joined #openstack-release07:08
*** tosky has joined #openstack-release07:25
*** ykarel_ has joined #openstack-release08:02
*** ykarel has quit IRC08:05
*** ykarel_ is now known as ykarel08:10
*** ricolin_ has quit IRC08:22
*** dtantsur|afk is now known as dtantsur08:27
dtantsurmorning folks, ttx. will merging present an issue from stable perspective?08:40
dtantsurit was initially framed as a feature, but then I got to realize that some hardware will outright refuse to work without changing the new setting.08:40
dtantsurI know we've had a similar conversation a few times on release patches, so I decided to chat in advance.08:41
ttxdtantsur: yeah it's the same grey area. It's not dangerous to users (as it's backward-compatible) but it does add confusion. Like someone writing a book on Ussuri ironic listing config options, the stable rule (not adding config options) protects it.09:02
ttxSo it's a trade-off between the confusion it brings vs. the bug it fixes09:02
ttxIt's a bit of a slippery slope because at some point, all features are backward-compatible and help the user do things they could not do before09:03
ttxso where is the line?09:03
ttxWe have collectively rules that security issues and data loss issues, when the only way to fix them is to add a config option, are OK09:04
ttxThat is rare enough to not break the user assumptions as to what may appear in a stable release09:04
ttxPersonally, I stop at regressions, security issues, and irrecoverable bugs (think data loss)09:07
ttxBugs that require a config option to be fix an issue that has always been there... I personally consider that a feature. But your opinion may vary.09:09
ttx(a feature enabling hardware that never worked before)09:14
dtantsurOh, it's a bit interesting. It can count as regression, but it's not *our* regression.09:16
dtantsurNamely, ipmitool in RHEL 8.2 started defaulting to another cipher suite. So if negotiation for some reason does not work, users start being broken.09:17
dtantsurHow would you evaluate this situation, ttx?09:17
ttxah, that may cross the regression line then :)09:20
ttxdtantsur: I think that justifies it then -- I guess the config option was the only way to safely introduce the fix?09:24
dtantsurttx: well, since negotiation fails, I don't see other options rather than make the admin tell us09:26
dtantsurwe could retry with another suite, but that puts us in a dangerous place because we'd likely reduce security09:26
dtantsurwe also don't have a way to know which suite ipmitools defaults to09:26
ttxthanks for nothing ipmitools09:27
dtantsurIPMI is a terrifying zone09:28
ttxok so I think it's on the right side of the grey :) Feel free to link to this discussion in the review, to avoid repeating yourself for other reviewers09:28
dtantsurhave you heard about cipher 0?09:28
* ttx runs09:28
dtantsurhaha, I guess you have :)09:29
dtantsuranyway, thanks for feedback. I'll wait for TheJulia and we discuss between us as well.09:29
*** vishalmanchanda has quit IRC09:43
*** vishalmanchanda has joined #openstack-release09:57
*** e0ne has joined #openstack-release10:06
*** e0ne has quit IRC10:08
*** e0ne has joined #openstack-release10:09
evrardjpDid I say something wrong in there ?10:24
evrardjpif yes, what do I need to do to fix it? :)10:24
ttxNo that seems correct to me10:31
ttxI think last time it was blocked on RPM packagers not being interested and seeing a SIG as a downgrade10:31
ttxIt's also OK if they prefer to continue as a project team, really. They produce a clear deliverable that is released as part of the openstack release10:33
openstackgerritMasayuki Igawa proposed openstack/releases master: Release Tempest 25.0.0 for Victoria
ttxThe reason why SIG makes sense to me is that it's really a special interest in collaborating to produce RPM packaging10:33
ttxbut you can also totally see it the other way around (RPM packaging is part of openstack release rather than a special interest that consumes the release)10:34
*** suryasingh has quit IRC11:48
*** ricolin_ has joined #openstack-release12:02
*** dave-mccowan has joined #openstack-release13:04
fungievrardjp: ttx: so just to be clear on that proposal, sigs are able to still use the openstack/releases repo to trigger release automation?13:04
fungiwhat "release model" are they associated with?13:05
evrardjpindependant mostly13:06
ttxfungi: not using openstack/releases13:07
ttxthey may still choose to do stable branches names after releases13:07
evrardjprpm-packaging might be in itself a tagless deliverable IIRC, but I think that might go away, because I am not sure there was a need for it, just a misexpectation that it has to be done (I will confirm with jpena) on the thread13:08
ttxI saw branches last time I looked13:09
ttxbut yeah, they might have been created to check the necessary box13:09
ttxin which case it makes a lot of sense to migrate to a SIG and get rid of artificial rules created for project teams13:10
fungiyeah, in evrardjp's e-mail he suggested they "can still propose releases (if I am not mistaken)" so i assumed he meant through the openstack/releases repo13:10
ttxfungi: usage of openstack/releases is ultimately the line between "in the release" (project teams) and "out of the release" (SIG)13:11
fungithat was my understanding as well, which is why i asked13:11
ttxI guess SIGs could replicate a similar structure/tooling, but the release management team is not responsible for it13:11
ttxjust simpler to just push tags really13:11
fungiright, that doesn't seem like the same thing as "propose releases" so might need some clarification13:12
ttx should hopefully make it clear13:13
fungiwell, i meant clarification in evrardjp's proposal to them13:14
ttxah yes13:14
fungiwhere he implied they'd be able to continue relying on the release team13:14
ttxok on it13:14
fungiit sounded incorrect to me, but i didn't want to reply since i wasn't 100% sure either13:15
evrardjpI thought that was solved and we thought of allowing SIGs to use the tooling13:15
evrardjpI was wright to mention _if I am not mistaken_ then13:15
evrardjpbecause I was :)13:16
evrardjpwhat's holding us to do this with releases tooling though?13:17
*** tosky_ has joined #openstack-release13:18
evrardjpttx: I don't see that the official group structures is preventing the use of the release tooling in any way13:18
*** tosky is now known as Guest8304713:18
*** tosky_ is now known as tosky13:18
ttxwell it's a package13:19
evrardjppun intended?13:19
ttxYou either have accountability and release liaisons, or you don;t13:19
ttxIt's not coherent to want the release team to have oversight on your releases and not want any accountability13:20
evrardjpThat wasn't my goal13:20
ttxYou could still use the tooling, I guess. Make your own openstack/releases-like repo13:20
ttxbut all SIGs so far just opted to push tags directly13:20
ttx(the rest of the tooling is similar)13:21
smcginnisYou can also use or a similar version of it to manually tag releases.13:22
ttxthere is confusion here between tooling and how it's implemented via the openstack/releases and the release management team.13:22
smcginnisMight require small tweaks to that script though.13:22
ttxI'm just saying the Releasemanagement team stops at serving project teams, because we have to have a limit13:22
ttxbut our tooling can definitely be reused if other teams want to implement strict release management13:23
ttxIt's generally not worth the hassle13:23
ttxIt's really a question that we can't do our job (release management) without basic accountability (PTL/release liaison in the team). So you can't have one without the other13:24
ttxalso our job only has value for things that need to be coordinated, aka "the openstack release"13:25
ttxthat all opens a space for things that could be released separately with less accountability, like... SIGs making software releases13:25
fungii would argue that for cycle-trailing projects as a whole, the benefit statement there is minimal13:25
ttxfungi: indeed13:25
ttxcycle-trailing is a bit of an artifact from pre-SIG times13:26
ttxby definition is you are cycle-trailing you are not part of "the openstack release", but we played semantics13:26
ttxbecause there was just no other way to organize work back then13:27
evrardjpI don't disagree ttx13:27
ttxpersonally I'd rather turn all cycle-trailing into SOGs, but i don;t want to force down change either13:27
evrardjpalthough for cycle-trailing, some projects are part of the release, but cycle-trailing appeared because it didn't make sense to produce software depending on others in one day13:28
ttxsure, it just stretches the definition of "a release" really13:28
ttxand the need for accountability that I described above13:29
evrardjpfor me cycle trailing shouldn't be a SIG. I am thinking of a deployment tool: it doesn't make sense to put it out of the release.13:29
ttxI think it does.13:29
evrardjpFor me it's the cycle that needs to be changed to have the time to release a deployment tool13:29
ttxLittle benefit in having your releases go through release management13:29
ttxlittle benefit in accountability and release liaisoning13:29
ttxIt's definitely a thing that is published separately from the coordinated release and taht deploys it13:30
ttxso it makes total sense as a separate thing13:30
evrardjpI don't disagree it's the state, I am mentioning the fact that it shouldn't be separate13:30
evrardjplike docs, deployment tooling should be part of the software13:30
evrardjpbut we can agree to disagree :)13:30
evrardjp(fun story I used docs as an example, right? :p )13:31
ttxsure, again it's really about where you place the bar.13:31
ttxAt which point is the software deploying the software a separate entity? Semantically, they are separate. Functionally, that's more arguable13:32
ttxso it's a grey area, and it's why we tolerated both forms for it (project teams and SIGs)13:33
ttxand by "we" I mean the very few people who actually care due to acute OCD13:33
evrardjp ttx do you have a patch for the "comparison of official group structures" to clarify that point? Not sure I understood your point there13:35
ttxwhich point?13:37
evrardjpI just pushed a patch
evrardjpIt's just to clarify the expectations, so that people won't ask that question should it show up again :)13:50
fungihonestly, even the libraries we produce as dependencies really are separate software in my opinion13:55
fungiwe release them far earlier than the suite of services13:55
fungiand they can in many cases be used outside an openstack context13:56
ttxfungi: yeah, they just happen to be developed by the exact same teams14:03
ttxand we need to have accountability on them since they condition the release14:03
openstackgerritIury Gregory Melo Ferreira proposed openstack/releases master: Release IPA-builder 2.2.0
openstackgerritIury Gregory Melo Ferreira proposed openstack/releases master: Release virtualbmc 2.1.1
*** ianychoi has joined #openstack-release14:59
*** ykarel is now known as ykarel|away14:59
*** e0ne has quit IRC15:30
*** tkajinam has quit IRC15:44
*** ykarel|away has quit IRC15:49
*** ricolin_ has quit IRC15:50
*** dtantsur is now known as dtantsur|afk16:10
*** vishalmanchanda has quit IRC16:23
openstackgerritIury Gregory Melo Ferreira proposed openstack/releases master: Release virtualbmc 2.2.0
*** iurygregory has quit IRC17:10
*** irclogbot_1 has quit IRC18:19
*** irclogbot_1 has joined #openstack-release18:24
*** irclogbot_1 has quit IRC18:31
*** irclogbot_0 has joined #openstack-release18:36
openstackgerritMerged openstack/releases master: Swift 2.26.0 release and stable/victoria branch
openstackgerritMerged openstack/releases master: Release Tempest 25.0.0 for Victoria
*** jbadiapa has quit IRC19:20
*** slaweq has quit IRC19:41
*** sboyron has quit IRC20:04
*** armax has quit IRC21:15
*** hberaud has quit IRC21:32
*** hberaud has joined #openstack-release21:32
*** dave-mccowan has quit IRC22:22
*** EmilienM has quit IRC23:06
*** EmilienM has joined #openstack-release23:06
*** armax has joined #openstack-release23:27
*** tosky has quit IRC23:31
*** armax has quit IRC23:54

Generated by 2.17.2 by Marius Gedminas - find it at!