[08:28:10] moritzm: could you take a look to https://gerrit.wikimedia.org/r/c/operations/puppet/+/537596? [08:28:19] moritzm: maybe there are better ways of solving it [08:28:56] so... the main ATS instance gets a service called trafficserver, so it inherits the systemd unit provided by the package, that ships a [Install] section and hence it can be enabled on systemd [08:29:30] the others (right now just trafficserver-tls) can't be enabled cause it's missing a [Install] section [08:31:03] you want this as a kind of umbrella, so that e.g. trafficserver.service deals with all the invidivual instances? [08:32:03] so if that means that all the individual instances inherit the common parts from trafficserver.service.. that would be perfect yeah [08:34:06] as long as it doesn't mean that trafficserver needs to be enabled to get trafficserver-tls enabled of course [08:34:46] (cause right now on the text cluster I need to deploy trafficserver-tls without trafficserver being enabled yet) [08:34:58] if course it's going to be present on the system cause it gets created by the debian package [08:35:05] s/if course/of course/ [08:36:01] you can declare PartOf=foo.service in the sub service, we have that kind of setup already e.g. on eventlogging hosts [08:37:18] but why wouldn't we want to have the WantsBy for trafficserver itself? is that a temporary thing for the ongoing transition? [08:37:35] then we could simply mask the ATS bits that are currently unused [08:37:41] hmmm [08:37:43] "Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit" [08:38:04] that wouldn't work, I need to be able to restart those on an independent manner [08:40:32] so yeah, It looks like adding an Install section for the additional service would be the simple approach [08:41:26] yeah, that would in fact work, I thought initially you were looking for some eventlogging.service meta service style approach [08:41:38] I'll have a closer look at the patch in a few [08:41:41] ack, thx [08:48:09] <_joe_> vgutierrez: yeah KISS please [08:48:48] _joe_: sure, that was my intention, but I wanted to be sure that I wasn't missing any systemd feature [08:48:53] <_joe_> systemd allows to do pretty convoluted things, but - as usual - the fact you could doesn't mean you should [08:49:15] <_joe_> even if [08:49:32] <_joe_> it's 3 lines of config, to add an [install] section [08:50:09] <_joe_> and since the services are indeed independent from one another (meaning you don't need to restart one if you restart the other) [08:50:17] <_joe_> they should be treated as such [08:50:23] <_joe_> unless I'm missing some detail [09:00:31] yey... [09:00:36] as soon as it got the [Install] section [09:00:38] Notice: /Stage[main]/Profile::Trafficserver::Tls/Trafficserver::Instance[tls]/Systemd::Service[trafficserver-tls]/Service[trafficserver-tls]/enable: enable changed 'false' to 'true' [09:00:45] nice :) [09:02:49] good :-) [09:03:56] since we are discussing systemd and trafficserver.. [09:03:59] https://github.com/wikimedia/puppet/blob/production/modules/trafficserver/manifests/init.pp#L14-L28 [09:04:42] that assumes that the trafficserver service needs to be unmasked always [09:04:56] sadly is not the case for the text cluster right now (cp1075 aside) [09:05:37] but every solution that comes to my mind to solve that is hacky as "I need to take a shower after committing that" [09:12:22] we could set the desired end state (masked/unmasked) in Hiera? then the unmask would only kick in for upload, but not text? [09:26:30] yeah, that could be an option.. but I need to move the masking/unmasking from there then [09:27:33] you still need the mask for the initial install on text and upload, so this would seem to only need to query the Hiera state for the unmask block, right? [09:27:58] yeah [09:28:38] but at that point maybe moving the unmask to trafficserver::instance makes sense [09:29:32] maybe, I miss the insight on the future steps for ATS to make a meaningful comment :-) [09:33:27] let's see if pcc is happy that way... [09:34:35] so something like https://gerrit.wikimedia.org/r/c/operations/puppet/+/537611 [13:46:30] what does it take to rename a puppet 'cluster'? [13:46:48] can I just do it in all the right places and cross my fingers? :) [13:50:08] also, is there any specific process for removing a group from admin module? [13:52:24] <_joe_> in theory, for 'cluster' you just need to change the hiera variables [13:52:36] <_joe_> and also in theory, it should mostly be a few different roles [13:54:25] <_joe_> probably analytics is a bit more annoying [14:01:15] in this case it is just the eventbus stuff [14:01:24] so in prod cluster on kafka main role [14:01:32] want to rename it to kafka_main [14:02:05] <_joe_> so just change the cluster: XXX variable in hiera [14:02:18] <_joe_> some grafana dashboards might need to recompute their variables [14:02:48] k pfctr [14:24:53] * jbond42 afk for a bit [14:29:10] ottomata: followed up on the patch wrt group removal [14:29:39] ty [16:04:22] cdanis: when you have a few minutes, I could use some help understanding Dbctl. In particular, I want to more-or-less revert https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/427690/ and I find that pretty much all the code that touches is different now. [16:24:02] he's on holidays AFAIK [16:24:35] maybe marostegui could bring some light [16:26:13] oh, thanks [16:27:05] andrewbogott: https://wikitech.wikimedia.org/wiki/Dbctl -- not sure your answers are there, but they should be! [16:27:35] I have that page open. I don't like tweaking production config without supervision though :) [16:27:46] totally fair [16:28:25] since this has all been moved into a prod root only realm all I can do is point to whatever docs I find ;) [16:29:34] this is also going to mean that labtestwikitech will have to talk to etcd which I'm not excited about [16:30:13] If 2fa didn't live in wikitech I could ignore all this! [16:30:48] * andrewbogott tempted to just hack labtesthorizon and labteststriker to not use 2fa [16:32:54] andrewbogott: volans and _joe_ are good people to talk to while I’m out [16:33:39] * volans in a meeting right now [16:59:55] it'd be nice if gerrit showed which reviews had unaddressed comments on them in the my reviews view [17:00:33] chaomodus that is done in PolyGerrit under 2.16 :) [17:00:41] (the new thread view!) [17:16:14] <_joe_> andrewbogott: you want to move wikitech back to a local db? [17:17:49] not wikitech, just the text box [17:17:55] 'labtestwikitech' [17:18:07] it's in codfw so it's never really worked to have it use prod dbs, on account of they're read-only in codfw [17:18:54] we have our own db box, db2001-dev.codfw.wmnet that hosts our test databases in codfw, I was planning to move labtestwikitech over there [17:23:49] <_joe_> ok so, you have several problems there [17:24:10] <_joe_> I guess test-wikitech is in the same db section as wikitech, right? [17:24:23] <_joe_> so they need to share the configurations [17:24:49] <_joe_> this means that what you want, AIUI, is to change the db instance in codfw to db2001-dev.codfw.wmnet [17:24:53] here is how it looked, back in the day: [17:24:53] https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/427690/5/wmf-config/db-codfw.php [17:25:14] yep, I think that's what I want [17:25:14] <_joe_> and we cannot ever switch wikitech over to codfw in this way, correct? [17:25:27] <_joe_> I think it's a pity [17:25:57] <_joe_> but for now, given we have no labweb in codfw, it's ok I guess [17:26:33] <_joe_> we might need to revisit in the future. Anyways, if you have a task I can comment there, and probably marostegui will want to comment too [17:26:43] hm… I would've thought that labtestwikitech would use a different db name from wikitech (as it always has) [17:26:46] and so the two wouldn't be coupled [17:27:02] is the issue that they now /are/ coupled because of the dbctl changes? [17:27:06] <_joe_> oh they're not coupled? like in the dblist? [17:27:31] <_joe_> no no I assumed they were as I don't remember anyone adding its own section [17:27:34] <_joe_> lemme see on noc [17:27:42] I don't immediately know what you mean by 'the dblist' [17:27:52] <_joe_> they're in mediawiki-config [17:28:16] <_joe_> they tell you what database cluster to use for each wiki name [17:28:26] <_joe_> https://noc.wikimedia.org/db.php [17:28:37] <_joe_> says labtestwiki is in the same cluster as labswiki [17:31:12] I'm digging in the config code but this is all very different from when I last touched it [17:31:25] I'm pretty sure the notion of the 'wikitech' db cluster is new since I was last here [17:33:11] hm, nope, I did it. Hm [17:34:42] https://www.irccloud.com/pastebin/dnhxD08l/ [17:34:49] There's no reason we can't decouple that now, is there? [17:38:23] labtestwiki is a weird egg honestly. its kind of the equivalent of testwiki for wikitech and kind of a beta cluster wiki. :/ [17:39:15] I would prefer that it not exist at all :) [17:39:50] <_joe_> I think this needs a task [17:40:25] https://phabricator.wikimedia.org/T233236 [17:48:25] <_joe_> ok, I'll try to remember to comment there tomorrow morning :( [17:49:05] thanks!