Azure TRE: Template Properties Not Removed On Upgrade?

Have you ever wondered why those lingering template properties just won't disappear after an upgrade in Azure TRE? You're not alone! This article dives into the curious case of deleted template properties sticking around even after an upgrade process. We'll explore the issue, the steps to reproduce it, and discuss potential solutions. So, let's get started and unravel this mystery!

The Persistent Property Problem

In the realm of Azure TRE (Trusted Research Environment), managing template properties is crucial for maintaining a clean and efficient workspace. Imagine deploying a workspace service with a specific property, say my_new_property. Now, picture this: you later decide to remove this property from the template, thinking an upgrade will tidy things up. But alas, the property stubbornly remains in your workspace or workspace service properties. This can lead to confusion, clutter, and potentially even conflicts down the line. This article describes the scenario where properties removed from a template are not automatically removed from the workspace or workspace service after an upgrade. This behavior raises questions about whether this is the intended functionality and if there are mechanisms to ensure properties are properly removed during upgrades.

This issue touches on the core principles of infrastructure as code (IaC), where the desired state is defined in templates. When a template is updated, the system should ideally reconcile the actual state with the desired state. In this case, the expectation is that removing a property from the template should lead to its removal from the deployed environment during an upgrade. The persistence of deleted properties can lead to inconsistencies between the template and the deployed environment, potentially causing unexpected behavior or configuration drift. Understanding the root cause of this behavior and identifying solutions or workarounds is crucial for maintaining consistency and predictability in Azure TRE deployments. Let’s delve deeper into the steps to reproduce this issue and explore the underlying mechanisms that might be contributing to it.

Steps to Reproduce the Issue

To really understand a problem, sometimes you have to get your hands dirty and recreate it yourself. So, let's walk through the steps to reproduce this persistent property issue in Azure TRE. By following these steps, you can see the behavior firsthand and better grasp the challenge we're addressing. Documenting the exact steps to reproduce the problem is essential for effective troubleshooting and communication within a development or operations team. Clear reproduction steps allow others to verify the issue, investigate its root cause, and develop appropriate solutions. This systematic approach ensures that the problem is well-understood and can be addressed efficiently. Here’s a breakdown of the process:

1. Deploy a workspace service: Start by deploying a workspace service that includes a property, for example, my_new_property. This sets the initial state where the property exists within your environment. This initial deployment establishes the baseline configuration that we will later modify and upgrade. It’s important to ensure that the property is correctly configured during this step, as any discrepancies here can affect the subsequent upgrade process. Verify that the property is visible and accessible within the workspace service after the deployment.
2. Remove the property from the template: Next, you'll need to modify the template by removing the my_new_property definition. This simulates a scenario where a property is no longer required or has been deprecated. This step is crucial because it defines the desired state after the upgrade. The system should ideally recognize this change and remove the corresponding property from the deployed environment. Ensure that the property is completely removed from the template definition to accurately reflect the intended change.
3. Upgrade the workspace service: Initiate an upgrade process for the workspace service. This is the key step where the system should ideally reconcile the template changes with the existing deployment. The upgrade process typically involves comparing the current state with the desired state defined in the updated template and applying the necessary changes. Monitoring the upgrade process for any errors or warnings can provide valuable insights into the issue.
4. Observe the lingering property: Finally, check the workspace service properties and observe that my_new_property is still present. This confirms the issue: the property was not removed during the upgrade, despite its absence in the updated template. This observation highlights the discrepancy between the desired state (template without the property) and the actual state (workspace service still containing the property). Documenting this observation clearly demonstrates the problem and provides a basis for further investigation.

The Code Snippet

To give you a clearer picture, let's take a look at the code snippet that demonstrates the property definition. This YAML snippet shows how my_new_property is initially defined in the template. Analyzing the code helps to understand the property's attributes, such as its type, title, description, default value, and whether it's updateable. This level of detail is crucial for troubleshooting and ensuring that the property is handled correctly during upgrades. The snippet provides a concrete example of the property being discussed, making it easier to visualize and understand the problem. By examining the code, we can identify any potential misconfigurations or inconsistencies that might contribute to the issue. Let's break down the snippet:

    "my_new_property": {
      "$id": "#/properties/my_new_property",
      "type": "string",
      "title": "my new property",
      "description": "my new property",
      "default": "test property",
      "updateable": true
    }

This YAML code defines a property named my_new_property. Let's break it down:

• $id: This is a unique identifier for the property within the JSON schema.
• type: Specifies the data type of the property, which is string in this case.
• title: A human-readable title for the property,