Feature Requests

meshStack should be able to run BBDs with (a) pre-defined test configuration(s) to ensure they work flawlessly for the users of a platform. Scenario: Day 1: I create the terraform for a BBD to provide a namespace from a K8s cluster to developers. Day 2: I am satisfied and release the BBD into the general marketplace for developers to use (so they get namespaces). Day 19: Some credentials expire and my BBD cannot anymore provide namespaces. Day 27: A developer sends a support request because he needed a namespace urgently but it didn't work. Now I need to drop everything and jump into the nitty-gritty of a service I built a while ago. Improvement: If I could setup automated testing for my namespace BBD (e.g. daily in this case), I would have received a notification on Day 20 before any user impact. I would have had 7 more days to pro-actively fix the service. The user/developer experience on Day 27 would have been flawless. Therefore, regular automated testing of BBD with a test configuration would improve the quality and robustness of my platform – especially over time (Day 2, 22, or 222...).

meshStack should support building blocks outputting a health status url and display that status along with the BB in the project dashboard (and elsewhere). Details: I provide a service for my application via building block, e.g. a k8s cluster. I want to see it's health status immediately in meshStack to understand if my application stack is healthy. Therefore, meshStack should support a specific BB output (e.g. ms_monitor_url =" https://some.service.url/health ) which it regularly checks to get the health status of the service. Benefits for the user: Currently, I see green in meshStack if the BB run was successful (which is the first step). However, more important to me as a developer is if my service is healthy (second step). Therefore, I need to get this signal into my BB instance as suggested above. The BBD creator – who knows the service by heart – is the best person to define how to ping the state of the service afterwards. Therefore there should be a canonical way to surface that information to the service users. As a developer, if my application fails, I see immediately in meshStack if one of the depending services is responsible. meshStack can track the service health over time and provide an SLA report. This fosters best practice and resiliency in service provisioning. When applied consequently to a company's BB landscape, an aggregated view of service health across the company is easy to derive and useful for the insights for the overall platform health.

The aim is to enhance building block billing flexibility by allowing: Charging annual fees (for example, provisioning a Google Gemini AI license based on a yearly commitment). Defining diverse payment schedules (upfront payment or monthly instalments)

As a developer adding and testing a new building block version is cumbersome as an existing building block can not be "upgraded" into the draft version. Currently, especially if its a "apply once" building block you need to create a new tenant/project to apply it or remove the old one and re-apply the new building block as draft. This might not always be easily possible. It also only allows testing the "upgrade" procedure once the building block is released and an admin actually performs the upgrade into the new version. If you could already "upgrade" into a draft version this transition could be tested beforehand.

It is already possible to upgrade an individual building block without triggering a new run. I would like to have the same feature available as well when upgrading building blocks in bulk. This is useful in cases where the change does not affect the configuration of the resources deployed by the building block. One example could be changing the private key for accessing the git repo where the terraform code is stored.

Use Case: As a Platform Engineer, I want to define the mapping between Terraform variables and meshStack Building Block inputs (including source types like User Provided, Tenant ID etc.) via a YAML file in the Git repository of the terraform module. This means, I just put e.g. a meshStack.yaml file next to my .tf files to pre-configure the meshStack BB definition. Value: This would enable a "Configuration as Code" approach for BB definitions, making it easier to version-control the interface alongside the implementation and reducing manual configuration steps in the meshStack Admin UI. Import of terraform repos into meshStack BB definitions could skip the mapping step in the UI and read it from the mapping file instead. Value Created: * GitOps Workflow: Enables "Configuration as Code" for Building Block definitions. * Consistency: Ensures that every time a module is imported or updated, the input mapping is already predefined by the module author. * Efficiency: Reduces manual configuration errors in the meshStack Admin Area. * "meshStack-enabled": Terraform modules could very easily be extended in out-of-the-box BB definition (e.g. in the meshStack hub) to be consumed in one go

Building Blocks (BB) form an increasingly larger part of the meshStack experience. As users work with BBs, they might experience issues or have questions about the usage. Therefore, there should be a quick and easy common channel to get in touch with the creators/owners of a building block. E.g. questions like "this parameter is not clear to me, what do you mean?" or "when using this BB, I experienced X..." which are important and helpful to improve BBs as a product. Therefore, there should be a native mechanism to facilitate this exchange easily and from the context of BB consumption in meshPanel.

It's tricky to work with the "Git Reference" field in BB definition because it might lead to "dead ends" until you update the Git Reference. You extend a BB repo in a feature branch (e.g. feat/extend-building-block) You create a BB definition with a "Git Reference" to that feature branch. After testing everything etc. you merge the feature branch into the main branch However, the BB definition will continue to execute the old branch (as designed). No matter what you change in the main branch (after the merge) it will not be picked up by the BB definition until you remember to update the Git Reference. This way, you can set a trap for yourself. When you delete the old feature branch, the BB definition at least fails and you will notice (though maybe with user exposure). Can meshStack support the BB designer somehow to be more conscious about which branch they select? I can imagine that his happens quite often as best practice is to work in feature branches. Also for demo settings it might be a trap to fall into (when you set something up quickly to adjust it later). TL;DR: BB definitions stuck to a git branch work as designed, but might lead to a trap when merging branches as you need to remember to update the "Git Reference" of all affected BB definitions accordingly.

Provisioning certain resources may be constrained by factors such as the number of available licenses, slots, or a global quota. To address this, a Building Block should include an option to define a quota that limits the number of times the block can be provisioned. This feature would ensure compliance with resource restrictions and prevent over-provisioning, while providing administrators with greater control and transparency.

As the purchaser of a building block, I would like to change the display name of the building block retrospectively so that it is immediately clear what the building block belongs to, especially in the case of multiple provisions or if the building block parameters change during lifetime. It should be noted that a default name is generated when the first building block is provisioned.