search

terraform-ibm-modules / terraform-ibm-rag-sample-da

A deployable architecture solution to deploy RAG resources.
Apache License 2.0
2 stars 0 forks source link

Update tests to use existing SM instance #73

Open ocofaigh opened 6 months ago

ocofaigh commented 6 months ago

In order to reduce clipping the SM trial quota limit, and to speed up validation tests, can we update https://github.com/terraform-ibm-modules/terraform-ibm-rag-sample-da/tree/main/tests/resources/existing-resources to support using an existing secrets manager instance, and set the test up to use the permanent instance in golden eye dev account?

rajatagarwal-ibm commented 6 months ago

PR https://github.com/terraform-ibm-modules/terraform-ibm-rag-sample-da/pull/83

rajatagarwal-ibm commented 6 months ago

My original PR is merged https://github.com/terraform-ibm-modules/terraform-ibm-rag-sample-da/pull/83.

Had discussion with @vburckhardt and @BRENDANK on the same.

However, I have identified a problem in the PR to use the existing SM, as we are hard coding the names of the secrets and creating them in the default Secret Group. The default value for the create_secret flag is true - which means it always attempts to create a new secret, even in the permanent SM instance where a secret could be created on the first test run and subsequent tests those secrets might not need to be created anymore. (Catch here - nuke might delete those secrets as they're not prefixed with geretain so you don't know what value should we set for the create_secret flag.)

The flow of stack creation is SaaS DA -> ALM DA -> Sample app DA.

The secrets are created in the Sample app DA (https://github.com/terraform-ibm-modules/terraform-ibm-rag-sample-da/blob/main/solutions/banking/main.tf#L33) , but are consumed in the ALM DA. Although ALM DA allows to give whatever name the user wants to give to those secrets, but has default values set, ex ibmcloud-api-key . See https://github.com/terraform-ibm-modules/terraform-ibm-devsecops-alm/blob/main/variables.tf#L285. The ALM DA assumes these secrets to be named that way for the CI/CD/CC pipelines.

Additionally, although ALM DA supports custom secret group names and defaults to Default, but I wonder I would hit the same issue if I pass any other secret group name as it is expecting it to be default.

Looks like a circular dependency here.

Need to have a deep dive discussion on the same. I will schedule a meeting with Vincent and Brendan.