| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: Stop using deprecated pkg_resources API https://review.opendev.org/c/openstack/diskimage-builder/+/907691 | 03:23 |
|---|---|---|
| tkajinam | JayF, That deprecation is a huge killing for us :-( | 03:35 |
| tkajinam | I found it's being replaced in a few libraries which I was looking into during the weekend but I wasn't aware that was because of actual deprecation... | 03:36 |
| JayF | I mean, it is what it is :/ I only did it because Sam from gentoo community pointed it out | 03:36 |
| JayF | and apparently that is the stdlib solution (the pypi library is the stdlib solution before it goes into stdlib) | 03:36 |
| JayF | I suspect there are more elegant ways, but I'm interested to see if that works ... if it does we're probably fine (from dib standpoint) | 03:37 |
| tkajinam | yeah | 03:39 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: Stop using deprecated pkg_resources API https://review.opendev.org/c/openstack/diskimage-builder/+/907691 | 03:49 |
| ykarel | frickler, so now not seeing Disk quota error but it still fails | 05:24 |
| ykarel | rsync error: error in socket IO (code 10) at io.c(801) [receiver=3.1.3] | 05:24 |
| ykarel | rsync: connection unexpectedly closed (633901 bytes received so far) [generator] | 05:24 |
| ykarel | errors around altimages, seems these are new content and we need to skip these ? | 05:36 |
| ykarel | http://mirror.iad.rax.opendev.org/centos-stream/SIGs/9-stream/ vs mirror.rackspace.com/centos-stream/SIGs/9-stream/ | 05:36 |
| opendevreview | yatin proposed opendev/system-config master: [centos-stream] Exclude altimages from SIGs https://review.opendev.org/c/opendev/system-config/+/907703 | 05:58 |
| ykarel | pushed ^ | 05:58 |
| *** ralonsoh_ is now known as ralonsoh | 08:56 | |
| opendevreview | Elod Illes proposed openstack/project-config master: [relmgt] Update reno when cutting unmaintained branch https://review.opendev.org/c/openstack/project-config/+/907626 | 10:11 |
| opendevreview | Merged openstack/project-config master: [relmgt] Update reno when cutting unmaintained branch https://review.opendev.org/c/openstack/project-config/+/907626 | 13:00 |
| opendevreview | Merged opendev/system-config master: [centos-stream] Exclude altimages from SIGs https://review.opendev.org/c/opendev/system-config/+/907703 | 13:22 |
| fungi | summarizing discussion from #openstack-infra, there was a launchpad and ubuntuone sso outage for a while (not sure how long) that cleared up a few minutes ago. if anyone was having trouble getting to launchpad.net or logging into things with login.ubuntu.com, please try again and hopefully things are back to normal | 14:58 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: DNM: CI science around gentoo fixes https://review.opendev.org/c/openstack/diskimage-builder/+/907757 | 15:21 |
| fungi | for SCIENCE! | 15:21 |
| JayF | Sam is trying to get it working | 15:22 |
| JayF | my task is to answer random questions and push his patches to gerrit lol | 15:22 |
| JayF | Gentoo *needs* a tool like DIB something fierce, and I suspect once we get it working, it'll be off to the races to add it around the docs there, so lots of interest in keeping it going | 15:22 |
| * JayF spent the weekend manually doing a dib-style stage4 for a cheap ARM chromebook he got last week | 15:23 | |
| fungi | very cool! | 15:26 |
| elibrokeit | tkajinam: for what it's worth, pkg_resources is going away no time soon at all, and quite possibly even "never". It has a few decades worth of people using it in pypi libraries that will never be updated and whose authors may be retired from the internet or dead | 15:28 |
| elibrokeit | but pkg_resources is slow and non-performant anyways, and adds a very odd install_requires = setuptools, and will of course produce deprecation warnings | 15:29 |
| clarkb | fwiw the thing that replaces pkg_resources is slower on python2 (less of a concern for many users) and it isn't much faster on python3 (but at least not slower) | 16:12 |
| clarkb | unfortunately the underlying issues that made pkg_resources are somewhat inherent to the problem space | 16:12 |
| clarkb | (it has to scan the disk) | 16:12 |
| elibrokeit | clarkb: it's interesting that it would be slower *anywhere* since the big difference is supposed to be that pkg_resources scans every single package no matter what, and the replacement only scans the ones matching the filesystem glob you asked for | 17:30 |
| elibrokeit | hmm, I suppose plugin entrypoints do require reading most things | 17:31 |
| clarkb | elibrokeit: yes I guess specifically for using entrypoints | 17:31 |
| elibrokeit | getting metadata for a single package became *much* faster as it wasn't using the original pkg_resources functionality to its full potential | 17:31 |
| fungi | elibrokeit: but the primary painpoint we had with projects using pkg_resources was where we already needed to scan every installed package to find entrypoints for plugins (e.g. stevedore) | 17:33 |
| fungi | so most of the likely speedups are going to be some variety of caching, and then you get into the usual cache invalidation challenges | 17:33 |
| clarkb | ya I don't think importlib added any caching or package tracking db | 17:34 |
| elibrokeit | yeah I guess the argument for moving away from pkg_resources is, in this case, mostly seen by upstream wanting to deprecate it because many of their users are better served elsewhere | 17:34 |
| elibrokeit | and therefore -> deprecation, somewhat compelling reason to start examining alternatives | 17:34 |
| fungi | correct, and us as developers/maintainers not wanting to have to explain the constant deprecation warnings to our end users | 17:35 |
| elibrokeit | also somewhat relevant here: https://discuss.python.org/t/deprecating-importlib-resources-legacy-api/11386/29 | 17:35 |
| elibrokeit | (speaking of deprecations) | 17:35 |
| fungi | yeah, i remember when that first came up as well | 17:38 |
| elibrokeit | well, that last comment I linked to has an offer to maintain the functional API, including a "FWIW I find it much friendlier" | 17:39 |
| elibrokeit | so... fingers crossed that it gets restored in the 3.13 alphas? | 17:40 |
| clarkb | one way to make it faster would be to put entrpoint info in their targets so that when you go to import those paths they are discoverable directly without scanning the whole world | 17:40 |
| clarkb | instead entrypoints are tracked on the packages that install them not the target | 17:41 |
| fungi | not sure how that would work, since wheels just get unpacked in-place and can't install anything outside their own trees | 17:41 |
| elibrokeit | depends on your architecture for registering plugins | 17:41 |
| elibrokeit | you don't have to use metadata for this | 17:41 |
| clarkb | fungi: you would have to add metadata to the extracted wheel | 17:41 |
| clarkb | I'm sure there are good reasons they don't do this | 17:42 |
| fungi | right, and something would have to check the metadata of every "extracted wheel" (install package), right? | 17:42 |
| clarkb | fungi: ya when you install you would reconcile it | 17:42 |
| fungi | i thought that's what the entrypoints already were | 17:42 |
| clarkb | fungi: no entrypoints are metadata on the source side not the target side | 17:42 |
| clarkb | whcih means when you want to load entrypoint foo.bar.entrypoint you have to scan the entire world to see if anyone defines an entrypoint for that path | 17:43 |
| clarkb | this is why pkg_resources is slow | 17:43 |
| fungi | i guess i'm misunderstanding what you mean by source and target here. not sdist vs installed wheel? | 17:43 |
| clarkb | fungi: no location of the entrypoint code vs its import path | 17:43 |
| elibrokeit | you just use namespace packages | 17:43 |
| clarkb | elibrokeit: those don't work for other reasons | 17:44 |
| elibrokeit | foo_plugins/ and expect people to stick a name.py | 17:44 |
| clarkb | oh I see not actual namepsaces packages in python land | 17:44 |
| clarkb | but ya | 17:44 |
| fungi | clarkb: but that's different for each plugin, right? so you still have to scan all the packages' metadata to find them, like with the entrypoint metadata | 17:44 |
| clarkb | fungi: but only at install time | 17:44 |
| clarkb | every time you do a pip install or remove to add or remove code from the system you wouldh ave to reconcile the metadata | 17:45 |
| fungi | clarkb: "at install time" is the problem. there is no arbitrary code run at install time, wheels are just unpacked in-place unceremoniously | 17:45 |
| clarkb | then runtime can just import | 17:45 |
| clarkb | fungi: yes pip would have to do it | 17:45 |
| fungi | okay, i see what you mean, add a feature to pip | 17:45 |
| fungi | (and all other installers, so start with a packaging pep) | 17:45 |
| fungi | pretty sure i can predict how that discussion will play out. pip maintainers are unlikely to see the benefit, pep delegates are unlikely to want to accept the proposal without a reference implementation in an installer already, so you might have luck convincing one of the other package installers to be a "first mover" for that feature, but if you want to keep using pip you're not going to get | 17:47 |
| fungi | the benefits for a very long time | 17:47 |
| elibrokeit | clarkb: no I literally mean namespace packages in python land | 17:49 |
| elibrokeit | every package with a plugin would install to the foo_plugins/ namespace | 17:49 |
| elibrokeit | and you pick up plugins like this: | 17:49 |
| clarkb | ya I mean I'm not advocating for any of this | 17:50 |
| elibrokeit | import foo_plugins; all_plugins = [m.name for m in pkgutil.iter_modules(foo_plugins.__path__, foo_plugins.__name__+'.')] | 17:50 |
| clarkb | I just htink that reconciling the links at install time and taking the hit at install time is better than taking the hit at runtime | 17:50 |
| elibrokeit | all_plugins is a list like ['foo_plugins.tech1', 'foo_plugins.tech2'] | 17:50 |
| elibrokeit | pkgutil just scans each foo_plugins/ directory on sys.path for importable namespace sub-modules | 17:51 |
| fungi | clarkb: the other area this touches on is that the python packaging community is slowing coming to the conclusion that python packages as we know them now are really only useful for installing libraries/dependencies, not for installing applications, and that to install an application (say openstackclient) you should use some other kind of packaging and installation | 17:52 |
| elibrokeit | ha | 17:52 |
| elibrokeit | I have been saying that for a long time, mostly in a dig at the python packaging community for not wanting to do anything else | 17:52 |
| fungi | which has been a lot of the recent pushback on proposals which would ease application deployment | 17:53 |
| elibrokeit | (because spoiler: setup.py install worked quite fine for this) | 17:53 |
| fungi | basically they're starting to consider these sorts of concerns "out of scope" for tools like pip | 17:53 |
| elibrokeit | fungi: https://github.com/pypa/packaging-problems/issues/576#issuecomment-1058464665 | 17:54 |
| elibrokeit | > Maybe I'm missing something, and historically people somehow used Python tools like distutils to install Unix system files. I don't think that was ever intended/supported use (I've heard a lot of Linux distro maintainers complaining that people should use the Linux management tools, not Python, to alter system-managed files) so there's no "modern way" of doing this, and if it was | 17:55 |
| elibrokeit | possible in the past then I guess sorry, it's no longer supported... | 17:55 |
| elibrokeit | I had some... comments on that fascinating take | 17:55 |
| elibrokeit | they seem to have been under the impression that it was NEVER possible | 17:55 |
| elibrokeit | not that they're starting to declare it out of scope with the new wheel based approach | 17:55 |
| fungi | precisely | 17:55 |
| elibrokeit | it took major effort and investment to make distutils / setuptools handle data files for unix directories correctly | 17:56 |
| elibrokeit | they *repealed* that effort and now don't realize that it ever worked? | 17:56 |
| fungi | they're suffering from a semi-recent and growing phenomenon in open source communities... the old guard have burned out or gone, and there was insufficient continuity to impart their history to those who came after | 17:58 |
| fungi | see also: chesterton's fence | 17:58 |
| clarkb | maybe someone will write a cargo plugin for python packaging | 17:58 |
| fungi | clarkb: the irony is, now, folks are convinced that python packaging and cpython distribution need to be redone to mimic cargo/rustup | 17:59 |
| fungi | and switch to vendoring everything like all good rust (and go) projects do | 17:59 |
| fungi | because wcpgw | 17:59 |
| fungi | also distros are unnecessary now that we have containers. because, um. well just because, right? | 18:00 |
| clarkb | fwiw the cargo user expereicen is really good. I'm not sure that necessarily requires static linking though | 18:03 |
| clarkb | I think the things that make it good are having one way to package things rather than a million with a bunch of arbitrary code mixed in, an init method that gets you a working start point | 18:03 |
| fungi | it's also a very different language with a very different usage model | 18:03 |
| fungi | oh, and yes dynamic linking is still apparently a challenge for rust, based on recent discussion on the debian-devel ml | 18:04 |
| fungi | supposedly the rust maintainers don't want to commit to a stable abi, is the root of the problem | 18:05 |
| elibrokeit | there's a crABI proposal but it appears to have lost steam | 18:09 |
| elibrokeit | I don't think the cargo user experience is very good at all though | 18:09 |
| elibrokeit | people superficially think it is really good because thus far, cargo has been able to get away with a userbase that only wants to build executables and sometimes libraries, in a mostly-rust codebase with occasional bits of C/C++ wrapped up in a rust API as a crate dependency | 18:11 |
| clarkb | I think the key bit is consistency | 18:11 |
| elibrokeit | any project that wants to do something as trivial as create a manpage by converting a markdown/rST/asciidoc file to roff, learns instantaneously, on the spot, that it's hopeless | 18:11 |
| clarkb | yes it is pluggable but for the most part everyone is using the same tool and it does the basic things one way and everyone does it that way | 18:12 |
| clarkb | this is where python really suffers | 18:12 |
| clarkb | there is too much choice and tribal knowledge | 18:12 |
| fungi | that's because rust is still relatively young | 18:12 |
| clarkb | ya that certainly helps | 18:12 |
| elibrokeit | pep 517 proposed to solve this problem, and only made it 50x worse... | 18:12 |
| elibrokeit | proliferation of build backends that are all just flit with slightly different config file names | 18:13 |
| clarkb | meanwhile you can't build a wheel with a custom build dir | 18:13 |
| fungi | it's already beginning to leak into other ecosystems. e.g., pyca/cryptography doing lots of stuff in a rust-based extension now | 18:13 |
| elibrokeit | cryptography shows exactly how well that works in mixed rust + !rust projects... | 18:15 |
| clarkb | infra-root: I have two gitea related changes queued up. The first is to update the db connection limit and the second is to upgrade gitea a minor release version up from where we are. I don't think the db update will auto restart the services (and I'm not sure we want it to). I'm happy to land these changes in either order and manually restart things gracefully for the db change. | 18:15 |
| clarkb | That way we don't conflate things if there are issues. Any opinions on how we want to approach these two chagnes? | 18:15 |
| fungi | and the resulting madness that is https://packages.debian.org/source/sid/python-cryptography | 18:15 |
| elibrokeit | use setuptools, setuptools-rust, and a set of eclectic and custom toml settings in pyproject.toml | 18:15 |
| fungi | from a distribution's point of view, any python-based project that uses cryptography now has just opted into a build dependency on a dozen rust libs | 18:16 |
| fungi | and upstream cpython is busily evicting the last remnants of cryptographic functions from the stdlib owing to the increase in pyca/cryptography's popularity | 18:17 |
| fungi | so soon (if not already) that's basically anything with cryptographic needs written in python | 18:18 |
| clarkb | I think those issues are orthogonal to the developer experience using cargo though. My point is I think the lessons aren't necessarily "static linking good" but instead "make getting started easy, don't make users/developers understand super esoteric things riddled across 20 years of docs and 3 deprecated libs just to install a simple python tool, and act consistently when making | 18:18 |
| clarkb | decisions (dep solving is good)) | 18:18 |
| clarkb | python has improved some of this and some of it is just as bad as ever | 18:19 |
| fungi | and some of it has gotten worse | 18:19 |
| clarkb | the new warning about not specifying the distribution location or whatever it complains about in all our repos now is a good example of this | 18:19 |
| clarkb | the docs on that don't help me and I'm a person that has dealt with python packaging for 15 years | 18:19 |
| elibrokeit | I think the answer to that was honestly just either saying "use flit instead of setuptools" or campaigning for people to use setup.cfg instead of setup.py | 18:19 |
| elibrokeit | but they decided the big takeaway was that people felt stifled and wanted more choice :D | 18:20 |
| elibrokeit | not specifying the distribution location? | 18:20 |
| clarkb | bsically you're left with copying the example of the day for a new project, editing it until you think it works then in a year or two giving up on being up to date any longer | 18:20 |
| fungi | pbr (distutils2 really) solved that long ago, it's unfortunate that it took setuptools 10 years to copy the setup.cfg idea, and by then pyproject.toml was basically already coming into existence in parallel | 18:21 |
| clarkb | elibrokeit: setuptools wants you to specify the location of the package explicitly or something like that | 18:21 |
| clarkb | elibrokeit: when you don't (which many packages that are older than a couple years don't) you get a warning with a poitner to some docs. If you read the docs it doesn't explain anything just tells you to do X or Y but without background for understanding | 18:21 |
| JayF | clarkb: ++++++++++ to the "the docs don't help me and I've been working with python packaging for years and years" | 18:21 |
| JayF | Lots of problems I didn't know exist getting solved at the expense of re-causing problems we had worked around | 18:22 |
| elibrokeit | ah, that would be this change: https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#auto-discovery | 18:23 |
| clarkb | compared to cargo you do a cargo init and you're off to the races | 18:23 |
| JayF | fungi: In some ways, elibrokeit has acted as a bridge preventing some of that ... burnout/ageout-caused-brain-drain in some communities. New generation of developer making a point to understand why things are the way they are before going about willy-nilly changing things | 18:24 |
| JayF | elibrokeit: ^ that may be the nicest thing I'll ever say about you, go get it framed :D | 18:24 |
| JayF | lol | 18:24 |
| elibrokeit | :D | 18:24 |
| *** mtreinish_ is now known as mtreinish | 18:24 | |
| clarkb | that said I do apprecite it is difficult to pull back from an arbitrary code execution packaging system into something more rigid and well defined | 18:25 |
| clarkb | and they have been making improvements. | 18:25 |
| elibrokeit | I think the bulk of that work really came from the addition of setup.cfg based config | 18:26 |
| JayF | Yeah, I see most of this as people trying to reduce the scope of the project they work on | 18:26 |
| JayF | Most of us know the pain of working on a project with huge scope with not enough people to run it :) | 18:26 |
| elibrokeit | I am actually a bit confused by the automatic discovery thing | 18:26 |
| JayF | and just lots of evidence there's not enough context to know what scope to keep | 18:27 |
| elibrokeit | it seems to be tied to using pyproject.toml, but also tied to... flit envy? | 18:27 |
| elibrokeit | I think they want to make setuptools as simple as it is when using flit | 18:27 |
| clarkb | elibrokeit: yes the discovery thing is what I | 18:27 |
| elibrokeit | so that you can have a blank project with no config and it automatically detects stuff for you | 18:27 |
| clarkb | er | 18:27 |
| clarkb | that is what I'm thinking of | 18:27 |
| clarkb | and yes it is confusing | 18:27 |
| clarkb | I think the issue we have is that the dir structure is such that auto discovery has to make a guess and the current guess it makes is working for us | 18:28 |
| clarkb | what isn't clear to me is what it wants us to supply for explicit discovery inputs | 18:28 |
| JayF | elibrokeit: this is very akin to the GUI vs CLI chat in -chat today. Typically that kinda autodiscovery is going to make the simpler case better at the expense of the complex cases. | 18:28 |
| elibrokeit | it is *supposed* to not try that nonsense, if you already used packages=find: or packages=list,of,packages | 18:28 |
| clarkb | looking at the two gitea changes only the db conn limit bump has multiple +2s. I'll go ahead and approve that one now then and plan to do the restarts necessary to pick that up after it applies | 18:34 |
| fungi | did i miss reviewing one? | 18:34 |
| clarkb | no you're on both | 18:35 |
| clarkb | one thing I noticed is that the mm3 mysqld conf uses a 99- prefix | 18:35 |
| clarkb | any idea if I dno't think this is necessary, but maybe I should update the change I wrote for gitea to do the same thing? | 18:36 |
| clarkb | ya includedir says it reads them in alphabetical order | 18:36 |
| clarkb | so not strictly necessary but might be a good idea? | 18:36 |
| fungi | clarkb: it's only relevant if there ends up being more than one config fragment in the same directory adjusting the same value | 18:37 |
| clarkb | ya and there are no other files in that dir currently | 18:37 |
| fungi | but for https://review.opendev.org/907141 i did copy that behavior just for added surety | 18:37 |
| clarkb | I'll respin it for consistency but maybe not bother with full fledged rereview? | 18:37 |
| fungi | sure | 18:38 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Increase gitea db connection limit https://review.opendev.org/c/opendev/system-config/+/907500 | 18:40 |
| clarkb | done | 18:40 |
| clarkb | I'll approve that if it passes testing | 18:40 |
| clarkb | fungi: I left a small note on your question on the keycloak change. Otherwise that change lgtm | 18:42 |
| fungi | thanks! | 18:44 |
| fungi | and yeah, i guess we proved that the configuration works, now it's just a matter of figuring out the appropriate envvar names for that | 18:45 |
| clarkb | fungi: system-config/playbooks/roles/gitea/tasks/main.yaml has an example | 18:47 |
| clarkb | at the end of the file | 18:47 |
| fungi | clarkb: oh, i also misunderstood where you meant and thought you were saying to keep it out of the command string in the docker-compose file, which may also be important? | 18:49 |
| fungi | i suppose that might also get logged or appear in /proc | 18:50 |
| fungi | er, well, envvars also appear in /proc but might show up in process listings i mean | 18:51 |
| clarkb | fungi: my main concern is cron sending email with that content in it. Not an issue here but that is why I chose that form for gitea and other places | 18:52 |
| fungi | yeah, makes sense. as for the test itself, would it be better with a targeted query like the example in my comment? | 18:52 |
| fungi | with the envvar substitution of course | 18:53 |
| clarkb | I don't think it is functionaly different since both check for db contents | 18:53 |
| clarkb | and maybe I misunderstood the initial question | 18:53 |
| clarkb | ya I think I did. I thought you were asking if we should use mysql on the host vs docker. Now realize its mysqldump + grep vs a query | 18:53 |
| clarkb | either are fine I think | 18:53 |
| fungi | instead of doing a mysqldump and checking the massive returned string for a specific substring, using a specific sql query to just return the data we're interested in looking for | 18:54 |
| fungi | i simply didn't want to respin the change to adjust that one test unless others thought it was a good idea. if i'm updating it anyway for the envvar then i can also switch to an sql query while i'm at it | 18:54 |
| clarkb | I think both are fine and not worth a respin. | 18:56 |
| fungi | clarkb: as for the docker-compose file, what's your opinion on the --db-password={{ keycloak_db_password }} templating for the container command parameters list? | 18:56 |
| clarkb | ya I guess the issue there is ps will show it. But still not an issue for cron + email | 18:56 |
| clarkb | did we determine if the env vars would work? | 18:56 |
| fungi | i can see an argument for figuring out what the envvar equivalent is so that the raw password string for the database account isn't in the process list | 18:56 |
| clarkb | ya I think that would be prefereable if we can figure that out | 18:56 |
| fungi | i'll look and see if i can figure it out | 18:57 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Upgrade to Keycloak 23.0 https://review.opendev.org/c/opendev/system-config/+/907141 | 19:07 |
| fungi | looks like the launchpad outage is still affecting their ppa system: https://zuul.opendev.org/t/openstack/build/f74bc0d228d0444a8211e98b378297c2 | 19:26 |
| fungi | "failed to fetch PPA information, error was: HTTP Error 503: Service Unavailable" | 19:26 |
| clarkb | why does the mirror job run for 907141? Maybe due to the group and host var updates? | 19:29 |
| clarkb | we might be able to edit the file list for the job(s) and make that better | 19:29 |
| fungi | also that's the arm64 version of the job specifically | 19:30 |
| fungi | but the amd64 version is probably running too, i haven't looked | 19:31 |
| clarkb | they match - roles/ | 19:32 |
| clarkb | I don't think that is necessary | 19:32 |
| clarkb | I'll push a change to remove that line | 19:32 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Don't run mirror jobs when roles/ updates https://review.opendev.org/c/opendev/system-config/+/907902 | 19:34 |
| clarkb | etherpad just made a new release that modifies how plugins install | 19:51 |
| clarkb | we'll have to investigate if that impacts our image building | 19:51 |
| fungi | ppa outage is impacting system-config-run-base and other jobs too https://zuul.opendev.org/t/openstack/build/6e300dab7a914a51a63261ea2f1b0ee6 | 20:03 |
| fungi | due to the "ensure-pip: Install backport pip" task | 20:04 |
| fungi | which we'll be able to drop when we're free of xenial, at least | 20:04 |
| clarkb | ya it hit my gitea change as well | 20:05 |
| fungi | that's where i noticed it, actually | 20:06 |
| fungi | anyway, looks like the DB_PASSWORD envvar isn't plumbed through according to https://zuul.opendev.org/t/openstack/build/013849b13a0b47fa9b6564a6e8c2d15f/log/keycloak99.opendev.org/containers/docker-keycloak.log#267 | 20:09 |
| fungi | i'll try KC_DB_PASSWORD to see if it's any better | 20:09 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Upgrade to Keycloak 23.0 https://review.opendev.org/c/opendev/system-config/+/907141 | 20:10 |
| fungi | yeah, i should have remembered i have a held node i could just try it on | 20:19 |
| fungi | but also i just realized there's still an ansible task in there unnecessarily creating /var/log/keycloak that isn't used for anything | 20:20 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Upgrade to Keycloak 23.0 https://review.opendev.org/c/opendev/system-config/+/907141 | 20:21 |
| fungi | the only remaining unknown with that change is whether all the nested quoting to run an sql query from bash in docker via python will actually translate. i have quoting nested four layers deep | 20:23 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: Fix various minor issues with Gentoo; make CI pass https://review.opendev.org/c/openstack/diskimage-builder/+/907757 | 20:33 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: Re-enable voting on Gentoo DIB CI job https://review.opendev.org/c/openstack/diskimage-builder/+/907904 | 20:33 |
| *** dasm is now known as Guest1739 | 20:33 | |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: Fix various minor issues with Gentoo; make CI pass https://review.opendev.org/c/openstack/diskimage-builder/+/907757 | 20:35 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: Re-enable voting on Gentoo DIB CI job https://review.opendev.org/c/openstack/diskimage-builder/+/907904 | 20:35 |
| *** Guest1739 is now known as dasm | 20:38 | |
| fungi | well fudge, my db query isn't working as-written, likely something to do with escaped quotes | 20:43 |
| fungi | aha, it's because you can't nest escaped single quotes inside unescaped single quotes | 20:51 |
| fungi | you can nest escaped double quotes though | 20:51 |
| fungi | hope nobody needs a toothpick, i'll be using them all | 20:53 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Upgrade to Keycloak 23.0 https://review.opendev.org/c/opendev/system-config/+/907141 | 20:53 |
| fungi | also, the ppa outage seems to be resolved, for now anyway | 21:06 |
| clarkb | time to recheck all the things | 21:09 |
| fungi | argh, it looks like \\\" is getting turned into \\" not \" | 21:22 |
| fungi | maybe making it a raw string will help | 21:24 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Upgrade to Keycloak 23.0 https://review.opendev.org/c/opendev/system-config/+/907141 | 21:33 |
| clarkb | fungi: I think the gitea db change will pass testing this time (happy PPAs). I'll go ahead and approve it now | 21:46 |
| clarkb | and then I'll restart services once applied | 21:47 |
| fungi | cool | 21:49 |
| fungi | i'm around to help, just whipping up dinner real quick | 21:50 |
| clarkb | the main thing is the coordinatioj between the proxy and gitea services so that end users don't notice and gerrit replication doesn't fail | 21:51 |
| clarkb | oh I need to get a meeting agenda out too | 22:03 |
| clarkb | I think I can trim the inmotion/openmetal item. I'll add an ote about gitea things. Anything else to add or remove or edit? | 22:04 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: Fix various minor issues with Gentoo; make CI pass https://review.opendev.org/c/openstack/diskimage-builder/+/907757 | 22:06 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: Fix various minor issues with Gentoo; make CI pass https://review.opendev.org/c/openstack/diskimage-builder/+/907757 | 22:11 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Upgrade to Keycloak 23.0 https://review.opendev.org/c/opendev/system-config/+/907141 | 22:32 |
| clarkb | ok some initial meeting agenda edits are in | 22:37 |
| clarkb | I'll send it out at the end of my day giving others time to make edits if they want to | 22:37 |
| opendevreview | Merged opendev/system-config master: Increase gitea db connection limit https://review.opendev.org/c/opendev/system-config/+/907500 | 23:21 |
| clarkb | that appears to be in place on gitea09 now. i'll work on the restarts now | 23:30 |
| clarkb | gitea09 is done. I connected to mariadb and ran `select @@global.max_connections;` to verify the limit bumped (and it did) | 23:34 |
| clarkb | and now all six cluster members should be running with the updated db configs | 23:41 |
| clarkb | #status log Gracefully restarted the gitea cluster to pick up new database connection limit configs | 23:42 |
| opendevstatus | clarkb: finished logging | 23:42 |
| clarkb | last call on meeting agenda items. I'll send that out in about 10 minutes probably | 23:48 |
| fungi | gitea's still working for me | 23:53 |
| fungi | sorry, stepped away for a few just as it deployed | 23:54 |
| clarkb | no worries it all went well | 23:56 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Upgrade to Keycloak 23.0 https://review.opendev.org/c/opendev/system-config/+/907141 | 23:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!