Importer normalize #14891
Importer normalize #14891
Conversation
Normalize the ID using the importer function to conform to what is defined in the ID formatter. This is to mitigate cases like users import resource ID with lowercase 'g' for the resource group. In this case, the current validation in the importer raise no error, which results into the incorrect cased ID leak into terraform state. This will cause the other referencing resource get unexpected plan diff (see hashicorp#14854). This commit adds the helper function for both untyped and typed sdk. The users are expected to pass in a wrapper function around the parse function generated via the resource id tool. While this wrapper might be eliminated once we have generic in Go.
|
hey @magodo Thanks for this PR. Whilst this is one approach we could look to take, we're intentionally not doing so and validating that the Resource ID is parsed in the correct casing so that this is predictable at import (and usage) time. As you've mentioned there's a bug in the older Resource ID parser logic (which are generated via the tool in this repository) where the casing on the resourceGroups segment isn't being validated correctly - however the new Resource ID parsers do, so we should probably look to instead fix this via fixing the old Resource ID parser to check the casing on the Resource Groups segment (or to update the Resource ID generator to use the newer Resource ID parsers, which isn't something we're planning to do at this point in time, in favour of moving those out of this repository in the near future). Whilst we can look to make the parser case-sensitive for this segment - we'd need to ensure this is still insensitive for the Resource Group ID resource at this time, since this is the only resource which has this segment in lower-case ( Where we could go through and update the existing Resource ID parsers to use the new approach, give we're not far off replacing the existing ones with the new approach - I think it's probably best waiting until the new ones are rolled out everywhere, rather than amending the older Resource ID parsers in this case, WDYT? Thanks! |
|
@tombuildsstuff That makes a lot of sense, thank you for letting me know the details! |
|
One thing worth mentioning is that we can validate case sensitively for importing, while we still need the case insensitive one for parsing id from response |
Indeed, the new Resource ID Parsers generate an insensitive parser by default, which makes that easier. Since this'll be fixed by both the new Resource ID Parsers (and the Resource Group ID issue fixed by updating this ID with a state migration), whilst I'd like to thank you for this contribution I'm going to close this PR for the moment - but we'll be switching over to use the new Resource ID parsers in the not-too-distant future which should solve this 👍 Thanks! |
|
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. |
Normalize the ID using the importer function to conform to what is
defined in the ID formatter.
This is to mitigate cases like users import resource ID with lowercase
'g' for the resource group. In this case, the current validation in the
importer raise no error, which results into the incorrect cased ID leak
into terraform state. This will cause the other referencing resource get
unexpected plan diff (see #14854).
This commit adds the helper function for both untyped and typed sdk. The
users are expected to pass in a wrapper function around the parse
function generated via the resource id tool. While this wrapper might be
eliminated once we have generic in Go.
Together with this PR comes with two real world examples (one for typed sdk and one for the untyped sdk). If this makes sense, then we can move on refactoring for the remaing resources.