Hi @jcdlt, glad you managed to find some time to dig into it.
What is the effect of defining several checks within the same policy ?
When defining multiple checks per policy, all checks are executed at the same time and then the desired result created from all. The Nomad Autoscaler will always pick the safest action out of all the check results, meaning more capacity will always be chosen. The check calculations page has some additional detail on this.
Same question, this time when defining several scaling policies that apply to the same resource ?
Each policy acts as an independent entity and is subjected to isolated workflows. This means that if you have two policies acting on the same resource,
policy-a calculates a count of 3 and
policy-b calculates a count of 4; the Autoscaler will trigger separate scaling events which would therefore result in flapping of the remote resource count. It is therefore not suggested to have multiple policies per target, but instead have multiple checks per policy.
In your example situation, I would personally run two autoscaling groups for each class of node you have, with a policy per ASG.
Scale in increments
There are a couple of features available or in-progress that I believe can help in the situation you have described. Firstly is the proposed threshold strategy plugin which should be available in the coming weeks. This will provide finer control over the calculated increment; if you have any feedback on the approach we would love to hear.
In order to avoid spinning up more instances too quickly you could alter the cooldown policy option to be a higher value. This means the autoscaler waits until performing new calculations after a scaling event, which would accommodate situations where the queue is emptying and the current capacity is sufficient. You could also set a policy max value to cap the number of running instances at a value to ensure cost budgets are met.
Lastly, I will raise a PR to add support for Vmware vSphere as a target.
Firstly, thank you so much for taking the time to write a new plugin. As a team, it is amazing to see people contributing and adopting the Nomad Autoscaler into varying environments. That being said, at the present time we are unable to accept further in-tree target plugins and prefer to keep these external. We do not have the capacity currently to support and maintain the additional code, along with the testing infrastructure we would need to provide the level of confidence and support we would desired. Additional information can be found within our contributing page.
Please let me know if you have any follow up questions or any feedback.
jrasell and the Nomad team