search

juju-solutions / matrix

Automatic testing of big software deployments under various failure conditions
Other
8 stars 9 forks source link

Make glitch plans more repeatable by simplifying selection process #90

Open pengale opened 7 years ago

pengale commented 7 years ago

Instead of our current branching path through selectors, we should have a single select function, that includes something like the following args:

hosted charm(s) ("application")
ram
cpu
workload_status
leadership

To select a machine, we take a weighted sum of the args (leadership weighs less; hosted charms weighs more) of each deployed machine, and select the one with the best match, choosing randomly in the case of a tie.

actions now take a machine as the third argument (which, in the case of a selector that just acts on a model, is just a random machine), and derive stuff they need to act based on the properties of the machine.

abentley commented 7 years ago

I suppose the full list of attributes would include some or all of the attributes Juju can be constrained on: https://jujucharms.com/docs/2.1/reference-constraints

abentley commented 7 years ago

To be clear, for every machine that hosts a unit, a randomly-chosen "application" would be specified, so that operations on units are repeatable.