arkadijs
commented
4 years ago Mixed ASG is low level AWS API. Creating a dumb wrapper won't create much added value. We need a recognizable value we could communicate to our customers.
Write a Wiki page:
- Describing exact UX - how I, as a customer of Agile Stacks, with limited understanding of mixed ASGs could benefit from it by making my spot fleet resilient and hopefully cheap.
- Outline the design of the component.
- Define integration points / API:
- to the UI
- node drainer
- autoscaler
- Clusterman?
- EKS?
- local node storage
Break down the task into smaller chunks and create issues with estimates. Then we can discuss.
rstreics
User wants to create a mixed ASGs worker nodes with flexible distribution policies to mitigate spot instance reclamation risk by AWS
In scope of current task
Problem
User wants to benefit from the mixed auto-scaling group purchase options, where they define multiple instance pools, distribution between on-prem and spot instances as well as fulfilment strategy (such as best-capacity or best-price etc).
See details https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html
Motivation
To achieve concern above we can limit mixed asg implementation to the worker pools. In fact http://github.com/agilestacks/stack-k8s-aws can be provisioned without the mixed asg. And mixed asg can be added as a worker pool component as part of platform stack. It is up to [http://github.com/agilestacks/automation-hub](automation hub) to decide should this component to be added to the stack template or not.
In this case we do not want to overload existing component https://github.com/agilestacks/components/tree/master/k8s-worker-nodes with new functionality. It is better design and more flexible to implement as a separate component.
Such separation will give possibility to implement mixed auto-scaling group as a separate component without overloading existing components. In addition it will keep good granularity of the component. Component should do one function (or serve to the one principle).
In addition it will give option will give freedom to choose different provisioning technology.
Technology choice
At present we use http://terraform.io as our default provisioning technology for the cloud resources. However terraform is a declarative. While user wants to list a collection of imperatives (instructions) on how auto-scaling group should behave. Such concern makes terraform to strict.
We don't want to repeat bad practice of mixing imperatives and declarative definitions described in (https://www.thoughtworks.com/radar/techniques/templating-in-yaml)[Tech Radar]. Logical options will be to utilise benefits of CloudFormation with
Key debate is wether we should use Golang or Python as a driver to process imperatives from the user and produce a declarations.