| *** darmach5 is now known as darmach | 12:55 | |
| clarkb | seems like its quiet today almost like for many this is a holiday | 14:42 |
|---|---|---|
| mnaser | clarkb: in terms of making noise do you happen to know if pip is pinned in the openinfra images perhaps? | 14:52 |
| mnaser | we have some projects (not all) that seem to be getting pip installed in devstack that are missing their wsgi entrypoints | 14:52 |
| clarkb | mnaser: it shouldn't be. However, pip packages do set minimum required python versiosn so depending on the version of python you may get an older version | 14:53 |
| mnaser | https://zuul.oss.vexxhost.dev/build/9fd0ce96ee954c32a20868b8d1a97c5e/log/controller/logs/screen-magnum-api.txt#36 and https://zuul.oss.vexxhost.dev/build/9fd0ce96ee954c32a20868b8d1a97c5e/log/controller/logs/screen-m-api.txt#36 | 14:53 |
| mnaser | that's manila and magnum, i wonder... | 14:53 |
| clarkb | there was discussion about how the newer pep517 packaging stuff would break the wsgi script installation | 14:54 |
| clarkb | I don't see a pyproject.toml so maybe not exactly that but could be related | 14:54 |
| mnaser | interestingly enough nnova api went up fine | 14:55 |
| mnaser | keystone as well from spot check | 14:55 |
| clarkb | https://opendev.org/openstack/manila/src/branch/master/setup.cfg#L41-L42 it is still defined here at least | 14:56 |
| mnaser | https://zuul.opendev.org/t/zuul/buildsets?project=openstack%2Fmanila | 14:57 |
| mnaser | i wonder if i'm messing up the serach there or its not loading | 14:57 |
| clarkb | mnaser: I wonder if the path is simply wrong? like that extra data/ in the path stands out to me | 14:57 |
| clarkb | mnaser: that is for the zuul tenant. You need to switch to the openstack tenant then search there | 14:57 |
| mnaser | ahhhh oops | 14:58 |
| clarkb | the data/ path shows up for nova too so maybe not a path problem | 14:58 |
| mnaser | our failing build is uwsgi 2.0.20 and upstream which works is uwsgi 2.0.24 | 14:59 |
| mnaser | failing is py3.10 and passing is py3.12 (upstream) | 15:00 |
| mnaser | i wonder if this is something where we need to get newer python or run on noble | 15:00 |
| mnaser | and its more the "import error" than the "callable not found" | 15:00 |
| clarkb | I seem to recall that uwsgi gives a different error when the file exists but it can't run the code. Ya | 15:00 |
| clarkb | but maybe not | 15:01 |
| clarkb | actually I may be confusing ^ with my granian experiments | 15:01 |
| clarkb | I would probably hold a node and check if the file exists | 15:01 |
| clarkb | or add a ls -al /opt/stack/data/venv/bin to the devstack run somewhere | 15:01 |
| clarkb | infra-root I set a name on review02's bfv volume (review02-bfv-root-disk) so that we aren't confused about what it is after the instance is deleted. I also did a server show review02.opendev.org which says delete_on_termination='False' for both the data volume and the root disk bfv volume | 15:03 |
| clarkb | infra-root I think that means we are ready to delete the review02.opendev.org instance. I think I'll delete by uuid (16acb0cb-ead1-43b2-8be7-ab4a310b4e0a) to avoid typos accidentally removing review03 or similar. Does anyone want to check that uuid and maybe double check the volumes before I issue the server delete? | 15:04 |
| mnaser | clarkb: you can always protect review03 too for safety :P | 15:06 |
| clarkb | all these newfangled features. But that is not a bad idea. fwiw I tend to do a show first then a delete like doing a select then a delete to ensure you've got the correct db rows selected | 15:08 |
| clarkb | but its all levels of belts and suspenders | 15:08 |
| mnaser | oh yeah for sure, it's always scary and you want to make sure you dont want to delete prod like oracle did =) | 15:09 |
| frickler | mnaser: sounds similar to https://bugs.launchpad.net/designate/+bug/2109577 , likely either new setuptools or pip release | 15:09 |
| mnaser | frickler: ouch, ok, so alot of projects might blow up when that gets bumped | 15:13 |
| clarkb | its odd that py312 is working but not py310 in that case. But still definitely possible | 15:13 |
| clarkb | (I would expect it to be the other way aruond if newer setuptools or newer pip is the problem. But they may have version specific behaviors or divergent releasese using requires python etc) | 15:14 |
| johnsom | mnaser +1 that is happening | 15:15 |
| johnsom | I am also trying to figure out the right way to pin setuptools in the grenade jobs, as they are blowing up too | 15:15 |
| clarkb | I guess it should be easy to reproduce locally too just pip install manila using $pythonversion and check the bin dir in the venv? | 15:15 |
| clarkb | johnsom: pinning setuptools is dangerous | 15:15 |
| johnsom | excatly | 15:15 |
| clarkb | the only effective way of controlling setuptools is via pyproject.toml | 15:15 |
| fungi | mnaser: do you know when it started for you? | 15:16 |
| mnaser | i can try and go through build logs, one sec | 15:16 |
| clarkb | all other methods are doomed to people wondering why it works for you when it doesn't work for them | 15:16 |
| johnsom | I don't want to backport the new wsgi modules as it's a breaking change with the wsgi script disappears | 15:16 |
| fungi | wondering if it's related to https://github.com/pypa/setuptools/issues/4961 | 15:17 |
| mnaser | fungi: last pass was 2025-04-26 20:44:56 and then first fail was 2025-04-28 00:32:17 | 15:17 |
| mnaser | https://zuul.oss.vexxhost.dev/buildsets?project=vexxhost%2Fmagnum-cluster-api&pipeline=check&skip=0 - if you want to dig through the logs they're just plain devstack | 15:17 |
| fungi | mnaser: yeah, that is pretty well aligned with the setuptools 80 release timing | 15:19 |
| frickler | looks like upstream is broken the same way, like all the failures in https://review.opendev.org/c/openstack/magnum/+/940510 | 15:19 |
| fungi | but also importlib_metadata 8.7.0 happened at the same time | 15:20 |
| clarkb | shuold be straightforward to bisect that locall with a venv | 15:20 |
| clarkb | at least using released versions to identify the underlying culprit. Then you can decide if it is worth bisecting commits within that problematic lib/tool | 15:21 |
| fungi | the reason i mention importlib_metadata 8.7.0 is that the setuptools 80.0.0 changelog mentions a testing fix to deal with an entrypoint indexing change in importlib_metadata | 15:22 |
| fungi | i wonder if the difference is that python 3.10 is using the importlib_metadata package which updated, while with later python versions we're using importlib.metadata from stdlib? | 15:27 |
| fungi | reading between the lines, importlib_metadata 8.7.0 looks like it's reflecting the state of importlib.metadata from cpython 3.14.0a7 | 15:29 |
| clarkb | importlib.metadata is no longer provisional in 3.10 | 15:37 |
| clarkb | but maybe they need functionality in a newer version and and don't in 3.12? | 15:37 |
| clarkb | fungi: frickler: any thoughts on review02 instance deletion? | 15:43 |
| fungi | my only thought is "go for it" | 15:44 |
| fungi | double-checking the uuid now | 15:44 |
| fungi | 16acb0cb-ead1-43b2-8be7-ab4a310b4e0a matches what i see | 15:45 |
| clarkb | ok I'm deleting it now | 15:46 |
| fungi | thanks! | 15:47 |
| clarkb | #status log Deleted review02.opendev.org (16acb0cb-ead1-43b2-8be7-ab4a310b4e0a) it has been replaced by review03.opendev.org | 15:47 |
| opendevstatus | clarkb: finished logging | 15:47 |
| clarkb | the two volumes show up as available in volume listing now | 15:47 |
| clarkb | as expected I shoudl add (due to delete on termination being set to false for both) | 15:47 |
| clarkb | https://antirez.com/news/151 redis 8 releases today with an AGPLv3 license making it open source again | 16:37 |
| fungi | what was the other project that went proprietary and then very recently back to an osi-approved license? | 16:39 |
| JayF | AGPLv3 is still business-repellent though | 16:40 |
| clarkb | fungi: I think it was elasticsearch | 16:41 |
| clarkb | JayF: yes, though a lot of that seems founded on fud. | 16:41 |
| clarkb | (how many companies are patching their redis server with in house changes?) | 16:41 |
| JayF | How many companies have lawyers that would say a web service exposed to the internet that connects to redis is exposed to AGPL terms? | 16:42 |
| clarkb | its probably not zero but also probably not the marjority | 16:42 |
| JayF | I know there's at least one because I've worked for em | 16:42 |
| clarkb | I have as well | 16:42 |
| clarkb | but again a lot of that seems based on fear because its never been litigated so the boundaries are fuzzy | 16:42 |
| JayF | And like, I agree that seems like a stretch from a plain reading, but I won't tell a lawyer how to lawyer if they won't tell me how to write code | 16:43 |
| JayF | My hunch is the business-unattractiveness of AGPLv3 was a point of that switch, not a bug | 16:43 |
| JayF | AGPLv3 software /peddled by an untrustworthy upstream/ would make me even more nervous about being the litigation test case | 16:43 |
| clarkb | I think companies genuinely (from their perspective) believe that people are not contributing back appropriately to things when they are open source | 16:44 |
| clarkb | AGPL does exist to try and mitigate that problem | 16:44 |
| clarkb | the way it does it does make many companies avoid it | 16:44 |
| JayF | I have a lot of sympathy for "the amazon problem" so to speak (AWS takes your OSS project and your revenue stream) | 16:45 |
| clarkb | basically I doubt that bsuinesses being agpl averse is the primary function here. I suspect the primary function here is if you make changes and your customers interact with those changes you have to upstream them | 16:46 |
| clarkb | it just happens that also makes business averse to using software licensed that way | 16:46 |
| fungi | yes, i agree it's probably the most commercially-deterrent license in the osi-approved list, mainly because saas companies are used to not having to disclose their own alterations to open source software because they're intentionally not clasically redistributing it | 16:47 |
| clarkb | I guess its not upstream its the people itneracting with it get the cahgnes but ya | 16:47 |
| fungi | agpl3 is essentially gpl3 but with the caveat that letting a user interact with an instance of the software is a kind of distribution | 16:49 |
| clarkb | and only if you modify it | 16:51 |
| fungi | well, yes, the actual additional provisions in it follow from that basic principle | 16:51 |
| JayF | At a web company I once worked at, in dev training, they said (FUD) that if we used any AGPL libraries they could be forced to release the source code for their entire web property | 16:52 |
| JayF | I think that's ^^^ the root cause of AGPL itself being scary; any licensing scheme which has unclear edges is going to be interpreted in the least charitable way possible | 16:53 |
| JayF | I like /the idea/ of it, but in practice I 1000% understand the decision to avoid | 16:53 |
| clarkb | mongodb is interesting because they switched from AGPL to SSPL | 16:59 |
| clarkb | whereas the other big changes have been licenses like apache 2 to SSPL/BSL and now some back to AGPL if my memory is correct | 16:59 |
| fungi | taking the quiet afternoon as an opportunity to go out for a late lunch/early dinner, should be back by 21:00 utc at the latest | 19:16 |
| clarkb | o/ I've got to pop out soon for parent teacher meetins so I'll be out for a bit too | 19:58 |
| fungi | no worries, i'm back now | 20:50 |
| fungi | looks like i didn't miss much | 20:50 |
| clarkb | and half back. Second teacher is out sick so we'redoing that over zoom from home in an hour | 21:27 |
| fungi | oh fun | 22:10 |
| fungi | at least it's good that the pandemic better equipped schools for that sort of thing | 22:10 |
| clarkb | ya and the teachers that went through it are quite good at it. Managing waiting rooms and breakout rooms and all that | 22:44 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!