Resources with similar labels will be locked in a random order

[NoamRodrik]

This is designed to prevent over-usage on the first numerical resources and to uniformly distribute load between resources.

[clonejo]

Do i understand correctly that a resource with the requested label will be selected at random?

In my use case, i have generic and specialized resources, and when a generic resource is requested, that request could be fulfilled by either a generic resource or a specialized resource. There are fewer of the specialized resources, so i like to keep those unused when possible and available for a request for a specialized resource. To give an example: monochrome and color printers. The color printers have the monochrome label as well, but one would like to keep them free so a color print does not have to wait for some monochrome print when monochrome printers have been idling the whole time.

Right now these priorities can be configured somewhat through the resource order.

[NoamRodrik]

@clonejo Good example, this does make this impossible with the current pull request... This should at least be configurable for those who need to randomize their resources - as by default it should be in order. Sounds good?

[TobiX]

As @clonejo suggest, I would be happier with a configurable solution. In FreeStyle projects, there is the possibility to provide a script to select a resource from a label, which seems a bit too powerful for my taste, but it was already there when I adopted the project :smile: - I'd suggest exploring the idea of providing "selections strategies" via an extension point and we can provide some useful ones inside this plugin and people who want to shoot themself in the foot can provide more complex strategies via additional plugins. The most obvious basic ones:

• first() - the current default
• random() - the one you want to add
• preferOtherLabel(String) - the one @clonejo suggested

Sounds good?

[jimklimov]

Wait, what - are the scripted selectors not exposed in the pipeline step? That would be a bummer to migrate some of our older jobs into the new era :\

We are testing against devices, which we lock for a test. Sometimes a new firmware build is not that good, so a device has to be restored manually - but as far as the lockable resources are concerned, the virtual item is available, matches a label and can be assigned. So the legacy jobs responsible for that have a script to check if the candidate resource is actually usable and only assign those to a job run, to avoid failures just because the test device was AWOL.

The example with printers reminds me of (uh, my) RFE in issue #81 to add weights to the matched resources, as determined by the custom script or perhaps also by extended syntax of resource label definition. In the printer example above, monochrome-only printers might list a label token say "monochrome:1" and color printers would include a "monochrome:2". Then the lock step called for a job which needs a label:"monochrome" printer, gets a list of items with sorted by priority (all 1's, then all 2's, ...) and can pick a random one of those with highest priority currently available.

[mPokornyETM]

What about new parameter randomOrder to allow this scenario. Per default false that means no body see difference. The idea is not wrong.