Open iamar7 opened 3 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
@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.
@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?
@ocofaigh and @iamar7, i understand your use case.
Let me explain the issue in detail as an user who is using the API/Terraform:
/settings
(Making/Modifying the resource scc_instance_settings
):
{
"object_storage":{
...
},
"event_notifications":{
"instance_crn":"{event_notifications_crn}:",
"source_name":"{source_name}",
"source_description":"{}"
}
}
/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.
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
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:-
complete
example directoryTF_VAR_ibmcloud_api_key
="xxxxxxXxxxxxxXxxxxxxXXxxxxxxxxXXXX"terraform init
terraform plan
terraform apply
Important Factoids
References
0000