Page MenuHomePhabricator

Implement per-request timeout / resource consumption limits in the orchestrator
Closed, ResolvedPublic

Event Timeline

This probably needs to be done.

James's estimated effort: 0.5 day (if whoever picks this up thinks that will take considerably longer, please check whether we agree on the task)

The timeout part should take 0.5 days, yes (1 at most), for just an unconfigurable 15-second timeout. I'm not clear on the resource consumption part. What are we measuring in terms of resource consumption? What's too much?

Change 881403 had a related patch set uploaded (by Cory Massaro; author: Cory Massaro):

[mediawiki/extensions/WikiLambda@master] Add example of orchestrator timeout.

https://gerrit.wikimedia.org/r/881403

Change 881405 had a related patch set uploaded (by Cory Massaro; author: Cory Massaro):

[mediawiki/services/function-orchestrator@master] Add twenty-second timeout to the orchestrator.

https://gerrit.wikimedia.org/r/881405

Change 881405 merged by jenkins-bot:

[mediawiki/services/function-orchestrator@master] Add twenty-second timeout to the orchestrator.

https://gerrit.wikimedia.org/r/881405

Change 881403 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Add example of orchestrator timeout.

https://gerrit.wikimedia.org/r/881403

The timeout part should take 0.5 days, yes (1 at most), for just an unconfigurable 15-second timeout. I'm not clear on the resource consumption part. What are we measuring in terms of resource consumption? What's too much?

When I wrote this, I was thinking a per-request memory limit or similar. Happy to declare this Resolved as-is though if you think this is good enough?

Hmm, I'm assuming we'll handle the memory limit bit in Kube. Let's keep this open for that (unless there's already another, more specific task to cover that).

cmassaro subscribed.