[01:17:35] <wikibugs>	 10netops, 06Operations, 10ops-codfw: audit network ports in a4-codfw - https://phabricator.wikimedia.org/T140935#2481487 (10faidon) @RobH, try `show lldp neighbors` (with or without `| match ge-4` at the end).
[11:37:10] <ema>	 bblack: I'm not even convinced it's a good idea, but: https://gerrit.wikimedia.org/r/#/c/300249/
[11:38:13] <ema>	 found the "redundancy" while writing https://gerrit.wikimedia.org/r/#/c/299543/4/modules/varnish/files/tests/upload/08-frontend-cors.vtc 
[12:32:49] <bblack>	 ema: It's redundant in V3, but vcl_synth and vcl_deliver are separate output paths in V4.
[12:33:03] <bblack>	 http://book.varnish-software.com/4.0/_images/simplified_fsm.svg
[12:49:32] <ema>	 bblack: I've seen that but funnily enough the test passes on v4 too
[12:49:59] <bblack>	 even with the line from the patch removed?
[12:50:05] <ema>	 yup
[12:50:41] <ema>	 let me check again though
[12:50:45] <ema>	 perhaps I've done something wrong
[12:50:54] <bblack>	 I'm pretty sure we've seen that they're separate in the wild, with the complexities around our X-Cache VCL and how parts of that didn't work until it was called in duplicate from deliver/synth
[12:51:00] <bblack>	 but I guess I'm not 100% sure
[12:51:36] <ema>	 ha! you're right
[12:51:51] <ema>	 I've removed the line from /etc/varnish/, not /usr/share/varnish/tests
[12:51:56] <ema>	 (doh)
[12:52:02] <bblack>	 it happens at least once a month
[12:58:11] <hashar>	 good morning/ciao.  Had a lame gdnsd question for you guys :}
[12:58:23] <bblack>	 the answer is 42
[12:58:39] <hashar>	 would it be feasible to have a bastion.wikimedia.org DNS entry that is geographically balanced between the bastXX01.wikimedia.org hosts ? 
[12:58:53] <hashar>	 just wondering, not asking for it to be implemented :-}
[12:58:54] <bblack>	 yes
[12:59:13] <bblack>	 that might be confusing for ssh's saved server host keys, though
[12:59:23] <bblack>	 unless we explicitly set them all the same, maybe?
[12:59:29] <hashar>	 yeah would need to have the host key to be the same on all bastion
[12:59:51] <hashar>	 so yeah lot of madness / maintenance for little gain :D
[13:00:05] <hashar>	 thank you!
[13:00:23] <bblack>	 the DNS part is pretty trivial.  the hostkey part could probably be puppetized.  it's an interesting idea.
[13:00:37] <bblack>	 we could also have gdnsd monitor TCP connect to port 22 and depool ones it can't reach.
[13:01:00] <hashar>	 then the host private key would have to be centrally managed, and hence saved in the private.git repo which might not be much of a good idea
[13:01:18] <bblack>	 hashar: there might be ways around that
[13:01:27] <hashar>	 the idea was to have a graceful failover whenever a bastion host dies for some reason
[15:12:39] <wikibugs>	 10netops, 06Operations, 10fundraising-tech-ops: Cleanup layer2 firewall config from pfw-eqiad - https://phabricator.wikimedia.org/T111463#2483519 (10Jgreen)
[15:15:25] <wikibugs>	 10netops, 06Operations, 10fundraising-tech-ops: Cleanup layer2 firewall config from pfw-eqiad - https://phabricator.wikimedia.org/T111463#2483531 (10Jgreen) p:05Low>03High bumping to high because this blocks adding pfw ports, which in turn blocks hardware refreshes
[15:20:01] <wikibugs>	 10netops, 06Operations, 10fundraising-tech-ops, 10ops-eqiad: put pfw1- ge-2/0/11 in the 'fundraising' vlan for new host frqueue1001 - https://phabricator.wikimedia.org/T140991#2483556 (10Jgreen)
[15:22:22] <wikibugs>	 10netops, 06Operations, 10fundraising-tech-ops, 10ops-eqiad: put pfw1- ge-2/0/11 in the 'fundraising' vlan for new host frqueue1001 - https://phabricator.wikimedia.org/T140991#2483582 (10Jgreen)
[15:33:04] <wikibugs>	 10netops, 06Operations, 10ops-codfw: audit network ports in a4-codfw - https://phabricator.wikimedia.org/T140935#2483624 (10Papaul) ge-4/0/0 up up mw2239 ge-4/0/1 up up mw2240 ge-4/0/2 up up mw2241 ge-4/0/3 up up mw2242 ge-4/0/4 up up mw2243 ge-4/0/5 up up mw2244 ge-4/0/6 up up mw2245 ge-4/0/7 up up mw2246 g...
[15:47:13] <wikibugs>	 07HTTPS, 10Traffic, 06Operations, 06WMF-Communications, 07Security-Other: Server certificate is classified as invalid on government computers - https://phabricator.wikimedia.org/T128182#2483662 (10Florian)
[16:14:42] <wikibugs>	 10netops, 06Operations, 10ops-eqiad: Upgrade cr1/cr2-eqiad JunOS - https://phabricator.wikimedia.org/T140770#2483833 (10faidon)
[16:17:40] <wikibugs>	 10netops, 06Operations, 10ops-eqiad: cr1/cr2-eqiad: install new SCBs and linecards - https://phabricator.wikimedia.org/T140764#2483845 (10faidon)
[16:17:42] <wikibugs>	 10netops, 06Operations, 10ops-eqiad: Replace cr1/2-eqiad PSUs/fantrays with high-capacity ones - https://phabricator.wikimedia.org/T140765#2483842 (10faidon) 05Resolved>03Open @cmjohnson, if I recall correctly, you swapped cr2's fantray with the new one but not cr1's, since they were the exact same model...
[16:40:58] <wikibugs>	 10netops, 06Operations, 10ops-eqiad: Upgrade cr1/cr2-eqiad JunOS - https://phabricator.wikimedia.org/T140770#2483946 (10faidon) OK, today we upgraded JunOS on cr2-eqiad to 13.3R9, as well as swapped the SCBs with new ones.  The JunOS upgrade all generally worked without many issues and took about ~2hrs. The...
[16:42:18] <wikibugs>	 10netops, 06Operations, 10ops-eqiad: cr1/cr2-eqiad: install new SCBs and linecards - https://phabricator.wikimedia.org/T140764#2483971 (10faidon) cr2's SCBs were upgraded today, which didn't go very smoothly for various reasons. T140770 has the full writeup.  cr2 still doesn't have the new linecard install,...