Azure
Dynamic Templates and Related Telemetry
We have a need to be able to have variations of the metadata template for different architecture or use case. When a user selects the option from a parameter in the solution, the correct template should be tracked for telemetry. @spboyer
More details here from the conversation @rajeshka @kristenwomack @AngelosP
TLDR; Dynamic Templates and Related Telemetry
"We have an accelerator that is published to GitHub and app templates and the here is how the metadata looks like in azure.yml."
We wanted to have two variations of this, for example
- agentic-applications-for-unified-data-foundation-usecase1
- agentic-applications-for-unified-data-foundation-usecase2
Which the user should be able to choose from a parameter either before azd up or during azd up run. It can be a usecase choice ( like Retail vs FSI) or a database choice in the architecture ( like using Azure SQL DB vs PostgresSQL). We have this ask for both in two templates.
We like to solve for it more generic so that we can build on top of this in long term.
Right now you have to create a templates for each permuation of the choices, and have the metadata tag reflect the relevant choice in order to reflect it in the telemetry.
In order to reduce the amount of templates with repeative components, we would want to support a model where a user can select one or more parts i.e. Database, AI Model similar to how they might select a Region or Subscription. BUT we would want to have the telemetry relflect these choices and know the success/fails and associated metrics we already track.
First let's remind ourselves how azd telemetry works today (for templates, not for standalone usage):
- An azd telemetry event will contain a property called TemplateId which is a look up key.
- The Kusto table Templates contains the mapping between the key and the name of the template.
If the above is changed / altered in any way, we will have to re-build the dashboard and how it retains data for the long term because it all relies on this mechanism working with just a simple join on TemplateId. It's doable, but pretty much a re-write of everything with some re-use on the UX. We would be looking at 4-5 weeks + testing after that.
One way to keep everything working exactly as it is now, is to have azd send a different TemplateId for every variation of the template, and something in the backend inserts new keys into the Template table that matches them. So whatever process is currently inserting new records in the Template table, it could insert all the possible variation IDs in there. Then everything continues to work as it does today.
A variation on that approach would be to encapsulate into a Kusto function the logic for generating the new template IDs that azd will be sending so that we can generate all the variation template IDs using that function. We would then union that with the real template IDs and everything would continue to work.
An alternative to the above suggestion would be to not call this dynamic templates which implies everything is a unique template generated dynamically.
Instead, this could be a new concept called template variant or template permutation or something like that which means it's all the same template ID, but there is some other property that sets them apart. This would mean we would not be able to treat these as templates, but they would be something else that would work as the child of a template.