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)

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 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?

I meant the way we configure streams in mediawiki-config but definitely you are right. We would need a similar approach for what you mentioned.

I have just realized that, because we are considering in this ticket to move client libraries to the new TestKitchen extension, I guess we could keep the older way (metrics client libraries embedded in EventLogging) until we update all the extensions/codebases that, somehow, are using client libraries via EventLogging at this moment. That would be something similar as what we are doing with the renaming of the mpic.wikimedia.org domain:

1. Enable the new way (client libraries in TestKitchen extension) keeping the older one (client libraries embedded in EventLogging
2. Update one by one all the client libraries consumers (at least CheckUser, GrowthExperiments, ReportIncident and WikimediaEvents extensions after a quick search) until nobody uses the older way
3. Deprecate/Remove client libraries from EventLogging

Regarding the first AC: bring client libraries into Test Kitchen MW extension

• I assume that mw.eventLog.* will be kept in EventLogging after moving client libraries to TestKitchen to provide backward compatibility. It will be also a good opportunity to start deprecating/removing/updating those functions. We could update EventLogging to use TestKitchen and keep that code for current instruments to use mw.eventLog.* code via EventLogging until we finish that deprecation process (see (T408091: [EPIC] Deprecate and remove mw.eventLog.newInstrument(), T408096: Migrate 1 instrument using mw.eventLog.newInstrument() to mw.xLab.getInstrument(), T408097: Remove mw.eventLog.newInstrument(), . . .or the related Epic: T408059: [GOAL] Tidy up EventLogging)

I've repurposed T367034: TestKitchen Extension: Merge PHP MetricsPlatform client library to cover merging PHP Metrics Platform Client Library into the TestKitchen extension.