nsxt_policy_project short_id is not marked ForceNew

[adarobin]

Describe the bug

The short_id field of the nsxt_policy_project is not marked with ForceNew. This causes an error to be returned by Terraform if you attempt to perform an apply with a change to this field.

Reproduction steps

1. Attempt to change the short_id of an existing nsxt_policy_project

Expected behavior

A plan should show that the nsxt_policy_project needs to be recreated in order to change the short_id. An apply should not throw an error message.

Additional context

╷
│ Error:  Failed to update Project compute.services: short_id once set cannot be modified. (code 524234)
│ 
│   with module.compute_services_project.nsxt_policy_project.main,
│   on ../modules/miserver_nsx_project/main.tf line 1, in resource "nsxt_policy_project" "main":
│    1: resource "nsxt_policy_project" "main" {
│ 
╵
Releasing state lock. This may take a few moments...

[ksamoray]

Hi @adarobin,
NSX API defines short_id as a value that can be assigned only during creation and cannot be updated.
While ForceNew will enable "updating" this attribute, in reality the project object will be deleted and replaced with a new one.
As this could impact the project's sub-objects (or more likely, fail - NSX will not perform a cascaded deletion if I'm not mistaken), I don't think that using ForceNew makes sense in this case.
I'd rather leave this as a create-only attribute as it is in the NSX UI. @annakhm what's your opinion about this?

[annakhm]

I would agree ForceNew is an overkill here, recreating the whole project is likely not what the user had in mind when changing short_id. Unless the project is brand new with nothing created yet below it.
@ksamoray do you think it is feasible to recreate the project from Update code in case its empty, and otherwise throw an error?

[ksamoray]

@annakhm it's never empty, if the value is not assigned by the user, NSX assigns a value, e.g the project_id if it's short enough and unique. Which is why this attribute is Computed: true

[adarobin]

It doesn't feel very Terraform-like for it to not propose a delete and recreate. There are other id-type fields in this provider that have ForceNew set on them (nsx_id is a prime example). If I attempt to change similar fields in other providers (i.e. project_id in google_project the plan will show that the resource will be destroyed and recreated.

recreating the whole project is likely not what the user had in mind when changing short_id

This is a true statement, but if I saw the plan propose a destroy and recreate I would have understood what was going on and figured out how I wanted to handle it. What I did not expect was a successful plan showing an update followed by an apply that threw an error. At the least, the plan should have thrown the error from my perspective.

[annakhm]

@annakhm it's never empty, if the value is not assigned by the user, NSX assigns a value, e.g the project_id if it's short enough and unique. Which is why this attribute is Computed: true

Sorry for bad phrasing, I meant empty project, not empty short_id

[annakhm]

It doesn't feel very Terraform-like for it to not propose a delete and recreate. There are other id-type fields in this provider that have ForceNew set on them (nsx_id is a prime example). If I attempt to change similar fields in other providers (i.e. project_id in google_project the plan will show that the resource will be destroyed and recreated.

recreating the whole project is likely not what the user had in mind when changing short_id

This is a true statement, but if I saw the plan propose a destroy and recreate I would have understood what was going on and figured out how I wanted to handle it. What I did not expect was a successful plan showing an update followed by an apply that threw an error. At the least, the plan should have thrown the error from my perspective.

@adarobin, thanks for your comment, good point about failing on plan stage. This could be a good compromise, however this doesn't seem feasible with terraform sdk that we use today, since we don't have access to the state from the context of validation function. Therefore, there is no way to determine whether value was updated.

[salv-orlando]

Hello @adarobin! We are going over "historical" issue to clear our backlog.
Is this still a concern for you?

While I get your point about being able to do and recreate, my concern is that a NSX project is a rather "big" container which will host a different number of objects (transit gateways, VPC, Tier-1s, segments, etc.).

When I was discussing with Anna about your issue, my point was that I would rather not have any ForceNew attribute for this kind of resources.
Thought?

[adarobin]

Hi @salv-orlando,

Recreating the resource is how I would expect Terraform to treat this scenario. For example, say I made a new project and then realized I forgot to explicitly set short_id so I wanted to recreate the project. If I had only made a project, the project would be recreated without issue. If I had created other resources in the project, the recreate would fail (assuming no cascade deletion). An error message that the project could not be deleted because it contains resources makes much more sense to me in this scenario. I could then decide if I wanted to mark all of the resources created under the project as tainted in order to move the process along or live with the mistake and leave the project alone.

It certainly isn't a deal breaker -- just unexpected behavior that deviates from the norm in Terraform. If I make a change that requires recreating a resource, then a plan for that change should always show that. Otherwise, I am seeing a plan that is not valid and will never be able to succeed.

Edit: I guess the TL;DR is I still think this is a bug, but if you close this and leave it as is no hard feelings :-)