[08:23:08] Todavia no tienen nada para un ictus [09:36:03] <_joe_> XioNoX, topranks is there a way to tell if a server is in a TOR-switch row? [09:36:16] <_joe_> I mean programmatically [09:36:28] _joe_: what's the context? [09:37:03] <_joe_> XioNoX: context is adding new k8s nodes to clusters [09:37:26] <_joe_> depending on what configuration you have, it changes where in homer you should put the data [09:37:45] <_joe_> I want to indicate people a way to know where they should add the stuff [09:38:03] <_joe_> that is not "at the time of writing, only rows E-F in eqiad..." [09:38:18] <_joe_> so that we don't have to check with you [09:38:40] yeah and thinking of it now we also have that scenario in drmrs, and now esams [09:38:47] so it's getting harder to track manually [09:39:35] can I suggest that we start also looking at not hardcoding all that info and grabbing it from netbox? it seems fairly error prone and tedious to update evry time [09:39:36] <_joe_> yeah drmrs and esams aren't my concern in this specific case, but you can see how it will get more difficult with time [09:39:49] <_joe_> volans: which info? [09:39:52] there are multiple ways [09:40:15] $ git grep -c kubernetes [09:40:15] config/sites.yaml:40 [09:40:22] the IPs [09:40:24] _joe_: I guess https://gerrit.wikimedia.org/r/c/operations/cookbooks/+/903174 would eliminate this issue? [09:40:25] <_joe_> ah you mean the IPs for k8s nodes [09:40:30] <_joe_> volans: sure it makes sense [09:41:27] <_joe_> XioNoX: uhm so basically removing that info from homer? [09:41:41] _joe_: yup [09:41:49] depending on where you need that data, but easiest might be to get it from netbox [09:42:14] <_joe_> yeah the thing I asked you was specifically about homer integration [09:42:47] XioNoX: would that cookbook add the peers on-the-fly? Like we'd have no saved config for the peers / homer wouldn't generate them? [09:43:19] yep [09:43:23] <_joe_> yeah my only worry is that this makes homer unable to recreate all peers itself [09:43:28] not sure that's a good move [09:44:29] <_joe_> topranks: I think what volans was suggesting was to basically implement the functionality that is in that cookbook inside homer, integrating it with netbox to fetch the data [09:44:29] _joe_: yeah, we no longer have a "source of truth" for what the config should be [09:44:49] <_joe_> topranks: OTOH, this isn't properly config but "state" [09:44:56] <_joe_> and gitops sucks for this stuff [09:45:09] <_joe_> but I would rather have homer handle the automation if possible, yes [09:45:28] that's an idea alright. tbh we could be using bgp dynamic neighbors on the swtiches/routers and not need per-device config, I think we rejected that idea though [09:45:40] I think we already had that conversation a few months ago :) [09:45:55] <_joe_> XioNoX: ok, sorry, I wasn't part of it :) [09:46:12] <_joe_> (which conversation?) [09:46:47] _joe_: think this one: https://phabricator.wikimedia.org/T306649 [09:49:47] <_joe_> yeah I see the discussion [09:50:09] in theory we could look to see if homer could build the list of k8s peers automatically based on location, certainly we could pull most from netbox, although we'd probably need to base it on server name which might not be ideal [09:50:36] <_joe_> well if we add the custom field... [09:51:17] <_joe_> anyhow, I think it's ok if we have to also run this cookbook when we recreate the configuration of switches from scratch [09:51:29] <_joe_> it seems like something you do relatively rarely? [09:51:45] <_joe_> but it's not for me now :) [09:52:17] fwiw the latest netbox allows (finally!) to specify tags on a per-object-type basis, so once upgraded we could start considering using them [09:53:38] _joe_: it's fairly rare and yeah not a major deal to run that cookbook too [09:54:26] I'd be in favour of bringing that logic also into homer though, so it remained as much as possible a "one shot" to configure the device if you want. And the cookbook is available to service-ops if they add nodes and want to just set up new peers [09:55:11] tldr, we can do homer + cookbook but it's a lot of engineering time and added complexity. Homer only is super slow and more problematic to run as it can show changes for unrelated parts of the config. [09:56:07] I really don't like the idea of fragmenting the automation tbh [10:11:18] Hi , I think I have accidentally committed someones prestaged files on srv/private. These are the files mentioned Together with my datahub changes https://www.irccloud.com/pastebin/CqPvj5vt/ [10:15:52] cc claime jynus --^ [15:25:35] arnaudb: I have a puppet-merge waiting behind one of yours (Icinga config). Feel free to merge mine with yours, or I can merge yours if you prefer. [15:26:11] he is busy [15:26:18] but let me merge them [15:26:56] btullis: ongoing [15:27:15] btullis: yours was "proxy.nginx.erb" right? [15:27:21] Great, thanks. Yes, that's the one. [15:27:26] done [15:33:35] thanks jynus ! [18:39:46] robh: are you running puppet-merge? [18:40:00] ahhh hell i forgot to hit enter on yes [18:40:02] fixing sorry about that [18:40:07] its completing now [18:40:09] my apologies [18:40:13] no worries :) [18:40:19] done [18:40:29] thx for reminder =]