AuthManager is currently behind a feature switch ($wgDisableAuthManager) so its code is never executed. This is intended to be a temporary measure to smoothen the rollout and should be disabled and then ripped out as soon as possible.
Description
Details
Event Timeline
Change 280945 had a related patch set uploaded (by Gergő Tisza):
Remove $wgDisableAuthManager
Change 291782 had a related patch set uploaded (by Gergő Tisza):
[HOLD] Enable AuthManager on beta wikitech
It is only used on login / account creation (and only normal login, not CentralAuth autologin), and to a mininal extent on Special:Preferences (and in the users API but only if you ask for a non-default property); those might get slower, although I would expect execution time to be dominated by DB writes, in which there was very little change. So I wouldn't expect any impact (but we should definitely monitor for it).
Also password change, including the account recovery temporary password.
(and only normal login, not CentralAuth autologin),
But it is involved when CentralAuth autologin triggers auto-creation of the local account.
and in the users API
Specifically, that's ApiQueryUsers (api.php?action=query&list=users).
One other thing that might impact performance for logins and account creations is that AuthManager uses the Session secret thing you patched for unit tests in https://gerrit.wikimedia.org/r/#/c/291503/. I don't think anything else uses that yet, although OATHAuth uses very similar code when logging in with two-factor.
Is there any difference between that code and the SessionManager autocreation code? IIRC it was just moved over to the new class.
(Well, a bunch of provider callbacks get called, but CentralAuth is the only one that actually implements that and it doesn't do anything it didn't do before.)
That, and the providers getting called for testUserForCreation() (although most probably did AbortAutoAccount before), and the account creation lock.
I'll try enabling in beta today. The only missing bits are things logging into zerowiki (T135074, T135698) which is not affected and TranslationNotifications logging into other wikis (T110766) which is probably not affected, and worst case it breaks translation notifications on beta, which we can live with. OTOH the extra testing time for CentralAuth will be very valuable.
Mentioned in SAL [2016-06-01T16:54:02Z] <tgr@tin> Synchronized wmf-config/InitialiseSettings-labs.php: T135504: enable AuthManager in beta (duration: 00m 32s)
Change 291782 abandoned by Gergő Tisza:
[HOLD] Enable AuthManager on beta wikitech
Reason:
Was done via Ic4b4f9665ee9a08b6b1d7b3736797a2e906d5f63 instead.
Change 291782 restored by Gergő Tisza:
[HOLD] Enable AuthManager on beta wikitech
Reason:
Apparently beta wikitech is not really beta (it's not affected by the -labs.php config files) so this is still needed.
Change 293086 had a related patch set uploaded (by Gergő Tisza):
Do not set wgAuth to LdapAuth when AuthManager is enabled
Change 293091 had a related patch set uploaded (by Gergő Tisza):
Update audit hooks for AuthManager
Change 293086 merged by jenkins-bot:
Do not set wgAuth to LdapAuth when AuthManager is enabled
Change 293227 had a related patch set uploaded (by Gergő Tisza):
Enable AuthManager on group0
Mentioned in SAL [2016-06-07T22:56:44Z] <tgr> scapping AuthManager backports + feature switch enabled on group0 T135504
https://gerrit.wikimedia.org/r/#/c/293130/ is a blocker for deploying to wikitech (group1). I hope I can test it tomorrow; if not, leaving the switch off on wikitech for an extra week wouldn't be tragic either.
Change 293357 had a related patch set uploaded (by Gergő Tisza):
Enable AuthManager in group1
Mentioned in SAL [2016-06-08T22:20:34Z] <tgr@tin> Synchronized php-1.28.0-wmf.5/extensions/OpenStackManager/: backport [[gerrit:293130]] for AuthManager deploy T135504 (duration: 00m 28s)
Mentioned in SAL [2016-06-08T22:26:55Z] <tgr@tin> Synchronized wmf-config/InitialiseSettings.php: enable AuthManager on group1 T135504 (duration: 00m 23s)
Change 293434 had a related patch set uploaded (by Gergő Tisza):
Fix AuthManager feature switch configuration
Mentioned in SAL [2016-06-08T22:44:06Z] <tgr@tin> Synchronized wmf-config/InitialiseSettings.php: enable AuthManager on group1 for reals T135504 (duration: 00m 25s)
Change 293440 had a related patch set uploaded (by Gergő Tisza):
Clean up AuthManager configuration (no-op)
Is it possible that this change today broke IRC bots that do the !log -> SAL messages? Specifically morebots is broken and cant login on wikitech anymore , and the very last !log message that worked was about this change being enabled. see T137377 and the log excerpts there
Change 293440 abandoned by Gergő Tisza:
Clean up AuthManager configuration (no-op)
Reason:
meh, pointless for half a day.
Change 293491 had a related patch set uploaded (by Gergő Tisza):
Enable AuthManager on group2
Mentioned in SAL [2016-06-09T23:18:32Z] <tgr@tin> Synchronized php-1.28.0-wmf.5/extensions/ConfirmEdit/FancyCaptcha/resources/ext.confirmEdit.fancyCaptcha.js: deploying [[gerrit:293637]] for AuthManager T135504 (duration: 00m 24s)
Mentioned in SAL [2016-06-09T23:19:55Z] <tgr@tin> Synchronized php-1.28.0-wmf.5/extensions/MobileFrontend/resources/skins.minerva.special.userlogin.styles/userlogin.less: deploying [[gerrit:293638]] for AuthManager T135504 (duration: 00m 25s)
Mentioned in SAL [2016-06-09T23:20:52Z] <tgr@tin> Synchronized php-1.28.0-wmf.5/includes/specialpage/LoginSignupSpecialPage.php: deploying [[gerrit:293636]] for AuthManager T135504 (duration: 00m 25s)
Mentioned in SAL [2016-06-09T23:31:05Z] <tgr@tin> Synchronized wmf-config/InitialiseSettings.php: enable AuthManager on group2 wikis T135504 (duration: 00m 24s)
It's now been live on group2 for almost a day and I haven't heard anything concerning. The only significant change in the auth stats is that failed account creations are down (successful ones are not affected though). No log spam, new user count (which is measured in a different way than the AuthManager dashboard events) looks unchanged; I'm not good at finding my way in ganglia but the appserver/API/DB/redis graphs seemed flat. I think we can call this done.
So far so good, but with SessionManager it always seemed to be Friday evening before the major bugs started showing up for some reason.