864455 - switch slavealloc.{pub,pvt}.build.mozilla.org to the new cluster

Status: RESOLVED FIXED

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

Description

[Dustin J. Mitchell [:dustin] (he/him)]

These vhosts are not yet in use.  slavealloc.pub.b.m.o is a 301 redirect to https://secure.pub.build.mozilla.org/slavealloc, while slavealloc.pvt.b.m.o is an instance of the same slavealloc tool running on slavealloc.build.scl1.mozilla.com, with the same database backend.  This change will have no impact.

We have laid the groundwork to migrate this hostname to the redundant releng web cluster and are ready to make the cutover.  We want to touch base ot make sure that there are no local changes that releng would have made to the system that would be missed and to give you a heads up in case this will necessitate any change in workflow.  Please let us know if you see any reason not to proceed.

Comment 1

[Jake Maul [:jakem]]

Bulk-unassigning releng cluster migrations from me, into the main webops component.

Most (all?) of these come from relengweb1.dmz.scl3. Check /etc/httpd/conf/domains for Apache configs. DocRoots seem to be mostly in /var/www/html, but there's also some stuff in /data/www. There is a NetApp mount with 93GB of data on it... possibly needs migrated, possibly can just be used as-is on the new cluster.

This stuff is all migrating to the new releng webapp cluster in scl3... admin node is relengwebadm.private.scl3.

Dustin and Amy are primary contacts for questions.

Some of this may need to go through CAB... they can advise which ones.

How these are updated is unknown (at least by me). There are user accounts and file ownership permissions in place on relengweb1.dmz.scl3. There are logins in "last", so perhaps people are updating the content directly, by hand.

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

Sorry for the follow-up massive bug update, but we thought it best to avoid confusion.

This site is currently served from relengweb1.dmz.scl3, but is already set up and running on the releng cluster.  There's no technical work to do here, and no need to worry about the (ugly, weird) way things are hosted on relengweb1.  All that remains is to change the CNAME.  And to do that, we need either CAB permission, releng sign-off, or a decision to move forward with neither.

As a sanity check, I'd like to make one last comparison of the old and new clusters just before flipping the switch, just in case something has been changed since the last three times I made that check.

The new configuration is, as near as I could get it, a "normal" webapp configuration.  Jake had a look and didn't see anything unusual or surprising, so I think I did OK.  Updates are via normal push procedures for sites with code, and via puppet changes to the Apache config for code-free sites.  Docs for all sites are in Mana.

Comment 3

[Chris Cooper [:coop] (he/him)]

How does this bug relate to bug 863266 and bug 773057? Can either of those other bugs be duped forward to this one?

Also, I asked previously about being able to access slavealloc api data over https (at https://secure.pub.build.mozilla.org/slavealloc or similar):  is this the right bug to continue pursuing that? I'm motivated to help, if that's useful.

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

Bug 863266 requires this bug as well as bug 773057.  I'll update deps accordingly.

Honestly, the only change here is to change the secure.pub.build.mozilla.org CNAME to point to the new cluster; slavealloc.pvt.build.mozilla.org is already pointing there, if you'd like to get started on bug 773057.  Motivation's always a good thing :)

As for SSL access, yep, that's ready to roll -- it's half of bug 773057.

Comment 5

[Dustin J. Mitchell [:dustin] (he/him)]

DNS changed at 10am PDT today with no issues.