Eytan Avisror
Eytan Avisror
We should have a functional test that guarantees we are not causing a rolling upgrade with a code change. For example, if a change is made to code around labels...
We should have an automated functional scale/load testing, this test can perform the following actions: - Create N IGs with various configurations (launch template/config, spot/non-spot, fargate, managed, etc) - Assert...
Functional test is failing randomly at times, we should analyze why this is happening: https://github.com/keikoproj/instance-manager/actions/runs/868942813
In order to give more visiblity for namespace users, we should create and associate events with InstanceGroups objects in cases of warning/errors.
A common pitfall people are facing when trying out instance-manager is that they create an IG using a role that is already bootstrapped in the cluster. When the IG is...
We should do some refactoring on awsprovider to simplify it and make it a bit more maintainable. - [x] Split `aws.go` into multiple files according to service - `ec2.go`, `autoscaling.go`...
We should evaluate publishing an autoscaling group's activity history events as Kubernetes events. This might be useful for understanding why certain events happened in the cluster. Implementation can be dependent...
It would make a nice feature to allow changing scaling according to a cron expression. AWS has a feature for scheduled actions, however this will most likely cause a ping-pong...
We should evaluate using event filters to drive reconcile on Update/Delete https://stuartleeks.com/posts/kubebuilder-event-filters-part-2-update/
We should start to think about changes we want to make for v1alpha2. We should explore adding these as new fields in v1alpha1 so that it's easy to migrate. ###...