Page MenuHomePhabricator

Update CentralAuth migration scripts to populate new lu_local_id and lu_global_id fields during migration
Closed, InvalidPublic3 Story Points

Description

Make sure the migration scripts for CentralAuth (migratePass0.php and migratePass1.php) take the new fields into account and populate them with the right data (especially since we might be making those fields NOT NULL at some point).

Event Timeline

kaldari created this task.Oct 25 2016, 7:55 PM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptOct 25 2016, 7:55 PM
kaldari set the point value for this task to 3.Oct 27 2016, 5:10 PM
kaldari moved this task from To be estimated/discussed to Estimated on the Community-Tech board.
Niharika claimed this task.Nov 9 2016, 2:48 PM
Niharika moved this task from Ready to In Development on the Community-Tech-Sprint board.
Niharika added a subscriber: Tgr.Nov 14 2016, 1:16 PM

From my investigation into this task, I think we don't need to do anything special for migration purposes because the actual column population happens in the CentralAuthUser::attach() function. From what I found out almost all paths in maintenance/migrateAccount.php use the same function during migration.

@Tgr - does that seem correct?

@Niharika: migrateAccount.php is probably fine, but I think migratePass0.php and/or migratePass1.php might need to be updated.

@Niharika: migrateAccount.php is probably fine, but I think migratePass0.php and/or migratePass1.php might need to be updated.

I am not so sure. Neither of those scripts seem to touch the localuser table from what I can see. They seem to affect globalnames and localnames tables only.

Tgr added a comment.Nov 14 2016, 7:03 PM

Is there a point in touching those scripts? Wikimedia does not need them anymore, no one else is likely to do CentralAuth migrations, and CentralAuthUser would populate the fields eventually anyway.

I am not so sure. Neither of those scripts seem to touch the localuser table from what I can see. They seem to affect globalnames and localnames tables only.

@Niharika: It looks like migratePass1.php calls CentralAuthUser::storeAndMigrate(), although I'm not sure what that function does exactly. It seems like the localuser table would have to be populated at some point during the migration, but I haven't verified this.

Is there a point in touching those scripts? Wikimedia does not need them anymore, no one else is likely to do CentralAuth migrations, and CentralAuthUser would populate the fields eventually anyway.

@Tgr: If we're not going to support those scripts any more, they should be deleted and a big warning should be put at https://www.mediawiki.org/wiki/Extension:CentralAuth that there is no way to migrate an existing wikifarm to CentralAuth. Are there other devs we should ping about getting consensus to do that?

@Niharika: It looks like migratePass1.php calls CentralAuthUser::storeAndMigrate(), although I'm not sure what that function does exactly. It seems like the localuser table would have to be populated at some point during the migration, but I haven't verified this.

Yes, I did look into that. That function in turn calls attemptAutoMigration() which also ultimately calls the attach() function. I am pretty sure that attach() function is used in nearly every migration pathway so we need not worry about this.

Tgr added a comment.Nov 15 2016, 5:45 PM

@Tgr: If we're not going to support those scripts any more, they should be deleted and a big warning should be put at https://www.mediawiki.org/wiki/Extension:CentralAuth that there is no way to migrate an existing wikifarm to CentralAuth.

Migrations would still work, nothing in CentralAuth relies on the new fields being populated, and they get auto-filled eventually anyway.
(Not saying Niharika is not right - I didn't check. But even if some migration paths do not populate the fields, it's not an issue IMO.)

kaldari closed this task as Invalid.Nov 15 2016, 11:53 PM

OK, I'm gonna take y'all's word for it and close this as invalid.