currently we are using only hg.m.o and that means we share the same paths and constraints as public facing HG access
bkero: should we also be using 'hg clone --uncompressed' as much as possible with this move?
from irc: 1) this seems to be related to yesterday's hg migration, but unclear. 2) is "use hg-internal.m.o instead of hg.m.o" to be done as well as (or instead of?) using the two hg mirrors?
Component: Release Engineering → Release Engineering: Automation (General)
QA Contact: release → catlee
catlee: hg clone --uncompressed should be used (using the 'hg checkout --uncompressed http:// interface) only when using the hg-internal.dmz.scl3.mozilla.com address. joduinn: it was originally going to be related to the hg migration, although I did not get clearance from opsec in time for these both to happen concurrently. The hg mirrors can be used in case of network connectivity problems between scl1 and scl3. We should re-evaluate if the hg mirrors in scl1 are necessary.
Assignee: nobody → catlee
Priority: -- → P3
Created attachment 615833 [details] [diff] [review] add hg-internal as the first mirror mirrors are tried in order, so in theory this will try the new hg-internal mirror first before falling back to the old mirror.
Attachment #615833 - Flags: review?(bear)
Summary: all inside-the-build requests for HG should use hg-internal.m.o instead of hg.m.o → all inside-the-build requests for HG should use hg-internal.dmz.scl3.m.c instead of hg.m.o
Attachment #615833 - Flags: review?(bear) → review+
deployed in today's reconfig
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.