IBM-Cloud / terraform-provider-ibm

https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs
Mozilla Public License 2.0
342 stars 671 forks source link

Source name in event notification instance defaults to 'compliance' when using "ibm_scc_instance_settings" resource #5579

Open iamar7 opened 3 months ago

iamar7 commented 3 months ago

Community Note

Terraform CLI and Terraform IBM Provider Version

Terraform v1.5.7

Affected Resource(s)

Terraform Configuration Files

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

https://github.com/terraform-ibm-modules/terraform-ibm-scc/tree/main/examples/complete

Expected Behavior

The source shouldn't be set as "compliance" by default or there should be an option to set the source name.

Actual Behavior

It sets the source in the event notification instance with the name "compliance". As a result, if two SCC instances are provisioned using this module, the second instance attempting to use the EN will fail with an error stating that a source with the same name already exists.

Steps to Reproduce

Clone the repository and then follow the following steps:-

  1. Go to the complete example directory
  2. export TF_VAR_ibmcloud_api_key="xxxxxxXxxxxxxXxxxxxxXXxxxxxxxxXXXX"
  3. terraform init
  4. terraform plan
  5. terraform apply

Important Factoids

References

tyao117 commented 2 months ago

allowing this capability would be difficult to incorporate because the endpoint used to READ the settings doesn't return back the source_name

iamar7 commented 2 months ago

@tyao117 what is happening due to the above issue is that when the scc-da is used to create a new SCC instance with referencing an existing Event Notifications service, any additional project/configuration using SCC module fails because of the existing source name. Also, it is not optimal to create a separate EN instance for SCC instance.

ocofaigh commented 2 months ago

@tyao117 I would say that this is a common use case. Multiple SCC instance across different regions, but all configured to use the same Event Notifications instance? It also seems that the source name can be set in the UI, so I would expect terraform to be able to do the same thing?

image

tyao117 commented 2 months ago

@ocofaigh and @iamar7, i understand your use case.

Let me explain the issue in detail as an user who is using the API/Terraform:

  1. The user can set up an event notification configuration using the PATCH endpoint /settings(Making/Modifying the resource scc_instance_settings):
    {
        "object_storage":{
        ...
        },
        "event_notifications":{
            "instance_crn":"{event_notifications_crn}:",
            "source_name":"{source_name}",
            "source_description":"{}"
        }
    }
  2. If it succeeds, the user can see the settings configured using the GET endpoint /settings(getting the config state of newly created scc_instance_settings):
    {
      "event_notifications": {
        "instance_crn": "{{event_notifications_crn}}",
        "updated_on": "{{timestamp}}",
        "source_id": "{{event_notifications_crn}}"
      },
      "object_storage": {
      ...
      }
    }

If you notice in the event_notifications block, there is a difference between the GET and PATCH call where the source_name and source_description are not returned from the GET call(reading the resource in Terraform). Those two fields not being returned is the reason the Terraform plugin have those fields hardcoded.

The source_name and source_description are currently hard coded in the Terraform plugin to prevent any Terraform drift from happening because the Terraform read expects those fields to be returned back.

The fix requires an API endpoint change to fix/close your issue.

ocofaigh commented 1 day ago

This was fixed in https://github.com/IBM-Cloud/terraform-provider-ibm/pull/5818 since the source name is now required when doing EN integration