1139188 - remove username from UserProfile model (with minimal downtime)

Status: RESOLVED FIXED

(Marketplace Graveyard :: Code Quality, defect, P3)

Description

[Kumar McMillan [:kumar]]

+++ This bug was initially created as a clone of Bug #1131717 +++

Marketplace doesn't expose the 'username' field anywhere, and post FxA its just a hex number string anyway.  So lets change any code checking it to use email or id and remove it.

The patch landed in bug 1131717 but was partially reverted in https://github.com/mozilla/zamboni/pull/2959

We want to re-introduce this patch but in a way that will not incur excessive downtime in prod. The old approach would have left us with a 3 minute window when the database was out of sync with running code, thus causing tracebacks during user login.

Comment 1

[Kumar McMillan [:kumar]]

There is maybe a plan: https://etherpad.mozilla.org/mkt-no-downtime

Comment 2

[Kumar McMillan [:kumar]]

mat says this is fixed

Comment 3

[Mathieu Pillard [:mat]]

We applied the plan detailed in the etherpad on the following push (2015-03-10) and it worked:

    Background: Currently, in stage/prod, we have a username field in the model and a username column in the db. The tag we're about to deploy wants fxa_uid column to exist, with the data from username, at least for the users who have fxa_uid stored in the username (those with username length == 32)

    1. Before deploying the tag, we do the following with the database rotation strategy:

    DROP INDEX `username` ON `users`; -- on stage, it's called `fxa_uid` because of how we reverted the initial migration, so that needs to be tweaked for stage.

    ALTER TABLE `users` CHANGE `username` `username` varchar(255) NULL DEFAULT NULL

    ALTER TABLE `users` ADD COLUMN `fxa_uid` varchar(255) NULL DEFAULT NULL;

    UPDATE users SET fxa_uid=username WHERE LENGTH(username) = 32;

    if the username is not that length will it be NULL? If so, won't the unique index fail?

    we're dropping the unique constraint first, only adding it back for fxa_uid, which is set to allow (and default to) NULL

    CREATE UNIQUE INDEX `fxa_uid` ON users(fxa_uid);

    UPDATE users SET last_login=last_login_attempt WHERE last_login = '1970-01-01 00:00:00' AND last_login_attempt IS NOT NULL

    2. Deploy the tag normally, but only after the above query is done.

    3. Do the following once the deploy is over with the database rotation strategy:

    UPDATE users SET fxa_uid=username WHERE LENGTH(username) = 32 and fxa_uid IS NULL; -- to get any records added during the transition

    ALTER TABLE `users` DROP COLUMN username, DROP COLUMN last_login_attempt, DROP COLUMN last_login_attempt_ip, DROP COLUMN failed_login_attempts;

Notes:

    The drop index statement in step 1 removes the  unique constraint - necessary because of the weird data we have - the  alternative is to figure out which utf8 collation to use when ALTERing  and hoping it works

    We could directly set the fxa_uid column to 32. But this would not match dev and the code, so let's take care of that later in the future...