[08:03:06] ryankemper: looking at https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/refs/heads/production/modules/systemd/manifests/unit.pp#47 it seems that the categories unit we deployed (and rolled back) yesterday was trying to deploy an override and not a base unit. I don't entirely understand that behaviour. Friday isn't the right time to experiment in production, but maybe next week. [08:03:23] I've created https://gerrit.wikimedia.org/r/c/operations/puppet/+/950136 as a follow up [09:31:29] weekly update published: https://wikitech.wikimedia.org/wiki/Search_Platform/Weekly_Updates/2023-08-18 [09:34:55] pfischer/inflatador: if you have time one of these days, could you do a pass on https://wikitech.wikimedia.org/wiki/Search/Update_Pipeline#Decision_records and see if we can add context to some of our decisions? [09:35:59] Sure, I already added the proposal for kafka, but I have not gone over the existing records. [09:48:01] pfischer: thanks! [09:53:02] lunch! [14:11:17] ~~\o [15:00:50] Sorry I'm late! Medical issue [15:03:22] inflatador: I hope you're fine, or getting fine! We'll start without you [15:04:32] I'm OK, but it was the kind of thing you need to get checked immediately [15:16:04] do we have any reason to release the streaming updater via maven? Basically I'm pondering at the moment CI actions for releasing new versions of the docker image and wondering if it should do anything with maven [15:16:34] similarly wondering if should try and reuse the maven release plugin's ability to bump version numbers, but not sure if we can use that without using the rest of the release process [15:20:31] ebernhardson: if you just want to update versions, you could use https://www.mojohaus.org/versions/versions-maven-plugin/index.html [15:20:58] I do see value in having a similar release process for all projects. [15:21:16] That's probably a question for our new JVM Language Stewards! [15:21:24] yea, i was also wondering where the ci action definitions go :) Maybe we need a search-platform/workflow_utils kind of repo. [15:21:56] versions plugin looks nifty, that could probably work [15:47:35] ebernhardson: would you keep the SNAPSHOT vs RELEASE in your context? If you do, I don't see a reason to not use the release plugin. And if you don't then I do have a few issues :) [15:48:17] gehel: yea i expect we would use SNAPSHOT simply to keep things "normal" java, no need to vary [15:48:53] i suppose the reason to not release to a maven repo is that we never intend to read it from the maven repo. But if it's simply for consistency i suppose thats fine [15:49:42] i guess the docker image build could change, so far I've been assuming we would keep the existing image building that david setup and i was mostly looking at CI actions that would create tags and shuffle version numbers around before running the existing image build against the tagged branch [15:49:47] s/tagged branch/tagged release/ [15:54:38] actually i think i'd rather not change the image build much (the alternate build would be to pull a far jar from archiva). By having the image build package the fat jar itself from the repo test builds into a local minikube should be simpler [15:54:48] s/far jar/fat jar/ [15:57:10] https://dmp.fabric8.io/ (but this is probably borderline heretic) [15:57:41] weekend time! [15:57:49] :) enjoy [17:13:10] hmm, while testing (in a new test repo) how a gitlab ci release with maven release plugin would work, i'm finding that even though it's only triggering against the main branch gitlab still checks out a hash and leaves it in detached HEAD state [17:13:27] gehel added context to https://wikitech.wikimedia.org/wiki/Search/Update_Pipeline#Decision_records as you requested...LMK if I need to add any more [17:13:32] release plugin doesn't like working from detached HEAD...i wonder if there is a good reason to not just checkout the expected branch [17:32:23] ebernhardson: regarding version bumps w/o maven-release-plugin: there seems to be a workaround by combining build-helper and versions plugin [17:33:45] In my side project use continuous deployment, so I have a 999-SNAPSHOT as version in my pom but the released docker containers are simply tagged with the commit hash. [17:34:26] No external repository is involved in the deployment process. [17:35:50] BTW: did you see Giuseppe’s response to https://phabricator.wikimedia.org/T341625 ? I added a chart, but I’m not sure, if I got the cross-DC calls to MW-API correctly. [17:36:49] pfischer: yea i saw, i need to work up a response. I think part of the confusion is that my response is mixing up how much duplication there is for separate clusters vs kafka stretch [17:37:47] if each datacenter is independent, then fetching early doesn't really change the consistency between eqiad and codfw, only if they were to read the same events via stretch [17:39:16] i'll have to ponder his comments re: updating on refresh. It's something we've always done, and i would feel awkward about being unable to find things, but awkard isn't a strong justification :) [17:41:02] for the releases plugin vs build-helper and versions plugin, i guess i'm unsure. We could certainly make every commit to master package up an image [20:43:14] errand, back in ~20 [20:58:10] closer! now it pushes to gitlab but archiva credentials are missing...wonder if we have examples yet of pushing to archiva from gitlab [21:08:33] * ebernhardson still sorta wonders if it's worth figuring that part out, since we don't intend to use it. In theory fully configured would sign things and upload to central and archiva [21:12:19] been back [23:39:15] heading out