If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

QA and deploy BrowserID train-2012.05.14 to production



Cloud Services
Operations: Deployment Requests
6 years ago
6 years ago


(Reporter: lloyd, Assigned: petef)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [qa+])



6 years ago
+++ This bug was initially created as a clone of Bug #749756 +++

Version: 8d9fc6d (0.2012.05.14.1) branch train-2012.05.14

Tests pass: http://travis-ci.org/#!/mozilla/browserid/builds/1328209

ChangeLog including issues resolved: 

[QA] Suggested additional areas of focus for QA:
  * focus on first time sign-in with verification in the same and different browsers.
  * normal regression of closed issues mentioned in ChangeLog
  * test 123done.org

[ops] deployment issues:
  * SCHEMA CHANGES:  passwd CHAR(64) added to staged table - this field may be added before deployment, it will not break current code
  * REQUIRED NEW CONFIGURATION: we need a new json configuration value, kpi_backend_sample_rate set to 0.0 (number).

IMPORTANT NOTE: There is an outstanding issue that could derail this train related to expected user impact during deployment of this train: https://github.com/mozilla/browserid/issues/1592


6 years ago
Assignee: nobody → petef
No longer depends on: 744689
QA Contact: operations-deploy-requests → jbonacci


6 years ago
For #1592, QA should start the process of creating accounts with the current code in Stage. We should not verify those through email.
We should also attempt some password changes, but hold off on verifying those as well.
Then, we can have petef roll the code to 2012.04.14 and then attempt to click through those new account and password change links to see what happens.
Whiteboard: [qa+]
No longer blocks: 747738
Some possible tests to try:
1. brand new account
2. adding secondary to acct with only primary
(3. adding primary to account with only secondary)
(4. adding primary to primary)
5. adding secondary to acct w/ secondary
6. resetting a forgotten password

Comment 3

6 years ago
DB change note: since browserid.staged is so small, not bothering with pt-online-schema-change, so just running "alter table staged add column passwd char(64);" on the master and letting the DDL replicate to slaves.

Comment 4

6 years ago
ok, pushed to stage (db change, config change, and new RPM).
QA accepts this train to Stage:
8d9fc6d merge hotfixes from train-2012.04.27
locale svn r105177
:petef can you update the clientX boxes for QA?

Comment 7

6 years ago
(In reply to James Bonacci [:jbonacci] from comment #6)
> :petef can you update the clientX boxes for QA?
> Thanks!

updated those & l10n-preview
:jrgm and :ioana.budnar - sorry for being remiss in my duties here....
Release wiki:

Test Plan spreadsheet:
QA signs off on this (non-shipping) train. 
- verifications done
- load_gen stopped today @11:50, since we'll be pushing out a new train in a
  - web3.idweb.scl2.stage was rebooted during the test due to a hardware issue
  - still see occasions when the LB will have spurts of unavailability
    (returns Service Unavailable message). Also other ECONNREFUSED errors that
    can't be correlated to backend problems.
  - I've seen a few more cases where there are single errors that do appear to
    be real, but the logs don't leave any context about what happened. 
  - 7 errors on the backend that report "error forwarding request to
    keysigner: Error: getaddrinfo ENOENT" (or forwarding to dbwriter). They
    all happened at 3 specific times on 2012-05-22, so not seemingly code 

Comment 10

6 years ago
Since QA has signed off and we're not shipping this to prod, closing this for now.
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Final updates here:


6 years ago
Blocks: 758840
You need to log in before you can comment on or make changes to this bug.