[09:15:49] running tofu apply for the main branch on cloudcontrol1007, I got [09:15:51] https://www.irccloud.com/pastebin/L0WFhjDG/ [09:16:10] as if s3 were down or something [09:18:37] this is T370498 [09:18:38] T370498: SystemdUnitDown Unit opentofu-infra-diff.service on node cloudcontrol1007 has been down for long. - https://phabricator.wikimedia.org/T370498 [09:38:10] hmm [09:38:20] have you tried listing the bucket directly? [09:41:20] I haven't [09:41:28] also, this works just fine in the other 2 nodes [09:41:45] I haven't followed up, got distracted with something else [09:44:22] seems to be working now, I trigged the timer manually [09:47:24] dhinus: thank you for the magic wand fix :-P [13:04:22] dhinus: when executing any cookbook in my laptop, I get this [13:04:24] https://www.irccloud.com/pastebin/xFiXujlV/ [13:04:26] is this known? [13:06:27] * arturo food time [14:23:47] arturo: spicerack is not yet compatible with python 3.12 [14:24:03] T354410 [14:24:04] T354410: [spicerack] python-kafka does not support python 3.12, there's a fix but there has not been any releases since 2020 - https://phabricator.wikimedia.org/T354410 [14:24:18] :-( [14:27:08] thanks for the information [15:09:07] bd808 probably not on adopting the tool, although def let me know if you need any code reviews. right now i don't have a pressing need to modify the code - grep and cut basically was okay here. i do wonder if it would be worth us thinking about sending the stuff into the data lak and then getting purging and other aggregation thing. main reservations are that's a bit of work and i also worry about query strings if not sanitized [15:11:24] i was interested to hear if it was objectionable to entertain the piping of that stuff. i thought i saw someone posting that they were looking to enhance the tool or something to narrow down more pageview-like stuff, i'm guessing using content-type and status code or some such thing (which would require code and schema changes obvs) [15:49:34] oh shoot, he's probably not here (and i hope he isn't reading irc!). sorry in advance / retrospect i didn't reply last night bryan [15:51:51] I think he's off on Fridays for the next while [15:53:27] dhinus: I have the tofu cookbook ready: https://gerrit.wikimedia.org/r/c/cloud/wmcs-cookbooks/+/1055420 [15:54:05] * blancadesal wanders off into the weekend [15:54:12] have a good one you all [15:54:24] o/ [15:54:42] * dr0ptp4kt andrewbogott: he's a smart guy! summer is the life. [15:55:00] o/ [16:00:53] * arturo offline [16:14:56] * dhinus is also done for the week, will check the cookbook on monday [16:16:09] dr0ptp4kt: if anyone cares enough about the traffic logs for tools to put them in the s3kr3t data lake I won't stop them. I personally think that would be pretty useless without a related project to then actually product some public facing data from them. The project to mirror the data lake for use by the volunteer community died a fiery death when otto found out that cloud vps !== prod for monitoring/alerting/etc. [16:16:27] *produce [16:18:28] * bd808 is only here in ghost form ;) [17:13:27] (^^ fwiw, we later learned that Search set up a and elasticsearch instance in production that was queryable from Cloud VPS. If we had realized we could do that, we would have done it! I still have hopes for 'public data lake' on eday) [17:14:41] yeah i agree, i mean it's useful to be able to see that 'tool x' does this thing and then on the edge/origin 'thing x' is happening as a consequence and at what velocity...but being able to have something like aqs, a report, whatever, that would make it more useful. good to know no qualms per se, though, thank you! but you should get your day off! i'm hopeful some day we can expose more so people can do [17:15:20] the compute (and storage) intensive things with the non-confidential data, although recognize it's a ton of work in most realities.