-
Notifications
You must be signed in to change notification settings - Fork 470
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
feat: add var automatic_channel_upgrade #281
Conversation
Potential Breaking Changes in 07aef57: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @the-technat thanks for opening this pr! The pr-check
job failed so would you please run the pre-commit
and pr-check
job on your machine as the document instructed then try again?
I also recommend to add this new variable in examples/startup
's code so our e2e test could cover it. Again, thanks for your contribution!
main.tf
Outdated
condition = (var.automatic_channel_upgrade == null || ( | ||
// or we have set it to patch and only specify the minor version | ||
contains(["patch"], var.automatic_channel_upgrade) && | ||
matches("^[0-9]{1,}\\.[0-9]{1,}$", var.kubernetes_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any special reason we should use this regex here instead of determining whether var.kubernetes_version
is null
or empty?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lonegunmanb when using the patch
channel the user can specify a minor version, like 1.20
or 1.21
, but the user cannot specify a patch version, like 1.20.0
or 1.21.4
.
This is because if the cluster is autoupgraded to a newer patch version because of the channel setting, we dont want Terraform to roll back that change because a specific patch version is specified in the variable kubernetes_version
.
Instead setting a minor version does not trigger a rollback when the patch version is upgraded by the channel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly. Simply checking if it's null is only viable if someone set automatic_channel_upgrade=stable|rapid
since then AKS automatically updates to new minor versions and no one only specifies the major version I guess. But with automatic patch upgrades we want to make sure that a valid minor version (e.g 1.24
or 1.25
) is specified, thus the regex matching those versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I'm not an aks expert, I'll leave the shot to @zioproto , you make the call.
@the-technat I have to go back on the Please dont fix it in this PR. Could you please rebase your branch on the current |
@zioproto, @lonegunmanb I addressed some of your suggestions already, rebased the PR and fixed the pre-commit/pr-test check. I'm happy to add some unit tests as well but first we need to find the correct way of validation. @lonegunmanb suggested moving the checks into
|
I think we could just extract the expression we're using now for the |
@lonegunmanb ah now I see what you meant. Yeah that should work. I'll try to do it. |
- AKS clusters can now be automatically upgraded to new patch or minor versions - Added unit tests to covert differnet auto-upgrade settings - Extended startup example to enable automatic patch upgrades (most common use-case) Signed-off-by: Nathanael Liechti <[email protected]>
@lonegunmanb I added a table-driven unit test to ensure that the upgrade check produces the right result. Is this what you expected? |
Tests still fail but locally they pass. |
No worries, I'll check the test. |
Apology for the inconvenience @the-technat , after a quick glance your unit tests are good, the failure was caused by Checkov check. I'll keep digging. |
Hi @the-technat , thanks for your patience. It looks like Checkov (the policy checking tool we're using now in this pipeline) was broken, to fix the Checkov we need upgrade Checkov's version in our CI runner image, but that brought another issue, in newer Checkov they've introduced new policies for Aks resource, which this module failed to comply for now. I don't want to make this pr too complex, so I want to skip these new policies, would you please help me by adding this config file with you pr so the Checkov would just skip these policies? The new checkov file name should be |
@lonegunmanb no problem, we all well know flaky CI tests 😉. I've added the config file as you recommended and now the tests seem to pass here as well. Anything else that needs to be addressed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @the-technat for your update, almost LGTM, once the e2e test passed, only a tiny change request to solve, one extra commit contains only one line change would make this pr been merged.
I switched the version to |
With pleasure! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @the-technat , LGTM! 🚀
Since AKS now supports automatic upgrades, we @swisspost like to use this feature. I addressed the concerns described in the issue with the following tests:
v1.23.8
usingexamples/startup
.automatic_channel_upgrade=patch
using Terraformv1.23.12
using Azure CLI=> As expected Terraform will downgrade the cluster to
v1.23.8
, same must the case when automatically patching minor versions and specifying the version.So the correct usage would be that one specifies only the minor version (e.g
1.23
) and enables automatic patch upgrade or omits the version field completely and enables automatic minor upgrades. But since Terraform variable validation can't reference other variables I can't catch misconfiguration there. But If I'm honest, it makes absolutely sense to me, that you don't specify the patch version if you want automatic upgrades.Note: the default value must be
null
and notenone
as the Provider docs would suggest. I got errors in validation when trying to passnone
as default value.Issue number
Closes #280
Checklist before requesting a review
CHANGELOG.md
file