You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 25, 2022. It is now read-only.
opc_compute_ip_network.example: Error updating IP Network 'example': 404: {"message": "no IpNetwork object named /Compute-OMITTED/user2/example found"}
Expected Behavior
Should be able to modify the resource since user2 has admin privileges for network resources
Actual Behavior
Since opc provider isn't authenticated as user1, user2 cannot modify an imported resource that was created by user1.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
Authenticate as user2 in opc provider
Define ip_network resource in terraform config + add new tags
Currently the terraform provider only supports provisioning using a single user as the provider implementation assume all resource in a single configuration are created under the /Compute-${domain}/${user} path.
It should be possible to reference existing resources using the fully qualified resource name e.g. to reference an existing sec_list created by a different user can be done by sec_lists = [ "/Compute-${var.domain}/${var.another_user}/${var.sec_list_name}" ]. By using multiple terraform configurations and shared state should allow for a separation of concerns where, for example, user1 provisions the security rules and user2 provisions the instances in a separate config. (if there are attributes where use of the fully qualified name does not work, open a bug)
Support for multiple users and custom container paths within a single configuration may be considered if there is significant demand, but no immediate plans, and could be subject to underlying permission limitations based on the ability to user2 to create or modify resources under the user1 resource path
It should be possible to reference existing resources using the fully qualified resource name e.g. to reference an existing sec_list created by a different user can be done by sec_lists = [ "/Compute-${var.domain}/${var.another_user}/${var.sec_list_name}" ].
So I am currently doing this but the /Compute-${var.domain}/${var.another_user} part gets stripped off in the state file, so every time I re-run a plan or apply, it wants to destroy or change the resource.
Terraform Version
Terraform v0.11.7
Affected Resource(s)
I'm guessing this would affect any resource, but this issue is happening with the following:
Terraform Configuration Files
provider "opc" {
user = "user2"
password = "${var.password}"
identity_domain = "${var.domain}"
endpoint = "${var.endpoint}"
}
resource "opc_compute_ip_network" "example" {
name = "example"
ip_address_prefix = "192.168.2.0/24"
tags = ["Imported"]
}
Debug Output
Terraform will perform the following actions:
~ opc_compute_ip_network.example
tags.#: "0" => "1"
tags.0: "" => "Imported"
Plan: 0 to add, 1 to change, 0 to destroy.
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
opc_compute_ip_network.example: Modifying... (ID: /Compute-OMITTED/user1/example)
tags.#: "0" => "1"
tags.0: "" => "Imported"
Error: Error applying plan:
1 error(s) occurred:
opc_compute_ip_network.example: 1 error(s) occurred:
opc_compute_ip_network.example: Error updating IP Network 'example': 404: {"message": "no IpNetwork object named /Compute-OMITTED/user2/example found"}
Expected Behavior
Should be able to modify the resource since user2 has admin privileges for network resources
Actual Behavior
Since opc provider isn't authenticated as user1, user2 cannot modify an imported resource that was created by user1.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform import opc_compute_ip_network.example /Compute-OMITTED/user1/example
terraform apply
Important Factoids
The text was updated successfully, but these errors were encountered: