terraform-ibm-modules/terraform-ibm-watsonx-saas-da

A deployable architecture solution to deploy IBM Watsonx SaaS resources.

terraform-ibm-watsonx-saas-da's Issues

Provide an option to create a project with "Mark as sensitive" flag

Description

Allow the user to request the WatsonX project to be created with "Mark as sensitive" flag.

The SCC profile AI Guardrails 2 (v.1.1.0) checks for the project settings and flag projects not using the flag as non-compliant.
The flag can only be set when the project is created, so the DA should allow the users to deploy a compliant configuration.

Per https://api.dataplatform.cloud.ibm.com/v2/projects/docs/swagger/#/Projects/project_create, the settings.access_restrictions.data element can control the "Mark as sensitive" flag.

New or affected modules

configure_project/main.tf

---

By submitting this issue, you agree to follow our Code of Conduct

Unexpected status code 401 from API https://private.us-south.kms.cloud.ibm.com/api/v2/keys

I observed the following error when deploying the DA:

 2024/08/29 20:51:21 Terraform apply | Error: unexpected response code '401': {"statusCode":401,"message":"Unexpected status code 401 from API https://private.us-south.kms.cloud.ibm.com/api/v2/keys"}
 2024/08/29 20:51:21 Terraform apply | 
 2024/08/29 20:51:21 Terraform apply |   with module.storage_delegation[0].restapi_object.storage_delegation,
 2024/08/29 20:51:21 Terraform apply |   on storage_delegation/main.tf line 36, in resource "restapi_object" "storage_delegation":
 2024/08/29 20:51:21 Terraform apply |   36: resource "restapi_object" "storage_delegation" {
 2024/08/29 20:51:21 Terraform apply | 
 2024/08/29 20:51:21 �[1m�[31mTerraform APPLY error: Terraform APPLY errorexit status 1�[39m�[0m

Re-apply hit the same error

Lock the provider versions in the DA

I also noticed that the DA is not locked into an exact provider version. This is not a good practise as it means when new provider versions are released, your DA may break.
You should use >= x.x.x for modules, and then use = x.x.x for DAs

Insufficient account entitlements error seen when trying to enable storage delegation

 2024/09/02 15:39:50 Terraform apply | Error: unexpected response code '403': {"statusCode":403,"message":"Insufficient account entitlements."}
 2024/09/02 15:39:50 Terraform apply | 
 2024/09/02 15:39:50 Terraform apply |   with module.storage_delegation[0].restapi_object.storage_delegation,
 2024/09/02 15:39:50 Terraform apply |   on storage_delegation/main.tf line 36, in resource "restapi_object" "storage_delegation":
 2024/09/02 15:39:50 Terraform apply |   36: resource "restapi_object" "storage_delegation" {
 2024/09/02 15:39:50 Terraform apply | 

What is the missing entitlements? Is it documented somewhere?

Update status badge to graduated on README.md

Set paid plans as default

Free plans have some restrictions, we should use paid plans to enable all the capabilities.

Storage delegation does not work when KMS is private

When KeyProtect is set to private endpoints/network only, the storage-delegation module will fail to create a key.

This can be resolved using the endpoint_type parameter for ibm_kms_key resources.

As this DA will typically run in Schematics, and KeyProtect private endpoints are always enabled, I think you can just add the parameter, but if you want to add logic/variables to control it, that is up to you.

Decoding access token fails intermittently

terraform-ibm-watsonx-saas-da/main.tf

Line 56 in db51d5c

account_id = jsondecode(base64decode(regex("^Bearer .+\\.(.+)\\..+$", data.ibm_iam_auth_token.deployer.iam_access_token)[0])).account.bss

Terraform's base64decode function is sensitive to base64 padding and the JWT token does not have one.
When the token part has certain length that would require the padding (trailing ==) in the encoded value, base64decode throws an error and plan/apply fails.
Apparently parsing the token for an account ID is not a good idea.

I think it would be better to fetch the necessary attributes in the configure_project module that should construct the URL and return it. Account ID can be parsed from a CRN of a watson instance.

Support deploying some of the watson services in jp-tok region.

Description

Use case: some customers want to deploy some of the watson services in jp-tok region.

Issue: currently, the location field is set to allow only the regions that are supported by ALL watson service.

2 approaches:

• In the location field - add all regions supported by at least one watson service. Add some static checks in the terraform logic to error out if the users selected to deploy a service in a region that is not supported
• Or, add an optional region input for each watson service

restapi call of v2/projects returned 502 Bad Gateway

The below error was seen when deploying WatsonX SaaS DA. Creating the issue for tracking to see if it occurs frequently or not..

2024/09/04 13:37:43 Terraform apply | module.configure_project[0].restapi_object.configure_project: Creating...
 2024/09/04 13:37:52 Terraform apply | 
 2024/09/04 13:37:52 Terraform apply | Error: unexpected response code '502': <html>
 2024/09/04 13:37:52 Terraform apply | <head><title>502 Bad Gateway</title></head>
 2024/09/04 13:37:52 Terraform apply | <body>
 2024/09/04 13:37:52 Terraform apply | <center><h1>502 Bad Gateway</h1></center>
 2024/09/04 13:37:52 Terraform apply | <hr><center>cloudflare</center>
 2024/09/04 13:37:52 Terraform apply | <script type="text/javascript"  src="/mLarPub5/S0K/XkJ/zGe561KkpO/N9YO6c2rJNbh/BzYlJg/dzg1I/xl5JDc"></script></body>
 2024/09/04 13:37:52 Terraform apply | </html>
 2024/09/04 13:37:52 Terraform apply | 
 2024/09/04 13:37:52 Terraform apply | 
 2024/09/04 13:37:52 Terraform apply |   with module.configure_project[0].restapi_object.configure_project,
 2024/09/04 13:37:52 Terraform apply |   on configure_project/main.tf line 1, in resource "restapi_object" "configure_project":
 2024/09/04 13:37:52 Terraform apply |    1: resource "restapi_object" "configure_project" {

use regional data platform APIs

Trying to deploy the SaaS DA in eu-de region, I found a strange behaviour. Basically I provisioned ML and Studio in eu-de (COS is global) but when I called POST /transactional/v2/projects , the watson project was created in us-south (and the COS bucket as well). If I try to use it, it does not work since there is no ML instance associated.

The issue is in the endpoint used, http://api.dataplatform.cloud.ibm.com/ is not global but is related to us-south.
For common data platform APIs:

• Dallas - api.dataplatform.cloud.ibm.com
• London - api.eu-uk.dataplatform.cloud.ibm.vom
• Frankfurt - api.eu-de.dataplatform.cloud.ibm.com
• Tokyo - api.jp-tok.dataplatform.cloud.ibm.com

Improve description of the variables

#4 (comment)

Add support for HPCS key encryption

The cos_kms_crn input has validation that will only allow Key Protect, however HPCS is supported by the COS service for encrypting buckets.
By not supporting HPCS, it means the GenAI / RAG stack cannot support HPCS, yet all other DAs allow HPCS.

I also notice the code is using the provider directly to create keys and key rings. All other DAs are using https://github.com/terraform-ibm-modules/terraform-ibm-kms-all-inclusive

split api key used for provisioning and configuration

currently we use ibmcloud_api_key for everything, we should split what is used from TF provider to provision resources and what we use to call watson APIs. In this way we can use a trusted profile to provision the services.

Split user and project configuration into separate modules

Description

As we need to create a new user (to be confirmed) and a new project (this is confirmed) in the RAG App DA, it makes sense to reuse the same modules used to provision WatsonX AI users/projects in the terraform-ibm-watsonx-saas-da module. Therefore, could we split those modules into their own repositories so they can be reused?

New or affected modules

terraform-ibm-watsonx-saas-da

new:
terraform-ibm-watsonx-saas-user
terraform-ibm-watsonx-saas-project

---

By submitting this issue, you agree to follow our Code of Conduct

onboard watsonx da into catalog from release in this repo

Description

@ocofaigh - could we plug the catalog onboarding pipeline here?

Align references to watson and watsonx products in the output variables to their proper brand names.

Affected modules

• watsonx_saas

Terraform CLI and Terraform provider versions

• Terraform version:
• Provider version:

Terraform output

Debug output

Expected behavior

all Brand names should be accurate.
Watsonx Discovery -> Watson Discovery
watson platform -> watsonx platform
Watson Governance -> watsonx.governance

Actual behavior

Steps to reproduce (including links and screen captures)

1. Run terraform apply

Anything else

---

By submitting this issue, you agree to follow our Code of Conduct

Update the default naming convention for the storage delegation key protect key name

Deploy Watson SaaS DA v1.4.1 with:

• cos_kms_key_crn = null (default value)
• cos_kms_new_key_name = "" (default value)
• cos_kms_ring_id = null (default value)
• resource_prefix = conall

The plan shows the key name being called: key_name = "conall-"

 2024/09/02 11:26:27 Terraform plan |   # module.storage_delegation[0].ibm_kms_key.kms_key[0] will be created
 2024/09/02 11:26:27 Terraform plan |   + resource "ibm_kms_key" "kms_key" {
 2024/09/02 11:26:27 Terraform plan |       + crn                     = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + endpoint_type           = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + force_delete            = true
 2024/09/02 11:26:27 Terraform plan |       + id                      = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + instance_crn            = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + instance_id             = "crn:v1:bluemix:public:kms:eu-de:a/9f9af00a96104f49b6509aa715f9d6a5:361aec48-b8a9-4b93-bd0d-e3a2384990d4::"
 2024/09/02 11:26:27 Terraform plan |       + key_id                  = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + key_name                = "conall-"
 2024/09/02 11:26:27 Terraform plan |       + key_ring_id             = "default"
 2024/09/02 11:26:27 Terraform plan |       + payload                 = (sensitive value)
 2024/09/02 11:26:27 Terraform plan |       + registrations           = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + resource_controller_url = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + resource_crn            = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + resource_group_name     = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + resource_name           = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + resource_status         = (known after apply)
 2024/09/02 11:26:27 Terraform plan |       + standard_key            = false
 2024/09/02 11:26:27 Terraform plan |       + type                    = (known after apply)
 2024/09/02 11:26:27 Terraform plan |     }

There should probably be some kind affix to the default naming convention so it shows something like this: conall-storage-delegation-key

Allow to use references to existing instances

Description

When the Watson SaaS DA is used to deploy resources for multiple solutions or is used in a stack context, the users should be able to use references to existing instances instead of provisioning new ones, especially for services with expensive plans like Discovery or Assistant.

• Allow an optional parameter for Watson Discovery instance GUID. If supplied, no new instance is created, the plan parameter is ignored. The output values related to Discovery instance are set to corresponding attributes of the instance
• Allow an optional parameter for Watson Assistant instance GUID. If supplied, no new instance is created, the plan parameter is ignored. The output values related to Discovery instance are set to corresponding attributes of the instance

The main advantage of this feature is the ability to seamlessly integrate the existing instances in stack deployments where the dependent components can use the output of the Watson SaaS DA in the same way whether new instances are provisioned or existing ones are referenced.

New or affected modules

mail.tf

---

By submitting this issue, you agree to follow our Code of Conduct

Allow provisioning of Watson instances with private endpoints

Description

The user should be able to enforce the allowed networks on provisioned instances by allowing to pass the service-endpoints parameter when creating a service instance:

 resource "ibm_resource_instance" "machine_learning_instance" {
......
   parameters = {
     service-endpoints: "private"
   }

The default for the service endpoint parameter could be set to "public" to keep the existing default functionality.
Note that the "private" option is not available on "lite" plans.

Since switching to private only endpoints may disrupt the integration or other processes, we need to have a way to control endpoint type for each service individually.

Private endpoints for Watson Machine Learning instances are required by the AI Guardrails compliance profile in SCC.
The endpoint type cannot be changed once the instance is provisioned.

New or affected modules

---

By submitting this issue, you agree to follow our Code of Conduct

Error when requesting no project to be created

When running the DA with watsonx_project_name = "__NULL__" the terraform plan fails due to no items in module.configure_project.

The DA should allow passing empty project name which should result in no WML project being created.
The outputs related to WML project should be empty in this case.

terraform-ibm-watsonx-saas-da/outputs.tf

Line 132 in 1b805c5

value = module.configure_project[0].watsonx_project_id

demo project already exists - initial run

Seen this error a few times when deploying the DA in an existing account. It seems that the project name is unique per account (regardless of the number of machine learning instance), so suggesting to add a random suffix to the name to avoid clashes.

configure_project | Failed | unexpected response code '400': Project name 'demo' already used.

SaaS DA is intermittently failing on deploy

The RAG stack failed catalog validation on the Watson Saas deploy. After rerun the validation passed.
It is an intermittent failure

error

Terraform planned the following actions, but then encountered a problem:

  # module.configure_user.null_resource.configure_user must be replaced
-/+ resource "null_resource" "configure_user" {
      ~ id       = "2144875551820406457" -> (known after apply)
      ~ triggers = { # forces replacement
          ~ "always_run" = "2024-07-04T17:57:35Z" -> (known after apply)
        }
    }

  # module.configure_user.null_resource.restrict_access must be replaced
-/+ resource "null_resource" "restrict_access" {
      ~ id       = "7300154366233028698" -> (known after apply)
      ~ triggers = { # forces replacement
          ~ "always_run" = "2024-07-04T17:57:34Z" -> (known after apply)
        }
    }

Plan: 2 to add, 0 to change, 2 to destroy.

Error: failed to find an object with the 'metadata/guid' key = 'f2d50750-891d-4c71-937e-6bad51cb55b0' at //api.dataplatform.cloud.ibm.com/v2/projects

  with module.configure_project[0].data.restapi_object.get_project,
  on configure_project/main.tf line 56, in data "restapi_object" "get_project":
  56: data "restapi_object" "get_project" {

 [1m�[31mTerraform PLAN error: Terraform PLAN errorexit status 1�[39m�[0m

resource group handling

terraform-ibm-watsonx-saas-da/main.tf

Line 14 in ea3f756

module "resource_group" {

Replace by

module "resource_group" {
  source                       = "terraform-ibm-modules/resource-group/ibm"
  version                      = "1.1.5"
  resource_group_name          = var.existing_resource_group == false ? var.resource_group_name : null
  existing_resource_group_name = var.existing_resource_group == true ? var.resource_group_name : null
}

for consistency.

The boolean also allows to execute the logic in the case where group name is not known at apply time (eg: when terraform logic call the DA)

Include resource group ID as output

Description

Include created resource group ID as output - as discussed, we will probably need this in the RAG App DA later.

New or affected modules

terraform-ibm-watsonx-saas-da

---