[08:36:07] 10netbox, 10netops, 10Infrastructure-Foundations, 10SRE: Netbox: Allocation of .0 and .255 IP address from 10.65.3.0/16 and 10.65.2.0/16 network - https://phabricator.wikimedia.org/T314183 (10ayounsi) Even though they look surprising, they are valid IPs. We do `ip_address = prefix.get_first_available_ip()`... [09:03:22] 10Mail, 10Infrastructure-Foundations, 10SRE, 10Sustainability (Incident Followup): Upgrade Exim to 4.96 - https://phabricator.wikimedia.org/T310836 (10Aklapper) [13:24:59] 10netops, 10Infrastructure-Foundations, 10SRE: Lumen link between cr2-eqiad and cr2-esams down - July 2022 - https://phabricator.wikimedia.org/T313783 (10ayounsi) 05Open→03Resolved a:03ayounsi > Issue on the Subsea portion, betwen Bellport and Bude. No event and unable to isolate the cause [13:41:50] oh, looks like j.obo is out today? [13:53:52] yeah, it's a holiday in Ireland [14:33:59] moritzm & jbond jruby 3.0 support still looks pretty far away indeed, https://github.com/jruby/jruby/milestone/90 [14:36:15] thanks for the link! [14:36:46] even when they complete it, it's an endless catchup, given that the C-based Ruby in Debian is already at 3.1 :-) [14:37:31] yeah for sure, it seems pretty apparent that they lack the development resources to stay in lock step [14:38:52] what is this about? I ask because there was talk about jruby at the puppet bof at debconf [14:39:50] paravoid: it is indeed about puppet master packaging [14:40:13] i missed that BoF how did the discussion go? was there a plan? [14:40:25] kind of [14:43:20] let me check what the latest is [14:43:27] thanks [14:44:18] at the time there was talk about fixing the jruby package, and also (re)packaging older version of some gems that would work with jruby [14:44:38] this was the list: https://wiki.debian.org/Teams/Puppet/Work#JRuby_missing_dependencies [14:45:12] but I'll check the status with one of the maintainers (Apollon, moritzm knows him too) to see where we are [14:46:52] thanks paravoid, that helps outline some of the work that is needed [14:48:04] can you give me a little more context on what we're talking about here? is it about the eventual puppet 7 upgrade? [14:48:11] thanks paravoid but ohh that looks horible. also if the ruby version is in conflict with the jruby version that could mean that a machine wouldn;t be able to have puppet agent (requires ruby-semantic_puppet) and puppet-master (requitres jruby-semantic_puppet) [14:48:15] paravoid: yes [14:48:44] we are stuck on puppet 5.5 untill we have a package for the new puppet server [14:50:03] given what I heard over thre I think it can take a while for Debian to package the stack -- have you explored the tradeoffs involved in running puppet server without using debian's packages? [14:50:55] jbond: my read is that the jruby variants would have different package names and possibly different install paths, so I think they could be co-installable [14:54:25] pragmatically Debian could also cease supporting Jruby as a general purpose Ruby implementation (which would be brittle to run random Ruby apps anyway given how far it lags behind Ruby/C) and offer it simply as puppet-jruby-env as a multi tarball package which vendors in the specific gems [14:54:54] given that noone can/will really make use of the jruby-gems outside of jruby/puppetserver... [14:55:41] paravoid: ^^^ i think this is the fallback plan [14:57:52] jhathaway: i agree i think we should be able to run them together but seems like the suggestions above is to "[when creating the jruby package] one must make sure to add Conflict: ruby-FOO in debian/control," so it seems we may need to at least repackage [15:01:16] jbond: ah good point, I missed that :( [15:03:29] we could also prototype puppet-jruby-env internally and then if it works fine (and the approach to package this in separate packages is still stalled) pitch it to Debian [15:03:58] sgtm [15:06:05] yeah that sounds good [15:08:07] jbond, jhathaway: how about a quick meeting on Wed to discuss necessary steps towards puppet-jruby-env? [15:08:20] yes sgtm thanks moritz [15:08:27] yup, thanks [15:08:51] ack, I'll create an invite in a bit [15:08:57] cheers [15:25:42] 10netbox, 10netops, 10Infrastructure-Foundations, 10SRE: Netbox: Allocation of .0 and .255 IP address from 10.65.3.0/16 and 10.65.2.0/16 network - https://phabricator.wikimedia.org/T314183 (10Papaul) @ayounsi make sense if it is /16 and yes it is working on IDRAC. The only issue is we received an alert on... [16:42:53] 10netbox, 10netops, 10Infrastructure-Foundations, 10SRE: Netbox: Allocation of .0 and .255 IP address from 10.65.3.0/16 and 10.65.2.0/16 network - https://phabricator.wikimedia.org/T314183 (10ayounsi) 05Open→03Resolved a:03ayounsi Assuming the duplicate IPs issue got solved. Feel free to re-open if... [17:01:12] 10Mail, 10Infrastructure-Foundations, 10SRE, 10Wikimedia-Incident: 2022-05-09 Exim BDAT Errors incident - https://phabricator.wikimedia.org/T309238 (10jhathaway) [17:01:28] 10Mail, 10Infrastructure-Foundations, 10SRE, 10Sustainability (Incident Followup): Upgrade Exim to 4.96 - https://phabricator.wikimedia.org/T310836 (10jhathaway) 05Stalled→03Open exim 4.96 is now in bullseye backports [17:15:47] anyone wondering about my office background in the meeting today, here is the wide angle view ;) https://photos.google.com/share/AF1QipOrT4ekOc2G2ePa8FLd9EbcrnqkWaFeSY41Xoaq-Dp-1gAHC0LPUKGkGN8sY3BYbQ?key=ZWt5S3gxVlFCLWpHaUs1d1FNY0o3Q3FSWXFNTFdB [17:16:20] jbond: <3 amazing [17:16:41] :D [17:53:30] hahaha, nice [17:59:18] lol [17:59:27] truly amazing jbond [18:10:01] something to illustrate for the next quarterly review slide deck, something about "targeted SRE fixes" :-) [20:07:55] 10netops, 10Infrastructure-Foundations, 10observability: Grafana posting to http://wpt-graphite.wmftest.org:8080/ - https://phabricator.wikimedia.org/T307445 (10lmata) >>! In T307445#8047790, @ayounsi wrote: > @jbond i think this can be closed? also curious whether this task can be closed [20:11:01] thanks all, love the suggestion morits :) [21:21:04] jbond: rotflol