Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource: ibm_resource_key is always recreated even when no changes are available for service Role #3803

Closed
prashanth-bhat opened this issue May 26, 2022 · 1 comment · Fixed by #3810
Labels
service/Resource Management Issues related to Resource Manager or Resource controller Issues

Comments

@prashanth-bhat
Copy link

Resource: ibm_resource_key is always recreated even when no changes are available for service Role
We observe this behaviour for Service Roles
Example: Device-Manager in Event Notifications service. Other roles such as Event-Source-Manager, Channel-Editor also has the same behaviour.

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform IBM Provider Version

prashanthbhat@Prashanths-MacBook-Pro EN-TF-new % terraform -v
Terraform v1.2.1
on darwin_amd64

  • provider registry.terraform.io/ibm-cloud/ibm v1.42.0-beta0

Affected Resource(s)

  • ibm_resource_key

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please share a link to the ZIP file.
terraform {
   required_providers {
      ibm = {
         source = "IBM-Cloud/ibm"
         version = "1.42.0-beta0"
      }
    }
  }

resource "ibm_resource_instance" "terraform_demo" {
  plan     = "lite"
  location = "us-south"
  name     = "terraform_demo"
  service  = "event-notifications"
}

resource "ibm_resource_key" "resourceKey" {
    name                 = "ENDeviceManagerKey"
    resource_instance_id = ibm_resource_instance.terraform_demo.id
    role                 = "Device Manager"
}

Debug Output

The output of the terraform apply commands are avilable in the attacment below
output.txt

Panic Output

Expected Behavior

If there are no changes in the TF configuration, even multiple execution of terraform apply should not regenerate the Service Credentials ( and hence API keys).

Actual Behavior

We run the TF configuration mentioned above.
On running it the second time without any changes, it recreates the Service Credentials.
As a result, each run of terraform creates a new API key

Steps to Reproduce

  1. terraform apply
  2. terraform apply # without any changes to the tf configration. See that a new service credential has been wrongly generated

Important Factoids

  • This behaviour is seen on the Service Role which Event Notifications service has defined : "Device-Manager"
  • Please note that terraform does not allow the role to be specified as "Device-Manger" but required the role to be set in the confuration as "Device Manager"
  • When we set the role as "Device Manager" in the configuration we see this in the output of terraform apply
      ~ role                  = "Device-Manager" -> "Device Manager" # forces replacement
  • This seems to be causing the forced regeneration of service credential.
  • Question: Why does the "ibm_resource_key" resource disallow "Device-Manager" role?
    Note: Event notification service defines this service role with "Device-Manager" as the name and "Device Manager" as the Display name in IAM.

References

  • #0000
@github-actions github-actions bot added the service/Resource Management Issues related to Resource Manager or Resource controller Issues label May 26, 2022
@prashanth-bhat
Copy link
Author

Please note the following:
Event Notifications service defines the Service role in IAM:
Name: Device-Manager
Display Name: Device Manager

We initially tried to create a resource with the followig

resource "ibm_resource_key" "resourceKey" {
    name                 = "ENDeviceManagerKey"
    resource_instance_id = ibm_resource_instance.terraform_demo.id
    role                 = "Device-Manager"
}

It failed with the following error:

Error: [ERROR] Error creating resource key when get role: RoleDoesnotExist: Event-Source-Manager was not found. Valid roles are Manager, Writer, Reader, Event Source Manager, Channel Editor, Event Notification Publisher, Status Reporter, Device Manager, Viewer, Administrator, Operator, Editor

We later changed the resource to

resource "ibm_resource_key" "resourceKey" {
    name                 = "ENDeviceManagerKey"
    resource_instance_id = ibm_resource_instance.terraform_demo.id
    role                 = "Device Manager"
}

This worked fine for the first terraform apply. However, each time we re-run, it is regenerating the Service credential as mentioned in the issue above.

kavya498 pushed a commit to kavya498/terraform-provider-ibm that referenced this issue May 31, 2022
kavya498 pushed a commit to kavya498/terraform-provider-ibm that referenced this issue May 31, 2022
kavya498 pushed a commit to kavya498/terraform-provider-ibm that referenced this issue Jun 7, 2022
hkantare pushed a commit that referenced this issue Jun 7, 2022
SunithaGudisagarIBM pushed a commit to ibm-vpc/terraform-provider-ibm that referenced this issue Sep 14, 2022
SunithaGudisagarIBM pushed a commit to ibm-vpc/terraform-provider-ibm that referenced this issue Sep 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service/Resource Management Issues related to Resource Manager or Resource controller Issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant