please deploy tag 0.1.1 on stage then on production after QA validation Thanks
Deploying to stage.
Assignee: nobody → bobm
Status: NEW → ASSIGNED
This has been deployed to stage.
First deployment to stage didn't stick, so Bob is investigating stack-building issues. We're online in the #absearch channel, if you want/need real-time updates.
Updating gevent to 1.1rc3 and boto to 2.39.0 seems to fix the issue. I have tried to install using the same commands from build_rpm and it looks fine. I have tagged 0.1.2 with the new pins
Thanks Bob and Karl for staying late on this one <3
0.1.2 has been deployed to Stage.
Can we deploy 0.1.3 for a last minute change. thank you
0.1.3 has been deployed to Stage.
Created attachment 8713369 [details] Test output for 0.1.3 on stage, 2016-01-28 I note that the 'cohort' key is new, and that there are now apparently three buckets each for TW and HK, whereas in https://bug1242065.bmoattachments.org/attachment.cgi?id=8711207&t=cpSyotCJsYwVLfRL942Rkp there were only two. Again I ask, is there some sort of spec I can consult to determine whether these are desired results?
Looking at it again, the extra 'bucket' is caused by the fact that the control cohorts were not distinguishable from the default before the addition of the 'cohort' key/value. So the test looks reasonable. :bobm, please ship this to prod at your earliest convenience.
:jp will be deploying this to production presently.
The deployment stack is complete and up, and kthiessen is kindly testing it for us. We'll update search.services.mozilla.com R53 alias with absearch1-abse-ELB-18DN5O07LFWAR once given the all clear.
Old stack in prod dualstack.absearch1-abse-elb-187qhnk00qrdu-969890898.us-west-2.elb.amazonaws.com. New Stack in prod dualstack.absearch1-abse-ELB-18DN5O07LFWAR-1443881701.us-west-2.elb.amazonaws.com DNS was flipped at 0:10:00 UTC.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.