Feature Requests

We love using the new building block readme to convey to our developers what service they will receive right when browsing the meshStack marketplace. I'd love to include similar instructions for our landing zones.

When you currently change the prefix for the tags in a platform config, the tags with the old prefix will remain in the cloud platform and are not cleaned up. This must be done manually at the moment. In order to smoothen this process, meshStack should automatically clean them up. Therefore it should keep track of the tags it created and then delete them if they are no longer present with the current configuration. It must still be guaranteed that any tags that were created outside of meshStack are not touched.

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.

As a user I want to see an overview of all my workspaces when I log in. I also want to see this overview when clicking on the icon in the top left corner. Background info: We conducted user tests and noticed all users expected an overview like that and were confused on how to change to another workspace. Some didn't even realize they had access to more than one workspace and did not understand what a workspace was.

As a platform team we'd like to monitor the health of deployed building blocks, especially whether there is any unwanted drift. Drift can occur due to side administration, immature terraform practices (e.g. missing lifecycle ignore_changes), or an unclear shared responsibility This ticket is to collect community feedback on common challenges you have with drift detection like choosing an automatic or manual reconciliation strategy for drift what kind of reporting on drift you'd like to see Related: https://meshcloud.canny.io/feature-requests/p/dry-run-on-terraform-building-blocks

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)

Currently, the API Key Id is a randomly generated UUID, which is not very human-readable. When used in external systems, one could consider deriving a prefix such as some-api-key from the name "Some API key" by lowercasing it and replacing all chars not matching [a-z] by - or similar. Still adding a random suffix to ensure uniqueness is a good idea probably! This would result in client_id values which can be easily correlated with meshStack API Keys, even in external systems. Also configuration errors (using the wrong client_id ) are easier to spot. Also logging is improved, see https://feedback.meshcloud.io/feature-requests/p/display-api-user-and-api-key-information-in-logs

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.

Observation: When creating / saving a building block revision, changes are no more visible traceable. Expectation / Feature Request: If a building block draft is no more required, it shall be discardable.