asg size changes should be ignored.
Updated asg sized after deploy, terraform apply detects the changes, which should be ignored.
At least change indesired_capacity should be ignored.
~ module.eks.aws_autoscaling_group.workers
desired_capacity: "2" => "1"
max_size: "5" => "3"
min_size: "2" => "1"
Ignore the changes, since we don't want the running system to be re-sized.
If you are fine to ignore change in desired_capacity, I can raise PR for this feature, please confirm.
Hey @ozbillwang 馃憢
So if I understand this correctly, the only value you're wanting to ignore is the desired_capacity, correct? The other values (min & max) rightly had a delta that terraform planned to change. I don't think those need to be ignored since they aren't dynamic values.
This sounds reasonable to me. Looking forward to your PR. Thanks for going through the process! 馃弲
PR has been raised.
so i guess with this PR merged we can experiment with external node autoscaler and in the end it will be compatible with terraform
@hatemosphere
This is no compatible problem. The benefit for this feature is, if you have running system with higher desired capacity, the change applied without reduce running worker nodes
Good observations. Yea this whole space is tricky, trying to determine which declarative system should own which resources, but I think in this case it makes good sense to defer to the k8s autoscaler. 馃憤
Hi! Why did you implement this rule? Does not it drive to configuration drift? Anyway it should be an opportunity to make any changes through terraform configuration, not by manual click in AWS console!
@dev-e no, because in k8s you need to use the cluster-autoscaler: https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/docs/autoscaling.md
@max-rocket-internet use of cluster-autoscaler is not mandatory. What if you want to control number of nodes by yourself?
@dev-e sure but then you make the change manually.
@max-rocket-internet, and so we get a configuration drift.
Sure. But most people use the cluster-autoscaler which is the proper way of handling scaling up and down. So what can we do? Lifecycle rules don't support interpolation so we can't make it easily configurable either.
@max-rocket-internet, thanks, I understood your argumentation. Actually I meant the minimum number of nodes that cluster-autoscaler cannot bring down. With autoDiscovery.enabled=true we still can operate with the minimum capacity by modifying asg_min_size parameter. Maybe it will be useful to add somewhere to docs about cluster-autoscaler.
Sure. But most people use the cluster-autoscaler which is the proper way of handling scaling up and down. So what can we do? Lifecycle rules don't support interpolation so we can't make it easily configurable either.
This is just blatantly false.
Especially given that less and less support for the autoscaler is built in, it seems like this should be configurable. I will likely open a PR for this.
Or I guess it has to be a static list. This is really unfortunate.