EASeJ deployment show "Ready to Validate` but it needs required input before validating

[mtamboli]

After project is created by AMA, I see 3 configurations for EASeJ, DB2 and MQ. DB2 gets validated in first attempt as it does not need any input.

For EASeJ, user will click on validate as it shows ready to validate but it fails as there is a required input of subscription id. so user waits for a few minutes, validation fails, user enters subscriptions id, again validation happens for a few minutes and then deployment.

We show change the default to input required edit like MQ to avoid the validation failure.

Affected modules

Terraform CLI and Terraform provider versions

• Terraform version:
• Provider version:

Terraform output

Debug output

Expected behavior

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

[vbontempi]

@mtamboli

this is not an issue but a way the DA is configured to work with subscriptionID:

• the DA code checks that either the subscription_id or subscription_id_secret_crn (currently hidden as there isn't a DA way to create the secret) are != null, so the user added a value
• the subscriptionID is a required parameter, but the current code considers a valid value null due to the logic of the first item
• the subscriptionID default value is currently null, which is a valid value
• the DA code getting both null raises the error

I agree, given the current limitations of the UI (subscription_id_secret_crn is hidden because of the gap with the secret and there is no way to add a cross variables validation like we have in the DA internal code) this leads to a bad user-experience

I think the best way to solve this, while waiting for the subscription_id_secret_crn to be usable through DA, would be to remove the null default value to the subscription_id, that will make the user required to explicitly set a value

[vbontempi]

@mtamboli last version of the DA makes the subscription_id without any default value so it is clear to the user that it must be filled (or explicitly set to null)

Let me know if we could go on with closing this issue