[09:15:51] <gifti>	 taavi: somehow it still does. at least for my generic webservice it did
[09:17:41] <wm-bot>	 !log tools.bridgebot <lucaswerkmeister> Triple IRC messages to other bridges
[09:17:44] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.bridgebot/SAL
[10:50:32] <jelto>	 hi all o/ Is it possible to create deny security rules in horizon for a project? It seems all rules are allow rules based on a default reject. I'd like to introduce another reject rule. Is this possible?
[11:29:56] <taavi>	 jelto: at least I don't see any options for that.. what's your use case?
[11:33:33] <jelto>	 taavi: restrict outgoing traffic to specific destinations for CI workers (gitlab-runner in wmcs)
[15:06:10] <Rook>	 !log paws T318273 Upgrade jupyterlab b342570b6bf55ebc5b3965f7d1fffa5cb4d06157
[15:06:13] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Paws/SAL
[15:06:14] <stashbot>	 T318273: upgrade jupyterlab - https://phabricator.wikimedia.org/T318273
[15:57:07] <andrewbogott>	 jelto: I'm not sure if there are explicit deny rules. The default is to deny everything so you could create an 'everything but' allow rule but that might be tedious
[15:58:58] <andrewbogott>	 jelto: you can also use 'remote -> security group' to permit only access to other members of a given security group.  That might be what you need.
[15:59:51] <jelto>	 great I'll try that! thanks for the recommendation
[16:01:36] <Cyberpower678>	 andrewbogott: my cinder storage is gone
[16:01:41] <Cyberpower678>	 My DB is offline
[16:01:56] <Cyberpower678>	 I'm actively using it right now.
[16:03:40] <Cyberpower678>	 Rebooting is not fixing the problem
[16:04:04] <Cyberpower678>	 andrewbogott: ^
[16:04:35] <andrewbogott>	 Cyberpower678: probably your just was rebooted and not recovering from the reboot? I just rebooted all bullseye VMs
[16:04:50] <Cyberpower678>	 No it didn't
[16:05:03] <Cyberpower678>	 I can't seem to access my cinder storage.
[16:05:27] <Cyberpower678>	 This was the absolute worst time for it to go down right now
[16:06:32] <andrewbogott>	 can you tell me what VM you're looking at, and what you mean by "can't access cinder storage"?
[16:06:40] <Cyberpower678>	 cyberbot-db-01
[16:06:46] <Cyberpower678>	 On the cyberbot project
[16:07:22] <Cyberpower678>	 It's supposed to mount under /srv
[16:08:31] <Cyberpower678>	 andrewbogott: ^
[16:09:32] <andrewbogott>	 you don't have an /etc/fstab entry for that volume so I wouldn't expect it to mount on reboot.
[16:09:39] <andrewbogott>	 Did you mount it by hand earlier?
[16:10:29] <Cyberpower678>	 No, it should have an fstab entry there.
[16:10:46] <Cyberpower678>	 Something nuked it
[16:11:07] * Cyberpower678 mounts the volume again
[16:13:57] <Cyberpower678>	 andrewbogott: thanks for catching that.  I will have to fix the fstab.  No idea why the entry to mount the storage got lost.
[16:14:09] <andrewbogott>	 sure thing -- you're unstuch for now?
[16:14:12] <andrewbogott>	 *unstuck
[16:14:27] <Cyberpower678>	 Yes.  MariaDB sprang back to life now
[16:15:39] <Cyberpower678>	 Thank you
[18:04:37] <RhinosF1>	 taavi, TheresNoTime: stashbot needs a poke
[18:24:41] <TheresNoTime>	 RhinosF1: (or someone) can you do me a favour? Can you remove me from the deployment calendar this week (UTC late) — I'm at the CommTech off-site but not near a laptop atm
[18:25:11] <RhinosF1>	 TheresNoTime: I'm mobile atm
[18:26:00] <RhinosF1>	 Need to eat soon
[18:26:00] <TheresNoTime>	 Darn
[18:26:00] <RhinosF1>	 Then I will forget
[18:26:00] <TheresNoTime>	 :D
[18:26:00] <RhinosF1>	 Because my memory is ye
[18:26:03] * TheresNoTime will do it later ^^
[18:27:58] <wm-bb>	 <lucaswerkmeister> TheresNoTime: done
[18:28:28] <TheresNoTime>	 Thank yoy?!
[18:28:37] <TheresNoTime>	 Oops, *thank you!
[18:28:41] <wm-bb>	 <lucaswerkmeister> :D
[18:34:35] <RhinosF1>	 Lucas_WMDE: can you poke stashbot too?
[18:42:48] <RhinosF1>	 It is back
[18:42:54] <RhinosF1>	 Wmopbot died though now
[19:08:53] <danilo>	 for some reason wmopbot get its connection to IRC muted for approximately 15 minutes in those restarts, that is the time it delays to know the connection was closed, the last stashbot restart seems to has had the same delay, maybe that info help someone to discover what is happening with the bots
[19:41:16] <bd808>	 The code for stashbot actively pings the upstream IRC server and kills itself after 2 consecutive missed pings. In practice I think it would take ~15 minutes for that to kick in and cause a Kubernetes pod restart.
[19:41:25] <bd808>	  The bot's pod has been running for nearly 4 days now which makes me think that the recent ping timeout and rejoin here is netsplit activity, not something local to Toolforge. I may be misunderstanding that data though.