feature request: controller QoS for deployment of selected applications

[Dmitrii Shcherbakov]

It's not the first time that I see a model where key applications come up and perform clustering after most of other applications came up.

http://paste.ubuntu.com/25399698/

In case of OpenStack the problem is when keystone, rabbitmq and mysql come up last while some API services have already been set up.

I don't remember any deployments during the last few months that would not act the same way.

This leads to certain scenarios where you have many cervices in a blocked or waiting workload state and a spike of activity after some core services come up.

Those core cervices do not perform clustering until they have enough units, hence, units of other applications that could do useful work in parallel simply wait.

It would be nice to have some kind of a QoS mechanism to prioritize machine or container allocation and general (controller and agent-side) processing of concrete applications.

I get an impression that in certain deployment-related code-paths there might be a "first-come first-serve" behavior because I deployed a lot of large OpenStack bundles and keystone, mysql and rabbit were at the bottom of the list and came up last.

http://paste.ubuntu.com/25399793/ (here keystone, percona and rabbit are far from being first in the list)

Charm logic affects deployment time of course but I noticed that the output of juju status simply reports certain agents in the 'allocating' state which means they get less priority which leads to longer deployment times.

I can summarize this as follows:

* a bundle author knows better which applications should come up first so that other applications are not blocked for too long
* having a QoS or a prioritization mechanism will allow juju to utilize that knowledge to optimize deployment time

It doesn't have to be "wait until this application has all units up", rather, if I have a choice of what to work on, pick a unit of work that has more priority. Hierarchical token bucket (HTB) comes to mind.

In a lot of ways a juju controller acts as a stream processing endpoint which may have its own scheduling algorithms.

It is useful to optimize that for both field and CI deployments.

Deploying a large bundle in stages is not convenient at all due to:

https://bugs.launchpad.net/juju/+bug/1567169

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.