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
Pulumi shouldn't fetch the latest AMI by default #88
Comments
|
Indeed - this is something we want to enable as part of the |
@lukehoban If I correctly understood that feature's behavior, it's not really what we need, as we should still be able to change the AMI by explicitly specifying it. |
When we use the "smart default" to pick the most recent EKS-optimized AMI, we now also mark the image as `ignoreChanges` to ensure that we do not pick up new "smart defaults" later. Users can still explicitly specify an `amiID`, and if they do this will also remove the `ignoreChanges` annotation so that the change will be applied. Fixes #88.
I opened #114 with my proposal for this. I believe it addresses @lbogdan's concern about whether it is possible to "unignore" this so that an explicit AMI can be provided. My feeling is this provides a nice balance of still having a "smart default" at creation time, and allowing full explicit customization, but without any surprises during updates. @ggilmore @lbogdan @metral Would appreciate your feedback on whether this sounds like a good solution. |
That seems to be exactly what we need, thanks! |
This sounds like a good compromise. |
When we use the "smart default" to pick the most recent EKS-optimized AMI, we now also mark the image as `ignoreChanges` to ensure that we do not pick up new "smart defaults" later. Users can still explicitly specify an `amiID`, and if they do this will also remove the `ignoreChanges` annotation so that the change will be applied. Fixes #88.
When we use the "smart default" to pick the most recent EKS-optimized AMI, we now also mark the image as `ignoreChanges` to ensure that we do not pick up new "smart defaults" later. Users can still explicitly specify an `amiID`, and if they do this will also remove the `ignoreChanges` annotation so that the change will be applied. Fixes #88.
Falling back to requiring AMI Id is not so friendly. It would be better to be able to specify an exact k8s version, e.g. |
It looks like, with the merging of #366 and closing of #258, the My team just experienced the issue described here, where the AMI updated and the services running in our cluster experienced downtime. I am not clear about what the solution is, given that Another thought, which may warrant the creation of a new issue: when this happens, ideally the new nodes would be spun up, and Pulumi would wait until they're healthy before swapping over to them and then shutting the old nodes. Is there a way to make that happen? Should I open a new issue for it? |
When using
pulumi update
with an EKS cluster, pulumi's default behavior is to always fetch the latest version of the EKS AMI if nodeAmiId isn't specified.While this behavior can be convenient, unexpected upgrades to the EKS AMI can cause unexpected downtime or break the cluster entirely.
For production situations, it's strongly recommended that you explicitly pass the nodeAmiId parameter so that you have full control over when your nodes upgrade.
pulumi-eks's default behavior should enforce best practices. I propose the following:
nodeAmiId
a required parameter (force users to make a conscious decision about the AMI that they want to use).See https://pulumi-community.slack.com/archives/C84L4E3N1/p1553791785005000 for more discussion.
The text was updated successfully, but these errors were encountered: