| opendevreview | chenker proposed openstack/governance master: Appoint Ke Chen as PTL for Watcher https://review.opendev.org/c/openstack/governance/+/932419 | 01:20 |
|---|---|---|
| *** dalees9 is now known as dalees | 07:42 | |
| *** elodilles_pto is now known as elodilles | 09:12 | |
| *** iurygregory_ is now known as iurygregory | 12:57 | |
| clarkb | cardoe: it was fungi with the concerns over security of binary objects | 15:56 |
| cardoe | And that's what my concern is as well. | 15:58 |
| cardoe | But my question is how well are we following the rules which say "make it clear its not the official way or officially part of the OpenStack community" when we upload those binary blobs to tarballs.openstack.org | 15:59 |
| cardoe | Is Joe Random going to say "oh clearly what I grabbed off of tarballs.openstack.org isn't actually supported or trust worthy so I must do the checks myself" | 16:00 |
| cardoe | Or is Joe Random going to say "HOLY CARP OpenStack stinks it ships bad stuff on tarballs.openstack.org. Dear Boss, Don't invest in OpenStack or use this thing!" | 16:01 |
| cardoe | And by extension when we're pushing things to quay.io and docker.io under orgs named "OpenStack-$PROJECT" that use the official OpenStack logo on the landing page and link back to openstack.org URLs for docs and other resources. | 16:02 |
| cardoe | So they might be following the letter of the rule but not necessarily the spirit of the rule. | 16:02 |
| cardoe | So my question is, does anyone see this as a problem? I think it's a problem. But if no one else does, I'll shut up and go back to my corner. | 16:03 |
| clarkb | ya I think fungi is also very concerned about that (I mean I am too, but also like pragamstism for for simplifying deployments and testing so maybe there is middle ground or do it until it breaks than figure it out I dunno) | 16:07 |
| fungi | i do think it's something we need to work out, yes. there are definitely options for more clearly communicating these things, we'd just need to decide how we want to go about it | 16:17 |
| JayF | I suspect cardoe is bringing this up because it's broken, at least from some perspectives | 16:18 |
| fungi | for example, the autoindexer on tarballs.o.o will render custom readme files at the top of the page before the file download links, we could take advantage of that feature to add mandatory warnings | 16:18 |
| JayF | cardoe: weren't you saying something about deliverables changing on t.o.o without a version change? Like automatically updating dependencies? that caused some kinda breakage? | 16:18 |
| cardoe | Yes. | 16:19 |
| JayF | so I think we're past the point of "until it breaks", at least from that perspective | 16:19 |
| cardoe | fungi: so the thing is people aren't necessarily browsing to t.o.o | 16:19 |
| fungi | note that i have a laundry list of similar concerns, for example horizon's xstatic packages which distribute copies of outdated, vulnerable javascript libraries on pypi | 16:19 |
| cardoe | "helm repo add https://tarballs.openstack.org/openstackhelm" is the published way of consuming data from the OpenStack Helm project. | 16:20 |
| fungi | or the fact that some deployment projects install stable branch dependencies from pypi using our frozen upper-constraints.txt files meant for testing | 16:21 |
| clarkb | cardoe: JayF: thats a problem with your publications. We don't generally allow tagged python artifacts to do that | 16:21 |
| clarkb | not with tarballs itself. So should be solveable | 16:22 |
| cardoe | clarkb: when you say "your publications", who do you mean? | 16:22 |
| JayF | in this case the "your" is openstack helm project I believe | 16:22 |
| JayF | which neither cardoe or I work directly on | 16:22 |
| clarkb | cardoe: whatever is writing to tarballs needs to be made smarter. For example python projects get releases built from tags. We don't allow you to replace the tag and rebuild the python package you must use a new tag | 16:22 |
| cardoe | I agree. But the PTL and the cores don't agree with me. | 16:23 |
| clarkb | in this case it sounds like you need to work with the helm folks to publish versions that are more immutable | 16:23 |
| cardoe | I'm not someone that works on the project | 16:23 |
| clarkb | got it | 16:23 |
| cardoe | I mean I'd happily fix it. | 16:23 |
| clarkb | we also publish tip of $branch python packages which do change | 16:24 |
| JayF | clarkb: cardoe: I think the "PTL and the cores don't agree with me" might be the reason the chat is happening in #openstack-tc | 16:24 |
| clarkb | maybe we should compromise and do both | 16:24 |
| JayF | I'd suggest posting something to the ML with the full story and context if it's something that needs to change | 16:24 |
| cardoe | You're right JayF. I was merely trying to see what the feelings around such behaviors are. If others don't find it problematic then I'll go back to my corner. | 16:26 |
| JayF | I think it should be clear when a deliverable may change without warning, and given your experience, it seems unclear | 16:26 |
| JayF | I actually really like the idea of having a "frozen in time" version and a regularly updating version tbh | 16:27 |
| cardoe | I'm not the only person to notice. The project doesn't use OFTC but instead uses a Slack and there's been comments in there. So the way I saw it was that the approach is harmful to the OpenStack project as a whole. So I saw it as problematic. Wanted to see if others agreed and then was going to approach the ML to discuss with a bigger audience. | 16:27 |
| JayF | but I'm not a helm user or expert mainly just trying to ensure left hand and right hand are talking :) | 16:27 |
| JayF | cardoe: Is that permissible under openstack policy? for a team to use a proprietary chat app as their primary comm environment? | 16:28 |
| cardoe | That's my understanding of helm deployments as well. If you select a version then it should be immutable. If you select $tip then it's not. | 16:28 |
| clarkb | I'm sure fungi knows where the rules for comms are. I don't think slack should be allowed or at least it shouldn't be the only option | 16:29 |
| fungi | i get the impression that openstack-helm was sort of adopted by the airship maintainers at at&t/microsoft and are probably d | 16:30 |
| fungi | on't think about such things | 16:30 |
| fungi | it might make more sense to figure out if openstack-helm is actually part of openstack any longer | 16:31 |
| gmann | every openstack projects needs to be on OFTC | 16:31 |
| gmann | and at least there is no proposal to move openstack-helm out of OpenStack | 16:32 |
| gmann | and #openstack-helm is IRC channel mentioned as official in governance for it. | 16:33 |
| cardoe | So there is a channel but you won't find any cores or PTL in there | 16:35 |
| fungi | worth keeping in mind though that it's not the only one. there are also teams with unused irc channels where all the team members communicate with each other over wechat instead | 16:46 |
| fungi | so seems like it might be a topic worth broader discussion | 16:47 |
| JayF | probably at a minimum those two examples might be a sign that our communication venues are not serving the needs of everyone | 16:47 |
| JayF | but also I suspect projects doing that are generally more loosely associated with openstack generally | 16:47 |
| clarkb | ya I mean no single communication tool is going to work for every single person. This is why we have multiple. Additionally openstack says this is part of what openstack projects need to do. The correct action is to work to amend that if necessary so that everyone can remain in sync and importantly remain in communication | 16:49 |
| clarkb | not just go off and do your own thing and continue to call it openstack... | 16:49 |
| fungi | right, that's why i suggested revisiting whether it makes sense for openstack-helm to really be an official part of openstack, since it seems outwardly like they might already be acting as a separate community | 16:49 |
| JayF | yep. and as I've said many times before it shouldn't be considered a bad thing for something to be outside of governance; it's better to reflect the reality of what things share pieces | 16:50 |
| cardoe | fungi: well that's the thing. vexxhost is using it but they've got a bit of a fork. And they work hard to upstream what they can. But a bunch of the vexxhost Zuul jobs are around building the pieces immutably. I know devnull is looking to do the same. So I've been trying to see how I can push them more to upstream. | 16:51 |
| cardoe | But I've been met with rebuffs. So I'm just seeing what the feeling is around some of the breakage with what I feel are the rules to push back on the project to include the community more. | 16:52 |
| cardoe | https://etherpad.opendev.org/p/oct2024-ptg-os-helm is another example. What's the topics and agenda? That's the official link from the PTG site. | 16:53 |
| fungi | yeah, i mean, at a minimum, there should be some public artifact/record of design discussions for openstack deliverables. open design is one of the four opens we promise to uphold | 16:53 |
| fungi | if there are design discussions happening in an openstack-helm slack channel, there should be a bridge to irc or some other way to publish logs of what's being talked about | 16:54 |
| fungi | or public summaries being produced to, e.g., the mailing list | 16:55 |
| fungi | (just my personal opinion, it's up to the tc to decide what's appropriate of course) | 16:56 |
| cardoe | I agree with you. | 16:56 |
| gmann | solution here can be that they should fix the current issue either it is tooling they use or technical but moving to different governance does not solve anything here. And moving out of OpenStack governance should not be the approach unless project differ from technical scope/mission. | 16:56 |
| cardoe | So the way I've looked at a number of the issues is that there's a governance rule and while the letter of the rule is followed, the spirit is not. | 16:57 |
| cardoe | e.g. the official documented discussion is OFTC https://docs.openstack.org/openstack-helm/latest/readme.html#communication but then there's a mention of Slack. | 16:58 |
| gmann | so its people issue instead of process. | 16:58 |
| cardoe | And short of me telling people they won't get an answer on OFTC, only the reviewbot speaks in the channel. | 16:59 |
| fungi | https://governance.openstack.org/tc/reference/projects/openstack-helm.html also lists an irc channel | 17:00 |
| gmann | yeah, we have many projects having silent IRC and some where only reviewbot are there no core/maintainers | 17:00 |
| fungi | my recollection is that they did use irc years ago, but the project leadership and maintainers have undergone a total replacement since then | 17:01 |
| cardoe | gmann: right. which happens. But I know for a fact project discussions happen on Slack. | 17:01 |
| cardoe | Which isn't captured. | 17:01 |
| gmann | yeah, projects.yaml is the one I referred and listed IRC chanenl there indicate that they should use IRC or atleast be available/answer there also | 17:01 |
| gmann | 'Which isn't captured.' and this break our (not just OpenStack wide but Open Infra projects level) 'four open' rules | 17:02 |
| opendevreview | Ghanshyam proposed openstack/governance master: Retire kuryr-kubernetes and kuryr-tempest-plugin https://review.opendev.org/c/openstack/governance/+/922507 | 18:26 |
| gmann | tc-members ^^ I need to update it, please revote on it | 18:26 |
| * gouthamr returns to his computer and reads scrollback | 19:18 | |
| * gouthamr invite kozhukalov #openstack-tc | 19:19 | |
| gouthamr | meh; no such nick | 19:20 |
| gouthamr | cardoe: thanks for raising the topic here; are you motivated to start a mail thread about this? there's a good deal of activity in these helm repos and interactions on gerrit too; maybe we assume positive intent (they're chatting where the contributors are, doing what was being done in the past) and ignorance rather than malice.. | 19:24 |
| cardoe | I'm 100% not saying there is malice. | 19:27 |
| gouthamr | ack; kozhukalov was a TC candidate; and he mentioned the #openstack-helm slack activity (users/contributors helping each other) and possibly bring opinions to the TC: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/RVAQFHQ4NWTZXRUCKE2GOL4RJ55MEBUX/ | 19:31 |
| cardoe | I can start a mailing list thread about it. My curiosity is that the project operates a bit in some nebulous area where the letter of the rules are followed but not the spirit. I've been engaging with users/operators who perceive things as being more official due to the appearance and/or creating forks of pieces where I'm trying to get them to contribute it upstream more. | 19:32 |
| gouthamr | ^ ++ appreciate that effort; either an ML thread or if you think the PTG presence you sought on the slack channel.. | 19:33 |
| gouthamr | related note regarding the PTG | 19:33 |
| gouthamr | i had to move the translation discussion into the community leaders spot - so unfortunately we may not be able to give it the full time it initially had (cc bauzas) | 19:34 |
| gouthamr | ^ this was because the timing didn't work for seongsoo/ianychoi (terribly late in Korea/Vietnam) .. but, they've got more PTG sessions than initially anticipated.. so we might be able to do an intro and setup an agenda for their meeting: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/CT23H4VKERBH5EOS3STZ4UNATU75OWCG/ | 19:36 |
| clarkb | gouthamr: can you update the time on line 102 of the eterhpad? | 19:49 |
| gouthamr | ^ yep | 19:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!