Closed Bug 1216019 Opened 9 years ago Closed 9 years ago

Add docs for aus5.mozilla.org

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nthomas, Assigned: cliang)

References

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1969] )

Bug 1179339 added aus5.mozilla.org, which is served by the same backend as aus4.mozilla.org but has a different SSL cert at the ZLB. I'd like to make sure there are some docs for this, to save on confusion when issues are reported, or the cert comes up for renewal.

The existing docs are at
 https://mana.mozilla.org/wiki/display/websites/aus4.mozilla.org

WebOps style wins, but if you want a suggestion add a .../websites/aus5.mozilla.org page which redirects to the link above, and add additional comments there. FWIW, on the Releng-side we think of the 'cluster' as Balrog, which then serves aus4.m.o and aus5.m.o. Any code update will affect both equally, despite all the aus4's in all the deployment setup.
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1969]
Assignee: server-ops-webops → cliang
I've done some re-arranging WRT to the AUS-related docs.
   * updated https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=8062552 to indicate that it discusses the back end infrastructure used by aus[2-5].mozilla.org
   * updated the title to keep aus4.mozilla.org and aus5.mozilla.org in the title (search-bait)
   * added other bits of search bait (expressly listing aus[2-5].mozilla.org, adding labels)
   * moved aus2.mozilla.org and aus3.mozilla.org documentation into an archive directory
   * added warning + links redirecting back to "balrog" general document to the top of aus2.mozilla.org and aus3.mozilla.org documentation

Can you please give things a look-see and tell me if there's more that needs to be added / updated?
LGTM. I see there are some details of VIPs in scl3, are any other changes needed for the phx1 evac ?
For the most part, we kept using the same IP addresses to reduce the number of changes that might complicate the EVAC.  We did have to change "public" VIPs because of VLAN changes; there were no network changes that required us to change server IPs or database IPs.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.