feat: allow for configuring auto_scaler_profile

[davidspek]

Describe your changes

This PR allows for users to specify the auto_scaler_profile settings when autoscaling is enabled. Some of these settings are quite vital too having the autoscaler work nicely.

Issue number

#000

Checklist before requesting a review

• The pr title can be used to describe what this pr did in CHANGELOG.md file
• I have executed pre-commit on my machine
• I have passed pr-check on my machine

Thanks for your cooperation!

[davidspek]

@microsoft-github-policy-service agree

[zioproto]

Hello, thanks for your contribution @davidspek

Could you please run locally the pre-commit and pr-check steps as explained here:

https://github.com/Azure/terraform-azurerm-aks#pre-commit--pr-check--test

I see this step is failing for this PR:

docker pull mcr.microsoft.com/azterraform:latest 
docker run --rm -v $(pwd):/src -w /src mcr.microsoft.com/azterraform:latest make pr-check

the variables in the variables.tf file are not in the order expected by the linter.

thanks

[davidspek]

@zioproto Thanks for the quick response. I had run the commands locally but it seems like it didn't run quite correctly. Everything should be good now.

[lonegunmanb]

Hello @davidspek, thanks for opening this pr! Almost LGTM but we'd like to keep our variables' description and default value as same as the officical document, so would you please align the description and default value for us? Thanks for your understanding!

[lonegunmanb]

Thanks @davidspek for your reply, we still need enum and number values in the description to be correctly backquoted, would you please copy the descriptions from this markdown document? Thanks for your understanding!

[davidspek]

@lonegunmanb Sorry for the late response. I've made the changes you've requested. Regarding the new_pod_scale_up_delay, it might be related to my specific environment. But given that it'll take me quite some time to try and validate that I've changed the PR to be inline with the provider documentation. We can change this to 0s (which I think it should be set to be default) down the road with a fix in the provider as well.

[lonegunmanb]

Thanks @davidspek for this update, we use terraform-docs to generate readme file from terraform code including this variables.tf, so it's very important to keep variables' description value to valid markdown format so the generated readme file's format could be correct. In the description we should backquote the value. I would suggest that we just copy the provider's document in provider's repo.

[davidspek]

@lonegunmanb Sorry for all the back and forth with all this. I just pushed a commit that I think resolves all your comments.

[lonegunmanb]

Hi @davidspek thanks for the update, almost LGTM and we've passed the e2e test. Only one change request, we can remove default = null, after that, we're good to merge.

Thanks for your understanding and contribution!

[davidspek]

@lonegunmanb Sorry for the late response, I was away on vacation. I'll remove the merge conflicts and make the last change shortly.

[davidspek]

@lonegunmanb If I remove the default = null for auto_scaler_profile_scale_down_delay_after_delete it becomes a required value for the module and the test will fail. I don't think we would want that to be a required value right?

[davidspek]

@lonegunmanb It seems like default = null is now required and used in lots of places. I've added where needed so the tests pass properly.

[lonegunmanb]

Hello @davidspek , I'm sorry we've met an issue on our pipeline so we have to upgrade the Github action yaml files in this repo, would you please merge your branch with the latest master branch so we can run the e2e test? Apology for the inconvenience, we're still refactoring the pipeline.

[davidspek]

@lonegunmanb No problem. I've rebased on the latest master and pushed it now.

[lonegunmanb]

Hello @davidspek , we have a version upgrade test failure:

Terraform will perform the following actions:
        
          # module.aks.azurerm_kubernetes_cluster.main will be updated in-place
          ~ resource "azurerm_kubernetes_cluster" "main" {
                id                                  = "/subscriptions/f7a632a5-49db-4c5e-9828-cd62cb753971/resourceGroups/876f024bb7fd76f9-rg/providers/Microsoft.ContainerService/managedClusters/prefix-876f024bb7fd76f9-aks"
                name                                = "prefix-876f024bb7fd76f9-aks"
                tags                                = {}
                # (30 unchanged attributes hidden)
        
              ~ auto_scaler_profile {
                  ~ new_pod_scale_up_delay           = "0s" -> "10s"
                  ~ skip_nodes_with_local_storage    = false -> true
                    # (15 unchanged attributes hidden)
                }
        
                # (9 unchanged blocks hidden)
            }

If our users upgrade the module's version to the merged version then they would face such change. The issue was caused by reusing var.enable_auto_scaling as this new added dynamic block's toggle so once the user has set this variable to true, they might see the surprise change when they upgrade the module's version.

I would suggest adding a new variable as the toggle to turn on and off this dynamic block.

[lonegunmanb]

We need a new toggle variable for this new added dynamic block to avoid surprise change.

[davidspek]

@lonegunmanb Sorry for the late reply, we were out of office during the holidays. Before I make the above change, would you otherwise prefer a single map variable with all the settings for the autoscaling profile, rather than a dedicated variable for each autoscaler profile setting?

[lonegunmanb]

@lonegunmanb Sorry for the late reply, we were out of office during the holidays. Before I make the above change, would you otherwise prefer a single map variable with all the settings for the autoscaling profile, rather than a dedicated variable for each autoscaler profile setting?

Good point! I'm doing such practices in new created module like this one by using object type with optional attributes. The new object type solves some map's issues so I would prefer object.

But for aks module, my concern is we need keep consistency among our variables. Maybe someday we could publish a major release, converting variables into object types, but for now I would say let's preserve the status quo.

[lonegunmanb]

Thanks @davidspek for updating this pr, only some tiny issues to solve would make this pr been merged.

[davidspek]

@lonegunmanb Should be all good now.

[lonegunmanb]

Thanks @davidspek, LGMT! 🚀