Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay/Schedule automated AMI updates #328

Open
preflightsiren opened this issue Aug 20, 2021 · 1 comment
Open

Delay/Schedule automated AMI updates #328

preflightsiren opened this issue Aug 20, 2021 · 1 comment

Comments

@preflightsiren
Copy link
Contributor

Is this a BUG REPORT or FEATURE REQUEST?: Feature Request

Problem: When utilising #320 companies often have different tiers/channels of stability. Often they will want to have an AMI applied to development clusters, before being applied to production clusters.

Solution: Specify in configuration the amount of delay a cluster would like to add before updating the ASG configuration.

eg.

apiVersion: instancemgr.keikoproj.io/v1alpha1
kind: InstanceGroup
metadata:
  annotations:
    instancemgr.keikoproj.io/os-family: "amazonlinux2"
    instancemgr.keikoproj.io/lock-upgrades: "true"
    instancemgr.keikoproj.io/upgrade-delay: "7d"
  name: amazonlinux2-us-west-2b
  namespace: instance-manager
spec:
  eks:
    configuration:
      image: latest

Would update the image ID 7 days after the SSM parameter is changed.

@preflightsiren
Copy link
Contributor Author

I've been thinking about this change over the last couple of days, and I think the best/most natural way to implement would be with: #320 + #321 , and an approver workflow or controller that approves after a period of time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant