Being bold.

All subtasks are closed as Resolved. Being bold.

In T341185#9752094, @KCVelaga_WMF wrote:

Update: I have restructured the events into MP compatible format.

Being bold.

In T360748#9730352, @cjming wrote:

So like this?
<snip />

In T360748#9728601, @cjming wrote:

cc @phuedx -- I pasted the questions I have about the task field and Security and Legal in the design doc if you could clarify - thanks!

@DMartin-WMF: If you fetch the latest version of the EventLogging extension and run composer update in /path/to/mediawiki, then this should be fixed. It will be fixed in production next Thursday.

Approved (as if you needed my approval…)

mediawiki/extensions/EventLogging/+/859583: DNM: Add special page and script to send test events is a test script that I've used in the past when I just needed to send an event quickly.

@KCVelaga_WMF: Hey! Again, I'm sorry for not having commented sooner, especially if not doing so has introduced a delay.

In T362268#9714944, @Sfaci wrote:

• Express NodeJS + Vue frontend served as static content (without service-runner): (Available here) So far this seems to be the best approach. We can have all the advantages and none of these disadvantages that we have mentioned for the service-runner approach. With only a bit of work we already have the features we needed from service-template-node and, for now, we can serve the Vue frontend build statically but we could decouple backend/frontend in the future easily if needed, serving the second one as a separate process (and even in a separate container if needed).

In T361962#9697087, @phuedx wrote:

Support curation-rule-like rules in the stream config

$wgEventStreams = [
  'STREAM_NAME' => [
    // …
    'sample' => [
      [
        'unit' => 'session',
        'rate' => 0.1,
      ],
      [
        'unit' => 'session',
        'rate' => 0.1,
        'if' => [
          'performer_is_logged_in' => true,
        ],
      ],
    ],
  ],
];

My preference would be for #3 (Support curation-rule-like rules in the stream config) as it keeps the stream config as the single source of the truth/keeps the instrument simple.

I agree that it would be valuable to capture the sampling config for the instrument (not just for this instrument either).

See https://docs.google.com/spreadsheets/d/1pfsRDBk9QUAH9IzICxwDh7hUCYM_obB6RxpIwEgYrA0/edit (commentable by WMF).

In T358577#9665271, @phuedx wrote:

• The decision has been taken to host the application part of this in dse-k8s, which also implies it is going to be eqiad only, at least in the beginning. This means that for 6 months out of 12, the bridging extension of MediaWiki will need to pay the latency cost of reaching out across the 2 DCs. While the service mesh we have will alleviate some of that by maintaining persistent HTTP connections and paying only once the TLS negotiation cost, this is still at least (and only in the absolute best case scenario) 40ms+ the time the app will take to respond. If this ends up being in the critical path of end-user requests, it will create a significant performance regression for all users for 6 months.

This still needs more thought. I've proposed a budget of 250 ms for fetching the configuration from the app before falling back to default (static) configuration. 40+ ms best case is a huge chunk of that. Perhaps we should target deploying to WikiKube straight away.