Gear Rules with SDK Gears

Introduction

Leveraging the SDK in a gear gives the gear flexibility to access the Flywheel application just like an individual user would. Using these gears in a project gear rule allows a higher degree of automation in Flywheel.  With this additional capability, you can manage the set of permissions given to the gear. This is done using the same concept of roles, already defined for users.  The permissions are scoped to only the project of the gear rule.

Instruction Steps

Creating a Gear Rule with an SDK Gear

Besides configuring the gear rule logic and the inputs, this type of gear rule requires you to also provide a project role for the Gear Rule to operate under. This allows you to control or tailor the permissions given to the rule, as if it were a user in the system.

For an SDK gear use the dropdown to select the proper role for the SDK gear, based on it's expected function. Permission is limited to a single project - the project containing the gear rule.

Selecting Incorrect Permissions for an SDK Gear Rule

The gear's SDK actions will be constrained by the permissions, and so if a gear is designed to write to Flywheel using the SDK and you do not set it up with write permissions it will fail and show a permission error in the log.

Tailoring Permissions for SDK Gear Rules

In the same way that user roles are customized you can create a custom role for use with SDK Gear Rules. For example, if there is a concern about the potential for files being deleted by SDK Gear Rules using the read/write role, you can create a custom role that excludes the "Delete, including files" permission to use for SDK gear rules. This would stop any gear using the SDK delete functionality from deleting a file, and it would error out.

Specifying Tags on Gear Rules

When creating or modifying a gear rule via the REST API or Python SDK, you can specify a list of tags. Flywheel automatically applies those tags to every job triggered by the rule.

This is useful for:

• Compute profile routing: Tag jobs to route them to a specific compute profile configured on your site (for example, a GPU compute profile).
• Job identification: Distinguish jobs triggered by a gear rule from manually launched jobs when filtering the Jobs Log.

Python SDK Example

```python import flywheel

fw = flywheel.Client()

project = fw.lookup("my-group/my-project")

gear = fw.lookup_gear("dicom-mr-classifier")

Create a gear rule with tags

gear_rule = flywheel.models.GearRuleInput( name="Classify DICOM - GPU Profile", gear_id=gear.id, any=[], all=[ flywheel.models.RuleCondition(type="file.type", value="dicom") ], not_=[ flywheel.models.RuleCondition(type="file.tags", value="dicom-mr-classifier") ], tags=["gpu-compute"], # Tags applied to every job this rule triggers )

fw.add_project_gear_rule(project.id, gear_rule)

The tags field accepts a list of strings. To add tags when modifying an existing rule, include the field in the modification request body.