-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
New Resource: azurerm_automanage_configuration_profile
#19358
Conversation
GOROOT=C:\Program Files\Go #gosetup Process finished with the exit code 0 |
# Conflicts: # vendor/modules.txt
GOROOT=C:\Program Files\Go #gosetup Process finished with the exit code 0 |
azurerm_automanage_configuration_profile
azurerm_automanage_configuration_profile
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 for this PR @liuwuliuyun, this is off to a good start but there are two issues that need to be addressed. I've pointed these out in-line. Once those have been fixed up we can take another look through this.
internal/services/automanage/automanage_configuration_profile_resource.go
Outdated
Show resolved
Hide resolved
configuration_json = jsonencode({ | ||
"Antimalware/Enable" : false, | ||
"AzureSecurityCenter/Enable" : true, | ||
"Backup/Enable" : false, | ||
"BootDiagnostics/Enable" : true, | ||
"ChangeTrackingAndInventory/Enable" : true, | ||
"GuestConfiguration/Enable" : true, | ||
"LogAnalytics/Enable" : true, | ||
"UpdateManagement/Enable" : true, | ||
"VMInsights/Enable" : true |
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.
These should be exposed as individual properties instead of relying on the user to provide a valid json config.
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.
I agree that making this as individual properties would make it more user friendly. However, this part of property is not specified in swagger. Which means service team could protentially change this. For example, they could add/delete supported properties in the same API version. If that happens, we will introduce breaking change to customers without knowing.
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.
I have meet this multiple times and it is painful to resolve this kind of issue. Here is a recent example: Azure/azure-rest-api-specs#21553 . Plus, jsonencode is a terraform supported function and it is more flexible in this case.
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.
@JeffreyRichter any chance you could comment on the design of this API? We've seen instances of this previously where the API has been defined in this manner which have ultimately had a number of breaking changes to the API contract/payload (e.g. AKS/Kusto) - as such I'm wondering what consistency guarantees are available for the API here, as exposing this as JSON both isn't a good user experience and leaves this pretty brittle.
My understanding was that these "generic settings" API's were not recommended, so I'm kinda surprised to see the API version 2022-05-04
include this approach?
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.
I agree with Tom that this looks very suspicious. I don't have the full context here, but it also seems surprising to me that an open-ended JSON object would have passed by the ARM review board (I'll contact someone on that team and refer them to this). If the Azure service teams knows what can go here, then it should be in the swagger.
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.
I tracked down the original PR where this was introduced and looks like it did go through an ARM review. I think it was either some lack of understanding on the part of the reviewer or a genuine miss. We have already recognized the need for a blocking linter rule for catching this issue in future and we are actively working on plugging this hole. After this automation is put in place, any PR with a "generic setting" will be blocked until either the change is reverted or an exception is granted explicitly.
internal/services/automanage/automanage_configuration_profile_resource.go
Outdated
Show resolved
Hide resolved
…age_configuration"
# Conflicts: # vendor/modules.txt
# Conflicts: # vendor/modules.txt
Hi @stephybun and @tombuildsstuff , I just got the complete list supported by the json input from service developers and there are a dozen of them. Do we still need to change each one of them to seperate property so that adding ~20 new properties to this resource? Plus, this does have possibility to change in the future according to the developers.
|
Close this PR for now till further discussion. |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
This is a brand new resource
azurerm_automanage_configuration_profile
with new RPAutotmanage
Current swagger link:
https://github.com/Azure/azure-rest-api-specs/blob/main/specification/automanage/resource-manager/Microsoft.Automanage/stable/2022-05-04/automanage.json
Overview doc link: https://microsoft.sharepoint.com/:w:/t/AutomationConfigAll/EbQgLvuRu8RMjcoQoyEoZo4BO58xhyMDmcQLgQlAR5Z2YA?e=kjHdP4&wdOrigin=TEAMS-ELECTRON.p2p.bim&wdExp=TEAMS-TREATMENT&wdhostclicktime=1652200808743