[07:57:45] <dcausse>	 o/
[10:33:31] <dcausse>	 lunch
[12:11:31] <pfischer>	 o/
[14:03:29] <inflatador>	 <o/
[14:03:34] <inflatador>	 Happy New Year!
[14:12:19] <dcausse>	 o/
[14:12:25] <dcausse>	 happy new year! :)
[14:17:27] <inflatador>	 I updated my work laptop to the latest MacOS over the break, I guess I get to find out what it broke today ;P
[15:35:57] <ebernhardson1>	 \o
[15:39:33] <inflatador>	 <o/
[15:39:36] <inflatador>	 Welcome back!
[15:39:42] <dcausse>	 o/
[15:46:43] <dcausse>	 not having much luck to convince java (in the opensearch centos docker image) to use our root ca...
[15:48:39] <ebernhardson>	 :S I'm not really sure how that stuff works.  It must be possible though
[15:48:52] <inflatador>	 dcausse if you need SRE make an opensearch 3 image let us know, should be fairly easy since we are mirroring the opensearch 3 deb repo now
[15:49:31] <dcausse>	 inflatador: thanks, it's still all kind of a manual setup at the moment
[15:50:40] <dcausse>	 seems like the jvm is installed manually in /home/opensearch/jdk, could perhaps explain why it does not want to use the system wide /etc/pki/java/cacerts
[15:51:23] <ebernhardson>	 i had mixed feelings on using the embedded jvm, but that was the default so left it.  I understand why they do it, but i feel like it makes things more magical
[15:52:16] <inflatador>	 I'm guessing OpenSearch 2.x is too old for y'all's experiments? We do have an image of 2.19.4
[15:53:33] <dcausse>	 trying again with forcing the trustStore...
[15:53:45] <dcausse>	 inflatador: yes, we run 3.x
[15:56:07] <inflatador>	 It's also a RHEL-based distro vs Debian, so if you're mounting stuff into the container the CA paths will be different
[15:58:01] <dcausse>	 yes, had to use centos tools but the jvm is not installed via the system package
[15:58:30] <dcausse>	 seems to work by setting the path to the trustStore, getting a 404 now
[17:47:10] <dcausse>	 meh I broke relforge somehow REFERENCE: java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: /usr/share/opensearch/plugins/opensearch-knn/lib/libopensearchknn_faiss_avx512.so: ...
[17:56:38] <ebernhardson>	 :S
[18:00:45] <dcausse>	 /usr/share/opensearch/plugins/opensearch-knn/lib/libopensearchknn_faiss_avx512.so: /usr/share/opensearch/data/ml_cache/pytorch/2.5.1-cpu-precxx11-linux-x86_64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found...
[18:02:20] <ebernhardson>	 hmm, i mean i know generally what that means but not how it happens.  Sounds like a download for a different linux version
[18:03:00] <dcausse>	 it's in "ml_cache"... tempted to wipe this out and see
[18:03:09] <ebernhardson>	 yea that seems reasonable. Might have to reload the models?
[18:03:21] <ebernhardson>	 better to learn this stuff now than in prod :)
[18:03:27] <dcausse>	 yes...
[18:19:54] <ebernhardson>	 AFK an hour or two, taking care of a personal mishap
[18:21:28] <dcausse>	 actually this problem is not new, according to logs I see it since 2025-12-09...
[18:21:43] <dcausse>	 dinner
[19:07:24] <inflatador>	 lunch, back in ~40
[19:39:41] <inflatador>	 bback
[20:01:20] <inflatador>	 appointment, back in ~90m
[21:21:13] <inflatador>	 back
[21:25:00] <ebernhardson>	 err, back for awhile