[BUG] Import of "sap.default" trust configuration for subaccount produces inconsistent result after apply

[markusbalsam]

Is there an existing issue for this?

• I have searched the existing issues

What version of the Terraform provider are you using?

1.2.0

What version of the Terraform CLI are you using?

1.8.3

What type of issue are you facing

bug report

Describe the bug

Importing and modifying the default subaccount trust configuration for an existing subaccount produces an inconsistent result after apply. The identity_provider field is mandatory fro the btp_subaccount_trust_configuration resource but for the default trust configuration which is referenced with "sap.default" an empty value is returned.

Expected Behavior

The result after apply is consistent.

Steps To Reproduce

1. Execute terraform init
2. Apply the following configuration (for an existing subaccount)

   terraform {
     required_providers {
       btp = {
         source  = "SAP/btp"
         version = "1.2.0"
       }
     }
   }
   
   provider "btp" {
     idp            = var.custom_idp
     globalaccount  = var.globalaccount
   }
   
   import {
     to = btp_subaccount_trust_configuration.default
     id = "${var.subaccount_id},sap.default"
   }
   
   resource "btp_subaccount_trust_configuration" "default" {
     subaccount_id = var.subaccount_id
     identity_provider = "sap.default"
     available_for_user_logon = false
   }

3. While the modification of the trust configuration works, the following error is displayed at the end of the apply

   Error: Provider produced inconsistent result after apply
   When applying changes to btp_subaccount_trust_configuration.default, provider
   "provider["registry.terraform.io/sap/btp"]" produced an unexpected
   new value: .identity_provider: was cty.StringVal("sap.default"), but now cty.StringVal("").
   This is a bug in the provider, which should be reported in the provider's own issue tracker.

User's Role Collections

• Global Account Administrator

Add screenshots to help explain your problem

No response

Additional context

No response

[CHERIANS]

@markusbalsam can you clarify if you are trying to modify trust configuration from sap.default idp to custom idp

[markusbalsam]

@CHERIANS No, for one of our use cases, we want to set the available_for_user_logon flag to false for the default trust configuration of the subaccount. Since the default trust is not created directly by TF (it's created under the hood when the subaccount is created) it must be imported before it can be modified.

Since the identity_provider field is required and must not be empty for the btp_subaccount_trust_configuration resource [1], I'm setting it to sap.default which is also the origin key when using the corresponding data source [2]. However, for the default trust config, identity_provider is actually empty and this leads to the inconsistent result.

I think it should probably be possible to set the identity_provider field to an empty string for the default provider.

[1] https://registry.terraform.io/providers/SAP/btp/latest/docs/resources/subaccount_trust_configuration
[2] https://registry.terraform.io/providers/SAP/btp/latest/docs/data-sources/subaccount_trust_configuration

[lechnerc77]

@markusbalsam the default tenant is a bit of a special piece and the non-availability of the URL is imho a inconsistency. However it should be possible to import the default provider by handing over an empty string as identity_provider for the resource.

The following setup should work (at least worked for me an canary):

terraform {
  required_providers {
    btp = {
      source  = "SAP/btp"
      version = "1.3.0"
    }
  }
}

provider "btp" {
  idp            = var.custom_idp
  globalaccount  = var.globalaccount
}

import {
  to = btp_subaccount_trust_configuration.default
  id = "${var.subaccount_id},sap.default"
}

resource "btp_subaccount_trust_configuration" "default" {
  subaccount_id            = var.subaccount_id
  identity_provider        = "" #empty value for default trust
  available_for_user_logon = false
}

Can you please check?

[markusbalsam]

Thanks for the hint, @lechnerc77! This works. I remembered from earlier versions of the provider that an empty string were not allowed. This should be good enough for our use case.

[lechnerc77]

Closing the issue