[09:52:06] moritzm: https://gerrit.wikimedia.org/r/c/operations/puppet/+/720244 [09:53:54] ack, I'll have a look in 10m [09:54:47] Just a quick update on the dc switch live-test: lego.ktm and I have done a sucessful --dry-run of the switchdc cookbooks on cumin2002, including the additional 9th stage from 720075. cumin2002 supports tmux with fixed screen sizes (tested aswell). [13:14:24] what does gerrit do if you do `git review` on a merge commit? [15:01:28] kormat: I assume git-review will upload it like any other patch [15:01:39] and append a Change-Id if missing [15:02:17] I don't think we've ever done this intentionally, but Gerrit does allow review of multi-parent commits, e.g. merge commits. [15:02:37] but unless the repo in question uses feature branches etc this is probably not something we should do [15:02:41] the mind recoils at how that would be presented, knowing gerrit's strong UX [15:02:54] its quite reasonable actually. [15:03:21] https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/+/720158 [15:03:29] It gives you different base options as with patch versions [15:04:32] marginally more insightful than git-cli would be for a merge commit [15:05:15] https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/SmashPig/+/719375 [15:05:15] that's about what i expected. compared to parent 1, nice simple change. compared to parent 2, huuuge amount of changes. the default comparison tells you _nothing_ [15:05:22] this might be a slightly more normal example [15:05:46] (reviewing git merges is a nightmare regardless of the tools, to be fair) [15:05:59] https://gerrit.wikimedia.org/g/wikimedia/fundraising/SmashPig/+/3607b16f833c42e177e1b068c4256f37b1d5143b [15:06:05] here there's two diff links as well [15:07:08] yeah, fundamentally the problem is that it adds commits to the repo that werne't in the chain before. I'd always squash or rebase those for re-review on the main line. [15:07:28] polish them up and submit them as one or more regular patches. [15:08:51] where rebase is more work but preserves the information in a future-self-friendly way, and squash is the lazy option that is easy to do and gives you an arguably better diff and repo history than the merge commit would have, depending on how messy the alternate branch was [15:10:59] kormat: btw, no pressure but when should I expect to monitor pc ttl ramp up? ref T280604 [15:10:59] T280604: Post-deployment: (partly) ramp parser cache retention back up - https://phabricator.wikimedia.org/T280604 [15:11:17] planning a bit for next week [15:13:35] Krinkle: we've been waiting for input from you on https://phabricator.wikimedia.org/T280599#7331439 [15:15:19] barring some emergency, i wouldn't expect parsercache retention to be raised before next month, at the earliest [15:15:23] next week is the dc switchover [15:15:27] then i'm off for 2 weeks [15:17:59] kormat: ok, I recall giving the ok at least three times already on different tasks and email threads. [15:18:04] didn't know Peter asked for anther one on this one [15:18:35] Krinkle: so you agree that raising the PC retention period is low priority? [15:18:36] I agree it's not urgent to ramp up right away, but I didn't know we wanted to wait that long. [15:19:23] it'd just be nice to get it done and start focussing on other things, so as to not dirty the metrics [15:19:29] but I dont' think I will in that case wait that long. [15:19:31] i mean, you're on the task, and were pinged specifically on it. i don't know what else to tell you. [15:20:37] yeah, I just missed Peter's last comment I think. I did say a couple of times that the ttl ramp up is non-blocking and shoudl happen in parallel to their roll out [15:21:04] I've also emailed Peter on that already a few weeks ago, and on the other various tasks, I could have imagined it. [15:21:34] there's been a huge mess of tasks, it's been really hard to follow; but i don't specifically remember that [15:21:45] to clarify, I'm not going to ramp up the ttl without you, that's for your team to do. but I mean, I think it's perhaps okay to start doing some other work that interacts with PC that may change the metrics. [15:22:08] improve effiency, some other debt/cleanup etc [15:22:30] you mentioned 'planing work for next week' - please do not deploy any such changes during the week of a DC switchover [15:23:53] i have no objection in principle to things that improve the PC situation from being deployed after that, however [15:25:32] if there's no train next week, the changes will naturally deploy the week after [15:25:48] looks like there is a train next week however (tehre wasn't one this week, could'v been planned better I guess) [15:25:59] alright, I'll make sure they land after Tuesday's branch cut [15:26:06] and thus go out 2w from now [15:26:39] great, thank you [17:56:28] Heyas, with the netgears being backordered until 9/30 it seems like we may wanna just double up with https://www.fs.com/products/129517.html ? unfortunately the netgears are useless for anything but mgmt switch use so we'd end up with double switches =P [17:56:38] bahhhhh, wrong window. glad that iddnt have private data!