[09:27:13] I'll be rolling-restart prometheus servers across the fleet for https://gerrit.wikimedia.org/r/c/operations/puppet/+/598711, there will be metrics unavailability while that happens [09:31:25] what's the semantic difference between 'ack' and 'done' in gerrit? [09:31:36] i can't find any documentation for this [09:34:04] kormat: I use done when I change something in the code, and ack when the comment is a fyi or similar [09:34:26] ok, that makes sense [09:34:26] and they don't need longer comment, like nitpicks [09:34:59] what's the convention about who marks a comment as resolved? [09:35:22] in previous places it was always left to the person who made the initial comment to resolve it, so they could double-check that their feedback had been addressed [09:35:34] kormat: I don't think there is an explicit one [09:36:34] from experience I think it's more the person working on the CR though [09:37:12] mm, ok [09:45:07] does anyone have a good example of a well packaged but simple piece of software we maintain so a contributor can learn from it? [09:45:24] I wanted to show cumin but I cannot find the source package repo [09:46:05] jynus: debian branch [09:46:10] volans: thanks! [09:46:14] I only looked at master [09:46:21] both cumin and spicerack use that approach [09:46:27] is not the only one possible [09:46:33] I hadn't thought of that [09:46:37] thank you [09:46:51] as I only saw release tags [09:48:11] yes I use those too as the version is automatically gsthered from the tag [09:48:29] one less manual place to update [09:49:09] but maybe mo.ritz has better examples to show you ;) [09:49:12] I wanted to show my student an example of packinging python and that would help [09:49:25] mostly wmf specific quircks, if any [09:49:34] rather than generic debian ones [09:50:28] I don't think there is anything wmf-specific in the debian branch, but I might be wrong ;) [09:51:05] packaging a Python module or an application written in Python? [09:51:17] moritzm: technically both [09:51:17] we have a number of custom Prometheis exporters written in Python [09:51:27] e.g. prometheus-pdns-exporter [09:51:31] it is a cli and a module [09:51:35] or prometheus-ircd-exporter [09:51:44] thanks, I will pass those on too [09:52:29] or python3-conftool, it's also an internal package [09:52:43] ah, that would be nice [09:52:59] thanks for the suggestions, I will pass the source for those for more examples [09:53:24] so with wmf specific I mostly mean standards and things we assume [09:53:39] which don't necesarilly have to be non universal [09:54:10] but we have to have into account like we are likely to configure stuff with puppet, so package and puppet config should not fight [09:54:14] if you understand what I mean [09:58:02] FWIW I usually start from the assumption that save for very specific cases there shouldn't be any wmf-specific bits in the packaging unless the package/software is also wmf-specific [10:03:49] agreed, e.g. the prometheus exporters I mentioned were all written in a way that they could be used on any Debian system, if we apply additional config bits via Puppet, they are using the same config files someone would use if deploying without Puppet [12:01:40] elukey: did librdkafka expand its range of what was an allowable queue.buffering.max.kbytes at some point? CONFIGURATION.md says the range is [1 .. 2147483647] but nfacctd on netflow3001 only lets me set a maximum of 2097151 [12:47:55] cdanis: o/ - do you mean that librdkafka used by netflow returns an error ? [12:47:59] (Trying to understand) [12:48:16] May 27 11:55:01 netflow3001 nfacctd[9462]: WARN ( default_kafka/kafka ): [/etc/pmacct/librdkafka.conf:9] key=queue.buffering.max.kbytes value=10485760 failed: Configuration property "queue.buffering.max.kbytes" value 10485760 is outside allowed range 1..2097151 [12:50:32] it's fine, just seemed odd to me [12:50:41] i set it to the maximum and we'll see if we get any more segvs [12:51:51] ack, really ignorant about that parameter [12:52:09] (or maybe past me worked on it and it fell of my limited LRU brain :D) [12:52:17] the nfacctd usage of librdkafka seems a bit weird tbh [12:52:44] spawn a writer process, dump all data into it, in such a way that you can overflow kafka's queues?, wait for it to finish [12:52:54] 1x / minute [13:24:25] apergos: I have tried to merge and submit https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/596172/ but I don't get the submit button, can you try it? [13:25:20] marostegui: it's chained to the previous CR [13:25:27] see the right block Relation chain [13:25:33] I rebased it [13:25:37] Where do I see that? [13:26:32] marostegui: in the new UI to the right of the commit message [13:26:39] under the MORE button [13:26:45] 'Relation chain' [13:26:47] like here https://gerrit.wikimedia.org/r/c/operations/puppet/+/594961/1 [13:26:49] Ah, I use the old one, and I cannot find that there [13:27:20] in the old one is Related Changes [13:27:24] always to the right [13:27:28] I hav ee +2 and submit, feel free to puppet-merge [13:27:55] volans: yeah, but on the right side I only have related changes: db1146 enable notifications [13:27:56] XDDD [13:27:57] marostegui: join us in the future! https://gerrit.wikimedia.org/r/?polygerrit=1 [13:28:12] apergos: done, thank you [13:28:18] kormat: the new ui is terrible! [13:28:22] sure thing [13:28:37] marostegui: so is the old ui. it turns out the real problem is gerrit [13:31:39] <_joe_> well by this reduction logic, the real problem is java :) [13:31:53] _joe_: i'm also willing to accept that [13:33:23] <_joe_> kormat: I figured you'd be willing to [14:37:48] man this new UI is... I dunno. It somehow takes gerrit's problem of having too much information thrown at the viewer and just makes the information less accessible [14:37:57] I'll try it out [14:38:15] overall I prefer it, not least of all for the 'resolved' bit on comments (which I don't think old UI has) [15:25:00] <_joe_> there is the small problem the new UI still isn't feature-complete [15:25:07] <_joe_> else, it's far superior IMO [17:37:16] The "new" UI will be replaced by a "newer" one that's still slightly feature incomplete when we bump to 2.16, and again to a "yet-newer" one when we bump to 3.1 (some time in the next few months), FYI. [17:41:35] James_F: gerrit right? [17:41:54] any timeline where the bump to 2.16 will happen? [17:42:02] "Soon". [17:42:18] There'll be e-mails about it when a timeline is known. [17:47:42] jbond42: I saw you ping earlier about testing mcrouter on cloudservices2003 — were you able to learn what you needed? [17:49:36] andrewbogott: i istalled mcrouter on that machine and it seems to be running, although im not sure on the what service it provides on that box so im don't know if its running with errors. if yuo could check and see if everything looks normal that would be great. [17:49:54] jbond42: sure, I'll check [17:50:02] James_F i think we're going straight to 3.1 now (possibly 3.2). [17:50:04] in theory it's in a cluster with another host but I might need to make some puppet changes [17:50:05] there where also some unrelated pnds issues on the box which i mentioned in #-cloud-admin [17:50:20] jbond42: yeah, the pdns database needs manual setup [17:50:21] *pdns [17:50:25] ack [17:50:41] thank you for building that package. I'll let you know how it does [17:50:47] great thanks