*** armax has quit IRC | 00:17 | |
*** armax has joined #openstack-release | 00:21 | |
*** ricolin has quit IRC | 00:22 | |
*** armax has quit IRC | 00:34 | |
*** armax has joined #openstack-release | 01:12 | |
*** dave-mccowan has quit IRC | 03:16 | |
*** ricolin has joined #openstack-release | 03:23 | |
*** ricolin_ has joined #openstack-release | 03:42 | |
*** ykarel|away has joined #openstack-release | 04:01 | |
*** ianychoi has quit IRC | 04:29 | |
*** evrardjp has quit IRC | 04:33 | |
*** evrardjp has joined #openstack-release | 04:33 | |
*** openstackgerrit has joined #openstack-release | 04:36 | |
openstackgerrit | Tim Burke proposed openstack/releases master: Swift 2.26.0 release and stable/victoria branch https://review.opendev.org/752615 | 04:36 |
---|---|---|
*** ykarel|away is now known as ykarel | 05:00 | |
*** vishalmanchanda has joined #openstack-release | 05:34 | |
*** sboyron has joined #openstack-release | 06:01 | |
*** slaweq has joined #openstack-release | 06:14 | |
*** andrein has quit IRC | 06:53 | |
*** mwhahaha has quit IRC | 06:53 | |
*** johnsom has quit IRC | 06:53 | |
*** vdrok has quit IRC | 06:53 | |
*** rpittau|afk has quit IRC | 06:53 | |
*** nicolasbock has quit IRC | 06:53 | |
*** rm_work has quit IRC | 06:53 | |
*** masayukig has quit IRC | 06:53 | |
*** TheJulia has quit IRC | 06:53 | |
*** abelur has quit IRC | 06:54 | |
*** andrein has joined #openstack-release | 06:55 | |
*** nicolasbock has joined #openstack-release | 06:55 | |
*** vdrok has joined #openstack-release | 06:56 | |
*** mwhahaha has joined #openstack-release | 06:56 | |
*** masayukig has joined #openstack-release | 06:56 | |
*** rpittau|afk has joined #openstack-release | 06:56 | |
*** abelur has joined #openstack-release | 06:56 | |
*** TheJulia has joined #openstack-release | 06:57 | |
*** johnsom has joined #openstack-release | 06:57 | |
*** jbadiapa has joined #openstack-release | 06:59 | |
*** rm_work has joined #openstack-release | 07:08 | |
*** tosky has joined #openstack-release | 07:25 | |
*** ykarel_ has joined #openstack-release | 08:02 | |
*** ykarel has quit IRC | 08:05 | |
*** ykarel_ is now known as ykarel | 08:10 | |
*** ricolin_ has quit IRC | 08:22 | |
*** dtantsur|afk is now known as dtantsur | 08:27 | |
dtantsur | morning folks, ttx. will merging https://review.opendev.org/#/c/752633/ present an issue from stable perspective? | 08:40 |
dtantsur | it 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 |
dtantsur | I know we've had a similar conversation a few times on release patches, so I decided to chat in advance. | 08:41 |
ttx | dtantsur: 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 |
ttx | So it's a trade-off between the confusion it brings vs. the bug it fixes | 09:02 |
ttx | It'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 before | 09:03 |
ttx | so where is the line? | 09:03 |
ttx | We have collectively rules that security issues and data loss issues, when the only way to fix them is to add a config option, are OK | 09:04 |
ttx | ruled* | 09:04 |
ttx | That is rare enough to not break the user assumptions as to what may appear in a stable release | 09:04 |
ttx | Personally, I stop at regressions, security issues, and irrecoverable bugs (think data loss) | 09:07 |
ttx | Bugs 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 |
dtantsur | Oh, it's a bit interesting. It can count as regression, but it's not *our* regression. | 09:16 |
dtantsur | Namely, 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 |
dtantsur | How would you evaluate this situation, ttx? | 09:17 |
ttx | ah, that may cross the regression line then :) | 09:20 |
ttx | dtantsur: I think that justifies it then -- I guess the config option was the only way to safely introduce the fix? | 09:24 |
dtantsur | ttx: well, since negotiation fails, I don't see other options rather than make the admin tell us | 09:26 |
dtantsur | we could retry with another suite, but that puts us in a dangerous place because we'd likely reduce security | 09:26 |
dtantsur | we also don't have a way to know which suite ipmitools defaults to | 09:26 |
ttx | thanks for nothing ipmitools | 09:27 |
dtantsur | :D | 09:28 |
dtantsur | IPMI is a terrifying zone | 09:28 |
ttx | ok 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 reviewers | 09:28 |
dtantsur | have you heard about cipher 0? | 09:28 |
* ttx runs | 09:28 | |
dtantsur | haha, I guess you have :) | 09:29 |
dtantsur | anyway, thanks for feedback. I'll wait for TheJulia and we discuss between us as well. | 09:29 |
ttx | cheers | 09:31 |
*** vishalmanchanda has quit IRC | 09:43 | |
*** vishalmanchanda has joined #openstack-release | 09:57 | |
*** e0ne has joined #openstack-release | 10:06 | |
*** e0ne has quit IRC | 10:08 | |
*** e0ne has joined #openstack-release | 10:09 | |
evrardjp | Did I say something wrong in there http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017392.html ? | 10:24 |
evrardjp | if yes, what do I need to do to fix it? :) | 10:24 |
ttx | No that seems correct to me | 10:31 |
ttx | I think last time it was blocked on RPM packagers not being interested and seeing a SIG as a downgrade | 10:31 |
ttx | It'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 release | 10:33 |
openstackgerrit | Masayuki Igawa proposed openstack/releases master: Release Tempest 25.0.0 for Victoria https://review.opendev.org/752665 | 10:33 |
ttx | The reason why SIG makes sense to me is that it's really a special interest in collaborating to produce RPM packaging | 10:33 |
ttx | but 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 IRC | 11:48 | |
*** ricolin_ has joined #openstack-release | 12:02 | |
*** dave-mccowan has joined #openstack-release | 13:04 | |
fungi | evrardjp: 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 |
fungi | what "release model" are they associated with? | 13:05 |
evrardjp | independant mostly | 13:06 |
ttx | fungi: not using openstack/releases | 13:07 |
ttx | they may still choose to do stable branches names after releases | 13:07 |
ttx | named* | 13:08 |
evrardjp | rpm-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 thread | 13:08 |
ttx | I saw branches last time I looked | 13:09 |
ttx | but yeah, they might have been created to check the necessary box | 13:09 |
ttx | in which case it makes a lot of sense to migrate to a SIG and get rid of artificial rules created for project teams | 13:10 |
fungi | yeah, 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 repo | 13:10 |
ttx | fungi: usage of openstack/releases is ultimately the line between "in the release" (project teams) and "out of the release" (SIG) | 13:11 |
fungi | that was my understanding as well, which is why i asked | 13:11 |
ttx | I guess SIGs could replicate a similar structure/tooling, but the release management team is not responsible for it | 13:11 |
ttx | just simpler to just push tags really | 13:11 |
fungi | right, that doesn't seem like the same thing as "propose releases" so might need some clarification | 13:12 |
ttx | https://governance.openstack.org/tc/reference/comparison-of-official-group-structures.html should hopefully make it clear | 13:13 |
fungi | well, i meant clarification in evrardjp's proposal to them | 13:14 |
ttx | ah yes | 13:14 |
fungi | where he implied they'd be able to continue relying on the release team | 13:14 |
ttx | ok on it | 13:14 |
fungi | it sounded incorrect to me, but i didn't want to reply since i wasn't 100% sure either | 13:15 |
evrardjp | I thought that was solved and we thought of allowing SIGs to use the tooling | 13:15 |
evrardjp | I was wright to mention _if I am not mistaken_ then | 13:15 |
evrardjp | because I was :) | 13:16 |
evrardjp | what's holding us to do this with releases tooling though? | 13:17 |
*** tosky_ has joined #openstack-release | 13:18 | |
evrardjp | ttx: I don't see that the official group structures is preventing the use of the release tooling in any way | 13:18 |
*** tosky is now known as Guest83047 | 13:18 | |
*** tosky_ is now known as tosky | 13:18 | |
ttx | well it's a package | 13:19 |
evrardjp | pun intended? | 13:19 |
ttx | You either have accountability and release liaisons, or you don;t | 13:19 |
ttx | It's not coherent to want the release team to have oversight on your releases and not want any accountability | 13:20 |
evrardjp | That wasn't my goal | 13:20 |
ttx | You could still use the tooling, I guess. Make your own openstack/releases-like repo | 13:20 |
ttx | but all SIGs so far just opted to push tags directly | 13:20 |
ttx | (the rest of the tooling is similar) | 13:21 |
ttx | replied | 13:21 |
evrardjp | thanks | 13:21 |
smcginnis | You can also use https://opendev.org/openstack/project-config/src/branch/master/roles/copy-release-tools-scripts/files/release-tools/release.sh or a similar version of it to manually tag releases. | 13:22 |
ttx | there is confusion here between tooling and how it's implemented via the openstack/releases and the release management team. | 13:22 |
smcginnis | Might require small tweaks to that script though. | 13:22 |
ttx | I'm just saying the Releasemanagement team stops at serving project teams, because we have to have a limit | 13:22 |
ttx | but our tooling can definitely be reused if other teams want to implement strict release management | 13:23 |
ttx | It's generally not worth the hassle | 13:23 |
ttx | It'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 other | 13:24 |
ttx | also our job only has value for things that need to be coordinated, aka "the openstack release" | 13:25 |
ttx | that all opens a space for things that could be released separately with less accountability, like... SIGs making software releases | 13:25 |
fungi | i would argue that for cycle-trailing projects as a whole, the benefit statement there is minimal | 13:25 |
ttx | fungi: indeed | 13:25 |
ttx | cycle-trailing is a bit of an artifact from pre-SIG times | 13:26 |
ttx | by definition is you are cycle-trailing you are not part of "the openstack release", but we played semantics | 13:26 |
ttx | because there was just no other way to organize work back then | 13:27 |
evrardjp | I don't disagree ttx | 13:27 |
ttx | personally I'd rather turn all cycle-trailing into SOGs, but i don;t want to force down change either | 13:27 |
evrardjp | although 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 day | 13:28 |
ttx | sure, it just stretches the definition of "a release" really | 13:28 |
ttx | and the need for accountability that I described above | 13:29 |
evrardjp | for 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 |
ttx | I think it does. | 13:29 |
evrardjp | For me it's the cycle that needs to be changed to have the time to release a deployment tool | 13:29 |
ttx | Little benefit in having your releases go through release management | 13:29 |
ttx | little benefit in accountability and release liaisoning | 13:29 |
ttx | It's definitely a thing that is published separately from the coordinated release and taht deploys it | 13:30 |
ttx | so it makes total sense as a separate thing | 13:30 |
evrardjp | I don't disagree it's the state, I am mentioning the fact that it shouldn't be separate | 13:30 |
evrardjp | like docs, deployment tooling should be part of the software | 13:30 |
evrardjp | but we can agree to disagree :) | 13:30 |
evrardjp | (fun story I used docs as an example, right? :p ) | 13:31 |
ttx | sure, again it's really about where you place the bar. | 13:31 |
evrardjp | exactly | 13:31 |
ttx | At which point is the software deploying the software a separate entity? Semantically, they are separate. Functionally, that's more arguable | 13:32 |
ttx | so it's a grey area, and it's why we tolerated both forms for it (project teams and SIGs) | 13:33 |
ttx | and by "we" I mean the very few people who actually care due to acute OCD | 13:33 |
evrardjp | hahahahah | 13:33 |
smcginnis | :) | 13:34 |
evrardjp | ttx do you have a patch for the "comparison of official group structures" to clarify that point? Not sure I understood your point there | 13:35 |
ttx | which point? | 13:37 |
evrardjp | I just pushed a patch https://review.opendev.org/#/c/752699/ | 13:49 |
evrardjp | It's just to clarify the expectations, so that people won't ask that question should it show up again :) | 13:50 |
fungi | honestly, even the libraries we produce as dependencies really are separate software in my opinion | 13:55 |
fungi | we release them far earlier than the suite of services | 13:55 |
fungi | and they can in many cases be used outside an openstack context | 13:56 |
ttx | fungi: yeah, they just happen to be developed by the exact same teams | 14:03 |
ttx | and we need to have accountability on them since they condition the release | 14:03 |
openstackgerrit | Iury Gregory Melo Ferreira proposed openstack/releases master: Release IPA-builder 2.2.0 https://review.opendev.org/752705 | 14:28 |
openstackgerrit | Iury Gregory Melo Ferreira proposed openstack/releases master: Release virtualbmc 2.1.1 https://review.opendev.org/752708 | 14:35 |
*** ianychoi has joined #openstack-release | 14:59 | |
*** ykarel is now known as ykarel|away | 14:59 | |
*** e0ne has quit IRC | 15:30 | |
*** tkajinam has quit IRC | 15:44 | |
*** ykarel|away has quit IRC | 15:49 | |
*** ricolin_ has quit IRC | 15:50 | |
*** dtantsur is now known as dtantsur|afk | 16:10 | |
*** vishalmanchanda has quit IRC | 16:23 | |
openstackgerrit | Iury Gregory Melo Ferreira proposed openstack/releases master: Release virtualbmc 2.2.0 https://review.opendev.org/752708 | 17:08 |
*** iurygregory has quit IRC | 17:10 | |
*** irclogbot_1 has quit IRC | 18:19 | |
*** irclogbot_1 has joined #openstack-release | 18:24 | |
*** irclogbot_1 has quit IRC | 18:31 | |
*** irclogbot_0 has joined #openstack-release | 18:36 | |
openstackgerrit | Merged openstack/releases master: Swift 2.26.0 release and stable/victoria branch https://review.opendev.org/752615 | 19:10 |
openstackgerrit | Merged openstack/releases master: Release Tempest 25.0.0 for Victoria https://review.opendev.org/752665 | 19:11 |
*** jbadiapa has quit IRC | 19:20 | |
*** slaweq has quit IRC | 19:41 | |
*** sboyron has quit IRC | 20:04 | |
*** armax has quit IRC | 21:15 | |
*** hberaud has quit IRC | 21:32 | |
*** hberaud has joined #openstack-release | 21:32 | |
*** dave-mccowan has quit IRC | 22:22 | |
*** EmilienM has quit IRC | 23:06 | |
*** EmilienM has joined #openstack-release | 23:06 | |
*** armax has joined #openstack-release | 23:27 | |
*** tosky has quit IRC | 23:31 | |
*** armax has quit IRC | 23:54 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!