The BTP CLI backend/server has the option to block "old" versions of the clients. This leads to an error message "please upgrade".

We need to include this scenario in our test setup of the BTP Terraform client

Is there an existing issue for this?

• I have searched the existing issues

What type of issue are you facing

bug report

Describe the bug

When trying to use the attribute origin for the datasource datasource_directory_users, the following error message is thrown:

` datasource_directory_users_test.go:35: Step 1/1 error: Error running pre-apply refresh: exit status 1

        Error: API Error Reading Resource Users (Directory)
        
          with data.btp_directory_users.mycustomidp,
          on terraform_plugin_test.tf line 8, in data "btp_directory_users" "mycustomidp":
           8:     data "btp_directory_users" "mycustomidp" {
        
        json: cannot unmarshal object into Go value of type []string'

I've un-commented the respective code in the file (marked with TODO).

Expected Behavior

The unit test should run through without the error message.

Steps To Reproduce

Runt go test ./... with the uncommented code in https://github.com/SAP/terraform-provider-btp/blob/main/internal/provider/datasource_directory_user_test.go

Add screenshots to help explain your problem

No response

Additional context

No response

Create an example for the setup of a simple scenario with the Terraform provider in a SAP BTP Trial account.

The resource for service instances is missing the parameter --data-center as input parameter for the CREATE operation.
This should be added to enable the service instance creation in satellite DCs

See: https://help.sap.com/docs/btp/btp-cli-command-reference/btp-create-services-instance

Check how Markdown is rendered in Hashicorp Registry. This can be achieved via the preview tool:

https://registry.terraform.io/tools/doc-preview?ajs_aid=8b501c0a-b895-4138-aa19-34d3be5a3880&product_intent=terraform&utm_source=tf_registry&utm_content=sidebar

Implementation of missing IMPORT operation for the resource subaccount_role_collection

What area do you want to see improved?

None

Is your feature request related to a problem? Please describe.

So far we don't support moving directories and subaccounts. In other words, terraform would try to recreate the subaccount or directory in case someone updates the parent_id.

resource "btp_subaccount" "a_subaccount" {
  parent_id = "" # can be the id of a directory or globalaccount
}

resource "btp_directory" "a_directory" {
  parent_id = "" #  can be the id of a directory or globalaccount
}

Describe the solution you would like

Terraform shall move the subaccount/directory to the given directory or globalaccount specified by the parent_Id.

Describe alternatives you have considered

No response

Additional context

No response

Implementation of missing/not fully implemented UPDATE operation for the resource subaccount_role_collection

What area do you want to see improved?

terraform provider

Is your feature request related to a problem? Please describe.

Some resources & datasources have a role_references attribute. In order to be in sync with the naming in the cockpit, this should be renamed to roles

Affected resources/datasources:

• btp_subaccount_role_collection
• btp_subaccount_role_collections
• btp_directory_role_collection
• btp_directory_role_collections
• btp_globalaccount_role_collection
• btp_globalaccount_role_collections

Describe the solution you would like

No response

Describe alternatives you have considered

No response

Additional context

No response

Implementation of missing IMPORT operation for the resource directory_role

Implementation of missing IMPORT operation for the resource subaccount_role

As of now the error messages in the integration test contain generic statements in the error cases. These error messages should be improved to have a more concise and easier to understand message that helps in finding the cause for the error

To allow a smooth user experience when using the Terraform provider especially for new customers that have no experience with Terraform per se we should:

• Evaluate if typical firewall setups in a company can cause issues when setting up the Terraform provider
• If issues occur we need to document and give advice how to deal with them as part of the official documentation (arrea: provider setup)

What area do you want to see improved?

other

Is your feature request related to a problem? Please describe.

To improve security, we should not handle authentication in our IAS instance but forward those to Azure AD.

Describe the solution you would like

• setup Enterprise Application in azure AD for IAS
• setup azure ad as corporate identity provider in azure
• forward incoming auth requests to the admin panel to azure AD

Describe alternatives you have considered

No response

Additional context

No response

Implementation of missing IMPORT operation for the resource subaccount_role_collection_assignment

The Terraform provider in general should provide the option to import existing resources. Our current implementation is not yet using this option. To close this gap we need to:

• Identify which resources can be imported from SAP BTP and do not yet implement the operation
• If a resource is importable, we must Implement the impirt operation in the corresponding resources
• If a resource is not importable, we must Implement the import operation to return a concise error message that this resource does not support the import operation.

In phase 1 we deliver the Terraform provider intentionally with a restricted scope. To give the users of the Terraform provider clarity what to expect from our first delivery, we must:

• Evaluate the gaps in attributes of resources (compared to BTP CLI)
• Document the gaps
• Create issues to address the gaps in upcoming releases after phase 1

Implementation of missing/not fully implemented UPDATE operation for the resource directory

What area do you want to see improved?

None

Is your feature request related to a problem? Please describe.

All the integration test resources we use for validating datasources are currently unmanaged (in other words they have been manually created). If we'd have them managed by terraform, we could share access easier.

GlobalAccount: terraform-integration-canary
Resources to be onboarded:

• Subaccount: integration-test-acc-static
• Directory: integration-test-dir-se-static
• Directory: integration-test-dir-static
• Directory User: [email protected]
• GlobalAccount User: [email protected]
• Subaccount User: [email protected]

Describe the solution you would like

Create a terraform workspace to manage integration test resources. State shall be stored in central backend like s3 or artifactory.

Describe alternatives you have considered

No response

Additional context

No response

What area do you want to see improved?

terraform provider

Is your feature request related to a problem? Please describe.

ADA team reached out, they want to orchestrate with a techuser which is managed by a custom IDP.

Describe the solution you would like

Add a new optional attribute idp to the provider configuration and pass it to the CLI at login.

provider  "btp" {
  username = ""
  password = ""
  idp      = "" # this is new
}

Describe alternatives you have considered

none

Additional context

No response

To internally onboard new team members to SAP BTP Terraform provider in a Developer role the following the following steps need to be taken:

• Windows or Mac computer available. There are no hardware limitations. Use dev containers
• CAM Profile BTP Terraform Developer assigned
• Set-up two days/meetings for Onboarding:
  - Day 1: Checking out "Get Started - SAP BTP" documentation, the "How to" process documentation for
  Review/Pull-Requests/Release, and starting to use the Terraform Provider.
  - Day 2: Starting Pair-Programming with tasks marked as "Beginner Level" in the github repository to
  gain hands on insights.

Prerequisite for the Development Onboarding Concept

• Create "Get Started - SAP BTP" similar to the AWS-Example.
• Create "Good first issue" label for Github and mark fitting tasks with that new label.
• Create/Update the "How to" documentation for Review/Pull-Requests/Release processes.
• Create documentation on "How to do changes", "how to release a new version". and "How to gain all required access rights" for SAP BTP Terraform provider.
• Create a template for the two onboarding meetings, including all relevant links to documentation and other required sources.

The recording of the integration tests via go-vcr show multiple logins especially at the end of the execution of tests for data sources. We need to investigate if this could be fixed or is simply due to the lifecycle management of the Terraform test framework.

Implementation of missing IMPORT operation for the resource globalaccount_role_collection

The provider documentation needs to be enhanced concerning the supported and non-supported authentication flows when using the provider.

This documentation needs to be added to the provider setup description that is part of the generated documentation.

After phase 1 the Timeouts in the Terraform provider resources are hard coded. These timeouts should be made configurable.
This also comprises a discussion around SLAs.

What area do you want to see improved?

usage tracking

Is your feature request related to a problem? Please describe.

To allow usage tracking, we should send a User-Agent header along with every API call.

Describe the solution you would like

The string should contain the version of the terraform CLI as well as the version of the terraform provider. If there's no version available (e.g. for a development build), dev shall be used as fallback.

"User-Agent": "Terraform/x.x.x terraform-provider-btp/y.y.y"

Describe alternatives you have considered

No response

Additional context

No response

Define the flow of deprecation of Terraform provider

• Evaluate options in Terraform framework
• Define communication of deprecation

When assigning role collections we currently do not support the variant of --to-attribute and the --attribute-value which comes into play when the user makes the assignment and has a custom IdP in place.

The action is supported by the BTP CLI (see https://help.sap.com/docs/btp/btp-cli-command-reference/btp-assign-security-role-collection) and the scenario is a valid scenario at customers. For details see https://help.sap.com/docs/btp/sap-business-technology-platform/map-role-collections-to-user-attributes

We need to close this gap and support this as a third variant when assigning role collections to users.

In order to make the Terraform provider more visible and to lower the entry barrier we should offer a dedicated Terraform tutorial on developers.sap.com.

The Terraform provider should be capable of a parallel execution of commands that create/update/delete resources in parallel.

As the Terraform provider is delegating this to the BTP CLI backend, this capability must be first implemented in the BTP CLI backend to use it in the provider

In order to provide a reasonable set of modules for phase 2, we must define reference scenarios and identify the required services and apps

To get insights around the usage and the usage patterns of the Terraform provider (which resources, which data sources etc.) we should implement a tracking/telemetry of the calls.
This establishes an additional feedback channel that helps us to improve the Terraform provider.

Note - This needs to be aligned with the BTP CLI as central entry point, as the Terraform provider is basically another client. The CLI would also beneft from the collected information

Executing the test in the devcontainer via go test ./... runs into an error

--- FAIL: TestResourceSubaccountEntitlement (0.03s)
    --- FAIL: TestResourceSubaccountEntitlement/happy_path_-_no_amount (0.03s)
        resource_subaccount_entitlement_test.go:15: failed to create new working directory: unable to symlink directory "/workspaces/terraform-provider-btp/internal/provider/fixtures" to "/tmp/plugintest3259771562/work2322337445/fixtures": unable to set "/tmp/plugintest3259771562/work2322337445/fixtures" permissions: chmod /tmp/plugintest3259771562/work2322337445/fixtures: operation not permitted
--- FAIL: TestResourceSubaccount (0.03s)
    --- FAIL: TestResourceSubaccount/happy_path (0.01s)
        resource_subaccount_test.go:19: failed to create new working directory: unable to symlink directory "/workspaces/terraform-provider-btp/internal/provider/fixtures" to "/tmp/plugintest1717460954/work3017526499/fixtures": unable to set "/tmp/plugintest1717460954/work3017526499/fixtures" permissions: chmod /tmp/plugintest1717460954/work3017526499/fixtures: operation not permitted
    --- FAIL: TestResourceSubaccount/error_path_-_parent_id_not_a_valid_UUID (0.00s)
        resource_subaccount_test.go:64: failed to create new working directory: unable to symlink directory "/workspaces/terraform-provider-btp/internal/provider/fixtures" to "/tmp/plugintest1564974435/work7732031/fixtures": unable to set "/tmp/plugintest1564974435/work7732031/fixtures" permissions: chmod /tmp/plugintest1564974435/work7732031/fixtures: operation not permitted
    --- FAIL: TestResourceSubaccount/error_path_-_name_must_not_contain_slashes (0.00s)
        resource_subaccount_test.go:76: failed to create new working directory: unable to symlink directory "/workspaces/terraform-provider-btp/internal/provider/fixtures" to "/tmp/plugintest3360258436/work504232938/fixtures": unable to set "/tmp/plugintest3360258436/work504232938/fixtures" permissions: chmod /tmp/plugintest3360258436/work504232938/fixtures: operation not permitted

Already checked:

• user vscode is in sudo group
• changing the temp dir via TF_ACC_TEMP_DIR leads to the same error
• manual linking and chmod works with user vscode

Implementation of missing/not fully implemented UPDATE operation for the resource directory_role_collection

What area do you want to see improved?

None

Is your feature request related to a problem? Please describe.

To ease the developer onboarding we should manage access with cloud access manager (CAM).

Describe the solution you would like

2 profiles shall be created

• BTP Terraform Developer:
  • GIthub Team: Terraform Provider BTP Team
  • Global Account Admin in BTP: terraformintcanary, terraformintprod
  • Subaccount Admin in all subaccounts
  • DL: BTP Terraform Developers (tbc)
  • shared mailbox [email protected]
• BTP Terraform Administrator:
  • GIthub Team: Terraform Provider BTP Admin
  • Global Account Admin in BTP: terraformintcanary, terraformintprod
  • Subaccount Admin in all subaccounts
  • DL: BTP Terraform Administrators (tbc)
  • Pass Vault Manage
  • IAS Admin
  • shared mailbox [email protected]

Describe alternatives you have considered

n/a

Additional context

No response

Currently the Terraform provider supports the following authentication mechanisms:

• SSO (local setup)
• User/Password (without 2FA)

What is missing and needed is a flow that supports a headless authentication.

Summary

Errors per input

Errors in README.md

• [400] https://api.reuse.software/info/github.com/SAP/terraform-provider-btp | Failed: Network error: Bad Request
• [400] https://api.reuse.software/badge/github.com/SAP/terraform-provider-btp | Failed: Network error: Bad Request
  Full Github Actions output

The Terraform provider in general should provide the option to update existing resources. Our current implementation is not yet using this option. In addition not every resource of SAP BTP allows an update. To close this gap we need to:

• Identify which resources can be updated in SAP BTP and do not yet implement the update
• If a resource is updateable, we must Implement the update operation in the corresponding resources
• If a resource is not updateable, we must Implement the update operation to return a concise error message that this resource does not support the update operation.

Implementation of missing IMPORT operation for the resource directory_role_collection

Implementation of missing IMPORT operation for the resource directory_role_collection_assignment

Define the quality criteria a service must meet in order to be implemented as a Terraform module.

Implementation of missing IMPORT operation for the resource globalaccount_role

• Setup integration tests for resources
• Document setup and enhancement in developer documentation

On the entities global account, directory and subaccount there is a mismatch between data source and resource when it comes to role references:

• The attribute is available in the data sources
• However, in the resource the role_references object is commented out without further information or is not available at all

This needs to be aligned/corrected

What area do you want to see improved?

Unit tests

Is your feature request related to a problem? Please describe.

No response

Describe the solution you would like

Currently the unit test for the resource entitlement doesn't cover the following tests:

• add entitlements with setting the amount
• check state import

This should be added. Corresponding TODOs are already addressed in the source code.

Describe alternatives you have considered

No response

Additional context

No response

What area do you want to see improved?

None

Is your feature request related to a problem? Please describe.

A btp_directory_entitlements resource is missing so far.

Describe the solution you would like

Similarly to the btp_subaccount_entitlements resource, we should have a resource to maintain entitlements on directory level.

Describe alternatives you have considered

No response

Additional context

No response

Implementation of missing IMPORT operation for the resource globalaccount_role_collection_assignment

Actual behavior

The providers do everything as expected, except the creation for the SAP HANA Cloud instance. The service instance does get created but an error message appears in the output. Terraform doesn't wait until the creation of the instance has finished. Because of the error message, the state isn't know as well - so the next ' terraform plan' won't recognize the existing instance.

Expected behavior

The instance of SAP HANA Cloud gets created, terraform wait's until the creation has finished and saves the state so the created instance is taken into account in further actions like ' terraform plan' or ' terraform destroy' .

The import of an existing setup i.e. setting up the state is quite cumbersome but reflects the status quo of the Terraform framework.
To make it more convenient we should explore the Terraformer Project by Google if and how we can integrate into it

Further details:
https://github.com/GoogleCloudPlatform/terraformer

Review of the documentation of the Terraform provider delivery in phase 1. The review comprises:

• The auto-generated documentation collected from the resources and data sources as well as from the examples folder. This documentation will then surface in the Terraform registry
• The documentation in the GitHub repository (README.md and developer documentaton)