azurerm_kubernetes_cluster - support for upgrade_override_setting property

[hqhqhqhqhqhqhqhqhqhqhq]

Community Note

• Please vote on this PR by adding a 👍 reaction to the original PR to help the community and maintainers prioritize for review
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for PR followers and do not help prioritize for review

Description

Support for upgrade_override_setting property in azurerm_kubernetes_cluster.

PR Checklist

• I have followed the guidelines in our Contributing Documentation.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
• I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
• I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work.
  For example: “resource_name_here - description of change e.g. adding property new_property_name_here”

Changes to existing Resource / Data Source

• I have added an explanation of what my changes do and why I'd like you to include them (This may be covered by linking to an issue above, but may benefit from additional explanation).
• I have written new tests for my resource or datasource changes & updated any relevent documentation.
• I have successfully run tests with my changes locally. If not, please provide details on testing challenges that prevented you running the tests.
• (For changes that include a state migration only). I have manually tested the migration path between relevant versions of the provider.

Testing

• My submission includes Test coverage as described in the Contribution Guide and the tests pass. (if this is not possible for any reason, please include details of why you did or could not add test coverage)

Change Log

Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.

• azurerm_resource - support for the thing1 property [GH-00000]

This is a (please select all that apply):

• Bug Fix
• New Feature (ie adding a service, resource, or data source)
• Enhancement
• Breaking Change

Related Issue(s)

Note

If this PR changes meaningfully during the course of review please update the title and description as required.

[wuxu92]

According to the guideline suggestions, we may make it a top level property.

terraform-provider-azurerm/contributing/topics/schema-design-considerations.md

Lines 75 to 85 in 778c935

	Finally there are instances where the addtional fields/properties for a object/feature are optional or few in number, as shown below.
	Example C.
	```go
	type ManagedClusterStorageProfileDiskCSIDriver struct {
	Enabled *bool `json:"enabled,omitempty"`
	Version *string `json:"version,omitempty"`
	}
	```
	In cases like these one option is to flatten the block into two top level properties:

[WodansSon]

@wuxu92, totally agree with you here, however it appears that not all of the possible fields have been exposed here as well based on the REST API documentation for this property. We should also drop the _settings part from the name of the exposed field in the provider, also per the contributing guide. 🙂

• For blocks avoid redundant words in the name that don't add informational value e.g.

firewall_properties can be shortened to firewall, the same can apply to individual properties e.g. email_address to email.

[wuxu92]

The only other field in the block is forceUpgrade as a boolean, which doesn't need to be exposed. So we may only need to expose one property named upgrade_override_until and keep the expand/flatten logic as it is now.

[hqhqhqhqhqhqhqhqhqhqhq]

I am hesistant to add this as a top level as service team indicated there may be additional properties relevant to upgrade_override_setting added later. We may, in future, need to wrap around these properties a layer down in upgrade_override_setting as it doesn't make sense to expose all of them in top level.

I will update the naming to upgrade_override.

@wuxu92 @WodansSon

[jackofallops]

Thanks @hqhqhqhqhqhqhqhqhqhqhq - this looks mostly good, but I have questions on the schema design and the testing approach if you can take a look?

[jackofallops]

Is this the only configurable property in this block? If so, it might be worth flattening this down to a single property, for example upgrade_override_until?

What happens to this value when the specified point in time passes, is it removed from the response, or still returned?

Should we also validate that the supplied time is in the future?

[hqhqhqhqhqhqhqhqhqhqhq]

Hi @jackofallops

1. There is only one property that user should configure, but service team indicated more may be added later.
2. When the value is in the past in time, it will stay in the response
3. I prefer not to add this check because if the time is in the past, users don't need to update it every single time; they can leave it as is (and it will not have any impact).

[jackofallops]

Does it make sense to be testing a time in the past here? It's unlikely this will be representative of user input? Could we generate a value for this based on time.Now() plus some realistic duration?

[hqhqhqhqhqhqhqhqhqhqhq]

Updated

[hqhqhqhqhqhqhqhqhqhqhq]

Hi @jackofallops @WodansSon
Thank you for review, I have made updates according to requested and changes and ready for re-review.
Please take another look when available and let me know anythings to change, thanks!

Also reran the test:

[WodansSon]

@hqhqhqhqhqhqhqhqhqhqhq, Thanks for pushing those changes, this LGTM 🚀