Skip to content

Allow kubernetes apiVersion upgrades #130

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

Merged
merged 4 commits into from
Oct 13, 2021

Conversation

willthames
Copy link
Contributor

Use the API version of the desired state to get current state
and then determine the patch from there

@willthames willthames force-pushed the allow-version-upgrades branch 3 times, most recently from a938e8d to 07dd737 Compare September 27, 2021 03:58
@willthames willthames marked this pull request as draft October 2, 2021 03:44
@willthames
Copy link
Contributor Author

This PR depends on #128 which depends on the outcome of discussions in #135 so I'll convert it to draft for now and rebase on the merged PR once that's agreed.

@willthames willthames force-pushed the allow-version-upgrades branch from 690f513 to 43cda02 Compare October 6, 2021 02:55
@willthames willthames marked this pull request as ready for review October 6, 2021 03:12
@willthames
Copy link
Contributor Author

I've updated this PR based on the changes in #128 - it should be good to go too now.

@pst
Copy link
Member

pst commented Oct 6, 2021

I reviewed #128, once that's merged, I'll tackle this right after.

Use the API version of the desired state to get current state
and then determine the patch from there
@willthames willthames force-pushed the allow-version-upgrades branch from 43cda02 to 71548b2 Compare October 7, 2021 07:38
@willthames
Copy link
Contributor Author

BTW if you want to create a new branch for this I can update the base branch for this PR. If that's the v0.8.0 branch I'll also update legacy_id_format to default to false

@willthames willthames force-pushed the allow-version-upgrades branch from 71548b2 to 11c0caa Compare October 7, 2021 08:05
@willthames willthames force-pushed the allow-version-upgrades branch from 11c0caa to de298e5 Compare October 8, 2021 04:24
@pst
Copy link
Member

pst commented Oct 8, 2021

I'll test and if successful release the current master this weekend. Then we don't need an extra branch, but can merge this into master to prepare for the second release in our series. Does that work for you?

@willthames
Copy link
Contributor Author

@pst - that makes a lot of sense, thanks

@pst
Copy link
Member

pst commented Oct 11, 2021

So, v0.6.0 is released, and I've upgraded my biggest configuration to the new version. The TF plan was 154320 lines long. The plan step produces a 16mb log file in GitHub actions. Because of the line-break change. But it applies without issues.

I'm a bit of scared of the terraform state mv once per resource for that configuration. With remote state, and locking and unlocking per command, this will take a while... I may have to work with a local state temporarily and then overwrite the remote state once I migrated locally.

@willthames willthames force-pushed the allow-version-upgrades branch from de298e5 to 3babef0 Compare October 12, 2021 01:28
Copy link
Member

@pst pst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally LGTM, I'd like to understand the one ForceNew change though before I merge.

When checking whether a resource exists, use any api version.
Only need to use specific versions when modifying an existing
resource.
@willthames willthames force-pushed the allow-version-upgrades branch from 3babef0 to b9847f3 Compare October 13, 2021 02:21
@pst pst merged commit 0d8b1e6 into kbst:master Oct 13, 2021
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

Successfully merging this pull request may close these issues.

2 participants