[14:56:29] <roy649>	 How do people handle github SSK keys for toolforge projects?  If I make a new ssh key for the tool and add that public key to my github account, that works.
[14:57:00] <roy649>	 But if I bring in a collaborator to the tool, they now have access to a key which is tied to my personal github, so that's not good.
[15:09:27] <roy649>	 Oh, maybe what I'm looking for  is what github calls a deploy key?
[15:09:28] <roy649>	 https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys
[15:34:43] * bd808 wonders why roy649 needs to push to github from the bastion in the first place
[18:41:44] <wm-bb>	 <lucaswerkmeister> /me never pushes to GitHub (or GitLab) from Toolforge either tbh
[19:12:30] <bd808>	 I do occasionally need to take some code I've tweaked back to a repo, but I usually do that with a workflow of making a local commit, exporting it as a patch, scp'ing the patch to my laptop, and then applying the patch to a working copy there.
[19:50:56] <andrewbogott>	 thcipriani: regarding https://gerrit.wikimedia.org/r/c/operations/puppet/+/1053956, that patch is already applied locally. Do I need to revert it?
[19:53:10] * andrewbogott reverts it
[20:01:21] <bd808>	 https://integration.wikimedia.org/ci/label/BetaClusterBastion/ are the jobs that need updating to switch the deploy server in deployment-prep. I think that basically involves registering the new deploy server as a Jenkins worker node, applying the "BetaClusterBastion" label to it, and removing the label from the old node.
[20:03:25] <thcipriani>	 andrewbogott: ^ yeah, that's the reason I noticed it. Beta cluster deploys started failing. I hadn't had a chance to test the deploy server. But if it's good to go, it should be as simple as moving some things around in Jenkins, I just wasn't certain if it were time to do that, so I merged something to make jobs happy.
[20:04:48] <andrewbogott>	 Wait, does that mean that reverting broke it again?
[20:05:15] <bd808>	 it's been busted since 17:03 UTC
[20:05:21] <bd808>	 https://integration.wikimedia.org/ci/job/beta-code-update-eqiad/
[20:07:06] <andrewbogott>	 that shows it as having been working until I reverted 15 minutes ago
[20:07:13] <andrewbogott>	 I mean, broken, then fixed, then broken again. 
[20:08:16] <andrewbogott>	 so thcipriani I'm at your service, you want that patch in or out?
[20:09:00] <bd808>	 "Last successful build (#504176), 3 hr 15 min ago"
[20:09:14] <thcipriani>	 andrewbogott: let's keep it in, and then I'll flail from there. That's the eventual state we want.
[20:09:28] <andrewbogott>	 OK, I'll merge then
[20:09:31] <andrewbogott>	 sorry for the breakage
[20:09:31] <thcipriani>	 thanks :)
[20:10:01] <thcipriani>	 eh, sometimes that's how progress gets made ¯\_(ツ)_/¯
[20:10:26] * bd808 :homer-backs-into-bushes:
[20:10:30] <thcipriani>	 once you reapply, let me know and I'll fiddle with jenkins
[20:13:36] <andrewbogott>	 ok, it's back
[20:16:25] <thcipriani>	 <3
[20:16:29] * thcipriani gets to flailing
[23:16:51] <bd808>	 !log logging Added self as project member to work on T369962
[23:16:55] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Logging/SAL
[23:16:55] <stashbot>	 T369962: New beta deployment server unable to connect to logging logstash server in WMCS - https://phabricator.wikimedia.org/T369962
[23:21:03] <bd808>	 !log logging Added rule to scap-access security group to let deployment-deploy04.deployment-prep.eqiad1.wikimedia.cloud submit logs (T369962)
[23:21:05] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Logging/SAL
[23:31:27] <bd808>	 !log logging Removed self from project members
[23:31:29] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Logging/SAL
[23:56:11] <wm-bot>	 !log melos@tools-bastion-13 tools.stewardbots SULWatcher/manage.sh restart # SULWatchers disconnected
[23:56:14] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL