[FEATURE]Allow to manage BPT resources without a state. Delegate TF state houskeeping to BTP.

[ptesny]

What area do you want to see improved?

terraform provider

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

How one can destroy/adjust a BTP resource that was not created with the help the btp terraform provider ?

Imagine a complex BTP landscape with lots of BTP real estate to manage.
Why not having a discovery option to refresh the tfstate with the resources that were added/removed w/o TF ?
Why not maintaining the TF state seamlessly with BTP infrastructure....?

Describe the solution you would like

How one can destroy a BTP resource that was not created with the help the btp terraform provider ?
Imagine a complex BTP landscape and lots of BTP real estate to manage. Why not having a discovery option to refresh the tfstate with the resources that were added/removed w/o TF.

With complex BTP landscapes a TF state becomes a liability, an additional burden....
Even if TF tool has been designed as requiring having a state, why this would not be managed transparently on the BTP side ?

If a TF btp provider state were managed as intrinsic BTP GA assets then this all could be dealt with transparently.

Describe alternatives you have considered

No response

Additional context

No response

[github-actions]

Thanks for the feature request. We evaluate it and update the issue accordingly.

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[lechnerc77]

@ptesny Thanks for the request. I think the request needs to be split into several aspects:

First thing to stress is that Terraform is intended to provision and manage infrastructure in a declarative way. One important design paradigm is the state of the infrastructure. It is not intended to be a drop-in replacement for imperative logic like scripts or CLI commands.

Concerning the specific questions:

How to destroy a BTP resource that was not created by Terraform?

I would like to rephrase this a bit: how to manage resources that have not been provisioned by Terraform? Resources that have not been provisioned by Terraform are invisible to Terraform. You can make them visible and bring them under the management of Terraform by importing them via the so called import (see documentation). Even with the generative approach mentioned there, this is a quite cumbersome undertaking when it comes to larger landscapes. That's the reason why we are working on a functionality that eases this import for you. For details see #724 .

Handling of the Terraform state

As mentioned above the Terraform state is a central design paardigm for Terraform (and OpenTofu) that enables many features of Terraform (delta updates, drift detection as well as collaborative work on infrastructure via platform teams). Customers have a lot of established options to store the state as described in the documentation. This comprises the storage as a Kubernetes secret, so they could theoretically use Kyma as a state backend.
Having said that the management of cloud infrastructure should not be seen with a siloed via (SAP only) but usually customers have several cloud providers and in most cases state mangement is already established for AWS, Azure or GCP and SAP BTP teams just need to be onboarded here.
While I agree that the state menagement is something a customer needs to think about, it is a necessary part of their cloud journey to do so.

BTP specific state backend

We are not planning to implement a BTP specific Terraform state backend.