Feature: List all resources deployed to an environment in rad resource list

[asilverman]

Overview of feature request

I would like to start by inspecting our operator use-case: An operator / developer wants to troubleshoot a failure in the application, however rad will only give a partial view of the resources deployed.

At the time of writing rad resource list only lists the radius resources deployed to the environment but it doesn't list the underlying Azure resources they may be connected to. This limits the operator's ability to see the full picture of the components that make up the functionality and this is a significant limitation in my personal opinion.

The ask is to have rad resource list to provide the full picture of all those resources that are directly/indirectly related to the rad environment.

Additional context

Conversation from 05/26/2022

[Wednesday 16:00] Ariel Silverman

Hi team,

I recently used the rad CLI to deploy a simple template that contains a single azure resource, the template and the command line executed follow:

azure-resources-storage-account.bicep

param storageAccountName string
param location string = resourceGroup().location


resource sa 'Microsoft.Storage/storageAccounts@2021-09-01' = {​​​​​​
  name: storageAccountName
  location: location
  sku: {​​​​​​
    name: 'Standard_LRS'
  }​​​​​​
  kind: 'StorageV2'
  properties: {​​​​​​
    accessTier: 'Hot'
  }​​​​​​
}​​​​​​

resource container 'Microsoft.Storage/storageAccounts/blobServices/containers@2019-06-01' = {​​​​​​
  name: '${​​​​​​sa.name}​​​​​​/default/logs'
}​​​​​​

cli command
rad deploy azure-resources-storage-account.bicep --parameters "storageAccountName=asilverman54321"

Now I would like to inspect the resource I just deployed, notice that I am not deploying the resource as part of an application (no applications have been deployed to my environment yet)

Question: Is it possible for me to use the rad CLI to list the resource I just created (via the rad CLI) ? If not, shouldn't this be supported?

---

[Wednesday 16:01] Ariel Silverman

I would expect the command rad resource list to show the resource I just created, however the result follows:

rad resource list       
Error: no application name provided and no default application set, either pass in an application name or set a default application by using `rad application switch`

---

​[Wednesday 16:37] Aaron Crawfis

Since this resource isn't "part" of an application, I don't think it would make sense to list it. rad resource list is meant to list all the resources within the application, not within the resource group that your environment is in or the resources you deployed with rad. (for context an Azure resource becomes "part" of a resource when a Radius container connects to it, although we have been discussing other ways to define/implement this).

There are a couple points that would be complicated if we were to list non-application resources:

• Do we show all the resources in the resource group your environment is in? What happens if you override the resource group of your storage account?

• Do we show all resources that you've deployed with the rad CLI? That gets tough because we'll now need to track this client side, and you'll get different answers based upon what machine you're on.

---

​[Yesterday 09:44] Ariel Silverman

Thank you for the context and explanation Aaron. I would like to challenge the idea that we shouldn't list resources that aren't "part" of an application. The reasoning is that in fact all resources declared in a manifest.bicep file that are deployed to a given environment are logically part of that environment and they should be visible to the entity that created them and/or is listing the components of the environment.

One way we could keep track of those resources that are deployed by Radius is to store a runtime object reference in the Radius control plane that is synchronized with the state of the Azure resource. otherwise the process of troubleshooting or even reasoning about what is deployed into a given Radius environment becomes fragmented and opaque.

See below my answers to the questions you listed:

Q1 : We should show only those resources that are created or referenced in the manifests that were deployed to the radius environment in question. I am not sure what you mean by "override the resource group of your storage account", can you elaborate more about this use-case/workflow ?

Q2: We should and there is no hard constraint that this has to happen client side, we can do this server side by creating runtime objects that are queryable and stored in etcd (like CRDs), and likely we should also add a controller that reconciles their state with Azure.

I am interested to hear your thoughts on the proposal above and also would recommend we consider that other solutions in this space (like Crossplane) handle this problem as described in my answer to Q1

---

​[Yesterday 10:21] Aaron Crawfis

all resources declared in a manifest.bicep file that are deployed to a given environment are logically part of that environment

This isn't the case. When you deploy a Bicep file with rad deploy you aren't deploying to an environment. You're deploying to the platform where the environment resides (ARM or UCP). When you declare resources in a Bicep file, only the Radius resources (containers, connectors, application) are part of the Radius environment or application. Then any Azure resources that are connected to from a Radius container become tracked in the environment as well, although I would not consider them part of the environment (this is the behavior today, we can always add new capabilities later). The Azure resources in the Bicep file that are not connected to by a container have nothing to do with Radius environments or Radius applications.

I am not sure what you mean by "override the resource group of your storage account", can you elaborate more about this use-case/workflow ?

When you run rad deploywe use the subsciptionId and resourceGroup of the environment entry stored in config.yaml to set the target scope of the deployment. So if you have a storage account in your Bicep file that storage account gets deployed to the same subscription and resource group as your environment. There is an option in Bicep to override the target scope of a resource and point it to a different subscription and resource group. Bicep functions - scopes - Azure Resource Manager | Microsoft Docs

we can do this server side by creating runtime objects that are queryable and stored in etcd (like CRDs), and likely we should also add a controller that reconciles their state with Azure.

An issue here is that on the server we never see non-Radius resources. ARM and UCP split the resource calls to the respective RPs, so we would never know that there was an Azure storage account in the Bicep file and therefore wouldn't be able to track it.

Overall I think that users should be able to opt-in to having their non-Radius resources be tracked by an environment and be part of an application, but this should be an explicit action that is more than having it just within a Bicep file. As a future feature I imagine this will be an extension resource on Azure resources, or some other mechanism we build with ARM

---

[Yesterday 10:36] Ariel Silverman

Thank you Aaron for the thorough reply. I have a couple of follow ups:

When you deploy a Bicep file with rad deploy you aren't deploying to an environment

I apologize for insisting in this matter, however my mental model is that as a user I create a Radius environment (azure or standalone) and this becomes the bounded logical space in which I deploy components and resources, those logical entities that I declare in my manifest and are sent via the rad deploy manifest.bicep command target a specific environment which in my understanding is a logical boundary and thus I should be able to introspect and list what was deployed there regardless of where those resources actually run since all I need is a logical reference to be able to reason about what is in vs what is out.

It sounds like my mental model is wrong by analysis of the quoted sentence above, maybe you can help me clarify, what is the logical entity that represents my workspace ? I thought it was the radius environment since that is the thing I initialize when I want to work with radius but I seem to be confused about that now

See the description of the rad deploy command below:
rad deploy --help

Deploy a RAD application

The deploy command compiles a .bicep file and deploys it to your default environment (unless otherwise specified).

You can combine Radius types as as well as other types that are available in Bicep such as Azure resources. See
the Radius documentation for information about describing your application and resources with Bicep.

You can specify parameters using the '--parameter' flag ('-p' for short). Parameters can be passed as:

- A file containing multiple parameters using the ARM JSON parameter format (see below)
- A file containing a single value in JSON format
- A key-value-pair passed in the command line

When passing multiple parameters in a single file, use the format described here:

        https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/parameter-files

You can specify parameters using multiple sources. Parameters can be overridden based on the 
order the are provided. Parameters appearing later in the argument list will override those defined earlier.

Usage:
  rad deploy [app.bicep] [flags]

Examples:

# deploy a template (basic)

rad deploy myapp.bicep


# deploy to a specific environment

rad deploy myapp.bicep --environment production


# specify a string parameter

rad deploy myapp.bicep --parameters version=latest


# specify a non-string parameter using a JSON file

rad deploy myapp.bicep --parameters [email protected]


# specify many parameters using an ARM JSON parameter file

rad deploy myapp.bicep --parameters @myfile.json


# specify parameters from multiple sources

rad deploy myapp.bicep --parameters @myfile.json --parameters version=latest


Flags:
  -e, --environment string       The environment name
  -h, --help                     help for deploy
  -p, --parameters stringArray   Specify parameters for the deployment

Global Flags:
      --config string   config file (default "$HOME/.rad/config.yaml")
  -o, --output string   output format (supported formats are json, table, list) (default "table")

---

Edited​[Yesterday 10:45] Ariel Silverman

There is an option in Bicep to override the target scope of a resource and point it to a different subscription and resource group. Bicep functions - scopes - Azure Resource Manager | Microsoft Docs

I am familiar with targetScopes and I think that at the moment radius and until further notice radius only supports targetScope == 'resourceGroup' which is the default. I am not sure how other targetScope values would work with the concepts of Radius and I would love to have a discussion about this because it seems to invalidate the notion that a radius environment is the containing entity for all components.

---

Edited​[Yesterday 10:48] Ariel Silverman

An issue here is that on the server we never see non-Radius resources. ARM and UCP split the resource calls to the respective RPs, so we would never know that there was an Azure storage account in the Bicep file and therefore wouldn't be able to track it.

I am not sure how you reached the conclusion that we are unable to track it, technically this is not an impediment and the proposed solution of creating CRDs in the radius control plane whose state is reconciled with Azure is in fact one possible way to track them, I am more than happy to describe in detail this option

---

Edited​[Yesterday 12:52] Ariel Silverman

Hey Aaron Crawfis I would love to get a chance to talk about this more and better understand your thoughts on this, how about we meet and update on the channel later with a summary of the best path forward ?

---

​#### [Yesterday 18:57] Aaron Crawfis

Yeah I'd be happy to grab 30 minutes. Pls also invite Ryan and Aman to also track the proposal and weigh in

---

[09:36] Aman Bhardwaj

These resources are not part of a Radius environment and call for creation of these are not even sent to the Radius RPs, this is not a scenario which is needed for private or public preview and low on priority, I would suggest to create a issues and park it unless there is significant customer base asking for it

Link to conversation in MS-Teams

AB#6873

[rynowak]

Thanks @asilverman for popping this back on top of my queue.

What's needed to move this forward is come up with an actual proposal. You could start working on this, or we could treat this more as a brainstorm, whichever seems better to you.

I think a proposal for this will answer the following questions:

• What is the definition of "resource deployed to an environment"?
• How is this data stored?
• How is this data created/updated?
• How is this data accessed and shown to users?