[07:35:45] o/ [07:50:25] o/ [08:27:51] pfischer: good to see you're up! [08:47:55] dentist appointment, back as soon as I can [11:36:09] dcausse: Hi David! Thank you for your review of https://gerrit.wikimedia.org/r/c/search/glent/+/898799. I followed your comment, would you +2 or rather wait for ebernhardson:? I have to release and deploy the new version of glent before I can move on with airflow DAG consuming it. Otherwise the tests fail. [11:36:49] pfischer: hey, sure looking [12:27:04] dcausse: Thanks! Looking at https://integration.wikimedia.org/ci/job/search-glent-maven-java8-docker-site-publish/search/?q=search-glent&Jenkins-Crumb=81bad099453d580cab20975c2af37cb96b13139d8a6faf03b14fffbee0686047 - it looks like we do not have a release pipeline for glent. Is that correct? Do I have to release/deploy it manually? [12:27:38] pfischer: hm... it's very possible [12:29:15] pfischer: we seem to release it to the public maven repo so yes I think it's all manual (https://mvnrepository.com/artifact/org.wikimedia.search/glent) [12:29:36] if you don't have perms there I can try to release it [12:30:27] Okay, I’ll try. [12:34:11] Hm, distributionManagement suggests that we deploy to archiva, right? [12:53:14] pfischer: hm... for this one no it shouldn't or I'm missing something [12:55:06] perhaps it needs -Pdeploy-central to deploy there [12:55:22] e.g. ./mvnw -Pdeploy-central release:prepare && ./mvnw -Pdeploy-central release:perform [13:26:08] o/ [13:27:03] dcausse: Hm, AirFlow expects glent it on archiva (and not on the central-mirror) [13:30:19] archiva should be configured as a proxy to central [13:31:16] Another thing that bugs me is a failing test: NormalizerTest.testSimpleLowerCase fails during clean release:prepare but passes under clean verify. Even weirder: the expected string contains characters in upper case despite applying Normalizers.lowerCase(). When the test fails those characters do get mapped to lowercase equivalents (correctly as far as I can tell): [13:31:36] <киану..ꮳꮃꭹ,?[?𞤁𞤂𞤀𞤃]-πάθος. džijⅲ. daß 𝐀?...> but was: [13:31:36] <киану..ꮳꮃꭹ,?[?𞤣𞤤𞤢𞤥]-πάθος. džijⅲ. daß 𝐀?...> [13:32:24] that looks "interesting" ? [13:32:34] … to say the least [13:33:31] I already tried normalising the test environment with a platform-independent user.language|country but that does not help [13:36:14] Ah, got it. release:prepare spawns a sub process that does not use the same JDK as the parent process and therefore uses JDK 11 my local default :facepalm: [13:36:55] `Normalizers extends com.beust.jcommander.converters.BaseConverter`: that's unexpected! [13:38:12] Why so? [13:38:43] that's a command line argument parsing library. [13:39:30] Oh, Normalizers is part of the command line parsing for Glent? [13:39:38] * gehel knows mostly nothing about Glent [13:40:55] Slightly confusing to me. I might have split that class in 2. [13:41:06] anyway, that's not part of what you're trying to do. [14:07:34] Hm, now I’m unable to push tags to the scm developmentConnection (which also uses https instead of ssh). So far I’ve tried to use my toolsadmin credentials (that work for the gerrit UI), also with my ssh username instead, but I always end up with an unauthorised error. :-( [14:09:15] Password is set encrypted in .m2/settings.xml and gets picked up as expected but the credentials themselves seem insufficient [14:15:58] I'm surprised that it uses https instead of SSH [14:16:39] but that shouldn't change anything [14:17:37] Well, I’m able to push through ssh [14:17:41] I'm looking at https://gerrit.wikimedia.org/r/admin/repos/search/glent,access to see if I find where we allow (or disallow) pushing tags [14:18:00] Then you should maybe switch that project to use SSH as well. [14:18:40] looking at other java projects, it seems that we standardize on SSH. [14:21:33] Wait, I have to generate HTTP credentials first… TIL [14:29:29] dcausse: the profile deploy-central does not exist in the project hierarchy. Should I create I create it to override distributionManagement? [14:34:34] \o [14:34:55] gehel: Do I get https://wikitech.wikimedia.org/wiki/ReleasingToMavenCentral correctly, that artefacts published to https://archiva.wikimedia.org/repository/releases/ do get mirrored to central? So far I was only aware of the opposite direction for https://archiva.wikimedia.org/repository/mirror-maven-central [14:35:48] pfischer: that profile should be defined in discovery-parent-om [14:35:51] pfischer: afaik only from central to archiva, not the other way around [14:36:34] based on glent releases existing in the wikimedia release repository on archiva, i suspect in the past we've always released there [14:36:53] and i dont see glent on search.maven.org [14:37:10] (it's been a long time since we released a change to glent) [14:37:24] well, ~aug 3 2021 [14:37:49] pfischer: that ReleasingToMavenCentral page is quite outdated! [14:37:49] ebernhardson: Alright, that would match what’s configured inside the POM (and gives me some peace of mind, thanks!) [14:38:25] gehel: effective POM for glent (with parent 1.65) does not show such profile [14:39:23] not sure how effective pom works with profiles. If the profile isn't active, should it be in the effective pom (since it is not effective) [14:40:22] The release procedure in https://gerrit.wikimedia.org/g/wikimedia/discovery/discovery-parent-pom#release seems more up to date (but specific to the projects using discovery-parent-pom) [14:43:04] I’ll check that out, thanks. At least IntelliJ is aware of deploy-central. [14:43:30] I've added a link to the discovery-parent-pom instructions from that page. [14:46:09] o/ [14:49:00] glent is findable in the public maven repos: https://mvnrepository.com/search?q=glent [14:49:41] huh, interesting. I guess i searched here (redirected from search.maven.org) and turned up nothing: https://central.sonatype.com/search?smo=true&q=glent [14:49:56] i don't actuallyknow, whats the difference between mvnrepository and sonatype central, are they different repos? [14:50:21] no clue, first time I try searching via search.maven.org [14:50:31] huh, i've always used that one for some reason :) [14:50:34] it finds some of the elastic plugin [14:50:36] weird [14:52:41] oh mvnrepository.com does index archiva.org [14:57:20] pfischer: sorry about that, I think I assumed it was released to central by seing results from https://mvnrepository.com/search?q=glent but that does search our own archiva repo too... [14:58:15] s/archiva.org/archiva.wikimedia.org/ [14:59:20] so mvn release:prepare && mvn release:perform should do the trick I suppose [14:59:39] deploying to archiva.wikimedia.org should be the default [15:10:41] We should document where we deploy each project. Maybe in each project's README? Or convert https://wikitech.wikimedia.org/wiki/Search_Platform/Accountability#Code_repositories to a table the deployment repo as a column? [15:11:30] indeed we should have better docs on that, especially for projects that aren't released every year and are easily forgotten. I like things in-repo, like a README, [15:12:04] having a central list could also be useful though, to make it easy to see if we start to have wildly diverging sets of places things are released to [15:13:22] agreed having a README in every project should be mandatory [15:28:19] I'd like to avoid duplication. And I like to have documentation close to the code. Maybe we should have a checklist somewhere of the main points we want in each README (like the target maven repo)? [15:28:32] Weekly status is up on Asana: https://app.asana.com/0/0/1204204455803514 [15:28:39] I'll push it on wiki in a few minutes. [15:50:16] gehel: I was finally able to deploy and I’ll definitely add a coherent README [15:51:12] dcausse w[cd]qs has been restarted, hopefully the JMX metrics are coming in now [15:52:17] pfischer: the overall process should probably be documented in https://gerrit.wikimedia.org/g/wikimedia/discovery/discovery-parent-pom#release, and the project specific bits should be in each project (my thoughts, feel free to disagree) [15:59:28] gehel: Totally agreed, in the end there was nothing project-specific. Still, the docs were silently assuming conditions that were not established on my machine at that time. So I’ll make the discovery-parent-pom docs a bit more wholistic and link to them from the README. [15:59:47] +1 [16:57:13] Enjoy the weekend! [17:08:22] ebernhardson: I released glent 0.3.1 and pointed the glent airflow DAG to it: https://gitlab.wikimedia.org/repos/data-engineering/airflow-dags/-/merge_requests/292 [17:09:01] I’m off now, see you on Monday! 🙂 [17:14:51] pfischer: thanks, i'll look over it today. enjoy your weekend [17:41:03] having some computer weirdness...going to reboot and take lunch, back in ~1h [18:25:59] inflatador: thanks! just realized (while not finding the metric) that I made a mistake in the codebase... [18:26:14] pushed a fix https://gerrit.wikimedia.org/r/c/wikidata/query/rdf/+/900729 [18:26:32] sorry about that... I should have added tests on the first patch :( [18:27:08] going offile, have a nice week-end! [18:50:55] back [19:57:18] inflatador: can i get you to restart airflow-scheduler@search service on an-airflow1005? It turns out we need to change our sudo rules, i can restart airflow-scheduler but not airflow-scheduler@search [19:59:05] ebernhardson ACK [19:59:49] It's restarted. But I thought you had full sudo on that host? [19:59:52] i'm not 100% sure that will fix the issue i'm running into...but it's my best guess :P The thing correctly renders to the webui but then when running the actual task one bit comes out untemplated...seems worth rtying [20:00:09] inflatador: nope, on airflow i have full sudo to the `analytics-search` user, but limited root capabilities [20:00:39] boo [20:00:52] I'll see if I can give you more perms on that one [20:01:15] inflatador: i just wrote https://gerrit.wikimedia.org/r/c/operations/puppet/+/900740 which should at least update the sudo rules so i can do that in the future [20:01:44] even better when you do my work for me ;P [20:05:22] hmm, sadly restarting that didn't fix my thing :( time for fun debugging time [20:05:43] should be extra fun debugging because it templates correctly in the webui, but then when the scheduler runs it it's not templated... [20:10:24] ebernhardson I merged your patch and did all the puppet stuff...you should be able to restart that service now. LMK if not [20:28:21] inflatador: sudo permissions look reasonable, thanks [20:53:11] this is so fun ... set a breakpoint on TaskInstance.render_templates and SkeinOperator.hook_submit. Can see it first render the templates...and then on hook_submit it's un-templated :P [21:00:42] oh! the answre is ... when this does python_callable=self.hook_submit that captures the `self` argument at the time. when templates are rendered it takes a deepcopy of the initial task, so the later execution is against a difference instance of the operator than when `self` was captured earlier... [21:01:02] which would also explain how yarn.wikimedia.org/cluster has a bunch of tasks with the name `{{ task_instance_key_str }}` even though the name field is marked templatable [21:01:52] * ebernhardson isn't sure why these operators even extend from PythonOperator instead of BaseOperator which would avoid this whole wierdness [21:02:40] ottomata: any memory of why SimpleSkeinOperator extends from PythonOperator instead of BaseOperator? [21:27:35] school run, back in 30 [22:07:47] back..silly cats managed to unplug my wifi while i was gone