[09:46:07] !log cloudinfra Added recordset for mx-out01.wmflabs.org (T271322) [09:46:10] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Cloudinfra/SAL [09:46:10] T271322: [mx] check what happened to mx-out01.wmflabs.org - https://phabricator.wikimedia.org/T271322 [09:47:01] !log wmflabsdotorg Removing old recorset that has been moved to cloudinfra for mx-out01.wmflabs.org (T271322) [09:47:03] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wmflabsdotorg/SAL [09:49:03] !log cloudinfra Added recordset for mx-out02.wmflabs.org (T271322) [09:49:05] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Cloudinfra/SAL [09:50:19] !log wmflabsdotorg Removing old recorset that has been moved to cloudinfra for mx-out02.wmflabs.org (T271322) [09:50:21] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wmflabsdotorg/SAL [11:16:36] !log account-creation-assistance removing custom mx hosts, as the global names are now resolvable again (T271322) [11:16:39] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Account-creation-assistance/SAL [11:16:39] T271322: [mx] check what happened to mx-out01.wmflabs.org - https://phabricator.wikimedia.org/T271322 [11:35:29] !log admin merging dmz_cidr change (T209082, T267779) [11:35:32] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [11:35:32] T267779: CloudVPS: detail list of dmz_cidr optional NAT addresses to avoid reaching everything in production with internal private VM addresses - https://phabricator.wikimedia.org/T267779 [12:52:51] !admin Taking osd.0 down on codfw ceph cluster to try the disk performance testing process (T271417) [12:52:52] T271417: [ceph] test how disabling the disk cache affects the io throughtput - https://phabricator.wikimedia.org/T271417 [12:53:35] dcaro: syntax is `!log admin ` [12:53:49] hahaha, xd, yep [12:53:58] !log admin Taking osd.0 down on codfw ceph cluster to try the disk performance testing process (T271417) [12:54:01] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [14:38:26] !log tools.lexeme-forms deployed 00d7fe313e (better edit links) [14:38:28] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [14:39:51] !log admin Starting speed tests on cloudcephosd2001-dev sdc (T271417) [14:39:54] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [14:39:54] T271417: [ceph] test how disabling the disk cache affects the io throughtput - https://phabricator.wikimedia.org/T271417 [15:19:39] !log admin Finished speed tests on cloudcephosd2001-dev, reprovisioning the osd.0 sdc (T271417) [15:19:42] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [15:19:43] T271417: [ceph] test how disabling the disk cache affects the io throughtput - https://phabricator.wikimedia.org/T271417 [16:48:53] andrewbogott: is it possible to share the floating IP across two instances? [16:49:19] That is, make it so all outgoing requests originate from the same IP as assigned to my first exec VM for IABot? [16:49:57] Cyberpower678: In theory you could build a load balancer. Otherwise I don't have great ideas how to accomplish that. [16:55:04] No ingoing requests are being made to the IP, I just want the floating IP to be used when making an outgoing request to the net for the purposes of checking dead links. There's been problems with false positives when using the shared IP/ [16:55:12] andrewbogott ^ [16:55:27] Otherwise, I may need a second floating IP for the new VM. [16:56:09] Or an implementation suggestion. I know bd808 has great suggestions for many problems I am trying to solve. [16:56:58] what's the reason for two exec VMs? Could a third VM acting as a forward proxy for the two exec VMs be an option? [16:57:21] stwalkerster the primary exec VM is out of resources. [16:57:32] what resources though? [16:57:36] CPU [16:57:39] and RAM [16:58:07] right, so a forward proxy on another machine might be a good option then [16:58:21] yeah, forward proxy is approximately what I meant by 'load balancer' [16:58:24] if you were out of available network capacity, a forward proxy would not have been usable [16:58:29] otherwise an additional IP is probably the easiest solution [16:58:49] I have no experience with setting those up. [16:59:21] andrewbogott: ah, fair enough. I tend to think of load balancers as specifically a form of reverse proxy :) [16:59:35] It might just be easier to assign a new IP, then to dedicate even more RAM and CPU to just set up a proxy. [16:59:45] stwalkerster your answer was definitely more specific and useful :) [17:02:48] andrewbogott which method would you be most comfortable with. I vote for the IP. [17:03:13] That's probably fine — open a request ticket and the team will discuss [17:03:23] assuming that actually gets you what you need :) [17:03:50] Sounds good. As long as I'm not using the shared IP. :-) [17:05:14] andrewbogott, btw, what's the ticket? [17:05:37] CustosLimen: I mean, you should open a quota request ticket [17:05:52] sorry that should be Cyberpower678 ^ [17:06:18] Oh. [17:06:19] Lol [17:13:46] !log tools.wikibugs Updated channels.yaml to: 07eb5156c9a035b4937a6269dc386d36d3726d18 Update name of SRE project in Phab [17:13:48] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [17:22:54] andrewbogott: https://phabricator.wikimedia.org/T271442 [17:23:55] got it. Unfortunately you're catching us right after our weekly review meeting so it'll be a bit [17:24:05] Sure. [18:10:44] !log tools.wikibugs Updated channels.yaml to: cfb1075f65fe0d4b6b896492846891e24cc5dfd9 Cleanup no longer used projects [18:10:48] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL