Unable to set vm_role for device_role

[BegBlev]

Hello,

For netbox_device_role resource if I try to change vm_role from false to true... it works.

terraform apply -target=module.netbox_content.netbox_device_role.test
module.netbox_content.netbox_device_role.test: Refreshing state... [id=19]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.netbox_content.netbox_device_role.test will be updated in-place
  ~ resource "netbox_device_role" "test" {
        id        = "19"
        name      = "test"
        tags      = []
      ~ vm_role   = false -> true
        # (2 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
╷
│ Warning: Resource targeting is in effect
│ 
│ You are creating a plan with the -target option, which means that the result of this plan may not represent all of the changes requested by the current configuration.
│ 
│ The -target option is not for routine use, and is provided only for exceptional situations such as recovering from errors or mistakes, or when Terraform specifically suggests to use it as part of an error
│ message.
╵

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.netbox_content.netbox_device_role.test: Modifying... [id=19]
module.netbox_content.netbox_device_role.test: Modifications complete after 0s [id=19]
╷
│ Warning: Applied changes may be incomplete
│ 
│ The plan was created with the -target option in effect, so some changes requested in the configuration may have been ignored and the output values may not be fully updated. Run the following command to
│ verify that no other changes are pending:
│     terraform plan
│ 	
│ Note that the -target option is not suitable for routine use, and is provided only for exceptional situations such as recovering from errors or mistakes, or when Terraform specifically suggests to use it
│ as part of an error message.
╵

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

If I try to change vm_role from true to false it does not work. Terraform detects the difference and offers to change the value but nothing happens.

terraform apply -target=module.netbox_content.netbox_device_role.test
module.netbox_content.netbox_device_role.test: Refreshing state... [id=19]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.netbox_content.netbox_device_role.test will be updated in-place
  ~ resource "netbox_device_role" "test" {
        id        = "19"
        name      = "test"
        tags      = []
      ~ vm_role   = true -> false
        # (2 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
╷
│ Warning: Resource targeting is in effect
│ 
│ You are creating a plan with the -target option, which means that the result of this plan may not represent all of the changes requested by the current configuration.
│ 
│ The -target option is not for routine use, and is provided only for exceptional situations such as recovering from errors or mistakes, or when Terraform specifically suggests to use it as part of an error
│ message.
╵

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.netbox_content.netbox_device_role.test: Modifying... [id=19]
module.netbox_content.netbox_device_role.test: Modifications complete after 0s [id=19]
╷
│ Warning: Applied changes may be incomplete
│ 
│ The plan was created with the -target option in effect, so some changes requested in the configuration may have been ignored and the output values may not be fully updated. Run the following command to
│ verify that no other changes are pending:
│     terraform plan
│ 	
│ Note that the -target option is not suitable for routine use, and is provided only for exceptional situations such as recovering from errors or mistakes, or when Terraform specifically suggests to use it
│ as part of an error message.
╵

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

After some investigations I found the PATCH request data miss the field when vm_role is set to false.

Here is mitmproxy trace in case changing vm_role from false to true.

PATCH https://netbox.local/api/dcim/device-roles/19/

Here is mitmproxy trace in case changing vm_role from true to false.

PATCH https://netbox.local/api/dcim/device-roles/19/

I searched in Go source code and did not find the problem. Perhaps it comes from Go Netbox library?

Any idea?

Terraform Version

v1.3.6

Step to reproduce

Use the following Terraform configuration:

resource "netbox_device_role" "test" {
  name = "test"
  color_hex = "aa1409"
  vm_role = false
}

[fbreckle]

Hi,

this is a common issue with optional attributes in the go-netbox library. In my fork, I usually just remove the omitempty flag from the Go code so that the behavior you described does not happen.

[BegBlev]

I suppose there are good reasons for you to use your 'go-netbox' fork but don't you think it would be a more comfortable situation to use upstream 'go-netbox' library from 'netbox-community'?
It would be easier to involved them.
Is there a large gap between upstream repo and your fork?

[fbreckle]

don't you think it would be a more comfortable situation to use upstream 'go-netbox' library from 'netbox-community'?
no

Is there a large gap between upstream repo and your fork?
yes

Theyre also not very responsive. E.g. I created a generalized version of this ticket here netbox-community/go-netbox#107

[BegBlev]

OK, this is clear,
I am not very comfortable with swagger and Go but what I understand is that there is a kind of mismatch between omitempty flag and changing resources using PATCH method. An omitempty field can be omitted in a PUT request but it must be included in a PATCH request.
What I don't understand is where the original problem comes from (Swagger description, Swagger to Go convertion, use of PATCH method....) ? I don't know :(