| fungi | over the weekend i noticed another issue with mailman bounce processing on openstack-discuss | 14:26 |
|---|---|---|
| fungi | some muas (outlook in particular, i think?) emit over-long headers. exim accepts those messages (as does mailman, which turns them around unaltered), but then the exim remote smtp router rejects them with a "message has lines too long for transport" permanent error which is counting as a bounce for every recipient | 14:32 |
| fungi | based on package changelogs, it looks like this feature got implemented in exim 4.95 (jammy), and then workarounds were added to increase it from the default 998 bytes by a few orders of magnitude in ubuntu's 4.96-5 packages (so noble, not backported) | 14:35 |
| fungi | i think we should duplicate the message_linelength_limit = 1G from noble into our configs, but am not quite clear how to go about that in playbooks/roles/base/exim/templates/exim4.conf.j2 since adding it on focal and earlier will result in a configuration parsing error | 14:37 |
| fungi | i guess i can use an ansible platform conditional in the jinja? | 14:37 |
| fungi | aha, looks like i can, something along the same lines as https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/master-nameserver/templates/named.conf.j2#L13-L15 | 14:42 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Increase message_linelength_limit to 1G https://review.opendev.org/c/opendev/system-config/+/940248 | 14:59 |
| fungi | there's a stab at it ^ | 14:59 |
| corvus | i'm finishing up the zuul restart manually | 15:07 |
| corvus | also i'm going to re-restart the scheduler on zuul01 since zuul02 jumped ahead a change | 15:08 |
| fungi | thanks corvus! i was worried it would come down to that | 15:09 |
| fungi | but didn't touch it because i wasn't sure if there might have been a cleaner way to resume the in-progress restart | 15:10 |
| corvus | proabably not; problably just re-running the restart playbook would be the most automatic thing we could have done. but this was near the end, so it's faster to do manually. :) | 15:13 |
| corvus | there's definitely room for improvement, but https://zuul.opendev.org/t/opendev/image/debian-bullseye exists now and we can see what zuul sees. | 15:20 |
| fungi | yay! | 15:22 |
| fungi | https://zuul.opendev.org/t/openstack/build/058df70b33f04569a32d9f43ddd2250f is a new failure for me (timeout in install-kubectl : Download openshift client tarball) | 15:24 |
| fungi | i'm able to fetch https://github.com/openshift/origin/releases/download/v3.11.0/openshift-origin-client-tools-v3.11.0-0cbc58b-linux-64bit.tar.gz here at home, so probably something temporary/random | 15:30 |
| corvus | ++ | 15:31 |
| fungi | also, looks like that's basically just cruft for the experimental kubernetes/rook gitea pod we're not using? | 15:31 |
| corvus | yeah i was thinking that's probably the only thing using it; could probably drop it if it becomes a problem. and even if we restart that, we might not need to get that client that way anymore. | 15:35 |
| Clark[m] | Ya I think we can safely drop the fetch off that tool on bridge | 15:40 |
| Clark[m] | I'm having a bit of a slow start today, but I'd like to finish up the paste cleanup that stalled out Friday. Any concerns with deleting paste01 and it's volume at this point (reminder paste02 didn't get a volume) | 15:41 |
| Clark[m] | Then following up on bindep and PBR and pyproject.toml stuff as well as doing more grafana debugging | 15:41 |
| clarkb | my monday morning system updates include a new bash package | 16:18 |
| clarkb | and amd cpu ucode updates. This is a fun one | 16:19 |
| fungi | yeah, i guess that's the one that asus leaked in the rog bios downloads? | 16:20 |
| clarkb | oh ya could be | 16:20 |
| clarkb | in any case I'll be rebooting shortly for that then finding breakfast then I can start digging in | 16:21 |
| clarkb | let me know if you think it is safe to proceed with paste01 and its volume cleanup despite the lack of volume on paste02 (frickler indicated this seemed fine on friday but I dont' think I heard from anyone else) | 16:22 |
| fungi | what were we using the volume for on the old server? database? | 16:22 |
| clarkb | yes the database | 16:22 |
| clarkb | it is a 75GB volume and we're only using 4.4GB of it iirc. | 16:23 |
| clarkb | the relatively small size of the db is why paste02 is happy at the moment there is a bit of headroom on the server's / disk | 16:23 |
| fungi | rootfs on new paste isn't even a quarter used, seems fine to just stick it there, i agree | 16:23 |
| fungi | we've got backups, and also /opt ephemeral if we want to do that | 16:24 |
| fungi | so plenty of safety/options | 16:24 |
| clarkb | cool once I feel awake I'll actually proceed with deleting paste01 and its volume then | 16:24 |
| clarkb | fungi: and then for bindep/pbr/pyproject.toml stuff I think we're still waiting on a pbr beta release? | 16:25 |
| clarkb | I guess we can proceed with landing pyproject.toml in bindep since the release for bindep was made on Friday | 16:26 |
| clarkb | then do followups that use teh beta release when available | 16:26 |
| fungi | yeah, on friday the openstack release team said something about approving the pbr beta release request today | 16:27 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Increase message_linelength_limit to 1G https://review.opendev.org/c/opendev/system-config/+/940248 | 16:36 |
| clarkb | https://review.opendev.org/c/opendev/system-config/+/940166/ and parent are two improvements to grafana deployments to make testing more robust (the linked change will impact production too by setting up journald logging for the container) | 16:41 |
| clarkb | those two should be safe to land at any time. Its the followup to upgrade that is not currently safe until we figure out the CORS stuff | 16:41 |
| opendevreview | Merged opendev/zuul-jobs master: Compress raw/vhd images https://review.opendev.org/c/opendev/zuul-jobs/+/935970 | 16:52 |
| clarkb | ok I have tea and have heard no objections to deleting paste01. I've quickly double checked and was just able to open a random paste from July. I'll proceed with server deletion and volume deletion now | 17:02 |
| fungi | sounds good, thanks! | 17:04 |
| clarkb | #status log Deleted paste01.opendev.org (d2312252-2318-4b8e-a255-b8cb8c2069b6) and its associated data volume (e4b23816-b205-47fe-8372-1ce4f7650b0a) | 17:07 |
| clarkb | it should be safe to proceed with https://review.opendev.org/c/opendev/system-config/+/939128 now. That may trigger quite a few infra-prod jobs though as it modified inventory | 17:08 |
| opendevstatus | clarkb: finished logging | 17:08 |
| clarkb | (that requires paste01 backups on the smaller backup server. It is safe now because now that the server is gone it won't create new backups) | 17:08 |
| corvus | i logged into the zuul web ui and pressed the "Build Image" button on https://zuul.opendev.org/t/opendev/image/debian-bullseye -- that should build and upload a compressed raw image. | 17:09 |
| corvus | we've already seen that in action in https://zuul.opendev.org/t/opendev/build/33a460e52e6b4c44ad524f97944dd7cc | 17:09 |
| corvus | the build took 50m and the upload of both artifacts (raw and qcow) took 20m | 17:09 |
| corvus | this next test will have the launcher download the compressed raw image, uncompress it, and upload it to vexxhost (we hope) | 17:10 |
| opendevreview | Clark Boylan proposed opendev/zone-opendev.org master: Remove paste01 dns records https://review.opendev.org/c/opendev/zone-opendev.org/+/940255 | 17:10 |
| fungi | clarkb: apparently the newline omitted by %- was necessary? https://zuul.opendev.org/t/openstack/build/89b96dcee0d241c1b063b9e6d0fa7576 | 17:10 |
| fungi | the job passed when it was just % | 17:11 |
| clarkb | huh or maybe we need a trailing - instead of a leading -? | 17:11 |
| clarkb | the leading - might remove the leading whitespace too? Its not super important to have I just thought avoiding blank lines would be a good idea | 17:11 |
| clarkb | landing 940255 and 939128 should largely conclude the paste replacement. I'm thinking doing one or two more services might be a good idea before doing review. Maybe codesearch and grafana or something along those lines | 17:13 |
| clarkb | corvus: this largely exercises the use of ui and api and compression? | 17:14 |
| fungi | clarkb: looks like the %- removes the preceding newline (and not the indentation?): https://zuul.opendev.org/t/openstack/build/89b96dcee0d241c1b063b9e6d0fa7576/log/lists99.opendev.org/syslog.txt#1417 | 17:14 |
| clarkb | oh interesting so ya we probably need the trailing - not the leading - | 17:14 |
| clarkb | -%} instead of {%- | 17:15 |
| fungi | but on the if not the endif, right? | 17:15 |
| clarkb | yes | 17:15 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Increase message_linelength_limit to 1G https://review.opendev.org/c/opendev/system-config/+/940248 | 17:16 |
| corvus | clarkb: yes -- specifically, does the zuul-launcher processing of a compressed raw image work :) | 17:16 |
| clarkb | actually replacing some zuul servers might be a better exercise since we're a bit harder on zuul (from a usage and management perspective) | 17:17 |
| clarkb | I won't dive into that today (enough other stuff) but I'll think about that a bit | 17:17 |
| opendevreview | Merged opendev/system-config master: Take screenshots of all grafana dashboards https://review.opendev.org/c/opendev/system-config/+/940154 | 17:35 |
| clarkb | looking at eavesdrop I see that ptg.opendev.org has a new cert from january 16th. We're still getting warnings about the cert expiring in 3 weeks though. Probably another case where apache isn't cycling worker processes quickly enough? | 17:42 |
| opendevreview | Merged opendev/system-config master: Log grafana to /var/log/containers with journald/syslog https://review.opendev.org/c/opendev/system-config/+/940166 | 17:45 |
| fungi | that's what i've been expecting, yes | 17:45 |
| clarkb | I've just checked grafana and the container was restarted and we have a log file in /var/log/containers as expected | 17:47 |
| clarkb | and the web ui appaers to be up and responding to me | 17:48 |
| clarkb | fungi: are you pushing an update to bindep to pull in the beta release of pbr? | 17:53 |
| fungi | i will once we see the beta on pypi, yes | 17:54 |
| clarkb | greatthanks! I need to pull up the latest state of the bindep stack anyway so will start catching up now | 17:54 |
| fungi | basically waiting for it to appear and then i've got the dnm change for bindep ready to push up on top of that stack | 17:58 |
| clarkb | fungi: the end of that stack is apparently in merge conflict | 17:59 |
| clarkb | so you might need to stack it on a change not at the end ofthe satck or rebase the whole thing or something | 17:59 |
| fungi | will do. git didn't see any conflicts that needed resolving, but i guess gerrit is less flexible there | 18:00 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: Use PBR's pyproject.toml build-backend support https://review.opendev.org/c/opendev/bindep/+/816741 | 18:00 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: Evacuate most metadata out of setup.cfg https://review.opendev.org/c/opendev/bindep/+/938520 | 18:00 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop support for Python 3.6 https://review.opendev.org/c/opendev/bindep/+/938568 | 18:00 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop requirements.txt https://review.opendev.org/c/opendev/bindep/+/938570 | 18:00 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: Drop tox.ini https://review.opendev.org/c/opendev/bindep/+/940219 | 18:01 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: DNM: Test PBR beta release https://review.opendev.org/c/opendev/bindep/+/940258 | 18:01 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: DNM: Test PBR beta release https://review.opendev.org/c/opendev/bindep/+/940258 | 18:03 |
| fungi | forgot to increase it in the dependencies list too | 18:03 |
| fungi | just for thoroughness | 18:03 |
| clarkb | ya that mgiht be necessary for it to be considered as valid because it is a beta release? | 18:04 |
| fungi | correct | 18:04 |
| clarkb | not sure how thoroughly those different configs get checked when installing the deps | 18:04 |
| fungi | one is for package build time, one is for runtime | 18:04 |
| clarkb | makes sense | 18:04 |
| fungi | so we could end up with bindep built with the pbr beta but then run with the prior full release (which should still work fine of course) | 18:05 |
| fungi | but this way we get more thorough testing in both aspects | 18:06 |
| fungi | also when the constraints update proposal gets pushed, we should have some additional test feedback hopefully | 18:06 |
| clarkb | fungi: we should wip that change? | 18:06 |
| fungi | i'm planning to do so the moment it exists | 18:07 |
| clarkb | thanks | 18:07 |
| fungi | just waiting for the propose-update-constraints job to start (it's still queued) | 18:07 |
| fungi | and stephenfin already has a full release of pbr proposed too, just wip for the moment, but once we're comfortable with these exercises we can go ahead with that too | 18:08 |
| fungi | some other what-if changes i want to add to that bindep stack are getting rid of test-requirements.txt and docs/requirements.txt (just distributing the appropriate test/docs dependencies into the necessary parts of the noxfile instead) | 18:10 |
| clarkb | before a full release happens we should ideally land the docs update (if that hasn't happend yet) and consider dropping the python3.12 restriction on setuptools as a requirement | 18:10 |
| clarkb | though the setuptools change can also happe in a followup release | 18:10 |
| clarkb | if we want to tread slowly here | 18:11 |
| fungi | yeah, also stephenfin has a change up to add 3.13 testing (which seems to work once we ironed out the kink with 3.13.1t cpython from pyenv) | 18:11 |
| clarkb | fungi: the change to use the beta pbr release is after the python3.6 removal. DO we want to test it with python3.6 just to see if anything else other than setuptools support for editable wheels is a problem? | 18:19 |
| fungi | sure, i can shuffle it up the stack once we have preliminary results | 18:19 |
| fungi | https://review.opendev.org/940260 exists and is wip now | 18:24 |
| fungi | https://zuul.opendev.org/t/opendev/buildset/86b76fa186a4487ebf62ddff9024d9df has the results from 940258,2 and i'll dig into the logs from them to double-check that we really did use the beta | 18:26 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: DNM: Test PBR beta release https://review.opendev.org/c/opendev/bindep/+/940258 | 18:26 |
| fungi | and that ^ checks it with 3.6 | 18:26 |
| fungi | https://zuul.opendev.org/t/opendev/build/f005295b1c714381abe55c22efcb1341/console seems to have pulled "pbr-6.1.1.0b1-py2.py3-none-any.whl" | 18:30 |
| fungi | "Successfully installed [...] pbr-6.1.1.0b1" | 18:31 |
| fungi | unfortunately it doesn't log the version used for the build backend | 18:34 |
| fungi | i'll test it locally and see if i can coax more details out | 18:41 |
| fungi | the 0.0.0 version in https://zuul.opendev.org/t/opendev/build/7490e13cb15e4b7c9fe3a6ded3900ca8/console#2/0/0/ubuntu-noble is mildly worrisome, wondering if that's because it still relies on directly invoking setup.py | 18:44 |
| clarkb | hrm ya that is not ideal | 18:47 |
| fungi | yeah, if i use `python3 setup.py sdist bdist_wheel` it fails to set the bindep version and ends up falling back on 0.0.0 | 18:47 |
| fungi | if i use https://pypi.org/p/build then i get the right version | 18:48 |
| clarkb | setup.py should be effectively doing the same thing as the pep 440 path though since its all setuptools under the ood. I wonder where the disconnect is | 18:48 |
| clarkb | I guess we have the choice of updating openstack release builds to use `build` and just move on or we can try and debug and fix it | 18:49 |
| clarkb | having at least a small understanding of why it is happening is probably a good idea | 18:49 |
| clarkb | fungi: does python3 setup.py sdist bdist_wheel work with the current full release of pbr on python3.12? | 18:50 |
| fungi | yeah, if i roll back to bindep master branch, no pyproject.toml file, then `python3 setup.py sdist bdist_wheel` gets the correct version string from git when using the same python/setuptools versions | 18:50 |
| fungi | though i am testing with python 3.13. i'll repeat with 3.12 | 18:50 |
| clarkb | fungi: I wonder if it has anything to do with the move of setup.cfg content | 18:51 |
| clarkb | since moving all of that into pyproject.toml is going to be modern build tooling specific maybe? | 18:51 |
| clarkb | its possible we need to keep that stuff in setup.cfg for broad compatibiltiy? | 18:51 |
| fungi | no, it's the mere existence of the pyproject.toml i think | 18:52 |
| fungi | just tested with python3.12/setuptools-75.8.0 on a checkout of 816741 and `python3 setup.py sdist bdist_wheel` builds bindep 0.0.0 | 18:53 |
| fungi | correction, presence of the build-system section in pyproject.toml, if i simply create an empty pyproject.toml on a master branch checkout it's still working okay | 18:55 |
| clarkb | that implies setuptools is changing its behavior based on pyproject.toml build-system even when it is invoked in the legacy manner. That feels like a bug but probably can't say until we know more | 18:56 |
| fungi | i suspect this has always been the case, and if we want pbr.build to work as a pyproject.toml build-system.build-backend we need to use a pep-417 compliant build frontend like the build tool | 18:56 |
| fungi | er, pep-517 | 18:57 |
| clarkb | ya that wouldn't surprise me and we might consider that a bug but upstream will say something like no this is used to force you to stop using the legacy sysetm or similar | 18:57 |
| clarkb | and build should work with the pre pyproject.toml addition right? so we can simply update our build jobs and be compatibiltiy with or without pyproject.toml? | 18:57 |
| fungi | i doubt they'd even get that detailed, and will more likely say that if you want to use pyproject.toml then stop directly invoking setup.py, with no further explanation | 18:58 |
| clarkb | ya | 18:58 |
| fungi | and yes, if that build-python-release job invoked pyproject-build instead of setup.py i'm 99% sure it would generate the right version | 18:59 |
| clarkb | ya I'm just worried about updating a global openstack job for the small number of things using pyproject.toml | 19:00 |
| clarkb | I guess if we want to be extra cautious we could switch behavior based on the presense (or lack) of a pyproject.toml file | 19:00 |
| fungi | note that this isn't an openstack job, it's a job defined in zuul-jobs | 19:00 |
| fungi | though openstack is running it, of course | 19:00 |
| clarkb | oh I thought this was the openstack specific job (which maybe inherits from this job) | 19:01 |
| fungi | nope, defined right in and used straight from zuul/zuul-jobs | 19:01 |
| clarkb | anyway seems like a good next step is updating the job to use `build` ? could be conditional based on pyproject.toml presence | 19:01 |
| fungi | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/build-python-release/tasks/main.yaml#L2 | 19:02 |
| fungi | yeah, i'll work on a change for that | 19:02 |
| clarkb | sounds good. The kids don't have school today so we're going to try and grab brunch/lunch shortly. But I can review when I return | 19:03 |
| fungi | have fun! | 19:03 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: DNM: Test PBR beta release https://review.opendev.org/c/opendev/bindep/+/940258 | 19:58 |
| opendevreview | Jeremy Stanley proposed zuul/zuul-jobs master: Add ensure-pyproject-build role https://review.opendev.org/c/zuul/zuul-jobs/+/940267 | 20:01 |
| corvus | looks like the vexxhost upload took about 12m and it's starting the raxflex upload now | 20:04 |
| corvus | when that's done... hopefully we'll see artifact c7b3bbdc25d0406f9ac6c27a95be3fab and upload 6e0a3ad8e88144ffa7406d7d5594b84f be deleted | 20:05 |
| fungi | clarkb: the latest iteration of the dnm change for bindep using the pbr beta version did pass for py36 as well. also it looks like the wip constraints bump of pbr to the beta version passed all jobs too (though i don't know how indicative that is of what to expect with a proper release) | 20:09 |
| corvus | it is done, but the old image wasn't automatically deleted. that's not a huge problem in the scheme of things. | 20:10 |
| fungi | that's massive progress, indeed | 20:10 |
| Clark[m] | fungi: I'm guessing that PBR isn't pre installed so the contraint doesn't apply in most jobs? It may apply to devstack though as I think it may be preinstalled there | 20:16 |
| fungi | well, also it tests runtime use where projects declare pbr as a dependency (install_requires) | 20:17 |
| fungi | Clark[m]: the good news is that the release-openstack-python job is also just reusing the same build-python-release role from zuul-jobs, so if we fix it there we fix it everywhere | 20:20 |
| fungi | digging through codesearch's hits on any use of "setup.py sdist" or "setup.py bdist_wheel" turns up a lot, but nothing else critical that gets run cross-project. just some stuff locally in projects they'll need to address if they start doing build-system.build-backend in pyproject.toml | 20:28 |
| opendevreview | Aurelio Jargas proposed zuul/zuul-jobs master: Add ensure-uv role https://review.opendev.org/c/zuul/zuul-jobs/+/940271 | 20:46 |
| clarkb | ok back. I'll review the zuul-jobs change now | 20:46 |
| clarkb | fungi: just to double check there isn't a change to update the build release job yet? Just a change to install build? | 20:56 |
| clarkb | fungi: also if you get a chance can you review https://review.opendev.org/c/opendev/zone-opendev.org/+/940255 and consider if we should single core approve https://review.opendev.org/c/opendev/system-config/+/939128 at this point? | 20:57 |
| fungi | clarkb: not yet, corvus suggested we get mordred's poetry change merged first since it touches the same role, but it's looking like it has new issues since the last time it was tested | 20:57 |
| clarkb | oh I see in the zuul matrix room now | 20:58 |
| fungi | yeah, digging deeper into that, but i'm really not familiar with poetry at all since i've never touched it | 20:58 |
| clarkb | thats annoying that poetry doesn't respect requires python | 21:01 |
| clarkb | this would be a complete non issue with pip... | 21:01 |
| opendevreview | Merged opendev/zone-opendev.org master: Remove paste01 dns records https://review.opendev.org/c/opendev/zone-opendev.org/+/940255 | 21:01 |
| clarkb | fungi: 1.0.8 supports python3.8 | 21:02 |
| clarkb | 1.1.0 supports python3.9 | 21:02 |
| fungi | yeah, but also it's actually the plugin that's erroring on a too-old python version, need to make sure it installs an old enough version of the plugin for the platform | 21:02 |
| fungi | it looks like poetry just wants to install the latest plugin version no matter what | 21:03 |
| clarkb | right poetry==1.1.0 should work on centos 9 and bullseye and 1.0.8 should work on focal | 21:03 |
| fungi | but will it still try to install the latest version of poetry-git-version-plugin? | 21:04 |
| clarkb | oh sorry I meant the plugin at those versions | 21:04 |
| fungi | it seems like it's the `poetry self add poetry-git-version-plugin` pulling in the latest available version | 21:05 |
| clarkb | poetry-git-version-plugin 1.1.0 should work with 3.9 and 1.0.8 should work with 3.8 | 21:05 |
| clarkb | https://python-poetry.org/docs/plugins/#with-pip this says you can install plugins with pip which should respect requires python | 21:05 |
| fungi | maybe `poetry self add ...` lets you specify plugin versions | 21:05 |
| clarkb | that might be an easy option | 21:05 |
| fungi | ah | 21:05 |
| fungi | agreed | 21:05 |
| clarkb | self add means install to the environment that poetry is installed to where as just add installs to the env for the project being managed by poetry | 21:06 |
| clarkb | so in theory if we just pip install to the venv poetry is in we can have pip figure out versions for us | 21:06 |
| fungi | {{ ensure_poetry_venv_path }}/bin/pip install poetry-git-version-plugin | 21:07 |
| fungi | something like that i guess | 21:07 |
| clarkb | ++ | 21:07 |
| opendevreview | Jeremy Stanley proposed zuul/zuul-jobs master: Hook poetry into ensure-python and build-python-release https://review.opendev.org/c/zuul/zuul-jobs/+/923094 | 21:09 |
| clarkb | and then I guess we should make pyproject-build the default and have an override to use setup.py directly and also the existing overrides for poetry? | 21:10 |
| clarkb | if use setup.py then setup.y; if poetry.lock present or poetry flag isn't turned off then poetry; else pyproject-build? | 21:11 |
| fungi | yeah, i was going to look for a "[build-system]" line in pyproject.toml, in order to keep the old behavior, but pyproject-build is supposed to also work with projects that don't have a pyproject.toml | 21:12 |
| fungi | so a use-the-old-stuff override projects can specify to get it back is maybe the best choice | 21:13 |
| clarkb | ya I think so, its more forward looking. our default is future proof with an escape hatch for old stuff | 21:13 |
| fungi | maybe call the legacy override something like invoke_setup | 21:14 |
| fungi | or even invoke_legacy_setup | 21:14 |
| clarkb | ++ | 21:15 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update grafana to 10.4.14 https://review.opendev.org/c/opendev/system-config/+/940073 | 21:20 |
| clarkb | I'm putting a hold in place for ^ | 21:20 |
| fungi | awesome | 21:21 |
| clarkb | as far as updates for the infra meeting agenda go I plan to recap the meetup content and point to our todo list, talk about converting to opendevmirror hosted container images, maybe touch on grafana stuff. Anything else to add? | 21:22 |
| fungi | exim line length change from earlier today could probably use some discussion, just so people are aware of yet another unexpected impact for mailman bounce processing | 21:29 |
| clarkb | ack added to my little note sheet | 21:31 |
| fungi | thanks! | 21:32 |
| opendevreview | Merged opendev/system-config master: Retire paste01 backups on the smaller backup server https://review.opendev.org/c/opendev/system-config/+/939128 | 21:59 |
| opendevreview | Jeremy Stanley proposed zuul/zuul-jobs master: build-python-release: pyproject-build by default https://review.opendev.org/c/zuul/zuul-jobs/+/940273 | 22:20 |
| fungi | i'll get the dnm change build-depending on that ^ and see if it addresses the issue like i suspect it should | 22:21 |
| clarkb | sound sgood | 22:22 |
| opendevreview | Jeremy Stanley proposed opendev/bindep master: DNM: Test PBR beta release https://review.opendev.org/c/opendev/bindep/+/940258 | 22:23 |
| clarkb | fungi: will build emit the wheel and sdist files to the same location as setup.py? | 22:26 |
| clarkb | that might be the other thing to check and address if not | 22:26 |
| fungi | yes, they still end up in dist/ | 22:26 |
| clarkb | nice | 22:26 |
| fungi | it's really up to the backend i think | 22:26 |
| fungi | not positive, but i suspect that's why it doesn't change when using setuptools directly vs using setuptools as a build backend | 22:27 |
| fungi | regardless, the build-python-release job should catch it if not | 22:28 |
| clarkb | makes sense | 22:31 |
| fungi | okay, https://zuul.opendev.org/t/opendev/build/21e81d0f22bb4e86a07b57e24d5dd4ff is going to be challenging to troubleshoot | 22:33 |
| fungi | ah, no, the dependency is borked, probably not even valid yaml or something | 22:34 |
| opendevreview | Jeremy Stanley proposed zuul/zuul-jobs master: build-python-release: pyproject-build by default https://review.opendev.org/c/zuul/zuul-jobs/+/940273 | 22:35 |
| fungi | now it's looking somewhat better | 22:38 |
| clarkb | fungi: I tried to capture the exim bit in the agenda's wiki page if you have a chance to check it | 22:38 |
| fungi | lgtm, thanks! | 22:39 |
| fungi | so this was without the depends-on: https://zuul.opendev.org/t/opendev/build/b7aa421f55fb444eb64c9bb8578fa582/log/job-output.txt#431 | 22:42 |
| fungi | and this was with the depends-on: https://zuul.opendev.org/t/opendev/build/17f555729d56402da9906a86317b31c9/log/job-output.txt#1662 | 22:42 |
| clarkb | held grafana is here: https://217.182.143.14/ and it seems to be working for me actually | 22:43 |
| clarkb | there are warnings about deprecated panels that require angularbut those are just warnings | 22:43 |
| clarkb | I'll have to open every dashboard tosee if any of them fail | 22:43 |
| fungi | mmm, one thing i'm noticing with the dnm change is that we're not getting bindep/tests included in the wheel, which i suspect is a problem with setuptools auto-discovery | 22:45 |
| clarkb | ok the dib status dashboard appears to fail | 22:45 |
| fungi | i'll test locally and see if i can bisect the stack to the point where they start showing up | 22:45 |
| clarkb | if anyone else looks that is probably a good place to start | 22:45 |
| fungi | the bindep/tests files that is | 22:45 |
| clarkb | fungi: I wonder if we're going to do src/bindep in our future | 22:45 |
| fungi | nah, it works later in the stack | 22:46 |
| fungi | pretty sure | 22:46 |
| clarkb | there is an __init__.py in the dir so not something silly like that file missing | 22:46 |
| fungi | right, it's directories without an __init_.py where setuptools by default doesn't find and include their contents | 22:47 |
| fungi | yeah, if i move to the end of the stack the wheel has bindep/tests/* included | 22:50 |
| fungi | oh, wait, i was comparing them backwards. with the depends-on we get the expected wheel contents. without the depends-on not only is the version empty but the wheel is missing all the test scripts/fixtures | 22:55 |
| clarkb | for grafana the problems appear to be related to the use of query in dashboards. Not all dashboards use queries those are fine | 22:55 |
| clarkb | and the firefox trace shows a cors missing allowed origin error | 22:55 |
| clarkb | https://community.grafana.com/t/problem-setting-up-graphite-data-source/5558 indiciates that one solution for that may be to have grafana proxy the graphite request | 22:56 |
| clarkb | so now I'm trying to figure out have grafyaml configure sthe graphite datasource. Maybe we can switch that to proxy and everything will work | 22:56 |
| opendevreview | Clark Boylan proposed openstack/project-config master: Proxy Grafyaml requests to Graphite https://review.opendev.org/c/openstack/project-config/+/940276 | 23:02 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Update grafana to 10.4.14 https://review.opendev.org/c/opendev/system-config/+/940073 | 23:04 |
| clarkb | maybe this will fix it for us | 23:04 |
| clarkb | ya I think that may have fixed it | 23:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!