Feature Requests

As a platform team operating out of the service management area I would also like to reach out to other workspaces via communication. This way I can announce new versions, deprecations, maintenance windows and so on without admin access.

As an engineer I want to manage my Building Block Definition via API (or ideally even via Terraform) so I can manage the Terraform code and the definition information as one asset, and I won't have to go into the UI anymore to make changes.

I want to use tag values (like the environment the tenant is in) in my building block definitions. Depending on the environment, my building block can be multi-region for prod (higher availability) or single-region for dev (cheaper) in the case of storage.

I have a Terraform resource in SAP BTP ( https://registry.terraform.io/providers/SAP/btp/latest/docs/resources/subaccount_entitlement ) that has an optional amount field. I'd like to ask this to my users but also let them skip it if they want to.

As a service owner I want to have a nice UX and enforce a manageable overview for my customers. At the moment the Building Block instance name is: at the very bottom of the form -> should be the first field cannot be used as an actual input -> therefore I require my users to input a name for the service instance twice (once as a input and once as a instance name for meshStack only) I cannot update the description of the Building Block Instance name Please expose the Instance Name as potential input for the actual building block provisioning

As a Service Team / Platform Team I want to be able to revoke a service in case of issues or security incidents. I require a easy mechanism which prevents the usage of a published building block for a certain time. It should also be correctly flagged as "revoked" or "blocked" in the Building Block and Service Overview.

What I want to do: The azurerm terraform provider allows to manage firewall_application_rule_collection (see https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/firewall_application_rule_collection ) with rules inlined. It does not allow to manage rules outside of this single resource definition. This means managing firewall rules is not doable effectively with meshStack building blocks without the support for complex inputs. In this example, the input needs to be a list of firewall rules.

As a Platform Operator, I would like to have the option for a deletion approval when a user deletes a building block. This would be useful in cases where there are manual steps involved after deleting the building block. Similar to the process of platform operator inputs.

Creating a new version of a Building Block and testing it with test objects and BB instances are easy. Nevertheless when upgrading the production instance I as a Platform Operator would like to test the migration to another version prior to a big bang roll out. If the migration works then there are no issues everything is fine. But if there are issues during the migration and I need to stop the building block run e.g. as the logs showed deletion of resources in terraform I am left with no logs afterwards. Just the message: "The step started but didn't complete because we haven't received no further updates from the external source." Which do not really help for debugging. I either need a way to just execute tf in a more managed way such as step by step tf plan and then apply. Or let the run stop keep the logs for proper insights.

As more users and teams work with meshStack more frequently, it becomes difficult to track who and when e.g. a platform has been created and by who owns it. Therefore, such typical meta information should be displayed in the platform view: Created by <username> Created at <timestamp> Last modified by <username> Last modified at <timestamp> It would help to understand better who contributed to a platform landscape and which one to ask about certain entries. Also, if some entries are maybe very old or quite recent is important context information. Collaborative usage would be less anonymous. Same goes for workspaces, projects, landing zones, policy rules – you name it. This really contributes to a better transparency of the multi-platform landscape in distributed collaborative platform organizations.