How to read the Placement Rules table

In the Queue Manager UI you can view all of your placement rules on one page. Learning about this page can help you manage your placement rules according to your needs.

The placement rules overview page is displayed in Cloudera Manager if you select the Queue Manager UI and then go to the Placement Rules tab. It displays a table with the following columns:

Table 1. Placement rules overview page
Column Name Description

Order

Placement rules are evaluated from top to bottom. This column provides the order of the placement rules.

Type

Indicates to the engine what the current rule should be matched against: application, user, or group.

Values: Application, Users, Group

Match

The string to match, or an asterisk "*" which means "all". For example, if the type is User and this string is "hadoop" then the rule will only be evaluated if the submitter user is "hadoop". The "*" does not work with groups.

Policy

Pre-defined or custom policies which defines where the application should be placed.

Values: User, PrimaryGroup, PrimaryGroupUser, SecondaryGroup, SecondaryGroupUser, ApplicationName, Specified, Reject, DefaultQueue, SetDefaultQueue, Custom

Parent Queue

In the case of User, PrimaryGroup, PrimaryGroupUser, SecondaryGroup, and SecondaryGroupUser policies, this tells the engine where the matching queue should be looked for. For example, if the policy is PrimaryGroup, parent is root.groups and the submitted's group is "admin", then the resulting queue will be: root.groups.admin

Custom Value

It can have two types of values:
  • In the case of the SetDefaultQueue policy: The default queue will change from root.default to the value of this field.
  • In the case of the Custom policy: The value of this field will be evaluated directly by the placement rules evaluation engine, which means that various placeholders such as %application or %primary_group will be replaced with their respective values.

Create Queue?

It sets the create flag and it works differently in weight and in legacy mode.

If it is set to No, the target queue determined by the placement policy will not be created if it does not exist. That means that dynamic auto child creation will not happen.

However, even if it is set to Yes it is still not guaranteed that the queue will be created. You also have to ensure that for the specified parent queue the dynamic auto child creation feature is enabled.

The following policies do not support the create flag:

  • reject
  • setDefaultQueue
  • defaultQueue

Fallback

If the target queue does not exist or it cannot be created, it defines a fallback action.

Values: Skip, PlaceDefault, Reject

Actions

Click on the applicable icon to perform actions on the placement rules:
  • Eye: View Rule
  • Bin: Delete Rule