By default, an application will run on all devices in a project. To run the application on only a subset of devices, a scheduling rule needs to be set. A scheduling rule is a collection of "filters" that restrict which devices an application should run on. Filters consist of multiple label conditions such as
Imagine that you have a project that has 2 different device types: x86 servers, and Raspberry Pis. Different applications should run on the x86 servers versus the Raspberry Pis.
After adding your devices into the project, you'll need to label each one to group the types of devices.
Next we'll add two applications: one designed to run on the servers and one designed to run on the Raspberry Pis. It makes sense to set a scheduling rule before creating the first release of the application so that the containers will be scheduled to the correct devices as soon as they're first deployed.
type=server. This scheduling rule will only deploy the application to any device that has the
type=serverlabel on it.
type=rpi. This scheduling rule will only deploy the application to any device that has the
type=rpilabel on it.
Now that the devices are split by device type, you can add releases to your application, which will always be released only to the device with the matching labels.
As you add more devices into the project, the application will only be deployed onto devices that have the corresponding label. These labels could either be manually added after the device is registered or automatically added during registration by using registration tokens.
The earlier example showed a simple scenario where only one device label was considered. However, there are many other scenarios that can be managed through scheduling rules. In order to explain how scheduling rules could be used for these more complex scenarios let's first define some terminology.
To evaluate if a device meets the requirement of the scheduling rule, one of the conditions of each filter must be met. In other words, all the filters are joined together by an AND and all the conditions of a filter are joined together by an OR. Another way to think about this is that the scheduling rule is evaluated as follows.
filter1 AND filter2 AND ...
This expression could be expanded to the following since filters have multiple inner conditions.
(condition1 OR condition2 OR condition3 OR ...) AND (condition4 OR condition5 OR condition6 OR ...) AND ...
Some example evaluations are provided below. Suppose we have the following devices in our project.
|device5||No labels set .|
|Schedule Rule||Matching device(s)|
|filter1: condition(||device1, device4|
|filter1: condition(||device1, device4, device3|
|filter1: condition(||device2, device3, device5|