Wednesday, 2024-06-12

*** bauzas_ is now known as bauzas00:08
*** bauzas_ is now known as bauzas00:20
*** bauzas_ is now known as bauzas00:32
*** bauzas_ is now known as bauzas00:40
*** bauzas_ is now known as bauzas02:37
*** bauzas_ is now known as bauzas03:55
*** bauzas_ is now known as bauzas04:14
*** bauzas_ is now known as bauzas04:26
*** bauzas_ is now known as bauzas05:48
*** bauzas_ is now known as bauzas06:16
*** bauzas_ is now known as bauzas06:45
*** bauzas_ is now known as bauzas06:53
*** bauzas_ is now known as bauzas07:41
*** bauzas_ is now known as bauzas07:49
*** bauzas_ is now known as bauzas08:05
*** ministry is now known as __ministry09:46
*** bauzas_ is now known as bauzas09:59
*** bauzas_ is now known as bauzas11:19
fungijakeyip: to be clear, you want me to just push a copy of the master branch from https://github.com/waipeng/capi-helm-charts and not a full clone (so omitting the gh-pages branch from it)? and what about the (20) tags it has?12:23
jakeyipfungi: yeap, just master. tags will be good, if it doesn't conflict with what we do in the releases repo?12:55
fungijakeyip: as long as you release higher versions in the future than the highest tag number, it should be fine14:02
fungijakeyip: the only other concern is that the branch is still being actively updated (most recent commit was 3 hours ago)14:03
fungiwhen i pull it and then push into gerrit, contributors will need to be ready to stop developing the version in github and start pushing changes to gerrit instead14:03
fungialso you'll probably want your very first change to add a .gitreview file, i can push that up once the import is complete but it should be approved straight away for ease of use14:11
*** bauzas_ is now known as bauzas14:31
clarkbI feel like I'm missing context. Where was the request made? Mostly trying to sort out why we can't just push to gerrit and approve with trivial noop CI15:07
fungiclarkb: https://review.opendev.org/91828715:10
clarkband the delta is too large to do through gerrit normally?15:12
fungiclarkb: 712 commits and 20 tagged versions over ~1.5 years15:16
fungiit's a project that was being independently developed and hosted in github but now the maintainers want to move it into opendev under magnum's governance15:17
fungithey just didn't make that clear when they proposed the change to create the repository, and didn't notice the bit of documentation that told them imports needed to happen at creation time15:17
clarkbfungi: oh did we recently create the new project?15:20
clarkbthat is unfortunate15:20
fungiclarkb: "recently" in august https://review.opendev.org/89311715:22
fungithe commit message referred to it as a "new project" and i didn't think to question whether that new project had a year's worth of historical commits numbering in the hundreds that they wanted to import15:24
fungimaybe they also thought initially they were going to build that one up from scratch, i dunno15:24
fungiit took them 9 months to realize they wanted to import their history into it, looks like (based on dates for the respective changes)15:25
opendevreviewSeongsoo Cho proposed openstack/openstack-zuul-jobs master: [WIP] Add ansible play for weblate client configuration  https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/92187816:07
*** bauzas_ is now known as bauzas16:53
JayFSome strange/unique CI failures in Ironic: https://zuul.opendev.org/t/openstack/build/ebd8fec9013b4453a139da009c34970b https://zuul.opendev.org/t/openstack/build/5ac373ea24df495aad72124bed580c78 18:23
JayFvery early in the zuul portion of the initial configuration, I think18:23
JayFthis is an example of hte last line before tracebacks > .pkg: 285 D discover exe for PythonInfo(spec=CPython3.10.12.final.0-64, exe=/home/zuul/.local/tox/bin/python3, platform=linux, version='3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0]', encoding_fs_io=utf-8-utf-8) in /usr [virtualenv/discovery/py_info.py:437 18:24
*** bauzas_ is now known as bauzas18:26
JayFhttps://pypi.org/project/filelock/#history 3.15.0 of filelock appears to have broken virtualenv18:26
JayFhttps://github.com/pypa/virtualenv/blob/main/src/virtualenv/util/lock.py#L2218:26
fungifirst guess is new virtualenv18:27
fungibut that hasn't updated for a month18:27
JayFfungi: I think I id'd it, with the filelock change18:28
JayFit's blowing up calling super() on a class subclassed outta filelock.FileLock18:28
JayFand it released less than an hour ago18:28
fungiaha, i was a few lines back on scrollback, yep18:28
fungii concur, that looks sus18:28
JayFwhat's the best approach for us to fix it? it's likely blowing up all gates, I just caught it early18:29
fungican you reproduce it locally and try again with the next newest filelock?18:29
JayFI can try18:30
fungiif so, exclude it in global-requirements.txt and roll it back in upper-constraints.txt18:30
JayFI also noted in an IRC chat I share with some python devs who work on core-ish stuff (like virtualenv) that it's broken, so hopefully upstream is looking too18:31
JayFbut I know that's probably in line behind a thousand things18:31
fungiyeah, reqs/constraints is our "quick fix"18:31
JayFfungi: it's not broken for normal tox runs locally, whatever is exercising the broken code is before it gets to ironic tests18:31
fungii'm available to expedite and promote gating for a fix like that too18:32
JayFfungi: unsure what that PythonInfo stuff is18:32
clarkbits specifically running tox but not running tests18:32
clarkbbut thats all tox logging18:32
JayFah, so I basically have to get an environment where the bad version of filelock is where my  *tox* is installed18:33
fungiit's breaking when running tox --notest -edocs18:33
fungiyeah, you could .tox/docs/bin/pip install filelock==x.y.z18:33
fungiand don't use -r when rerunning tox18:33
JayFI think I need it *in the parent env* not inside the tox env, yeah?18:33
fungiit's complaining in /home/zuul/.local/tox/lib/python3.10/site-packages/filelock/...18:34
fungiso it's the environment where yout tox is installed, yeah18:34
funginot the env tox creates. good point18:34
JayFwhich is why I also suspect global-reqs may not fix18:34
JayFbut I don't know how early zuul run stuff is shaped18:35
JayFyeah, 100% reproduced with a venv-built tox with wrong filelock version inside, trying to verify rolling back fixes18:35
clarkbya you may need to put a rule in the zuul-jobs ensure-tox role to say install tox and not filelock version foo18:35
JayFworks with filelock 3.14.0, fails with filelock 3.15.018:36
JayFvalidated18:36
fungitox is installed during the job, ftr: https://zuul.opendev.org/t/openstack/build/ebd8fec9013b4453a139da009c34970b/console#1/0/34/ubuntu-jammy18:36
clarkbhttps://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks/main.yaml#L3018:36
clarkbthats the lint you would modify to add filelock!=3.15.0 I think18:36
JayFah, good, was hunting for that repo18:36
clarkbs/lint/line/18:36
fungiso yeah, no constraints bailing us out of this one, but we can review that quickly18:37
clarkbor alternatively switch everything to nox assuming nox doesn't use filelock18:37
clarkb:)18:37
fungialso zuul/zuul-jobs changes can merge waaaay faster than openstack/requirements18:38
fungithey proceed directly to the gate when approved even if check isn't complete, and there's rarely a queue to hold them up18:38
JayFhttps://review.opendev.org/c/zuul/zuul-jobs/+/921885 Block broken version of filelock from installing 18:39
JayFI did validate that command line behaved as expected locally18:40
JayFand I'm hoping a hacky fix is good enough since 'd really, really hope upstream is on the ball about fixing this18:40
clarkbI think that role is exercised by tests too18:41
fungioh yes, ensure-tox is covered by tests in zuul-jobs18:44
JayFre: the review comment, I'm more thinking, virtualenv x.y.z+1 is going to come out, relying on the filelock 3.15.0 behavior, and we'll have to roll it back18:46
* JayF lolsobs in python18:46
fungiyeah, i feel you18:51
clarkbya I don't think there is a good way around that unfortunately18:51
fungiJayF: clarkb: looks like it failed on the same error19:02
fungihttps://zuul.opendev.org/t/zuul/build/d8a40f194eea49949e6f9508977a2845/console#2/0/24/ubuntu-jammy indicates the change applied though19:03
fungialso it looks like upstream yanked that version anyway19:04
fungihttps://pypi.org/project/filelock/ now claims the latest version is 3.14.0 from april19:04
fricklersounds like a nice emergency solution19:05
fungimaybe we're okay for now and we wait to see what they do next?19:05
fungiand let people who hit that error know they can recheck for now, i guess, if things seem to be back to ~normal for the time being19:05
fricklerhttps://pypi.org/project/filelock/3.15.0/ shows it was broken and yanked19:05
fricklerright, maybe do a status notice? but not me, I'm out for today now19:07
clarkbfungi: that specific tests installs tox again at another location :/19:07
clarkbbut ya I think if they yanekd it we're good19:07
*** bauzas_ is now known as bauzas19:35
*** bauzas_ is now known as bauzas20:00
clarkbhttps://github.com/tox-dev/filelock/issues/337 is the upstream issue. Sounds like nox may have been affected too since the issue was in virtualenv and both nox and tox use virtualenv20:22
*** bauzas_ is now known as bauzas20:53
jakeyipthanks fungi, I have the .gitreview ready to go. the two repos will diverge, that is ok, we know which tag we split at.21:18
fungijakeyip: good enough. i'll push the current state of the master branch and tags in that case. give me a few minutes21:20
jakeyipthanks!21:24
JayFdo we need to clear/update a pypi mirror or something? https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_42e/920216/1/check/openstack-tox-pep8/42ee026/job-output.txt21:29
JayFthis started post-yank and is still a failure21:29
clarkbJayF: that job failed at 18:23:51 utc you sure it was post yanking of the pacakge? That is before we discussed it above21:30
JayFit helps if I do UTC math for my current tz21:30
JayFhaha21:30
* JayF is in his third TZ in two weeks21:31
jakeyipjust to clarify, the original repo at https://github.com/stackhpc/capi-helm-charts/ will continue being developed by stackhpc to fit their requirements, and the opendev fork will be developed by magnum core to fit magnum. devs on both forks will cherry pick changes across.21:33
clarkbjakeyip: but the force push is a one time thing right?21:34
jakeyipthis is interim, stackhpc wishes to move to using opendev fork eventaully, but that's something for later21:34
clarkbJayF: I've got my irc client set to give me utc times which helps a lot. I've also got a utc clock on my phone21:34
jakeyipclarkb: yes force push now is one time, when we fork.21:34
jakeyip* at the point of fork21:35
JayFjakeyip: that's disappointing that you all couldn't get to a point of real upstream cooperation :( feels like a failure of governance that it got to that point21:36
JayFI wonder if we should have an RCA about this situation in the next TC PTG or something21:37
JayF(to be clear: 'you all' is all magnum community in this context; not stackhpc)21:37
clarkbjakeyip: cool I just want to amke sure thre isn't an expectation that opendev admins will force push peridoically to sync things across21:37
jakeyipJayF: unfortuately it's a trend now that many projects are being developed within companies, outside of opendev. I have been trying to convince colleagues not to do the same.21:39
fungijakeyip: https://opendev.org/openstack/magnum-capi-helm-charts21:40
jakeyip"go fast go alone, go far go together"21:40
jakeyipfungi: thanks21:41
fungiyw21:41
JayFjakeyip: I agree it's unfortunate; but it's really not a good look for you all tbh21:42
jakeyiphttps://review.opendev.org/c/openstack/magnum-capi-helm-charts/+/921897 21:44
*** bauzas_ is now known as bauzas21:46
jakeyipJayF: yeah... well the worse alternative is the upstreaming effort doesn't even happen21:46
jakeyipfungi: we don't have CI yet for that gitreview change. manual verify or is there a dummy job in zuul for this?21:51
fungijakeyip: you probably want to initially add a .zuul.yaml and include noop-jobs template there in the same change as your .gitreview addition: https://docs.opendev.org/opendev/infra-manual/latest/creators.html#add-jobs-for-your-project21:53
jakeyipfungi: thanks!21:53
jakeyipfungi: all done, thanks for your help! JayF clarkb too :)21:59
JayFeh I wasn't helpful just sad in your direction, give those guys all the love22:00
jakeyip:) 22:04
*** bauzas_ is now known as bauzas23:02
opendevreviewIan Y. Choi proposed openstack/openstack-zuul-jobs master: [WIP] Add ansible play for weblate client configuration  https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/92187823:29
opendevreviewIan Y. Choi proposed openstack/openstack-zuul-jobs master: [WIP] Add ansible play for weblate client configuration  https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/92187823:47

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