I think that the error (MetricsPlatform loaded twice) is because the code we have in master for TestKitchen is still saying MetricsPlatform everywhere. I guess we will have to merge, at least, Initialize Test Kitchen with revised files from Metrics Platform (that belongs to T407806: Rename Metrics Platform Extension to Test Kitchen) before trying again the reverted patch. That change will make TestKitchen really be TestKitchen and not like a clone of MetricsPlatform

In T410896#11469599, @Sgs wrote:
I would rather consume an API that uses UserIdentity than a string identifier. However, I'm still confused and missing a complete example of enrollment with this API. How does this help with the account creation problem? It feels the ad-hoc re-enrollment for logged-in active experiments is still necessary, isn't it? Here's a PoC GrowthExperiments/+/1219179 that tries to get rid of the account creation override problem. Review feedback is appreciated, maybe I'm getting something wrong.

This could be deployed right now but we will wait until T384506: Update event debug logging in EventLogging extension is ready to deploy both changes at the same time

Ticket is blocked the change to update how MediaWiki as a caller of Test Kitchen API depends on some other changes related to the new TestKitchen extension. There is a change ready that we will merge when unblocked.

In T407810#11462732, @cjming wrote:

In T407810#11459972, @Sfaci wrote:

As part of this work, are we considering to change metrics_platform_client (with something like test_kitchen_client) as the property where contextual attributes are listed when configuring a stream in mediawiki-config? It's not mentioned in the ticket and seems to be a non-easy thing (I guess we would provide backward compatibility at least during the transition)

definitely non-trivial -- tho maybe the additive approach is what we're undertaking? i.e. add new TestKitchenClient, point all refs to this, then remove MetricsClient?

if we're updating the MetricsClient to become TestKitchenClient, presumably we need to update the related references to the MetricsClient in WikimediaEvents and other extensions?

In T411035#11445871, @Sfaci wrote:

@dr0ptp4kt: Regarding the following

I've added an item to T411035: wmftkbot maintenance release to point to the new domain (once it's in place and routing requests) just to save the little bit of overhead of redirection, nonetheless!

The new domain, test-kitchen.wikimedia.org is available already. wmftkbot can point to it to make API requests (the login/UI thing will be working only at mpic.wikimedia.org until we update all the callers)

As part of this work, are we considering to change metrics_platform_client (with something like test_kitchen_client) as the property where contextual attributes are listed when configuring a stream in mediawiki-config? It's not mentioned in the ticket and seems to be a non-easy thing (I guess we would provide backward compatibility at least during the transition)

After confirming with Balthazar, I have removed a couple of unneeded ACs from the "Update callers" item:

• Add Test Kitchen service port -- see https://gerrit.wikimedia.org/r/c/operations/puppet/+/1056163
• Add Test Kitchen service listener proxy - see https://gerrit.wikimedia.org/r/c/operations/puppet/+/1056062

In T407901#11450040, @cjming wrote:

just verifying something here - do we want to replace product_metrics with test_kitchen in the secondary repo?
or do we want to have a subdirectory called test_kitchen within product_metrics?

Pending work here (updating architecture diagrams) will be addressed via T412316: Update architecture diagrams in the project documentation

In T407804#11420025, @phuedx wrote:

. . . .
That's correct. I think updating those pages to use that sketch is non-trivial though as there are documents linked to from the sketch that should also be transposed to a wiki. Doing so would dramatically increase the scope of this task so maybe it's best to create a new one?

In T407805#11445935, @dr0ptp4kt wrote:

Thanks @Sfaci. wmftkbot is now pointed at test-ktichen.wikimedia.org via its local config.yaml and a restart of the tk tool's continuous job on Toolforge, and it looks to be in working order.

@dr0ptp4kt: Regarding the following

@dr0ptp4kt: Regarding the following

The ticket is BLOCKED because there was an incident related to the cache. We have pre-emptively disabled this experiment until the incident is solved.

The experiment (https://mpic.wikimedia.org/experiment/synth-aa-test-traffic-impact) has been already registered according to the configuration mentioned above. Its activation has been planned for December 9th. That day early in the morning the implementation will have been backported.

As per slack conversation we agreed on the following plan to address this renaming work:

@mpopov @dr0ptp4kt As part of this work we are considering to enable the new domain, test-kitchen.wikimedia.org, and enable a redirection to there from the old one (mpic.wikimedia.org -> test-kitchen.wikimedia.org) to provide a smooth transition for users and callers. We have found that wmftkbot and experiment-analytics-config (and its related DAG) codebases use the public domain to get instruments/experiments configurations. Can you confirm whether they would follow the redirection if we enable it? The plan would be something like the following: