Scheduler migration limitations

There are some hard limitations on converting a Fair Scheduler configuration into a Capacity Scheduler configuration as these two schedulers are not equivalent. Learning about these major limitations can help you understand the difficulties you might encounter after the scheduler migration.

The features and configurations of Capacity Scheduler differ from the features and configurations of Fair Scheduler resulting in scheduler migration limitations. These limitations sometimes can be overcome either by manual configuration, fine-tuning or some testing, but in some cases there is no workaround.

Static and dynamic leaf queues cannot be created on the same level

If you have a parent queue defined in capacity-scheduler.xml file with at least a single leaf queue, it is not possible to dynamically create a new leaf under this particular parent.

Resolved: Weight mode and Dynamic Auto Child Creation is supported from Cloudera Runtime 7.1.6. In weight mode there can be static and dynamic queues on the same level.

Placement rules and mapping rules are different

Placement rules (used in Fair Scheduler) and mapping rules (used in Capacity Scheduler) are very different, therefore auto-conversion is not possible. You manually have to configure placement rules and mapping rules once the upgrade from CDH to CDP is completed. There are multiple reasons for this. The following are the most substantial differences:

In Fair Scheduler you can use special placement rules like "default" or "specified" which are completely absent in Capacity Scheduler.
In Fair Scheduler you can set a "create" flag for every rule. Mapping rules do not support this.
In Fair Scheduler in case of nested rules the "create" flag is interpreted for both rules. This is not true in Capacity Scheduler.
If a rule can return a valid queue in Fair Scheduler, it proceeds to the next rule. Capacity Scheduler, on the other hand, returns “root.default”.

Resolved: In Cloudera Runtime 7.1.6 a new JSON-based placement rule format and a new placement rules evaluation engine were introduced. They resolve many of the previous placement rule migration limitations.

Mixed resource allocation mode is not supported

In Capacity Scheduler all queues can be either absolute, relative or weighted. That means that hybrid mix of absolute and weighted queues is not supported in Capacity Scheduler.

The capacity value of dynamic queues is fixed

In Fair Scheduler, fair shares are recalculated each time a new queue is created. In contrast, Capacity Scheduler assigns a predefined percentage value for dynamically created queues.

This predefined percentage can be changed, but it is fixed until the scheduler is reconfigured. Once this value reaches 100, the next dynamic queue will be created with the value 0. For example, if the value is set to 25.00, then the fifth queue under the same parent will have a capacity of 0.

The following is an example of how you can convert the Fair Scheduler queue weights to Capacity Scheduler queue capacity (percentage relative to its parents) :

Table 1. Weight conversion example
Queue Path	Weight	Capacity Scheduler equivalent (capacity) `yarn.scheduler.capacity.<queue-path>.capacity`
root	1	100%
root.default	10	25%
root.users	30	75%
root.users.alice	1	33.333%
root.users.bob	1	33.333%
root.users.charlie	1	33.334%

In Cloudera Runtime 7.1.5 and lower versions the fs2cs conversion utility ensures that all percentages of direct children under one parent queue add up exactly to 100.000%, as it is demonstrated in the table. For example, all queues under root.users: root.users.alice + root.users.bob + root.users.charlie = 100.000%.

Weights are converted into percentage-based capacities the following way: On queue-level root, there are 2 queues: default and users. Because it is specified as 10 + 30 weights (40 altogether), 1 “unit of weight” is 2.5%. This is why root.default has 25% and root.users has 75% of the capacity. This calculation can be applied to all queue-levels.

Resolved: Weight mode and Dynamic Auto Child Creation is supported from Cloudera Runtime 7.1.6. and the fs2cs conversion utility converts into weight mode by default.