[task manager] support max_workers config value of 0

[pmuellr]

Both @gmmorris and I had assumed that you could config xpack.task_manager.max_workers to 0, which would prevent task manager from running any tasks at all. But turns out, you can't:

kibana/x-pack/plugins/task_manager/server/config.ts

Lines 75 to 80 in 9019946

	/* The maximum number of tasks that this Kibana instance will run simultaneously. */
	max_workers: schema.number({
	defaultValue: DEFAULT_MAX_WORKERS,
	// disable the task manager rather than trying to specify it with 0 workers
	min: 1,
	}),

We were thinking of using this for diagnostic purposes in a support case, when we realized we couldn't. And there is thinking that this could also be used productively to keep Kibana instances from having to be involved in running alerts, reports, etc.

So, suggesting we change the min there to be 0, from 1.

Was thinking, since this could make various activities completely non-operational in the case of setting it to 0 AND there's only one Kibana instance, it's worth some kind of INFO | WARN at startup indicating what's going on.

Was also thinking we might want to keep the min to 1 for cloud, since the configs are shared between those instances, so setting it to 0 would make alerting, reporting, etc non-operational.

Lastly, not sure what other plugins are using task manager, and if they would be affected here.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[gmmorris]

Thanks for opening the issue @pmuellr

Was also thinking we might want to keep the min to 1 for cloud, since the configs are shared between those instances, so setting it to 0 would make alerting, reporting, etc non-operational.

The reason I had even thought about this was actually for cloud - as cross env (cloud with on-prem) don't have a shared config, and they can clash.
I think we would still need to support 0 on cloud so that a customer can prevent their cloud Kibana from running tasks if needed (due to ESO complications, for example)

[mikecote]

Was thinking, since this could make various activities completely non-operational in the case of setting it to 0 AND there's only one Kibana instance, it's worth some kind of INFO | WARN at startup indicating what's going on.

+1 to this so it's easier for us to support/understand if this is the case.

I wonder how this would impact the runNow capabilities?

[gmmorris]

I wonder how this would impact the runNow capabilities?

Yeah, this is actually a problem 🤔

At its core, the problem is that we've designed our system under the assumption that all Kibana are configured the same, but the moment we have some who can run alerts and some that can't, we ned to be able to differentiate between them.
We can't have an API exposed on all Kibana, but only have it work for some. 😬

We might need to take a step back here and ask: What deployment configurations do we want to support and how?

[gmmorris]

We might need to take a step back here and ask: What deployment configurations do we want to support and how?

I've opened an issue to discuss things from that perspective
#94291

[mikecote]

Capability resolved by node.roles: ['ui'] #134388. Closing.