azurerm_postgresql_flexible_server_virtual_endpoint - validate with PostgresqlFlexibleServerVirtualEndpointIDInsensitively

[neil-yechenwei]

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

Though the resource ID of Postgresql fs virtual endpoint is with the segment "virtualendpoints" on Swagger but the resource ID on the generated go azure sdk is with the segment "virtualEndpoints". So I will use the "xxxInsensitively" func to resolve this issue.

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_postgresql_flexible_server_virtual_endpoint - validate with PostgresqlFlexibleServerVirtualEndpointIDInsensitively

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)

Fixes #28410

Note

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

[stephybun]

@neil-yechenwei are you able to reproduce the error in the linked issue?

I created a virtual endpoint in the portal with the ID
/subscriptions/***/resourceGroups/bcctest/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-sw/virtualendpoints/acctest-ve-sw

and was able to import it successfully with camel cased virtualEndpoints

$ terraform import azurerm_postgresql_flexible_server_virtual_endpoint.test /subscriptions/***/resourceGroups/bcctest/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-sw/virtualEndpoints/acctest-ve-sw
data.azurerm_subscription.test: Reading...
azurerm_postgresql_flexible_server_virtual_endpoint.test: Importing from ID "/subscriptions/***/resourceGroups/bcctest/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-sw/virtualEndpoints/acctest-ve-sw"...
azurerm_postgresql_flexible_server_virtual_endpoint.test: Import prepared!
  Prepared azurerm_postgresql_flexible_server_virtual_endpoint for import
azurerm_postgresql_flexible_server_virtual_endpoint.test: Refreshing state... [id=/subscriptions/***/resourceGroups/bcctest/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-sw/virtualEndpoints/acctest-ve-sw]
data.azurerm_subscription.test: Read complete after 0s [id=/subscriptions/***]

Import successful!

[stephybun]

Under no circumstance should we be validating input IDs case insensitively. One of the main reasons for moving to the resource ID parsers and validators generated by Pandora is because they can validate IDs case sensitively and prevent IDs with inconsistent casing from from entering a user's config and state.

[neil-yechenwei]

For the current issue, if we don't use xxxInsensitively at this point, the following error will occur during the import process.

Error Message:

azurerm_postgresql_flexible_server_virtual_endpoint.test: Importing from ID "/subscriptions/xx-xx-xx-xx/resourceGroups/acctest-ve-rg-test01/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-test01/virtualendpoints/acctest-ve-test01"...
╷
│ Error: parsing "/subscriptions/xx-xx-xx-xx/resourceGroups/acctest-ve-rg-test01/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-test01/virtualendpoints/acctest-ve-test01": parsing segment "staticVirtualEndpoints": parsing the VirtualEndpoint ID: the segment at position 8 didn't match
│
│ Expected a VirtualEndpoint ID that matched:
│
│ > /subscriptions/12345678-1234-9876-4563-123456789012/resourceGroups/example-resource-group/providers/Microsoft.DBforPostgreSQL/flexibleServers/flexibleServerName/virtualEndpoints/virtualEndpointName
│
│ However this value was provided:
│
│ > /subscriptions/xx-xx-xx-xx/resourceGroups/acctest-ve-rg-test01/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-test01/virtualendpoints/acctest-ve-test01
│
│ The parsed Resource ID was missing a value for the segment at position 8
│ (which should be the literal value "virtualEndpoints").

[neil-yechenwei]

@stephybun , yes. I reproduced this issue with terraform import azurerm_postgresql_flexible_server_virtual_endpoint.test /subscriptions/xx-xx-xx-xx/resourceGroups/acctest-ve-rg-test01/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-test01/virtualendpoints/acctest-ve-test01. As you can see, the segment of the Virtual Endpoint resource in the Azure portal is displayed as "virtualendpoints". However, when I try to import it using the all-lowercase segment directly, I encounter the following error. I noticed that you first retrieve the resource ID from the Azure portal, then convert the all-lowercase "virtualendpoints" into camel case "virtualEndpoints" before importing the resource. So, are you saying this is "by TF design," and users should refer to the Terraform resource documentation to determine the required resource ID format for importing?

Error message:

azurerm_postgresql_flexible_server_virtual_endpoint.test: Importing from ID "/subscriptions/xx-xx-xx-xx/resourceGroups/acctest-ve-rg-test01/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-test01/virtualendpoints/acctest-ve-test01"...
╷
│ Error: parsing "/subscriptions/xx-xx-xx-xx/resourceGroups/acctest-ve-rg-test01/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-test01/virtualendpoints/acctest-ve-test01": parsing segment "staticVirtualEndpoints": parsing the VirtualEndpoint ID: the segment at position 8 didn't match
│
│ Expected a VirtualEndpoint ID that matched:
│
│ > /subscriptions/12345678-1234-9876-4563-123456789012/resourceGroups/example-resource-group/providers/Microsoft.DBforPostgreSQL/flexibleServers/flexibleServerName/virtualEndpoints/virtualEndpointName
│
│ However this value was provided:
│
│ > /subscriptions/xx-xx-xx-xx/resourceGroups/acctest-ve-rg-test01/providers/Microsoft.DBforPostgreSQL/flexibleServers/acctest-ve-primary-test01/virtualendpoints/acctest-ve-test01
│
│ The parsed Resource ID was missing a value for the segment at position 8
│ (which should be the literal value "virtualEndpoints").

[stephybun]

So, are you saying this is "by TF design," and users should refer to the Terraform resource documentation to determine the required resource ID format for importing?

Yes, this is the reason why we try to ensure the example import ID in the documentation always matches the casing that we're expecting in the ID parsers/validators for that resource.

There are two errors described in linked issue, from what you've described you reproduced the second error that was pasted in the issue which is that the provider returns a validation error when trying to import the resource with the ID segment virtualendpoints.

I tried to reproduce the first error by

1. Creating the resource outside of Terraform and ensuring it has the ID segment virtualendpoints
2. Importing resource created in step 1. but updating the casing of segment virtualendpoints to virtualEndpoints

I expected to get the following error but didn't, it imported successfully.

│ Error: Cannot import non-existent remote object
│ 
│ While attempting to import an existing object to
│ "azurerm_postgresql_flexible_server_virtual_endpoint.test",
│ the provider detected that no object exists with the given id. Only
│ pre-existing objects can be imported; check that the id is correct and that
│ it is associated with the provider's configured region or endpoint, or use
│ "terraform apply" to create a new remote object for this resource.

Can you please see if you can reproduce this part of the issue?

[neil-yechenwei]

For the first error, if my understanding is correct, the user was just using a fake resource ID to test the functionality of terraform import, so this is expected. Since both errors are expected behaviors, I will close this PR.