Feature spec: compute extensibility user experience #96

willtsai · 2025-06-04T05:27:34Z

Add feature spec for compute extensibility to define requirements and user experience

Signed-off-by: Will Tsai <[email protected]>

… 2.5 Pro assisted in VSCode) Signed-off-by: Will Tsai <[email protected]>

Signed-off-by: Will Tsai <[email protected]>

architecture/2025-06-compute-extensibility-feature-spec.md

jonvsm · 2025-06-10T18:12:52Z

architecture/2025-06-compute-extensibility-feature-spec.md

+
+### Non-goals (out of scope)
+<!-- What are we explicitly not trying to accomplish? -->
+- Running the Radius control plane on a non-Kubernetes platform.


This is out of scope for now or forever?

For now, it's do-able.

out of scope for now, added a link to the roadmap item here.

architecture/2025-06-compute-extensibility-feature-spec.md

sylvainsf · 2025-06-10T18:22:48Z

architecture/2025-06-compute-extensibility-feature-spec.md

+              }
+            }
+            // This container requests confidential compute
+            extensions: [


Do we support extensions on UDTs? Wouldn't these be additional optional properties consumed as recipe inputs instead?

sylvainsf · 2025-06-10T18:24:08Z

architecture/2025-06-compute-extensibility-feature-spec.md

+1.  **Configure Environment-Specific Recipe Parameters (Optional)**:
+    *   If recipes have parameters that need to be set globally for an environment, configure them using `rad recipe update` or during registration.
+
+#### Packaging and Registering a "Recipe Pack" for an Environment:


This is a fantastic implementation, I like that version is already included.

architecture/2025-06-compute-extensibility-feature-spec.md

Signed-off-by: Will Tsai <[email protected]>

ytimocin · 2025-06-10T18:11:06Z

architecture/2025-06-compute-extensibility-feature-spec.md

+
+### Non-goals (out of scope)
+<!-- What are we explicitly not trying to accomplish? -->
+- Running the Radius control plane on a non-Kubernetes platform.


Does this mean that with extensibility and core types as UDTs we shouldn't expect to be able to host UCP in a different platform?

ytimocin · 2025-06-10T18:14:27Z

architecture/2025-06-compute-extensibility-feature-spec.md

+
+### Positive user outcome
+<!-- What is the positive outcome for the user if we deliver this, i.e. what is the value proposition for the user? Remember, this is user-centric. -->
+As a platform engineer, I can confidently adopt Radius across my organization, knowing I can extend its capabilities to support any compute platform, secret store, or gateway my teams require, without waiting for built-in support or modifying Radius core. I can register, customize, and share recipes that define how Radius provisions these resources, ensuring consistency with our application definitions while maintaining flexibility in our infrastructure choices and adhering to organizational standards. This empowers my development teams to leverage Radius benefits regardless of the underlying infrastructure.


We are talking about containers, secret stores, and gateways a lot. Are these the main resource types that we are focusing on? Why are we not talking about other core resource types?

Good point, we should include volumes, Will T said extenders are out of scope which I agree as I believe they'd just be replaced by new types/recipes.

yup, added the inclustion of volume resources too now.

architecture/2025-06-compute-extensibility-feature-spec.md

nithyatsu · 2025-06-10T18:28:43Z

architecture/2025-06-compute-extensibility-feature-spec.md

+                    }
+                }
+        -       providers: {
+        -           // provider configurations no longer hard-coded here


Are we saying we will add info such as subscription and respurce grpup to the bicep recipe itself?

We already have a requirement from some users that we will need to move those to the environment

On second thought, this shouldn't be encoded in the recipe. We can keep providers as is for now.

Signed-off-by: Will Tsai <[email protected]>

lakshmimsft · 2025-06-10T18:31:07Z

architecture/2025-06-compute-extensibility-feature-spec.md

+    *   Once the Recipe Pack is registered, the environment is configured with all the specified recipes for the core UDTs.
+    *   When applications are deployed to this environment, Radius automatically uses the corresponding recipes from the pack to provision `Applications.Core/containers@2025-05-01-preview`, `Applications.Core/gateways@2025-05-01-preview`, and `Applications.Core/secretStores@2025-05-01-preview` resources.
+1.  **Manage and Update Recipe Packs**:
+    *   Platform engineers can update the Recipe Pack manifest (e.g., point to new recipe versions, change default parameters) and re-register it. The CLI could offer options to overwrite existing registrations or manage versions of the pack within the environment.


We need to design/review/implement recipe versioning. Will that be a prerequisite before we work on recipe packs?

I think Recipes versioning will be a separate feature that we don't need to implement as a part of Recipe Packs. However, we should include versioning in scope for the implementation of Recipe Packs from the get go, even if the underlying Recipes packaged within the Pack don't support versioning yet.

Clarified this in the goals/non-goals

sk593 · 2025-06-10T18:31:11Z

architecture/2025-06-compute-extensibility-feature-spec.md

+-               }
+            ]
+            // This container requests confidential compute
+           runtimes: {


Should the confidential compute property be part of the ACI-specific recipe? Or is this an interim case while we look at Radius supporting conf containers?

Signed-off-by: Will Tsai <[email protected]>

architecture/2025-06-compute-extensibility-feature-spec.md

iyyappam · 2025-06-10T18:37:33Z

architecture/2025-06-compute-extensibility-feature-spec.md

+2.  **Discover/Create Recipes**:
+    *   Find community-provided recipes for desired platforms (e.g., ACI, AWS Fargate) from an OCI registry or Radius documentation.
+    *   Or, create custom Bicep/Terraform recipes for `Applications.Core/containers@2025-05-01-preview`, `Applications.Core/gateways@2025-05-01-preview`, and `Applications.Core/secretStores@2025-05-01-preview` to target a specific platform or customize existing behavior.
+3.  **Register Recipes for Core Types**:


Is there a way to constraint certain app files to be used against only certain recipe? Example: App with confidential container property set to true, should be allowed only on confidential recipe.

Not currently, we discussed this as well as the ability to only allow certain apps to use certain options/properties in a recipe.

architecture/2025-06-compute-extensibility-feature-spec.md

zachcasper · 2025-06-10T18:11:51Z

architecture/2025-06-compute-extensibility-feature-spec.md

+
+## Topic Summary
+<!-- A paragraph or two to summarize the topic area. Just define it in summary form so we all know what it is. -->
+Radius will be enhanced to support multiple compute platforms, secret stores, and gateway resources through a recipe-based extensibility model. This approach decouples Radius's core logic from platform-specific provisioning code. Core resource types (`containers`, `gateways`, and `secretStores`) will be implemented as User-Defined Types (UDTs) and will allow platform engineers to register Bicep or Terraform recipes for them. Radius will provide default recipes for Kubernetes and Azure Container Instances (ACI), but platform engineers can use, modify, or replace these to customize how Radius provisions resources to different environments, or to add support for entirely new platforms without requiring changes to Radius core.


Shouldn't core resource types include volumes?

yes, it should. i'll add it.

architecture/2025-06-compute-extensibility-feature-spec.md

zachcasper · 2025-06-10T18:25:13Z

architecture/2025-06-compute-extensibility-feature-spec.md

+                        }
+                    }
+                }
+        -       providers: {


The provider stores the AWS and Azure details that get past to the recipe context right? https://docs.radapp.io/reference/context-schema/#environment So we'll need the AWS account and region, and Azure subscription and resource group in the environment somewhere.

Yes, good point, this shouldn't be encoded in the recipe. We can keep providers in the environment as is for now.

zachcasper · 2025-06-10T18:28:29Z

architecture/2025-06-compute-extensibility-feature-spec.md

+        *   The platform engineer configures `std-env` with recipes for `Applications.Core/containers@2025-05-01-preview` that deploy to standard compute (e.g., regular ACI or Kubernetes pods). These recipes might ignore or log a warning for confidential container requests if they don't support them.
+        *   Example recipe registration (conceptual):
+            ```bash
+            rad recipe register std-container-recipe --environment std-env \


I strongly believe we should not have any recipe names. This leaks the implementation abstraction into the developers' world. If the developer needs a different recipe, that should be a different resource type.

zachcasper · 2025-06-10T18:29:57Z

architecture/2025-06-compute-extensibility-feature-spec.md

+            // This container requests confidential compute
+            extensions: [
+              {
+                kind: 'confidentialCompute' // Example extension kind


If there are additional properties needed to be set by the developer, that should be a different resource type. I do not think extension is the right thing here, nor do I understand how one would create an extension.

architecture/2025-06-compute-extensibility-feature-spec.md

zachcasper · 2025-06-10T18:35:20Z

architecture/2025-06-compute-extensibility-feature-spec.md

+1.  **Configure Environment-Specific Recipe Parameters (Optional)**:
+    *   If recipes have parameters that need to be set globally for an environment, configure them using `rad recipe update` or during registration.
+
+#### Packaging and Registering a "Recipe Pack" for an Environment:


A "resource pack" would be more useful. It would be a manifest of resource types and associated recipes. I would specify the resource pack during rad init.

Could we define a set of resources and a set of recipes within a single environment resource, and deploy that? That could replace the need for recipe or resource packs.

@brooke-hamilton see answer in a previous comment: https://github.com/radius-project/design-notes/pull/96/files#r2141274374

@zachcasper - I'm thinking Recipes and Resources would be bundled into the same pack - it seems pointless to have them separately as one wouldn't be used without the other. Thoughts?

zachcasper · 2025-06-10T18:38:02Z

architecture/2025-06-compute-extensibility-feature-spec.md

+        ```
+1.  **Package the Recipe Pack (Optional but Recommended)**:
+    *   The manifest file and any local recipe files (if not using OCI URIs exclusively) could be bundled into an OCI artifact or a simple archive (e.g., .zip, .tar.gz) for easier distribution and versioning.
+1.  **Register the Recipe Pack to an Environment**:


Register isn't the right verb here. We're configuring the environment. rad environment create --recipe-pack <location> seems more accurate.

Good point, I've changed it to leverage the rad environment update my-env --recipe-pack ... command instead.

architecture/2025-06-compute-extensibility-feature-spec.md

sylvainsf · 2025-06-19T18:12:44Z

architecture/2025-06-compute-extensibility-feature-spec.md

+This option is where the advanced capabilities are not exposed in the standard container properties provided by Radius out of the box, but rather require platform engineers to modify the container resource definitions to enable these capabilities. This could be done by creating a custom Radius Resource Type (RRT) that extends the standard container RRT to include platform-specific properties or configurations.
+
+**Pros:**
+- Keeps the standard container resource type clean and focused on core properties, avoiding clutter from platform-specific configurations or misuse of advanced container configurations by developers.


How is this cleaner than a runtimes property not used by developers in 99% of cases?

I think the common container properties that make up 90% of the developer use cases need to be elevated into the top-level container properties in the core container resource type. Properties such as restartPolicy that aren't part of the top-level container properties today should added into the core container RRT as this is a configuration common across platforms. This would be the mitigation against the strong need for punch-throughs today.

architecture/2025-06-compute-extensibility-feature-spec.md

Signed-off-by: Will Tsai <[email protected]>

willtsai · 2025-07-02T18:15:00Z

architecture/2025-06-compute-extensibility-feature-spec.md

+-   // These properties are removed from the volume resource
+-   //  and are instead defined in the recipe
+-   kind: 'azure.com.keyvault'
+-   resource: keyvault.id
+-   secrets: {
+-     mysecret: {
+-       name: 'mysecret'
+-     }
+-   }


Note that this would replace the Azure KeyVault specific implementation of volume that we have today: https://docs.radapp.io/reference/resource-schema/core-schema/volumes/azure-keyvault/

is there an implied restriction for an environment to use one type of volume to be attached to containers since a default recipe will be associated with Applications.Core/volumes@2025-05-01-preview . (the earlier implementation had a kind field ).

Yes, the implementation of volumes will be done on the Recipe going forward

Signed-off-by: Will Tsai <[email protected]>

architecture/2025-06-compute-extensibility-feature-spec.md

Signed-off-by: Will Tsai <[email protected]>

Co-authored-by: Zach Casper <[email protected]> Signed-off-by: Will <[email protected]>

Reshrahim · 2025-07-02T18:41:36Z

architecture/2025-06-compute-extensibility-feature-spec.md

+    *   Familiarize yourself with the Radius project's general contribution guidelines (often found in `CONTRIBUTING.md`).
+    *   Check for any specific guidelines related to recipes or extensibility.
+2.  **Develop Your Recipe(s)**:
+    *   Create high-quality, well-tested Bicep or Terraform recipes for one or more core types (`Applications.Core/containers@2025-05-01-preview`, `Applications.Core/gateways@2025-05-01-preview`, `Applications.Core/secretStores@2025-05-01-preview`).


For the new community contributed types, what namespace should we have them follow? Our tutorials and samples reference Radius.Resources as the namespace but the core types have Applications.Core . I think it should be consistent across the core types and the others.

good question. I'll bring this up for discussion on the naming convention for RRTs going forward.

zachcasper

High level thoughts:

What are the proposed schema changes for the core types? I would expect the new schema to be defined in this doc.
I'm very confused and concerned about allowAdvancedContainerCapabilities but there are not a lot of details here. I'm not supportive of an unstructured map. We should find the platform-specific properties that we want to expose for ACI and Kubernetes and put them in the extensions block.
What does a vanilla environment look like? Does it have all of the recipes enumerated?
Where are the recipes stored? How does that work in an air-gapped environment.
We need a user story for modifying the schema for a core type. I can use rad resource-type create but I will need the original resource definition. Today there is no way to get the current definition.

zachcasper · 2025-06-27T14:42:48Z

architecture/2025-06-compute-extensibility-feature-spec.md

+<!-- Step 1
+Step 2
+… -->
+#### Setting up and deploying an application to a Radius environment using existing Recipes for core types:


I do not understand what this user story is really saying. There are two personas here in one sentence, the platform engineer creating the environment and the developer deploying an application. There should only be one persona to keep the doc clear.

I think you are saying As a platform engineer, I need to create a new Radius environment that when applications are deployed to it, the containers are deployed to Azure Container Instances. But I'm not sure.

yes, that is right, i'll edit to make this more clear

zachcasper · 2025-06-27T14:45:34Z

architecture/2025-06-compute-extensibility-feature-spec.md

+#### Setting up and deploying an application to a Radius environment using existing Recipes for core types:
+
+1.  **Discover existing Recipes**:
+    *   Find community-provided recipes for desired platforms (e.g., ACI, AWS Fargate) from an OCI registry or Terraform module repo, or something like [Artifact Hub](https://artifacthub.io/).


Why would the platform engineer need to find community-provided recipes? Radius should ship maintained and tested recipes for various container platforms.

I think there's two paths:

Platform engineer uses the "stock" maintained and tested recipe packs that come with Radius for various container platforms.

Platform engineer wants to mix-n-match the "stock" recipes with some others, perhaps community-contributed ones they find or (more likely) bring their own custom recipes. They can either build their own recipe packs using this mixed bag of recipes, or they can register each individual recipe into their environment.

I'll make this distinction more clear with illustrated examples of both.

zachcasper · 2025-06-27T14:49:55Z

architecture/2025-06-compute-extensibility-feature-spec.md

+        resource env 'Applications.Core/environments@2025-05-01-preview' = {
+            name: 'my-aci-env'
+            properties: {
+        -       compute: {


At a minimum, you are removing the Kubernetes namespace. You're also removing the Identity property, but I do not understand what the property does.

Where are you re-defining the Kubernetes namespace for this environment?

good catch, the k8s namespace will move to the providers property in the Environment resource

zachcasper · 2025-06-27T14:50:16Z

architecture/2025-06-compute-extensibility-feature-spec.md

+                    'Applications.Core/containers': {
+                        default: {
+                        templateKind: 'bicep'
+                        plainHttp: true


What does plainHttp mean? If this is an existing property, it is not documented and is confusing in this context.

this is a typo, i'll remove it

architecture/2025-06-compute-extensibility-feature-spec.md

zachcasper · 2025-07-02T18:24:49Z

architecture/2025-06-compute-extensibility-feature-spec.md

+        -       }
+            ]
+            // This container requests confidential compute
+        +   runtimes: { // Consider renaming this to `options` or `platform`, etc. for clarity


I like extensions. It's a platform extension. Runtime doesn't make sense to me.

I don't like extensions because there is already an extensions property that will hold the Dapr configs. I propose we go with platformOptions

zachcasper · 2025-07-02T18:26:53Z

architecture/2025-06-compute-extensibility-feature-spec.md

+        *   `rad deploy ./app.bicep --environment std-env`
+        *   Radius uses the `std-container-recipe` registered in `std-env`.
+        *   The `frontend` container is deployed as a standard container.
+        *   The `backend` container, despite its platform-specific confidential container property, is deployed as a standard container because the `std-container-recipe` in `std-env` does not support confidential compute (or is configured to treat it as standard).


I don't see any platform-specific properties on the backend container.

will add concrete examples

zachcasper · 2025-07-02T18:29:30Z

architecture/2025-06-compute-extensibility-feature-spec.md

+    name: 'my-aci-env'
+    properties: {
+        recipes: {
+           'Applications.Core/volumes': {


I'm confused as to what a default, vanilla environment definition looks like. Does it have recipes for every core resource type? If it doesn't, what recipes does an environment point to by default? If it's jutst GitHub, how would this work in an air-gapped environment?

the default environments that ship with Radius will have platform specific recipe packs per environment, I will add an example to show that.

zachcasper · 2025-07-02T18:32:34Z

architecture/2025-06-compute-extensibility-feature-spec.md

+    application: app.id
+-   // These properties are removed from the volume resource
+-   //  and are instead defined in the recipe
+-   kind: 'azure.com.keyvault'


Do we only support Azure Key Vault volume types? If that's the case, shouldn't this just be a secret? I don't think you can have a generic volume resource type and push the kind into the recipe if it's going to be a Key Vault key.

this is supported today, where you can mount a secretstore (Azure Key Vault) to a container as a volume: https://docs.radapp.io/reference/resource-schema/core-schema/volumes/azure-keyvault/

zachcasper · 2025-07-02T18:35:57Z

architecture/2025-06-compute-extensibility-feature-spec.md

+#### Initialize Radius for specific platforms with default recipes:
+
+1.  **Kubernetes**:
+* `rad init kubernetes` initializes a Radius environment for Kubernetes with default recipes for core types.


We retain the interactive questions for rad init rather than introduce sub-commands. Keep the sub-commands on rad install.

Co-authored-by: Zach Casper <[email protected]> Signed-off-by: Will <[email protected]>

Feature spec: compute extensibility user experience

33152c1

Signed-off-by: Will Tsai <[email protected]>

willtsai requested review from a team as code owners June 4, 2025 05:27

willtsai added 3 commits June 3, 2025 22:28

Gemini 2.5 Pro authored this initial commit

96399df

Signed-off-by: Will Tsai <[email protected]>

first edits

be2782a

Signed-off-by: Will Tsai <[email protected]>

update detailed user steps

502222b

Signed-off-by: Will Tsai <[email protected]>

willtsai marked this pull request as draft June 6, 2025 18:17

willtsai added 2 commits June 6, 2025 17:01

add details for user experience steps and feature investments (Gemini…

378ada8

… 2.5 Pro assisted in VSCode) Signed-off-by: Will Tsai <[email protected]>

add terms, conf containers, spelling

8b611d2

Signed-off-by: Will Tsai <[email protected]>

willtsai marked this pull request as ready for review June 10, 2025 18:09

sylvainsf reviewed Jun 10, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

jonvsm reviewed Jun 10, 2025

View reviewed changes

sylvainsf reviewed Jun 10, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Outdated Show resolved Hide resolved

sylvainsf reviewed Jun 10, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

sylvainsf reviewed Jun 10, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

sylvainsf reviewed Jun 10, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

edit examples, spelling

a58cc1a

Signed-off-by: Will Tsai <[email protected]>

ytimocin reviewed Jun 10, 2025

View reviewed changes

nithyatsu reviewed Jun 10, 2025

View reviewed changes

spelling

c623e46

Signed-off-by: Will Tsai <[email protected]>

lakshmimsft reviewed Jun 10, 2025

View reviewed changes

sk593 reviewed Jun 10, 2025

View reviewed changes

formatting

d658c0b

Signed-off-by: Will Tsai <[email protected]>

nicolejms reviewed Jun 10, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

iyyappam reviewed Jun 10, 2025

View reviewed changes

nicolejms reviewed Jun 10, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

zachcasper reviewed Jun 10, 2025

View reviewed changes

lakshmimsft reviewed Jun 10, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

sylvainsf reviewed Jun 19, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

sylvainsf reviewed Jun 19, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

willdavsmith reviewed Jun 19, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

willtsai added 17 commits June 20, 2025 15:58

add types-contrib repo proposal

24a1284

Signed-off-by: Will Tsai <[email protected]>

add types-contrib repo proposal

b2f6fe3

Signed-off-by: Will Tsai <[email protected]>

add types-contrib repo proposal

cb200d1

Signed-off-by: Will Tsai <[email protected]>

add types-contrib repo proposal

ea11450

Signed-off-by: Will Tsai <[email protected]>

picture size

5c0e088

Signed-off-by: Will Tsai <[email protected]>

elaborate on options

a61830e

Signed-off-by: Will Tsai <[email protected]>

elaborate on options

179d9a4

Signed-off-by: Will Tsai <[email protected]>

elaborate on options

43f84ea

Signed-off-by: Will Tsai <[email protected]>

update repo pic

fa8e180

Signed-off-by: Will Tsai <[email protected]>

elaborate on options

6e0830d

Signed-off-by: Will Tsai <[email protected]>

add platform capabilities option 3

dd042d9

Signed-off-by: Will Tsai <[email protected]>

decide on option 3

686044b

Signed-off-by: Will Tsai <[email protected]>

clean up language and update repo structure

fadb5ab

Signed-off-by: Will Tsai <[email protected]>

clean up language and update repo structure

1432405

Signed-off-by: Will Tsai <[email protected]>

update repo pic

7983a1f

Signed-off-by: Will Tsai <[email protected]>

add volumes and init scenarios

bac383e

Signed-off-by: Will Tsai <[email protected]>

add volumes and init scenarios

37cc260

Signed-off-by: Will Tsai <[email protected]>

willtsai commented Jul 2, 2025

View reviewed changes

add note for volumes

8b12b3a

Signed-off-by: Will Tsai <[email protected]>

lakshmimsft reviewed Jul 2, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

brooke-hamilton reviewed Jul 2, 2025

View reviewed changes

architecture/2025-06-compute-extensibility-feature-spec.md Show resolved Hide resolved

willtsai and others added 2 commits July 2, 2025 11:29

sylvainsf suggestion

f528def

Signed-off-by: Will Tsai <[email protected]>

Apply suggestions from code review

853d000

Co-authored-by: Zach Casper <[email protected]> Signed-off-by: Will <[email protected]>

Reshrahim reviewed Jul 2, 2025

View reviewed changes

zachcasper reviewed Jul 2, 2025

View reviewed changes

Apply suggestions from code review

14c3695

Co-authored-by: Zach Casper <[email protected]> Signed-off-by: Will <[email protected]>

Feature spec: compute extensibility user experience #96

Are you sure you want to change the base?

Feature spec: compute extensibility user experience #96

Uh oh!

Conversation

willtsai commented Jun 4, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

willtsai Jul 2, 2025 •

edited

Loading

lakshmimsft Jul 2, 2025 •

edited

Loading