Page MenuHomePhabricator

Temp accounts deployment and the release train
Closed, ResolvedPublic

Description

In this task, let's clarify how temp accounts deployment will impact the release train.

In Q3 2024, we aim to deploy temp accounts on testwiki (and loginwiki). More wikis would follow in Q4. That would mean, for a period of some weeks/months, that testwiki reflects an editing paradigm for anonymous users (temp accounts in place of IP accounts) that is different from the bulk of our production wikis. Does that present a concern to Release-Engineering-Team?

One thought is that we encourage WMF teams and QA folks to verify their changes on both testwiki (temp accounts) and testwiki2 (IP editing, as it exists today), to avoid any surprises.

Related: T355880: Decide long term strategy for temp account default

Event Timeline

@thcipriani who can work with us from Release-Engineering-Team to clarify this task and document its outcomes?

Hey! Thanks for thinking of the train folks :)

It sounds like this code will be riding the train this quarter. I know very little about the code and the risks here, so it's tricky to give you a direct answer about my level of concern.

As a starting point could you tell me a little more:

  • How are you planning to roll this out? Sounds like code will be riding train and you're planning for an extended period on testwikis (via config...somewhere?) tell me more.
  • How would someone deploying this code know if something is going horribly wrong? We keep an eye on log messages and 503s and the like—is that sufficient?
  • What's the revert plan look like if something goes awry? Normal rollback ok? Or are there other considerations (changes to serialized objects between versions is the main thing I note that seems to bite us—but a disagreement between what's persisted and what's in the code is where problems arise)?

Most of these questions are in our Risky Change Template. The week something risky is going out, it's a nice template to use to give us a heads up, most of the time that suffices. This change seems pretty fundamental, so we might need more. But let's start with there and see.

Hey! Thanks for thinking of the train folks :)

It sounds like this code will be riding the train this quarter. I know very little about the code and the risks here, so it's tricky to give you a direct answer about my level of concern.

As a starting point could you tell me a little more:

  • How are you planning to roll this out? Sounds like code will be riding train and you're planning for an extended period on testwikis (via config...somewhere?) tell me more.

The plan is to deploy to:

  1. testwiki (with loginwiki and metawiki as supporting actors)
  2. pilot wikis (some weeks after testwiki rollout)
  3. rollout to rest of the WMF managed wikis over a duration yet-to-be-determined

The important line in the config is $wgAutoCreateTempUser['enabled'] = true;. If you look in CommonSettings-labs.php you'll see a couple of other related settings. But that is the global switch.

  • How would someone deploying this code know if something is going horribly wrong? We keep an eye on log messages and 503s and the like—is that sufficient?

Yes, I think that would suffice.

  • What's the revert plan look like if something goes awry? Normal rollback ok? Or are there other considerations (changes to serialized objects between versions is the main thing I note that seems to bite us—but a disagreement between what's persisted and what's in the code is where problems arise)?

A normal rollback of the config would be fine. However, there is a special consideration, in that once temporary accounts have been created on the wiki, and the global feature flag is switched off, we need a way to make sure that those users are logged-out, and continue to appear as temporary users. We're discussing that in T356524: Ensure temp accounts can be safely disabled after being enabled.

Most of these questions are in our Risky Change Template. The week something risky is going out, it's a nice template to use to give us a heads up, most of the time that suffices. This change seems pretty fundamental, so we might need more. But let's start with there and see.

That sounds good.

Overall, I think the important thing for Release Engineering and specifically train drivers to know would be, after testwiki rollout:

  • testwiki would reflect an editing paradigm (temporary accounts) that is *not* the same as all other wikis. So, during that time it would probably make sense to review logs from other group0 wikis more closely. And WMF teams should probably do any anonymous editing related QA on test2.wikipedia.org

@thcipriani https://www.mediawiki.org/wiki/Help:Temporary_accounts/How_it_works is also a useful reference, that is probably a good idea for RelEng folks to read before we enable this on testwiki.

Summary of meeting notes:

  • We'll provide documentation on how to switch off the feature (T356524)
  • No major concerns from Release Engineering about enabling this on testwiki from a release train perspective

As such, I think we can resolve this task. (cc @TAdeleye_WMF @Tchanders)

Tchanders claimed this task.

Most of these questions are in our Risky Change Template. The week something risky is going out, it's a nice template to use to give us a heads up, most of the time that suffices. This change seems pretty fundamental, so we might need more. But let's start with there and see.

That sounds good.

Overall, I think the important thing for Release Engineering and specifically train drivers to know would be, after testwiki rollout:

  • testwiki would reflect an editing paradigm (temporary accounts) that is *not* the same as all other wikis. So, during that time it would probably make sense to review logs from other group0 wikis more closely. And WMF teams should probably do any anonymous editing related QA on test2.wikipedia.org

@thcipriani https://www.mediawiki.org/wiki/Help:Temporary_accounts/How_it_works is also a useful reference, that is probably a good idea for RelEng folks to read before we enable this on testwiki.

This is going live this week, correct? Could you add info to T366960: 1.43.0-wmf.15 deployment blockers using the Risky Change Template?

Most of these questions are in our Risky Change Template. The week something risky is going out, it's a nice template to use to give us a heads up, most of the time that suffices. This change seems pretty fundamental, so we might need more. But let's start with there and see.

That sounds good.

Overall, I think the important thing for Release Engineering and specifically train drivers to know would be, after testwiki rollout:

  • testwiki would reflect an editing paradigm (temporary accounts) that is *not* the same as all other wikis. So, during that time it would probably make sense to review logs from other group0 wikis more closely. And WMF teams should probably do any anonymous editing related QA on test2.wikipedia.org

@thcipriani https://www.mediawiki.org/wiki/Help:Temporary_accounts/How_it_works is also a useful reference, that is probably a good idea for RelEng folks to read before we enable this on testwiki.

This is going live this week, correct? Could you add info to T366960: 1.43.0-wmf.15 deployment blockers using the Risky Change Template?

This was deployed via a config change to testwiki and loginwiki just now in the backport window. I will do the risky change comment.