Add new RP blueprint and resource azurerm_blueprint_assignment

[ArcturusZhang]

This PR added new resource azurerm_blueprint_assignment.

REST API: https://docs.microsoft.com/en-us/rest/api/blueprints/
Documentation: https://docs.microsoft.com/en-us/azure/governance/blueprints/create-blueprint-rest-api

And per internal discussion with the blueprint service team and the most urgent customer requirement, we will only add the blueprint assignment first in this PR. Therefore I did a lot work around when composing the acceptance test for this resource.

[jackofallops]

Hi @ArcturusZhang
Thanks for this PR.
I can understand the desire to manage Azure Blueprints in code, as a Preview service it lacks official tooling beyond the portal. That said, I feel that this is the wrong resource to introduce first. After review of this PR I believe that there is a great deal of the code that should be handled by supporting resources / data sources; possibly azurerm_blueprint_definition and azurerm_blueprint_version? (you’ve already covered some of this work in the functions used to enable your tests).

Additionally, I have concerns around the way this resource contains a privilege escalation that the user of the resource is unlikely to be aware of when a System MSI is used (Something that would be better exposed by requiring a Blueprint Definition be created/imported in terraform). The portal grants this temporarily via the Blueprint definition / assignment I believe, where this PR sets it explicitly without removal (which could, of course, be changed to match the portal behaviour.)

Since Blueprints are a large service which doesn’t fit 1:1 into Terraform, we need to work out the best approach forwards here rather than simply duplicating the API behaviour - as such we should not include this resource without support for the base resources it requires. I've done some investigative work on that previously, and I've revisited it to help review this PR. Sadly there are definitely issues and incompatibilities with supporting the blueprints service in general. For example, a parameter can be one of seven different types, which means that holding the default value for each parameter would involve a schema block containing an Optional field for each possible type with appropriate ConflictsWith configuration, this would be very unwieldy for the end user. This problem is even worse for the allowed values which collects together a list of these blocks. As soon as a blueprint contains any degree of complexity, the HCL representation would be nigh impossible to manage.

I don't do this lightly, as I can tell a lot of effort has gone into this, but I'm going to close this PR as I believe the service is not suitable for Terraform in its current form. I will speak with the team on this about possibilities on how it could be potentially supported in the future (either via API changes or if we can work with the service team to make this possible).

[r0b2g1t]

Wouldn't it have been better to develop a suitable PR for Terraform instead of closing it?

[jackofallops]

Hi @r0b2g1t
I appreciate the frustration. As I mentioned above, the service itself isn't a fit for Terraform currently, not just this particular resource, so opening another PR that also won't be able to be merged for the same reasons wouldn't be appropriate. We're intending to discuss this with the relevant teams at Microsoft to see if there is a way forward we can find and implement.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!

[katbyte]

reopend in a limited fashion as #6930