JobPinning

Pinning jobs to app version numbers

BOINC's default behavior is to process jobs with the latest app versions.

During the lifetime of an app, there may be changes that are not backward compatible, e.g.:

• A new version uses a different input file format
• A new version produces output that won't validate against older versions.

If the new version is introduced while there are still older jobs in the system, jobs will fail and/or not validate.

One alternative is to stop adding jobs until there are no jobs in progress, then add the new app versions and resume creating jobs. This can cause lots of unused capacity.

Another option is to create a new app. This can cause various problems, e.g. invalidating user configurations and app selection settings.

Job pinning

A third option is to pin jobs to a particular app version number. For example,

create_work --app_version_num 405 ...

means that the job is to be processed only by app versions with version number 415 (i.e. 4.15).

The default is 0, meaning that the job is processed using the latest version.

In addition, you must tell BOINC what the earliest usable version for the app is, i.e. the lowest version number for jobs currently in progress. Do this by setting the "min_version" field in the app's DB entry. The easiest way to do this is to change the project.xml, e.g.

    <app>
        <name>uppercase</name>
        <user_friendly_name>upperCASE</user_friendly_name>
        <min_version>415</min_version>
    </app>

and then run xadd.

This, however, requires you to specify exactly one app version that is to be used for a given workunit at the time when the work is generated. This migth not work in all cases, e.g. if you issue a new app version (possibly for a few platforms only) that is compatible to the previous one, but not to the pre-previous one, and you have still workunits for the oldest app version in the DB. Another issue might be that you are using some other workunit generator than BOINC's create_work tool, and thus the Workunit DB field is not (easily) accessible to you when you create the workunit.

Plan Classes

So here's a fourth way using plan classes: To the plan classes of the old app versiomn add

    <plan_class>
        <name>apppc</name>
        ...
        <max_wu_id>12345</max_wu_id>
    </plan_class>

Add a new plan class for the new app version(s)

    <plan_class>
        <name>apppcNEW</name>
        ...
        <min_wu_id>12346</min_wu_id>
    </plan_class>

Workunits up to ID 12345 will be processed with app versions using the old plan class "apppc", workunits from ID 12346 on will be processed with app versions using the new plan class "apppcNEW". There exist similar tags to restrict plan classes to batches (<min_batch> and <max_batch>).

For a detailed discussion of that feature and its use case see the github PR.