clarkb | is the wiki not responding for anyone else? cc infra-root | 00:02 |
---|---|---|
clarkb | and its back again. Looks like system load average was a bit high but I don't see anything amiss after ssh in and taking a quick look | 00:04 |
clarkb | and the agenda is sent. See yall then | 00:06 |
fungi | clarkb: database backups maybe? | 00:10 |
Clark[m] | Ooh ya could be backups | 00:15 |
opendevreview | Takashi Kajinami proposed opendev/yaml2ical master: Modernize python versions https://review.opendev.org/c/opendev/yaml2ical/+/909488 | 01:49 |
tkajinam | I wonder where the job for that yaml2ical repository is configured ? | 02:56 |
fungi | tkajinam: which job? are you looking for opendev/irc-meetings maybe? | 03:22 |
tkajinam | fungi, I was looking for what should be updated to get rid of tox-py35 job run there | 03:22 |
fungi | oh, checking | 03:23 |
tkajinam | the repository contains no .zuul.d or .zuul.yaml and seems jobs are configured differently in that repo, I guess | 03:23 |
fungi | tkajinam: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/projects.yaml#L515 | 03:25 |
tkajinam | yeah seems that's the one | 03:26 |
fungi | probably we just never got around to moving its jobs in-repo after the zuul v3 transition years ago | 03:26 |
fungi | i can't think of any good reason not to, it simply doesn't seem to have happened | 03:27 |
tkajinam | yeah | 03:27 |
opendevreview | Takashi Kajinami proposed openstack/project-config master: Drop py35 job template from yal2ical https://review.opendev.org/c/openstack/project-config/+/909494 | 03:27 |
opendevreview | Takashi Kajinami proposed opendev/yaml2ical master: Modernize python versions https://review.opendev.org/c/opendev/yaml2ical/+/909488 | 03:29 |
opendevreview | Takashi Kajinami proposed opendev/yaml2ical master: Modernize python versions https://review.opendev.org/c/opendev/yaml2ical/+/909488 | 03:29 |
tkajinam | fungi, ok you now know where I got the base content for .zuul.yaml :-P | 03:32 |
tkajinam | that's should be fixed in the latest patch but I'll see which job may be triggered | 03:32 |
fungi | ~yep | 03:33 |
tkajinam | ah, wait | 03:33 |
tkajinam | let me drop pep8 as well. I'm adding it to the repository side | 03:33 |
fungi | k | 03:33 |
opendevreview | Takashi Kajinami proposed openstack/project-config master: Drop python jobs from yal2ical https://review.opendev.org/c/openstack/project-config/+/909494 | 03:35 |
tkajinam | seems we have to merge the project-config update first to disable these jobs, but at least I saw pep8 job and py3(8|11) job were triggered so the update should work fine | 03:36 |
tkajinam | we may want to remove a few remaining jobs from the other repos but I'll look into these later when I get time. | 03:37 |
tkajinam | fungi, thanks for your prompt help as always :-) | 03:37 |
fungi | yes, project-config is a trusted config repo in that zuul tenant, so you can't get speculative execution of job changes in it for security reasons | 03:37 |
tkajinam | ah, I see | 03:37 |
fungi | but once 909494 merges, rechecking 909488 should work as intended | 03:38 |
tkajinam | yes. I'll post recheck once that one is merged | 03:38 |
opendevreview | Merged openstack/project-config master: Drop python jobs from yal2ical https://review.opendev.org/c/openstack/project-config/+/909494 | 03:49 |
opendevreview | Takashi Kajinami proposed opendev/yaml2ical master: Modernize python versions https://review.opendev.org/c/opendev/yaml2ical/+/909488 | 04:55 |
*** dmellado74522 is now known as dmellado7452 | 11:06 | |
*** dmellado74522 is now known as dmellado7452 | 12:00 | |
opendevreview | Merged opendev/yaml2ical master: Modernize python versions https://review.opendev.org/c/opendev/yaml2ical/+/909488 | 13:36 |
opendevreview | Takashi Kajinami proposed openstack/project-config master: Retire PowerVMStacker SIG: End Project Gating https://review.opendev.org/c/openstack/project-config/+/909535 | 13:46 |
opendevreview | Takashi Kajinami proposed openstack/project-config master: Retire PowerVMStacker SIG: Remove Project from Infrastructure Systems https://review.opendev.org/c/openstack/project-config/+/909584 | 14:06 |
*** dhill is now known as Guest338 | 15:02 | |
clarkb | if anyone ever wonders what "speech-dispatcher-dummy" is in your pavucontrol playback list it is apparently a screen reader thing in gnome/xfce | 15:37 |
fungi | as i don't use fancy feature-rich desktop environments, i doubt i have that | 15:41 |
fungi | but good to know! | 15:41 |
clarkb | fungi: I'm already thinking of the possibilities. I could have my morning emails dictated to me while I drink tea! | 15:43 |
fungi | i'd spend too much time geeking out over which voicefont i wanted | 15:47 |
opendevreview | Merged openstack/project-config master: Retire PowerVMStacker SIG: End Project Gating https://review.opendev.org/c/openstack/project-config/+/909535 | 16:04 |
JayF | I am working on moving from gnome->sway (i3 except wayland-flavored) | 16:21 |
JayF | it's amazing how simplifying environments can help you more easily direct your focus where you want it | 16:21 |
fungi | still using ratpoison, myself | 16:24 |
clarkb | ya I use xmonad with xfce. xfce is primarily there so I don't have to micro manage things like fonts and batteries | 16:24 |
JayF | fungi: sounds to me like ratpoison and sway are cousins, at least :D | 16:30 |
fungi | seems similar, yep | 16:31 |
mnaser | I don't assume there is a large particular interest in using OpenDev's Zuul for GitHub projects? | 18:20 |
mnaser | I know it's been brought up but we've got a somewhat vocal community that wants to use the github workflow but use zuul for testing and what not | 18:21 |
clarkb | mnaser: no, we did a small poc with kata and found that we end up in a culture clash where people don't want to debug anything and just want everythign to work for them but we aren't github experts and we end up at an impasse | 18:21 |
mnaser | clarkb: but say if someone shows up and actually sorts out what's needed, or is it kindof a case closed and i should spin up my own instance | 18:22 |
clarkb | I expect the current admins are unlikely to want to reopen that can of worms | 18:22 |
mnaser | fair enough | 18:22 |
mnaser | guess i'll have to stand up an instance :< | 18:23 |
clarkb | github as a tool is difficult to integrate with in a reliable manner without significant investment | 18:23 |
mnaser | right, i figured we were gonna do that investment anyways | 18:23 |
mnaser | better than doing that AND operating zuul | 18:23 |
clarkb | just setting up appropriate acls is a major problem. Then you're dealing with rate limits and weird behaviors like doing PRs from the same repo to iself whcih lead to branch deletions whcih break things | 18:24 |
mnaser | yeah i dont expect to be getting much support for it | 18:24 |
mnaser | mostly here's your project-config and glhf | 18:24 |
mnaser | but of course that's half the story if there are rate limits or whatever that will need admin assistance for logs | 18:25 |
clarkb | unfortunately that isn't what we need because you can't debug the issues in that situation | 18:25 |
mnaser | yeah fair nuff | 18:25 |
mnaser | welp, off to deploying a zuul instance i guess | 18:25 |
fungi | mnaser: put another way, we collectively decided that the opendev collaboratory includes an integrated code review+project gating solution, which includes a zuul deployment to provide that project gating, but the zuul exists as part of that combination and not in service of doing code review outside the collaboratory | 18:26 |
fungi | i.e. we're not offering zuul-as-a-service, it's zuul+gerrit-as-a-service | 18:26 |
mnaser | that's what i've been under the assumption of, but i thought it doesn't hurt to ask | 18:26 |
clarkb | what we can do and have tried to make work is third party CI | 18:32 |
mnaser | so no gating but just jobs? | 18:32 |
clarkb | the main gotcha for that right now is I think our current acl set on the zuul application in github assumed we might want to merge PRs so we need to prune that down to make people more comfortable | 18:32 |
clarkb | mnaser: yes and specifically jobs that have an intersection between projects we host and projects on github | 18:33 |
mnaser | yeah understandable | 18:33 |
clarkb | mnaser: one example historically not sure if still in use is the openstack ansible modules doing testing and reporting to ansible PRs | 18:33 |
clarkb | but in theory we could do similar with eventlet and openstack or ansible and zuul though neither of those are a thing today | 18:33 |
fungi | also jobs for projects hosted in opendev consuming source code from other hosting locations (including github) | 18:34 |
mnaser | yeah in this case since its the reverse it doesnt really help | 18:34 |
fungi | the other gotchas with either acting as a third-party ci to or consuming projects hosted elsewhere is that we can't safely consume zuul configuration in repositories that aren't gated by our zuul, so there inevitably ends up being a config project in gerrit where the job/project-pipeline stuff resides | 18:36 |
clarkb | fungi: I think we were hoping to push that into the "hosting" project on the openstack side | 18:38 |
clarkb | you should be able to add the project to the tenant config then your hosting project can define the jobs that use it. However, if you want the github side to trigger then ya we need it in a config project | 18:38 |
fungi | yeah, though in cases like pyca/cryptography's arm64 wheel builds, there was no clear place to stick it | 18:39 |
clarkb | speaking of I think we can turn that off now? I don't think it has been used in a bit | 18:40 |
clarkb | another example of how trying to work with github fails. They turn things off and say nothing ... | 18:40 |
JayF | I can ask the cryptography folks if you want | 19:50 |
clarkb | JayF: I don't think it hurts, but it has also been long enough that we can probably just clean stuff up on our side | 19:53 |
clarkb | and if they are able to get arm64 wheels built elsewhere then the utility we provide is limited | 19:53 |
fungi | the impression i got was they dropped our zuul's access the moment github actions grew arm64 support | 19:54 |
clarkb | ah that could be | 19:55 |
clarkb | which is also likely a simplification for them | 19:56 |
JayF | confirmed out of use | 20:11 |
tonyb | Sorry I missed the team meeting earlier | 20:14 |
fungi | gotta sleep sometime | 20:16 |
fungi | clarkb: so skimming our lodgeit source, it wants to use pillow to generate the captcha images. wasn't there a recent backward-incompatible major release of pillow and/or related libs? | 21:13 |
clarkb | I'm not sure but it wouldn't surprise me. Server logs may have tracebacks that give us a clue | 21:13 |
fungi | we don't seem to cap it in requirements.txt | 21:13 |
clarkb | for context diablo_rojo discovered that the captcha is broken on paste so you can't post things that need a captcha to pass | 21:14 |
fungi | `docker-compose logs lodgeit` is quite slow | 21:15 |
clarkb | it will be logs from the beignning of the container starting | 21:15 |
clarkb | this is one of the advantages of the syslogging if we have it for that service | 21:15 |
clarkb | I need ot eat lunch now though. And then do the service coordinator election thing | 21:16 |
fungi | text_size = self.font.getsize(self.text) | 21:18 |
fungi | AttributeError: 'FreeTypeFont' object has no attribute 'getsize' | 21:18 |
fungi | looks familiar | 21:19 |
fungi | being raised a few layers deep from Captcha().get_response(set_cookie=True) | 21:20 |
fungi | looks like we want pillow<10 or switch to calling getsize() on a font face instead | 21:23 |
fungi | or switch to the getbbox or getlength methods | 21:24 |
fungi | looking around i see several of these approaches used... any preference? | 21:27 |
fungi | i don't think it's really passing untrusted user input to pillow, so my security concerns with pinning it are minimal | 21:28 |
Clark[m] | Ya the input isn't from the user it's randomly generated words from the service aiui | 21:29 |
fungi | but on the other hand it could be a fairly simple patch to fix the call for pillow v10, or it could just be the tip of a much larger iceberg | 21:29 |
Clark[m] | I think it is figuring out sizes in order to make them fit in the final image? | 21:31 |
Clark[m] | Not sure which alternative maps most closely to that | 21:31 |
fungi | like here's someone who did fix it quite trivially, so maybe if it's our only issue with new pillow? https://github.com/Belval/TextRecognitionDataGenerator/pull/328/files | 21:31 |
Clark[m] | Could be. Can use a held node to test. Mine even maybe | 21:39 |
Clark[m] | That shouldn't impact the db work | 21:39 |
fungi | Clark[m]: i hacked it onto the server since it was already broken, seems like switching to getbbox worked, test to see if it's good for you and i'll propose the change | 21:44 |
opendevreview | James E. Blair proposed zuul/zuul-jobs master: prepare-workspace-git: Add ability to define synced pojects https://review.opendev.org/c/zuul/zuul-jobs/+/887917 | 21:46 |
clarkb | fungi: ack testing now | 21:47 |
clarkb | fungi: I get a captcha now but the text isn't very readable and it is shifted into the bottom right of the captcha | 21:48 |
clarkb | ok failed that captcha then it made a new one that I was able to pass | 21:48 |
clarkb | i think this is an improvement and we should oprobably merge it and can always improve later | 21:49 |
opendevreview | Jeremy Stanley proposed opendev/lodgeit master: Support Pillow v10 https://review.opendev.org/c/opendev/lodgeit/+/909618 | 21:49 |
fungi | yeah, i mean, those captchas are terrible, but they always were | 21:50 |
clarkb | indeed. And it is definitely better than the error we had previously | 21:50 |
clarkb | snowman ☃ in my test paste server doesn't seem to work but it does in prod | 22:00 |
clarkb | interesting | 22:00 |
clarkb | sqlalchemy.exc.DataError: (pymysql.err.DataError) (1366, "Incorrect string value: '\\xE2\\x98\\x83' for column `lodgeit`.`pastes`.`code` at row 1") | 22:02 |
clarkb | I wonder if we manually changed the db datatypes in prod many moons ago and lodgeit doesn't properly set that up on a new instance | 22:04 |
clarkb | ya the test db is set to latin1 | 22:06 |
clarkb | the default is still latin1 in prod but the table seems to have set utf8 explicitly | 22:08 |
clarkb | I'm going to ignore that for now | 22:09 |
clarkb | I have two pastes of only latin1 content on the test server. One short trivial one and one a bit longer. I'm going to try the db upgrade process now | 22:11 |
clarkb | https://paste.opendev.org/show/bWhZZH97IMLv44eeiWlB/ this is the result. I think it is happy from what I have seen so far | 22:18 |
clarkb | It does look like a temporary server is started that will complain about type deltas on system tables (this server is started to do the backup I think). Then that temp server is stopped and the upgrade process si performed | 22:19 |
clarkb | so the errors are ok? | 22:19 |
clarkb | the upgrade process for those same tables reports OK later | 22:20 |
clarkb | also I added the env var flag to do the upgrade and bumped the image version at the asme time so we don't need to step those through and can use a single change for both updates | 22:20 |
clarkb | I'll update the change to do that. I think we can even let automated deployments do the updates for us if we awnt or we can do it by hand then merge the change to reflect the new status. We can discuss thati n review | 22:24 |
opendevreview | Clark Boylan proposed opendev/system-config master: Upgrade the lodgeit mariadb to 10.11 https://review.opendev.org/c/opendev/system-config/+/909471 | 22:28 |
fungi | sounds great, thanks! | 22:30 |
clarkb | I wonder if "user tables won't be touched" implies it can do something like an automatic conversion from latin1 to utf8 | 22:31 |
clarkb | that said I think leaving the actual db tables alone is what we want here | 22:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!