For EKS that was created with Terraform

[onabison]

Hi,

I know it's be a request from my team -

An EKS cluster gets deployed (created) by Terraform, a state file gets created and uploaded to the backend bucket. Once one uses eksupgrade to maintain their cluster with the latest updates, the state file is now stale.

My idea is to add a feature/option for the tool to ask you for the location of your state file and update it with the latest versions of the objects that got updated.

thoughts?

[bryantbiggs]

Yes - this is very top of mind for us since a lot of users are creating clusters with Terraform today. We are open to hearing thoughts on how users might expect this functionality to work - what the interaction or experience between Terraform and eksupgrade looks like

[onabison]

I'm glad to hear that this is a valid topic and that it will be addressed and added as a feature.

My thought was, as I mentioned, that the program would prompt the user to provide the S3 bucket where the state file is (one should already be authenticated to the account as part of executing the eksupgrade command process), the tool will "save" the outputs of each component version as a string and will then search the state file for the appropriate values and replace the version with the one that was just updated. While most clusters will have different components (add-ons etc) there might be a need to do a describe on the cluster before the upgrade to create a list of all the component that will be upgraded during the upgrade and add those to the list of items that need to be searched and updates in the state file.

I have not ran through the entire process so this is just a very high level thought...

Thanks!
NK

[bryantbiggs]

Thank you for sharing. Its a challenging problem - I don't think we can simply manipulate the state directly because that would introduce an issue with the current Terraform code (3 part system - HCL code <-> Terraform state <-> actual resource state) - on the next plan/apply, the code will still have the "old" values which Terraform would interpret as needing a change (a bad change - trying to rollback versions which is not supported for the cluster itself)

[onabison]

Yes, agreed. I haven't thought it all the way through of course, just have the general thought of trying to use the eksupgrade tool and keeping the state file up-to-date for exact "rollback" reasons, which doesn't apply on everything that gets updates (as you stated the control plane version can't be rolled back). I think, for the most parts, it's the node or add-ons versions that would have the need to maintain compatibility and would need to be "agile"....