Closed Bug 971137 Opened 7 years ago Closed 7 years ago

please deploy fxa* train-01 branch to stage

Categories

(Cloud Services :: Operations: Deployment Requests - DEPRECATED, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: edwong, Assigned: jrgm)

Details

(Whiteboard: [qa+])

qa is going to attempt via self-deploy stack instructions
Nice. Ryan and I will be watching...
Whiteboard: [qa+]
I built the auth server rpm. The content server build needs the fix I describe in https://github.com/mozilla-services/svcops-oompaloompas/issues/28#issuecomment-34840539.
I've merged the fix in to PR #22 which is what's referenced from the self service build page. It should work now. jrgm, make sure you're using the tools linked from the self service build page since those are not "master", they're a PR that has working code in it.
Assignee: nobody → jrgm
This is progressing not so fast, as a number of access control problems have cropped up.
Ok, so api-accounts.stage.mozaws.net now points to a new cloud formation stack for fxa-auth-server.
I'll do fxa-content-server in a bit.

There's a small issue where the auth server reports the wrong version (rpm build issue). I'll probably replace the auth server stack with one that is fixed in a bit as well.
:jrgm that's sounds fine. The load testing was not scheduled to happen until Monday/Tuesday, so feel free to replace the auth server stack, as needed.

IRC chatter includes discussion on dropping all the leftover CF stacks and content/auth instances in US East.

Thanks all.
Okay, I rebuilt rpms with this fix - 

And then built new cloud formation stacks for auth-server and content-server in stage for the branch `train-01` in the respective repositories for each. 

Finally switch of DNS is below:

[ec2-user@ip-10-31-154-243 aws-tools]$ ./bind_dns.py accounts.stage.mozaws.net us-east-1 fxa-s-c-2 ContentServerELB
INFO:root:Waiting for DNS change to sync across AWS
INFO:root:Waiting for DNS change to sync across AWS
INFO:root:Waiting for DNS change to sync across AWS
INFO:root:Waiting for DNS change to sync across AWS
INFO:root:DNS Change completed.
[ec2-user@ip-10-31-154-243 aws-tools]$ ./bind_dns.py api-accounts.stage.mozaws.net us-east-1 fxa-s-a-9 AuthServerELB
INFO:root:Waiting for DNS change to sync across AWS
INFO:root:Waiting for DNS change to sync across AWS
INFO:root:Waiting for DNS change to sync across AWS
INFO:root:Waiting for DNS change to sync across AWS
INFO:root:DNS Change completed.
[ec2-user@ip-10-31-154-243 aws-tools]$
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Moving on to Train 2.
Status: RESOLVED → VERIFIED
:jrgm please depl0y train-01 to stage since it has a hot patch so we can verify then push to prod.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
change of plans, I didn't train 02 had been pushed to stage. Let's try and push to dev stack - I'll ask Chris
chris said OK to deploy to dev. train-01 at e43ef01669ee97f56d511a4786109a1fc2a13d29
Okay, I updated stage to train-01+logging-patch @ e43ef01669ee97f56d511a4786109a1fc2a13d29 (after talking with edwin that it was not a problem to repoint stage away from train-02 temporarily). Going to do some testing there now.
So I've run remote and a mild load test against stage and looks good (mild load, to not trigger using up on all the mysql connections, which I subsequently have now done). SO the rpm that is s3 can go to production for fxa-auth-server: 
s3://net.mozaws.ops.rpmrepo-stage/6/x86_64/fxa-auth-server-svcops-0.9.0-20140219gite43ef01.el6.x86_64.rpm
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
OK. Cool. We should open a new ticket for train-02 to Stage IF we are going to go that far this week.
Otherwise I will test of this Stage...
You need to log in before you can comment on or make changes to this bug.