Thursday, 2025-10-30

cardoeSo I missed out on the convo earlier unfortunately.02:30
cardoeI'll throw my hat in for the pytest group. OpenStack's test runner sucks in comparison. The fixture support from testing-cabal results in so much duplicated code.02:31
cardoeI can define a function a decorate it with @pytest.fixture in a top-level or in a child and be able to use it easily.02:32
cardoeI see so many duplicated helper objects/functions written and then added with self.addCleanup()02:34
cardoeAnd the reason I'm told is to support the parallelizing runner 02:35
cardoeOr to handle resource leaking issues.02:35
cardoepytest gives great backtraces of data as well.02:35
cardoeLast nice thing is that you can parameterize tests as well to reduce duplication.02:36
*** iurygregory_ is now known as iurygregory12:57
clarkbI'm not sure I understand why the fixutes library would require duplicated code. You define a fixture once then use it where you need it. But as mentioned before importantly those tools are standard compliant which was important when we wanted to ensure you could run your favorite test runner locally (including pytest)13:55
clarkbsince then due to the popularity of pytest many tools have made that work despite it being non standard so that particular issue has probably gone away13:56
clarkbthe reason for addCleanup is actually because test case tearDown() is only called if setUp() succeeds13:57
clarkbthis is documented here: https://docs.python.org/3/library/unittest.html#unittest.TestCase.addCleanup13:58
clarkbanyway its less about running in parallel and more about not leaking resources because tearDown is not called13:58
clarkband again importantly bceause all of ^ is tasndard you can just use pytest locally13:59
clarkbcardoe: note you can parameterize test cases with testscenarios in a standard compliant manner (I don't know if parameterized tests in pytest are standard compiant)14:02
clarkb(fundamentally these issues are probably one of a standard that is probably too clunky for daily use. pytest smooths over a lot of that but in the process means you can't use standard tools. Pytest being popular now and everything supporting it means maybe that is a non issue)14:03
cardoeIt might not require duplicated code but its just a pattern I see in projects.14:40
funginot surprising, but changing tools doesn't necessarily stop people from using them incorrectly/suboptimally. i would hesitate to equate how people use any tool to the actual capabilities or preferred patterns/workflows14:48
fungipeople often copy/paste (cargo cult) antipatterns just because they don't know there's a better or cleaner way, or maybe just don't have the time to invest in learning how to use it better14:49
priteauHello. I have a question about the tags framework. We had a blazar patch proposed to remove the "Team and repository tags" section, but they kept the blazar.svg file. This file does not render correctly for me, should we remove any mention of it?15:49
priteauThe patch I mentioned: https://review.opendev.org/c/openstack/blazar/+/96104615:50
priteauLooking at various README files, the project.svg files still show up in many of them17:12
gouthamrhonestly, i'm confused about that myself as a project maintainer, priteau 18:29
gouthamri think we should drop these too18:31
fungii happened to notice that there is some renewed activity on https://pypi.org/project/os-net-config even though it was retired early last year along with the rest of tripleo18:34
fungithe other collaborators were never deleted from that project, and one of them has added someone else today18:34
gouthamrsomewhat dejavu18:34
fungialso they uploaded a pre-release 12 days ago18:35
fungidevelopment seems to have moved to a repository in github, but they're continuing to use the same name and pypi project which openstack officially retired18:35
gouthamrsigh, they probably want us to transfer it, but didn't ask?18:36
fungiit's a grey area the tc may want to think about, retired project resumed outside openstack, users theoretically might continue using it without realizing it's no longer part of openstack18:36
gouthamryes18:37
gouthamrhttps://github.com/os-net-config/os-net-config18:37
fungiif we had deleted all the other collaborators from it when we did that for active projects on pypi, then i'm guessing they'd have switched to a new name for clarity18:38
gouthamr"Documentation: https://docs.openstack.org/os-net-config/latest"18:38
* gouthamr wonders how that getting updated?18:38
gouthamrs/that/that's18:38
fungialso if we had taken advantage of the new archiving feature in pypi...18:39
* gouthamr philosophically wonders if/when we built walls tall enough that prevented folks from _talking_ through this stuff18:41
gouthamrthink we need to go to the ML about this, fungi - you brought this up before when we were going through the list of human maintainers on pypi projects18:42
gmaanpriteau: replied in review, those are still valid tag and ok to continue as they point to correct place.18:42
fungisome of you work at the same company, so hopefully have insight or know who to talk to about it18:42
fungiif we "cleaned up" (deleted) those collaborators now and/or archived the pypi project, it might have some negative impact on the people trying to develop the fork on github18:43
fungii also seriously doubt any of the people working on it now pay attention to posts on openstack-discuss18:44
gouthamrack, i don't want us to do anything without dialog, even if the other parties have somehow done so.. we're a community with responsibilities; unlike individuals 18:44
gouthamrwe'll just CC them18:45
fungifrom openstack's perspective it looks like an uncoordinated takeover, but i don't think there's any malicious intent behind it18:46
gouthamryeah, i appreciate you bringing this up here, and not assuming (mal)-intent..18:47
fungiright, if someone's going to bring it up on the mailing list, i think it would be best done by a person at the same company for accountability reasons18:48
gouthamrunsure why that'd matter.. but i suppose you're being nice to Red Hat :D 18:48
fungimore that i don't want there to be any assumption that i'm targeting red hat negatively18:49
fungithis is a group that has explicitly chosen to work on openstack-related things outside openstack18:50
gouthamryeah, and my theory is that it was a "oops, we didn't mean for that to be retired" kinda thing18:51
* gouthamr will write to the ML18:52
fungithe people at that company working within the openstack community bringing up a situation with people working outside openstack on something with risky optics has less of a chance of coming across as an attack and more like keeping everyone accountable for their choices with regard to communication (or lack thereof)18:52
gouthamrsure, i don't think that Red Hat or its affiliates here would/should feel attacked. I must note that we're reminded on numerous occasions to work in the interest of this community, and to strengthen it by shaping its vision with our participation (my paraphrasing) .. i'd take this as someone reminding us of unintended consequences of unilateral actions 18:55
fungithanks. i'm mainly just wanting to get some clarity for potential users of that package without creating unnecessary drama19:05
gouthamrso 16.0.0 was the last release we tagged? https://github.com/openstack/releases/blob/master/deliverables/_independent/os-net-config.yaml19:11
fungiyes, roughly 4 months after tripleo was retired, people with access to the pypi project uploaded 17.0.0, and then a couple of weeks ago they uploaded a v18 pre-release19:11
fungiso it seems like development was continued outside openstack and the pypi project was taken over by the people working on it there19:12
fungithey never removed openstackci as an uploader though, so we're continuing to get notifications e.g. when they add a new collaborator with upload permissions19:13
fungiand the pypi project still misrepresents the "author" as "openstack" as well as having a readme that points to the prior urls for docs, git repository, bug tracking and release notes19:14
fungistill links to an openstack governance badge image too (albeit a 404 now)19:15
gouthamrhaha, that rounds up the story 19:15
gouthamr++ ty for these pointers19:16
clarkbgouthamr: fwiw I think the dosc link just hasn't been updated. We  are not updating the openstack docs for that project19:17
gouthamryes, i can ask for that to removed from references too19:18
gouthamrdo we have any guidelines to point to when forking our code? 19:18
fungithe "homepage" link on their pypi project also still points to the abandoned/retired repo on opendev19:19
fungigouthamr: i don't think we have any guidance about handling of outside artifact repositories that were previously controlled by openstack, like pypi or dockerhub19:20
* gouthamr thinks of gnocchi 19:20
gouthamrack fungi 19:21
gouthamrhttps://pypi.org/project/gnocchi/ must have been in this situation a while ago?19:22
JayFfungi: from another perspective, it *is* an attack on openstack, intentional or not, to publish artifacts for repositories we have retired19:26
JayFI guess os-net-config not being trademarkable makes it less easy for e.g. foundation level to get involved19:27
gouthamri'm thinking about the security perspective that we've discussed this sorta thing 19:27
clarkbright this was parto f the motivation behind asking peopel to give up their personal access to push packages19:38
clarkbI have no idea if these individuals received the emails askign them to do so19:38
gouthamrhttps://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup -- we missed os-net-config somehow19:39
fungiyes, the prior gnocchi situation informed some of the later tc policies about projects being retired within openstack when moving development outside openstack19:40
clarkbya so its possible this was an oversight on our side19:40

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!