[15:30:27] XioNoX: i thought my last email to drax was a success, i was wrong :( [15:30:46] yeah... I'd say ignore [15:30:49] jbond42: depends on teh definition of success [15:30:57] if you wanted to meet them, great success! [15:31:02] :D lol [15:31:02] :-P [15:31:25] I bet you can get a dinner invite in the next iteration ;) [15:31:33] hahaha :) [15:32:09] * jbond42 holding out for tokyo 2021 tickets [15:37:32] jbond42: is your puppet /etc/services patch ready for review btw? [15:39:20] cdanis: yes but there is a known bug. however i think it would be good to get early review of a couple of things to make sure this is the right directions specificly:... [15:39:43] the proposed data structure https://gerrit.wikimedia.org/r/c/operations/puppet/+/670917/26/modules/netbase/types/service.pp [15:40:09] and the merge stratagy which includes: [15:40:11] https://gerrit.wikimedia.org/r/c/operations/puppet/+/670917/26/modules/netbase/functions/services/merge.pp [15:40:18] https://gerrit.wikimedia.org/r/c/operations/puppet/+/670917/26/modules/netbase/functions/services/port_proto_keys.pp [15:40:24] https://gerrit.wikimedia.org/r/c/operations/puppet/+/670917/26/modules/netbase/functions/services/service_keys.pp [15:40:43] i feel someone with a more forlam CS background may see a more optimal way forward [15:41:01] ok! cool [15:41:05] I'll take a pass today [15:41:48] the current problems is to merge i create a hash keyed of port+proto.join(). then just use puppet (rubies) hash merge [15:42:22] for https in services it has a port for udp and tcp however thes services cataloge only ever have on proto [15:43:07] this means after the merge we have two 443 ports on for https tcp/udp and one from the service catalouge with just 443-tcp [15:43:35] https://gerrit.wikimedia.org/r/c/operations/puppet/+/673105/5/modules/profile/manifests/base/netbase.pp#21 [15:44:08] ill be arond later as well so feel free to ping me if anything doesn;t make senses [15:44:20] thanks! [15:44:39] I feel like I'm going to need to play with a puppet REPL some :) [15:44:53] https://github.com/nwops/puppet-debugger [15:47:24] TIL [15:47:39] I've used the hosted version of this or something similar a few times, looks like it is down though [15:47:41] thanks :) [15:51:48] i have not used the hosted one much found it a bit slow however with it local it means you can work on the actual puppet code (assuming all other issues around local puppet testing) which for this module is quote usefull https://phabricator.wikimedia.org/P14947 [16:09:13] jbond42: I just logged in into icinga via SSO and got redirected to: [16:09:16] https://icinga.wikimedia.org/cgi-bin/icinga/tac.cgi?tac_header [16:09:19] is that expected? [16:09:32] I think my initial URL was: [16:09:32] https://icinga.wikimedia.org/cgi-bin/icinga/status.cgi?allunhandledproblems&sortobject=services&sorttype=2&sortoption=3 [16:14:28] volans: sort of but not really i think its related to https://gerrit.wikimedia.org/r/c/operations/software/cas-overlay-template/+/609399 [16:14:36] which is a hack we put in specificly for icinga [16:14:47] because HTML FRAME is still a thing [16:15:06] in 2021... I hoped that the pandemic would have free us from that one at least... [16:15:27] lol :) [16:15:44] got it, not a big deal ofc, just mildly annoying when it happens :) [16:16:04] but hey, we could patch Icinga.. it's just C code to generate html... [16:16:08] what could possibly go wrong [16:16:44] lol yes im sure i not the only one with those wounds ;) [16:18:42] this reminded me: https://phabricator.wikimedia.org/T164206#3435220 [16:19:17] GIST: ...writing all the content to the file with fprintf(fp, ...) without checking the return value of it. [16:20:53] wow nice [16:30:09] volans: there is a race condition around the icinga redirect sometimes, yeah, and it is fairly unavoidable unfortunately