Set up alternate IP/DNS for hg

RESOLVED WONTFIX

Status

Infrastructure & Operations Graveyard
WebOps: Product Delivery
RESOLVED WONTFIX
5 years ago
2 years ago

People

(Reporter: catlee, Unassigned)

Tracking

Details

(Reporter)

Description

5 years ago
+++ This bug was initially created as a clone of Bug #964486 +++

Can we please set up a new DNS name and IP address for hg.m.o?

We need to divert some traffic out of our VPN tunnel to the public internet. We'd like to move SSL traffic to/from hg outside the VPN, but that requires us to have a different IP to adjust the routing tables.

Let's use 'hg-ssl.m.o' as the name.
(Reporter)

Updated

5 years ago
Blocks: 960571
i just mentioned this to :laura, we're going to have to be *extremely* careful with this request. i have sought advise from the source control experts here, but my initial concerns are the following:

1. ssl certificate change on hg to accommodate the hg-ssl subject alternative name - will this impact current development?

2.server aliases - so that we dont have to send customer host headers or the like, we'll need to add a server alias of hg-ssl. this is straight forward in apache, but can it be done gracefully in mercurial? 


i will be having a pow-wow later this afternoon with our source control folks to get their take on this change and report back with my findings.
(Reporter)

Comment 2

5 years ago
The bulk of our traffic is for hg-internal.dmz.scl3.mozilla.com, which is internal only AIUI. We'd need a public IP and name for this.
(In reply to Chris AtLee [:catlee] from comment #2)
> The bulk of our traffic is for hg-internal.dmz.scl3.mozilla.com, which is
> internal only AIUI. We'd need a public IP and name for this.

this adds another layer of complexity here. hg-internal.dmz.scl3 is served on an internal only zeus cluster. on this internal (only) cluster we cannot add an external ip. without a major overhaul, that would likely require downtime, we cannot get this done.
Actualy.

The hg-internal has a pool that is made from

10.22.74.37
10.22.74.38
10.22.74.39

The servers are in the DMZ Vlan and subnet and accessible from the generic ZLB "external" cluster. They are actually configured as a part of the larger pool behind the hg.m.o VIP

10.22.74.33
10.22.74.34
10.22.74.35
10.22.74.36
10.22.74.37
10.22.74.38
10.22.74.39

TL;DR nothing prevents us from creating a new virtual server, VIP and using just the three servers we need as a backend.
(In reply to Michal Purzynski [:michal`] (use NEEDINFO) from comment #4)
> Actualy.
> 
> The hg-internal has a pool that is made from
> 
> 10.22.74.37
> 10.22.74.38
> 10.22.74.39
> 
> The servers are in the DMZ Vlan and subnet and accessible from the generic
> ZLB "external" cluster. They are actually configured as a part of the larger
> pool behind the hg.m.o VIP
> 
> 10.22.74.33
> 10.22.74.34
> 10.22.74.35
> 10.22.74.36
> 10.22.74.37
> 10.22.74.38
> 10.22.74.39
> 
> TL;DR nothing prevents us from creating a new virtual server, VIP and using
> just the three servers we need as a backend.

i didn't know this! thnx :michal`. let me review this further.
so after much discussion and discovery (i am new to our hg setup), i found that there are no differences between the hg-internal and the hg pool nodes. additionally, ssl is enforced on hg.mozilla.org, which solves this very bug. 

all you should need to do is switch from using hg-internal.dmz.scl3.mozilla.com to hg.mozilla.org. let me know how this works out (or if i missed something obvious).
Status? I believe for other reasons, we decided not to pursue the alternate IP address plan.

Can we resolve this WONTFIX?
:lauara - i will defer this to you. i'm not currently up to speed on the current status of this.
Flags: needinfo?(laura)
we decided in meeting okay to not pursue at this time.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(laura)
Resolution: --- → WONTFIX
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.