[08:18:20] volans: i.nflatador, r.azzi and I are working on finally ripping the hardcoded `ELASTICSEARCH_CLUSTERS` config out of spicerack. could you take a look at the (newly revived) https://gerrit.wikimedia.org/r/c/operations/software/spicerack/+/716532 if you get a chance? [09:38:41] ryankemper: ack, done :) [11:13:09] Hello! When I create a new wiki, the `extensions/CirrusSearch/maintenance/UpdateSearchIndexConfig.php ` script I'm supposed to run mentions an "archive index". I'm wondering, is that an index of deleted articles? Or is it an archive index in some different way? [11:13:10] Lunch [11:30:54] urbanecm: it contains delete titles and is used by Special:Undelete IIRC [11:31:18] dcausse: thanks. so it doesn't have content of deleted pages or something like that? [11:31:50] not the content just the title, it's only usefull to allow "fuzzy" matching on the deleted titles [11:32:04] makes sense. thanks! [11:32:09] yw! [11:32:48] lunch [14:02:21] greetings [14:02:55] o/ [14:24:02] gehel LMK if you have time to work some packaging magic...getting error "no upstream tarball found at ../jvmquake_1.0.1.orig.tar." when trying to build jvmquake [15:26:03] * gehel knows mostly nothing about debian packaging [15:26:12] I suggest you try to ping moritzm [15:26:37] inflatador: do you have steps to reproduce? [15:26:47] Y, I can add to the phab ticket [15:27:19] I'm basically just following the generic deb pkg build guide at https://www.debian.org/doc/manuals/maint-guide/first.en.html [15:28:10] inflatador: you probably already know more than me about the subject! Moritzm is my usual go to expert for .deb [15:28:32] We have a few other Debian developers, asking for help in -sre might work as well [15:29:24] Y , will do. You already summoned m-moritz so I will refrain from pinging him thrice [15:29:47] Oh, sorry, I did not realize he was in this channel already [15:34:55] so the issue is [15:35:06] that with source format 3.0 [15:35:20] changes that get applied on top of the pristine source [15:35:36] (like the two patches that David added to fix the Makefile) [15:35:49] are applied/tracked relative to a given upstream release [15:36:13] that's what it's looking for jvmquake_1.0.1.orig.tar.xz (or bz2 or gz) [15:36:37] so of you download the release from the jvmquake Github page and place it there, then it'll work rightaway [15:37:10] there's also other workflows where the releases are stored in git, but here we can simply grab the release [15:37:56] Y, I noticed that there's a deb release upstream too, can we just use it, or do we need to build our own pkg? [15:38:51] depends, sometimes we use extrenal debs (like elastic) and often we have custom packages (which are more flexible to adapt/modify/update) [15:39:47] so in this case given that David has packaged it (he said earlier that the upstream debianianisation had bugs) let's use the internal build [15:40:36] there's no real exhaustive list of reasons, but external debs are often of poor quality, which causes integration issues [15:40:46] we need to decide on a case-by-case basis [15:41:08] yeah, this is new to me, I've come from a red hat shop where we almost never rolled our own pkgs [15:41:09] and many packages are also low level infra which rarely changes, e.g. I'd not expect a need to update jvmquake often [15:41:26] that't the RHEL curse :-) [15:41:37] but e.g. having a local package [15:41:48] allows us to be flexible with the JVM we use [15:42:13] Understood. In that case let me d/l the source as you mentioned and see if I can get it to build [15:42:23] if we e.g. upgrade to 11 or 17 for Elastic then we can easily just adapt the jvmquake deb and don't need to stick with their build optoon [15:42:41] sure, ping me if you run into any issues, happy to help [15:45:09] I thought that it would use the current sources in . instead of trying to get them from ../package_1.0.1.orig.tar.gz [15:47:20] looks like deneb doesn't have openjdk-11-jdk or openjdk-8-jdk [15:47:32] trying again on a local VM [15:47:34] it does, but the debian.tar only contains the changes relative to orig.tar, so it needs that to figure out the difference [15:47:52] better use build2001 [15:48:27] but in fact openjdk-11-jdk or -8- are not installed there, simply install them manually via apt install for now and I'll make a patch later to puppetise that [15:48:42] the source in . do not have the patch applied, I thought that this would be done by quilt as part of the build process [15:49:18] yeah, exactly. it gets applied via quilt during build (and also unapplied) [15:49:24] ok [15:49:41] but dpkg-source still needs to see the orig.tar to figure out if there are other changes relative to the pristine source [15:49:44] (afk for an errand for a bit now) [15:50:02] ok makes sense [15:50:18] I might have made another mistake if openjdk-11-jdk and openjdk-8-jdk needs to be pre-installed [15:51:43] in the rules file JAVA_HOME is determined with JAVA_HOME=$(shell readlink -f /usr/bin/javac | sed "s:bin/javac::") [15:51:55] so this assumes that only one openjdk is installed [15:55:00] I guess I should change that to make it more explicit like export JAVA_HOME=/usr/lib/jvm/java-$(JDK_VERSION)-openjdk-amd64 [15:55:02] dcausse I think it needs either one, not both...just that deneb has neither [15:55:13] so I don't think you actually need to change anything [15:56:15] it's compiling against some files in $JAVA_HOME so I suppose it's important to pick the right one? [15:56:40] it has things like: INCLUDE = -I"$(JAVA_HOME)/include" -I"$(JAVA_HOME)/include/linux" [15:56:56] unless those include files did not change between 8 and 11 [15:58:31] I think it's OK, I actually got pretty far on my local VM. There may be an issue with the 'UseParNewGC' on Java 11 but I kinda doubt it since upstream says they test with 11 [16:20:14] moritzm looks like tox is missing from deneb as well, should I install the 'tox' deb pkg? [16:28:56] yeah, that sounds fine, I'll also add it to puppet tomorrow [16:32:45] \o (actually here a bit ago, had airflow mtg) [16:41:24] o/ [16:55:01] quick workout, back in ~30 [17:25:38] I updated the patch for moving elasticsearch config out of spicerack: https://gerrit.wikimedia.org/r/c/operations/software/spicerack/+/716532 [17:36:57] back [17:42:26] ryankemper: inflatador want to merge the puppet patches and test the cookbook in dry-run mode? [17:46:07] razzi y, will set up a Google Meet in ~5m [17:54:51] razzi: inflatador: feel free to proceed, I’ll be online in 20 mins [17:55:00] razzi OK I'm up at https://meet.google.com/aii-kagz-kxz [18:01:04] volans: are you available to deploy spicerack? I don't see instructions on wikitech for deploying [18:02:02] razzi: I would need to do a new release, but right now stuck in incident response for the page [18:03:02] volans: cool, let us know if you're up for it after incident response, otherwise we can set up a time tomorrow [18:08:59] dinner [18:10:51] ebernhardson you have time to help troubleshoot jvmquake pkg build? It can't run some of its tests, error is "Unrecognized VM option 'UseParNewGC'" [18:10:58] inflatador: sure [18:11:16] cool, razzi and I are at https://meet.google.com/aii-kagz-kxz [18:11:22] inflatador: almost certainly thats saying its using an old JVM [18:12:31] https://github.com/Netflix-Skunkworks/jvmquake#automated-tests [18:18:45] https://github.com/Netflix-Skunkworks/jvmquake/issues/7 [18:21:25] https://github.com/Netflix-Skunkworks/jvmquake/releases/download/v1.0.1/jvmquake_1.0_amd64.deb [18:22:58] https://gitlab.wikimedia.org/repos/search-platform/jvmquake/-/merge_requests/1 [18:44:50] https://www.debian.org/doc/manuals/maint-guide/build.en.html [18:53:21] https://github.com/Netflix-Skunkworks/jvmquake/issues/7 [18:55:20] https://gitlab.wikimedia.org/repos/search-platform/jvmquake/-/merge_requests/1/diffs#diff-content-a99b6c281dc935585622b69e139dc31843a89afd [21:12:56] * ebernhardson wonders if there is any use to record index age in seconds, maybe record it in days to make writing queries easier? [21:13:20] I feel like x < 120 will be easier to read than x < 10368000 [21:20:10] could we have both? it's hard to imagine needing to-the-second granularity but it'd be nice to retain that option just in case [21:31:52] ryankemper: hmm, if days are a float it kinda still retains it, but maybe reduced precision [21:32:17] i guess we can also just have both, i have some unreasable desire to not have too many metrics or such things, but it's probably premature optimization [21:33:18] i suppose the third way is to record the creation date directly and figure out from there. But it seemed annoying to have to compare the time to the time the sample was recorded at query time [21:35:12] * volans not following much, but check if you can convert the unit at query time in prometheus ;) [21:38:38] volans: hmm, i'm looking but not seeing any unit conversion functions in the prometheus query functions reference [21:39:34] of course we can do a bunch of math, at that point it's only a question of which end it goes (and i'm never sure :P) [22:49:27] ryankemper guests showed up earlier than expected, need to step out a little early. Posted jvmquake update with link to errors at https://gitlab.wikimedia.org/repos/search-platform/jvmquake/-/merge_requests/1#note_4281 [23:25:19] ack, thanks