-
Notifications
You must be signed in to change notification settings - Fork 0
Materialized and Predicated Tags
Tags provide a way to classify nodes based on an arbitrary association to other nodes. It's incredibly important to provide this additional layer of organization to an end user. The source of these tags currently originates from resources.xml for a given project. Eventually, this may be pulled from Resource Providers. Changing a tag requires going to either a file (resources.xml) or the source of the resource provider and making the change and waiting for it to propagate back to Rundeck. While this is not overly taxing on the user, I think Rundeck can go further.
Materialized tags replace saved filters and make filters act the same way tags are used. Using a mocked up query language that incorporate tags, similar to google search site: and type: tags, using a tag from a resource provider would look like this:
tag:foo+bar name:serverA,serverB,serverC
For the case above, the query string is verbose and must be duplicated over and over again when this particular combination of servers is the target of a job or adhoc command. This can be error prone.
Instead, a user can create a materialized tag call foobarABC that represents the above query string. When the user wishes to select those nodes by the tags above, then the filter looks like:
tag:foobarABC
and gets expanded to tag:foo+bar name:serverA,serverB,serverC. Also note that the materialized tag is treated as if it were a tag from a resource provider.
Materialized Tags should also all jobs run by Rundeck. This provides a way to reference the nodes that were part of a job after the job has been run. Used in combination with Predicated Tags, these materialized tags can provide highly targeted job dispatching.
Predicate Tags do not themselves introduce any new tags into Rundeck, instead, they provide a way to refine the selection of nodes for a given tag. They are intended to further refine a selection of nodes by some algorithmic or boolean logic.
For example, given a predicate like first: the expectation is that the first node in a tag would be selected.
[first]tag:foo+bar [successful]job:43234
Would select the first of any nodes matching the tag foo+bar. Other tags might include, 1%, 10%, random_sample. Tags are provided through a plugin architecture.
It's important that each tag be clear if they're deterministic or not. This provides repeatability of re-running a job using a Predicated Tag. It may not be necessary to be deterministic between job definitions, but the SCOPE of determinism should be documented and communicated to users of predicated tags in the UI.
- success - Return the nodes that were successful for a job
- failure - Return the nodes that failed for any reason for a job
- sigfailure - Return the nodes that failed because of a signal thrown for a materialized tag representing a job.
- notrun - Return the nodes that were not run for a materialized tag representing a job.
- first - Return the first of a set of nodes
- 1% - Return 1% of the nodes
- 10% - Return 10% of the nodes