Scheduling

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 canary=true or customer=stark-industries.

Example

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.

Labeling your Devices

After adding your devices into the project, you'll need to label each one to group the types of devices.

Labeling your Server devices

  1. From the list of devices, select the device that is one of the servers.
  2. Select the device to get the details of the device.
  3. Add a device label, i.e. type=server.
  4. Repeat this for all devices that are servers.

Labeling your Raspberry Pi devices

  1. From the list of devices, select the device that is one of the Raspberry Pis.
  2. Select the device to get the details of the device.
  3. Add a device label, i.e. type=rpi.
  4. Repeat this for all devices that are Raspberry Pis.

Deploying Applications

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.

Creating your application for your servers

  1. Create a new application.
  2. Add a scheduling rule with a single filter containing the condition type=server. This scheduling rule will only deploy the application to any device that has the type=server label on it.
  3. Create the first release of the application.
  4. The release will only be deployed to any devices that have the type=server.

Creating your application for your servers

  1. Create a new application.
  2. Add a scheduling rule with a single filter containing the condition type=rpi. This scheduling rule will only deploy the application to any device that has the type=rpi label on it.
  3. Create the first release of the application.
  4. The release will only be deployed to any devices that have the type=rpi.

Deploying new releases

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.

Adding more devices

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.

Filters Reference

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.

  • A scheduling rule is a set of filters that control which devices an application should be deployed to
  • A filter is a set of conditions
  • A condition is a statement about labels on a device such as customer=stark-industries or customer!=stark-industries.

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.

DevicesLabels
device1customer=customer1, generation=3
device2customer=customer2
device3customer=customer3
device4customer=customer1
device5No labels set .
Schedule RuleMatching device(s)
filter1: condition(customer=customer1)device1, device4
filter1: condition(customer=customer1), condition(customer=customer3)device1, device4, device3
filter1: condition(customer!=customer1)device2, device3, device5
filter1: condition(customer=customer1)
filter2: condition(generation=3)
device1