Very good question, you're thinking about the impact of Turbonomic (no S) actions beyond the impact of the individual workloads. Unfortunately today, there is no means of reconciling a change in Terraform with what Turbonomic knows/sees/analyzes about the running workload. What is your process today for reconciling those changes between Terraform and the running workload? Do you redeploy the workload with the new definition in Terraform immediately (cattle), or do you make the change in Terraform and then to the running workload manually (pets)? You can integrate Turbonomic into whichever of these existing processes you are using today via the use of webhook workflows.
- In the case that you are managing 'cattle' and redeploying the workload, you can replace the native execution of the Turbonomic action with a webhook workflow to send the change to Terraform instead.
- In the case that you are managing 'pets' and manually updating the workloads, you can let Turbonomic change the running workload, and then send the change to Terraform to update the IAC/source of truth via a webhook workflow.
Is that helpful?
------------------------------
Gregg Minichiello
------------------------------
Original Message:
Sent: Fri October 06, 2023 12:19 AM
From: awais ali
Subject: Scaling ASG VMs and Pods managed by ArgoCD
Hey Greg,
Thanks a lot for getting back with an insightful reply. Considering that it would change the launch configs, I had a similar question about the IaC (Terraform, Pulumi). So consider I am maintaining my Infrastructure as code in Terraform, Turbonomics performs an action, and one of my engineers goes and changes something in Terraform, so the Terraform plan will show the change that no one had made because of the drift in the infrastructure and the state file. How has that been taken care of? Does Trubonomics make changes to Terraform files as well to make plans clean for Terraform?
------------------------------
awais ali
Original Message:
Sent: Thu October 05, 2023 03:49 PM
From: Gregg Minichiello
Subject: Scaling ASG VMs and Pods managed by ArgoCD
Hello!
I can speak to the ASG portion of your question but i don't have enough experience to touch on the K8s part. Turbonomic does not affect the individual EC2 instances within an ASG. Turbonomic will change the launch configuration for the ASG, and when a new VM is launched it will use the newly configured size for each EC2 it launches. This avoids the loop scenario you describe if Turbonomic were to simply change the running EC2, and the ASG would revert it on new launch.
------------------------------
Gregg Minichiello
Original Message:
Sent: Tue October 03, 2023 06:08 AM
From: awais ali
Subject: Scaling ASG VMs and Pods managed by ArgoCD
Hey guys,
How does Turbonomic react to occasions when it recommends a certain VM that is part of an ASG (Auto Scaling group) or pods that are managed using cluster auto schedular or using ArgoCD.
I want to know that if we take an action using Turbonomics and the ASG revert it back, so we will be moving in a circle where Turbonomics would try to decrease the size or delete a VM and ASG would try to make that again resulting in a never ending loop?
Similar is the case with Kubernetes resources, since people use different tools to mange their k8s resources. what is the Turbonomics strategy to cope with that?
------------------------------
awais ali
------------------------------