*** bauzas_ is now known as bauzas | 00:08 | |
*** bauzas_ is now known as bauzas | 00:20 | |
*** bauzas_ is now known as bauzas | 00:32 | |
*** bauzas_ is now known as bauzas | 00:40 | |
*** bauzas_ is now known as bauzas | 02:37 | |
*** bauzas_ is now known as bauzas | 03:55 | |
*** bauzas_ is now known as bauzas | 04:14 | |
*** bauzas_ is now known as bauzas | 04:26 | |
*** bauzas_ is now known as bauzas | 05:48 | |
*** bauzas_ is now known as bauzas | 06:16 | |
*** bauzas_ is now known as bauzas | 06:45 | |
*** bauzas_ is now known as bauzas | 06:53 | |
*** bauzas_ is now known as bauzas | 07:41 | |
*** bauzas_ is now known as bauzas | 07:49 | |
*** bauzas_ is now known as bauzas | 08:05 | |
*** ministry is now known as __ministry | 09:46 | |
*** bauzas_ is now known as bauzas | 09:59 | |
*** bauzas_ is now known as bauzas | 11:19 | |
fungi | jakeyip: 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 |
---|---|---|
jakeyip | fungi: yeap, just master. tags will be good, if it doesn't conflict with what we do in the releases repo? | 12:55 |
fungi | jakeyip: as long as you release higher versions in the future than the highest tag number, it should be fine | 14:02 |
fungi | jakeyip: the only other concern is that the branch is still being actively updated (most recent commit was 3 hours ago) | 14:03 |
fungi | when 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 instead | 14:03 |
fungi | also 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 use | 14:11 |
*** bauzas_ is now known as bauzas | 14:31 | |
clarkb | I 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 CI | 15:07 |
fungi | clarkb: https://review.opendev.org/918287 | 15:10 |
clarkb | and the delta is too large to do through gerrit normally? | 15:12 |
fungi | clarkb: 712 commits and 20 tagged versions over ~1.5 years | 15:16 |
fungi | it'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 governance | 15:17 |
fungi | they 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 time | 15:17 |
clarkb | fungi: oh did we recently create the new project? | 15:20 |
clarkb | that is unfortunate | 15:20 |
fungi | clarkb: "recently" in august https://review.opendev.org/893117 | 15:22 |
fungi | the 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 import | 15:24 |
fungi | maybe they also thought initially they were going to build that one up from scratch, i dunno | 15:24 |
fungi | it 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 |
opendevreview | Seongsoo Cho proposed openstack/openstack-zuul-jobs master: [WIP] Add ansible play for weblate client configuration https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/921878 | 16:07 |
*** bauzas_ is now known as bauzas | 16:53 | |
JayF | Some strange/unique CI failures in Ironic: https://zuul.opendev.org/t/openstack/build/ebd8fec9013b4453a139da009c34970b https://zuul.opendev.org/t/openstack/build/5ac373ea24df495aad72124bed580c78 | 18:23 |
JayF | very early in the zuul portion of the initial configuration, I think | 18:23 |
JayF | this 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 bauzas | 18:26 | |
JayF | https://pypi.org/project/filelock/#history 3.15.0 of filelock appears to have broken virtualenv | 18:26 |
JayF | https://github.com/pypa/virtualenv/blob/main/src/virtualenv/util/lock.py#L22 | 18:26 |
fungi | first guess is new virtualenv | 18:27 |
fungi | but that hasn't updated for a month | 18:27 |
JayF | fungi: I think I id'd it, with the filelock change | 18:28 |
JayF | it's blowing up calling super() on a class subclassed outta filelock.FileLock | 18:28 |
JayF | and it released less than an hour ago | 18:28 |
fungi | aha, i was a few lines back on scrollback, yep | 18:28 |
fungi | i concur, that looks sus | 18:28 |
JayF | what's the best approach for us to fix it? it's likely blowing up all gates, I just caught it early | 18:29 |
fungi | can you reproduce it locally and try again with the next newest filelock? | 18:29 |
JayF | I can try | 18:30 |
fungi | if so, exclude it in global-requirements.txt and roll it back in upper-constraints.txt | 18:30 |
JayF | I 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 too | 18:31 |
JayF | but I know that's probably in line behind a thousand things | 18:31 |
fungi | yeah, reqs/constraints is our "quick fix" | 18:31 |
JayF | fungi: it's not broken for normal tox runs locally, whatever is exercising the broken code is before it gets to ironic tests | 18:31 |
fungi | i'm available to expedite and promote gating for a fix like that too | 18:32 |
JayF | fungi: unsure what that PythonInfo stuff is | 18:32 |
clarkb | its specifically running tox but not running tests | 18:32 |
clarkb | but thats all tox logging | 18:32 |
JayF | ah, so I basically have to get an environment where the bad version of filelock is where my *tox* is installed | 18:33 |
fungi | it's breaking when running tox --notest -edocs | 18:33 |
fungi | yeah, you could .tox/docs/bin/pip install filelock==x.y.z | 18:33 |
fungi | and don't use -r when rerunning tox | 18:33 |
JayF | I think I need it *in the parent env* not inside the tox env, yeah? | 18:33 |
fungi | it's complaining in /home/zuul/.local/tox/lib/python3.10/site-packages/filelock/... | 18:34 |
fungi | so it's the environment where yout tox is installed, yeah | 18:34 |
fungi | not the env tox creates. good point | 18:34 |
JayF | which is why I also suspect global-reqs may not fix | 18:34 |
JayF | but I don't know how early zuul run stuff is shaped | 18:35 |
JayF | yeah, 100% reproduced with a venv-built tox with wrong filelock version inside, trying to verify rolling back fixes | 18:35 |
clarkb | ya you may need to put a rule in the zuul-jobs ensure-tox role to say install tox and not filelock version foo | 18:35 |
JayF | works with filelock 3.14.0, fails with filelock 3.15.0 | 18:36 |
JayF | validated | 18:36 |
fungi | tox is installed during the job, ftr: https://zuul.opendev.org/t/openstack/build/ebd8fec9013b4453a139da009c34970b/console#1/0/34/ubuntu-jammy | 18:36 |
clarkb | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks/main.yaml#L30 | 18:36 |
clarkb | thats the lint you would modify to add filelock!=3.15.0 I think | 18:36 |
JayF | ah, good, was hunting for that repo | 18:36 |
clarkb | s/lint/line/ | 18:36 |
fungi | so yeah, no constraints bailing us out of this one, but we can review that quickly | 18:37 |
clarkb | or alternatively switch everything to nox assuming nox doesn't use filelock | 18:37 |
clarkb | :) | 18:37 |
fungi | also zuul/zuul-jobs changes can merge waaaay faster than openstack/requirements | 18:38 |
fungi | they proceed directly to the gate when approved even if check isn't complete, and there's rarely a queue to hold them up | 18:38 |
JayF | https://review.opendev.org/c/zuul/zuul-jobs/+/921885 Block broken version of filelock from installing | 18:39 |
JayF | I did validate that command line behaved as expected locally | 18:40 |
JayF | and I'm hoping a hacky fix is good enough since 'd really, really hope upstream is on the ball about fixing this | 18:40 |
clarkb | I think that role is exercised by tests too | 18:41 |
fungi | oh yes, ensure-tox is covered by tests in zuul-jobs | 18:44 |
JayF | re: 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 back | 18:46 |
* JayF lolsobs in python | 18:46 | |
fungi | yeah, i feel you | 18:51 |
clarkb | ya I don't think there is a good way around that unfortunately | 18:51 |
fungi | JayF: clarkb: looks like it failed on the same error | 19:02 |
fungi | https://zuul.opendev.org/t/zuul/build/d8a40f194eea49949e6f9508977a2845/console#2/0/24/ubuntu-jammy indicates the change applied though | 19:03 |
fungi | also it looks like upstream yanked that version anyway | 19:04 |
fungi | https://pypi.org/project/filelock/ now claims the latest version is 3.14.0 from april | 19:04 |
frickler | sounds like a nice emergency solution | 19:05 |
fungi | maybe we're okay for now and we wait to see what they do next? | 19:05 |
fungi | and 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 being | 19:05 |
frickler | https://pypi.org/project/filelock/3.15.0/ shows it was broken and yanked | 19:05 |
frickler | right, maybe do a status notice? but not me, I'm out for today now | 19:07 |
clarkb | fungi: that specific tests installs tox again at another location :/ | 19:07 |
clarkb | but ya I think if they yanekd it we're good | 19:07 |
*** bauzas_ is now known as bauzas | 19:35 | |
*** bauzas_ is now known as bauzas | 20:00 | |
clarkb | https://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 virtualenv | 20:22 |
*** bauzas_ is now known as bauzas | 20:53 | |
jakeyip | thanks 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 |
fungi | jakeyip: good enough. i'll push the current state of the master branch and tags in that case. give me a few minutes | 21:20 |
jakeyip | thanks! | 21:24 |
JayF | do 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.txt | 21:29 |
JayF | this started post-yank and is still a failure | 21:29 |
clarkb | JayF: that job failed at 18:23:51 utc you sure it was post yanking of the pacakge? That is before we discussed it above | 21:30 |
JayF | it helps if I do UTC math for my current tz | 21:30 |
JayF | haha | 21:30 |
* JayF is in his third TZ in two weeks | 21:31 | |
jakeyip | just 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 |
clarkb | jakeyip: but the force push is a one time thing right? | 21:34 |
jakeyip | this is interim, stackhpc wishes to move to using opendev fork eventaully, but that's something for later | 21:34 |
clarkb | JayF: 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 phone | 21:34 |
jakeyip | clarkb: yes force push now is one time, when we fork. | 21:34 |
jakeyip | * at the point of fork | 21:35 |
JayF | jakeyip: 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 point | 21:36 |
JayF | I wonder if we should have an RCA about this situation in the next TC PTG or something | 21:37 |
JayF | (to be clear: 'you all' is all magnum community in this context; not stackhpc) | 21:37 |
clarkb | jakeyip: cool I just want to amke sure thre isn't an expectation that opendev admins will force push peridoically to sync things across | 21:37 |
jakeyip | JayF: 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 |
fungi | jakeyip: https://opendev.org/openstack/magnum-capi-helm-charts | 21:40 |
jakeyip | "go fast go alone, go far go together" | 21:40 |
jakeyip | fungi: thanks | 21:41 |
fungi | yw | 21:41 |
JayF | jakeyip: I agree it's unfortunate; but it's really not a good look for you all tbh | 21:42 |
jakeyip | https://review.opendev.org/c/openstack/magnum-capi-helm-charts/+/921897 | 21:44 |
*** bauzas_ is now known as bauzas | 21:46 | |
jakeyip | JayF: yeah... well the worse alternative is the upstreaming effort doesn't even happen | 21:46 |
jakeyip | fungi: we don't have CI yet for that gitreview change. manual verify or is there a dummy job in zuul for this? | 21:51 |
fungi | jakeyip: 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-project | 21:53 |
jakeyip | fungi: thanks! | 21:53 |
jakeyip | fungi: all done, thanks for your help! JayF clarkb too :) | 21:59 |
JayF | eh I wasn't helpful just sad in your direction, give those guys all the love | 22:00 |
jakeyip | :) | 22:04 |
*** bauzas_ is now known as bauzas | 23:02 | |
opendevreview | Ian 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/+/921878 | 23:29 |
opendevreview | Ian 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/+/921878 | 23:47 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!