| fungi | sean-k-mooney: amorin brought up another wsgi-using service in #opendev (mistral), and is going to port your pyproject.toml to it as well under the same pip-23.1-support review topic | 12:49 |
|---|---|---|
| fungi | just a heads up | 12:49 |
| sean-k-mooney | cool i put a script to make that easy in the etherpad | 12:50 |
| sean-k-mooney | https://etherpad.opendev.org/p/pep-517-and-pip-23#L21 | 12:50 |
| sean-k-mooney | clarkb: fungi: stephenfin is currently in the process of seting up a laptop and copying data form his old ssd so he proably wont be around much today or at least not af an hour or two until he finsihses with that | 12:58 |
| fungi | i don't think the pbr release discussion is all that urgent | 12:58 |
| sean-k-mooney | clarkb: so he proably wont see the ping about pbr | 12:58 |
| fungi | getting pep 660 support into a new pbr release soon will be great, but it's not blocking anything at the moment as far as i know | 12:59 |
| sean-k-mooney | so the only negitive to not having it is we need https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/899969 | 13:00 |
| sean-k-mooney | before we can merge all the pyproject.toml changes or we need to make the py39 jobs non voting | 13:01 |
| fungi | oh, i didn't realize 899969 was waiting for that | 13:01 |
| sean-k-mooney | well its the workaround | 13:02 |
| sean-k-mooney | we can either release new pbr or do that | 13:02 |
| sean-k-mooney | and then revert it later | 13:02 |
| sean-k-mooney | https://zuul.opendev.org/t/openstack/build/d966f72e3b014fa19ed6757f6b7721e4/log/job-output.txt#712 | 13:02 |
| fungi | oh, okay now i've read the comments. i agree | 13:02 |
| sean-k-mooney | what happening is that in the py39 job the .pkg tox env used for the build isolation is using py38 | 13:03 |
| fungi | i'll go ahead and propose the pbr 6.0.0 release to openstack/releases but we'll need oslo ptl buy-in | 13:03 |
| sean-k-mooney | to build the wheel | 13:03 |
| sean-k-mooney | that works fine | 13:03 |
| fungi | yes, having a pyproject.toml turns on build isolation in pip (you can also explicitly disable build isolation in pip as another workaround) | 13:04 |
| sean-k-mooney | but then when its installed in the py39 env it fails | 13:04 |
| sean-k-mooney | https://zuul.opendev.org/t/openstack/build/d966f72e3b014fa19ed6757f6b7721e4/log/job-output.txt#1261 | 13:04 |
| sean-k-mooney | fungi: so i don think its the build isolation exactly that the probelm | 13:04 |
| sean-k-mooney | it that for some reason when we install it in the py39 env its not using the fallback to legacy editable mode | 13:05 |
| sean-k-mooney | i tried requiring a newer setuptools too but that still didnt help | 13:05 |
| sean-k-mooney | fungi: most project dont actully have any py39 test | 13:06 |
| sean-k-mooney | so for most people this wont be an issue | 13:06 |
| fungi | does calling `python3.9 -m pip install ...` get around it? | 13:06 |
| fungi | not that i would want to use that as a workaround, just might help pin down the difference | 13:07 |
| sean-k-mooney | i dont know i dont currently have a ubuntu 20.04 env to test this in | 13:07 |
| sean-k-mooney | im also on pto until tueday so i can take a look thne but its not super urgent | 13:07 |
| sean-k-mooney | i validated that the tox env work fine on centos-9 stream and on my debian sid machine but i dont have py38/39 currently to test with | 13:08 |
| fungi | oh! please don't let me interrupt your time off any further. i wouldn't have pinged you had i realized :( | 13:08 |
| sean-k-mooney | your fine dont worry about it | 13:08 |
| sean-k-mooney | im actully on my work pc doing stuff | 13:08 |
| fungi | sounds like you're as bad at taking time off as i am | 13:09 |
| sean-k-mooney | one of the things i have to od is actully book more time off | 13:09 |
| sean-k-mooney | well i have like 15+ days left to book off of my 25 days of holidays for this year so ya... | 13:09 |
| sean-k-mooney | im pretty bad for actully taking it off | 13:10 |
| fungi | we don't really have a limit for how many days we can take off, but the end result is that i hardly get around to taking any at all | 13:10 |
| sean-k-mooney | yep i feel like they could give me that "perk" at redhat and the end result would be me taking less time off since there is no forcing function at the end of the year | 13:11 |
| fungi | sean-k-mooney: https://review.opendev.org/c/openstack/releases/+/900041 | 13:20 |
| sean-k-mooney | cool it might be good to test that but i have previosu tested installing pbr with pep-660 into the .pkg venv silencies the waring about not supporting it so it should work | 13:22 |
| fungi | thanks for trying it! | 13:23 |
| sean-k-mooney | before i drop off irc for a few days i want to ask one other question | 13:26 |
| sean-k-mooney | im currently workign on a ci system downstream that may also run as a third party ci upstream | 13:27 |
| sean-k-mooney | for reasons we cant create new gerrit repos downstream and our gitlab instace is usign the git driver so it only gets update every 2 hours and cant do sepculative execution... | 13:27 |
| sean-k-mooney | so im debating between creating a github repo for the zuul job ci repo | 13:28 |
| sean-k-mooney | or looking at opendev or rdo gerrit | 13:28 |
| sean-k-mooney | i asked this before but if we wanted to create a gerrit repo for hosting the third party ci repo on the opendev gerrirt would that be an option | 13:29 |
| sean-k-mooney | currently our down stream zuul has connection to the opendev gerrirt, rdos and github although i woudl have to add the bot to github | 13:30 |
| fungi | sean-k-mooney: was there a reason you didn't use zuul's gitlab driver instead of the basic git driver? | 13:30 |
| sean-k-mooney | fungi: that is a question i will be asking our downstream zuul maintainers | 13:30 |
| sean-k-mooney | fungi: i spent a day configuring it only to find out i was using git... | 13:30 |
| fungi | maybe they're on an old version of zuul | 13:30 |
| sean-k-mooney | Zuul version: 8.1.1.dev4 4a46644be | 13:30 |
| sean-k-mooney | not that old | 13:31 |
| sean-k-mooney | im going to follow up with them to see if we can just use the gitlab driver too | 13:31 |
| sean-k-mooney | but just wanted to collect my list of options | 13:31 |
| fungi | if it's a unique open source project and not just a direct copy/fork of one somewhere else, we can likely host it in opendev (would need more details to say for certain) | 13:32 |
| sean-k-mooney | oh this is litrally jsut going to be the zuul jobs proejct for storign our third party/downstream ci jobs for testing openstack | 13:33 |
| sean-k-mooney | specificaly testing nova with exotic hardware like gpus or sriov | 13:34 |
| sean-k-mooney | we could actully host the config in white box too | 13:34 |
| sean-k-mooney | but i need to have a converstation internally about is it ok to host this publically or not | 13:34 |
| sean-k-mooney | basically i went form only having a config project for this zuul tenant (with no speculitve execution) to we not have an untrusted project (with a 2 hour delay) | 13:35 |
| sean-k-mooney | so best solution would be allow creating a new repo in our internal gerrit | 13:36 |
| sean-k-mooney | or use gitlab driver | 13:36 |
| fungi | so, the other challenge with hosting it in opendev is that you'll probably want to have your ci system be the one to gate it | 13:36 |
| fungi | which we won't really be able to support | 13:36 |
| fungi | you could sort of work around that by having your ci report on changes for the repo in a third-party advisory capacity, but there's still the risk that it gets ignored or things merge out of sequence | 13:37 |
| sean-k-mooney | ya | 13:38 |
| sean-k-mooney | honestly when im back to work on tuesday ill just try and catch the downstream maintainer and ask why they are using the git driver. or are they fine with me just adding a new conenction with the gitlab driver | 13:38 |
| sean-k-mooney | i know the gitlab driver needs some project level api access | 13:39 |
| sean-k-mooney | so perhapse they just didnt wnat to do that | 13:39 |
| sean-k-mooney | basiucally settign up https://zuul-ci.org/docs/zuul/latest/drivers/gitlab.html#web-hooks | 13:39 |
| sean-k-mooney | cool anywya thanks for your advice o/ | 13:40 |
| fungi | yw | 13:44 |
| fungi | good luck, and enjoy your time off. don't hesitate to let me know if you have more questions | 13:44 |
| clarkb | fungi: stephenfin: talking out loud here about PBR and python2.7 support. I think swift is still testing against python2.7. Eventually a good replacement for that train tempest job might be to just run swift's unittests with pbr installed from git. | 20:47 |
| clarkb | upside to that is scope is significantly lower and if something goes wrong we've got a group that I think may be motivated to help debug it | 20:47 |
| fungi | that makes sense to me, sure | 21:25 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!