diff --git a/.github/config/en-custom.txt b/.github/config/en-custom.txt index 223956a2a..acafccc57 100644 --- a/.github/config/en-custom.txt +++ b/.github/config/en-custom.txt @@ -957,7 +957,6 @@ tlsdemo ConfigMap PodSpec composable -CRD nd OSI scaffolded @@ -1080,3 +1079,4 @@ ZDNET Newstrail postgresql natively +NuGet diff --git a/.github/workflows/issues.yml b/.github/workflows/issues.yml index 7699e96a3..fed222313 100644 --- a/.github/workflows/issues.yml +++ b/.github/workflows/issues.yml @@ -9,36 +9,6 @@ concurrency: cancel-in-progress: false jobs: - customer: - name: Add a label if Issue created by customer - if: github.event.action == 'opened' - runs-on: ubuntu-latest - env: - GITHUB_TOKEN: ${{ secrets.GH_RAD_CI_BOT_PAT }} - steps: - - name: Add label if author in preview team - env: - ISSUE: ${{ github.event.issue.html_url }} - AUTHOR: ${{ github.actor }} - run: | - MEMBERS=$(gh api orgs/radius-project/teams/Radius-Preview/members | jq -r '.[] | .login') - ADMINS=$(gh api orgs/radius-project/teams/Radius-Admin/members | jq -r '.[] | .login') - for USER in $MEMBERS; do - if [[ "$USER" == "$AUTHOR" ]]; then - ISADMIN=false - for ADMIN in $ADMINS; do - if [[ "$USER" == "$ADMIN" ]]; then - echo "$USER is an admin, skipping" - ISADMIN=true - fi - done - if [[ "$ISADMIN" == "false" ]]; then - echo "Adding label for issue $ISSUE" - gh issue edit $ISSUE --add-label "customer-issue" - fi - fi - done - ado: name: Sync issue to Azure DevOps runs-on: ubuntu-latest diff --git a/docs/content/concepts/architecture-concept/index.md b/docs/content/concepts/architecture-concept/index.md index 108decbc7..f5f51e1ad 100644 --- a/docs/content/concepts/architecture-concept/index.md +++ b/docs/content/concepts/architecture-concept/index.md @@ -82,7 +82,7 @@ All of Radius' core concepts are expressed using resources: All of these resources can be manipulated using the CRUDL+ operations that the resource providers provide. Since the functionality is implemented as part of the API any number of tools can have access to this functionality. -The `Applications.*` resource providers are fully-open source and were created as part of the Radius project. The `Applications.Core` and `Applications.*` resource providers are written in Go. +The `Applications.*` resource providers are fully open-source and were created as part of the Radius project. The `Applications.Core` and `Applications.*` resource providers are written in Go. #### Bicep Deployments Resource Provider diff --git a/docs/content/concepts/faq/index.md b/docs/content/concepts/faq/index.md index 12656ca7a..0aaf0d00f 100644 --- a/docs/content/concepts/faq/index.md +++ b/docs/content/concepts/faq/index.md @@ -86,7 +86,7 @@ Radius leverages Kubernetes in two ways: 1. As a hosting platform for the Radius control-plane 1. As a runtime for containerized workloads -While Radius only supports Kubernetes today, it is architected to support other hosting platforms in the future, including serverless platforms. Radius is not a Kubernetes controller and the primary user experience is not through CRDs. Instead, Radius Applications are an abstraction layer on top of Kubernetes and other cloud platforms. +While Radius only supports Kubernetes today, it is architected to support other hosting platforms in the future, including serverless platforms. Radius is not a Kubernetes controller and the primary user experience is not through custom resources (CRDs). Instead, Radius Applications are an abstraction layer on top of Kubernetes and other cloud platforms. ### How does Radius compare to Helm? @@ -96,8 +96,6 @@ Radius was built to provide a platform for modeling and deploying an entire appl Teams looking to leverage existing Helm charts can use the [Radius annotations and Recipe CRD](#TODO) to add Radius capabilities to their existing application. With just a few annotations, you can add the power of the Radius app graph, connections, and Recipes to your existing Helm chart. -Teams building or migrating applications on Radius can use Bicep to model their application and deploy to Kubernetes today, as well as future platforms, including serverless platforms. - ### How does Radius compare to Bicep? [Bicep](https://github.com/Azure/bicep) is a Domain Specific Language (DSL) for deploying infrastructure declaratively. Radius leverages Bicep as one of its supported languages for defining applications and Recipes. @@ -106,6 +104,8 @@ Similar to how you can define Azure resources in Bicep, you can define Radius re Radius currently uses a temporary fork of Bicep to add support for the Radius resources, but work is underway to merge extensibility support into the main Bicep repo and eliminate the need for a fork. +Teams building or migrating applications on Radius can use Bicep to model their application and deploy to Kubernetes today, as well as future platforms, including serverless platforms. + ### How does Radius compare to Terraform? [Terraform](https://www.terraform.io/) is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform is a great tool for deploying infrastructure, but doesn't provide a way to model an entire application and the dependencies between services and infrastructure, or act as an abstraction layer for multiple cloud providers. @@ -126,7 +126,7 @@ Radius is an open-source project that allows you to model, deploy, and manage ap ### How does Radius compare to Crossplane? -[Crossplane](https://crossplane.io/) is an open source Kubernetes add-on that extends any cluster with the ability to provision and manage cloud infrastructure, services, and applications using kubectl, GitOps, or any tool that works with the Kubernetes API. As Radius is unopinionated about how infrastructure is deployed through Recipes, Crossplane could be used within a Recipe. Both Bicep and Terraform modules are able to include Kubernetes resources and Crossplane CRDs. +[Crossplane](https://crossplane.io/) is an open-source Kubernetes add-on that extends any cluster with the ability to provision and manage cloud infrastructure, services, and applications using kubectl, GitOps, or any tool that works with the Kubernetes API. As Radius is unopinionated about how infrastructure is deployed through Recipes, Crossplane could be used within a Recipe. Both Bicep and Terraform modules are able to include Kubernetes resources and Crossplane CRDs. Once deployed, Crossplane-managed infrastructure can be included in a Radius application and queried via the Radius application graph. @@ -179,3 +179,9 @@ While there isn't direct support for targeting Azure Arc for Radius containers t [Azure Container Apps](https://azure.microsoft.com/products/container-apps/) is a service that allows developers to deploy containerized applications to Azure without managing any infrastructure. While Radius only supports Kubernetes today, it is architected to support other hosting platforms in the future, including serverless platforms such as Azure Container Apps. Serverless support is on our roadmap. + +### How does Radius compare to .NET Aspire? + +[.NET Aspire](https://learn.microsoft.com/dotnet/aspire/get-started/aspire-overview) is an opinionated, cloud ready stack for building .NET applications. .NET Aspire is delivered through a collection of NuGet packages that provide a batteries-included experience for building cloud-native applications as well as tools and IDE integration. + +Where .NET Aspire is focused on the .NET experience from moving from local development with a debugger to the cloud, Radius is not opinionated about the application runtime and doesn't seek to solve running applications locally as processes. Radius also offers tools for developers and operators to collaborate on an application throughout its lifecycle, such as the application graph and Recipes. diff --git a/docs/content/concepts/multi-cloud-concept/index.md b/docs/content/concepts/multi-cloud-concept/index.md index 038d3a5af..1cffcd45a 100644 --- a/docs/content/concepts/multi-cloud-concept/index.md +++ b/docs/content/concepts/multi-cloud-concept/index.md @@ -2,7 +2,7 @@ type: docs title: "Concept: Open-source and multi-cloud" linkTitle: Open-source and multi-cloud -description: For many enterprises, their cloud native computing strategy involves using multiple cloud providers. Open source projects, like Kubernetes, help ensure these enterprises achieve their strategy. As a result, Radius was designed to be open-source and multi-cloud from the start. +description: For many enterprises, their cloud native computing strategy involves using multiple cloud providers. Open-source projects, like Kubernetes, help ensure these enterprises achieve their strategy. As a result, Radius was designed to be open-source and multi-cloud from the start. weight: 100 categories: "Concept" --- @@ -29,7 +29,7 @@ Some enterprises explained that they were multi-cloud through acquisitions. Thei Finally, some enterprises explained that they were multi-cloud due to inertia. They had started with one cloud provider, but later, switched to using a different provider as their primary choice for new applications. Like the acquisition case above, there was no requirement to move existing applications to the new cloud provider. -Radius was designed with these enterprises in mind. Enterprises can "radify" their applications regardless of cloud provider, enabling these enterprises to use Radius regardless of whether or not the application is using a particular public cloud provider or a private cloud operated by the enterprise itself. Radius applications can use cloud vendor specific technologies, like Amazon's DynamoDB or Azure's Cosmos DB, or they can use open source technologies like Redis. +Radius was designed with these enterprises in mind. Enterprises can "radify" their applications regardless of cloud provider, enabling these enterprises to use Radius regardless of whether or not the application is using a particular public cloud provider or a private cloud operated by the enterprise itself. Radius applications can use cloud vendor specific technologies, like Amazon's DynamoDB or Azure's Cosmos DB, or they can use open-source technologies like Redis. ### Cloud-agnostic applications @@ -37,11 +37,11 @@ There were some enterprises that ran the same application in multiple clouds. Of Radius was designed to support this specific use case from the start. We wanted to make it possible for IT teams, platform engineering teams, or cloud center of excellence teams to make decisions about which cloud provider an application would use. We wanted them to be able to make that decision without having an impact on their developers and the application logic those developers were writing. -Radius supports cloud-agnostic applications in two ways. First, enterprises can use open source technologies in their applications. For example, developers that need a cache might use a Redis cache in their application. The platform engineering team would build Radius Recipes that, depending on the cloud provider, would use a different underlying Redis compatible service. This might mean using Azure Cache for Redis when deploying to Azure or Amazon ElastiCache for Redis on AWS. The developer's application logic and deployment assets like Helm charts should be the same, regardless of which cloud they're using. +Radius supports cloud-agnostic applications in two ways. First, enterprises can use open-source technologies in their applications. For example, developers that need a cache might use a Redis cache in their application. The platform engineering team would build Radius Recipes that, depending on the cloud provider, would use a different underlying Redis compatible service. This might mean using Azure Cache for Redis when deploying to Azure or Amazon ElastiCache for Redis on AWS. The developer's application logic and deployment assets like Helm charts should be the same, regardless of which cloud they're using. The second way Radius supports cloud-agnostic applications is with [Dapr, the Distributed Application Runtime](https://dapr.io). Dapr provides developers with APIs that abstract away the complexity of common challenges developers encounter regularly when building cloud native applications. These API building blocks abstract away services that provide state management, secrets management, or publish and subscribe systems. Developers can write to Dapr and platform engineering teams can use Radius to provide the underlying infrastructure for these Dapr based applications. For example, a Dapr application that's persisting state could use Azure Blob Storage or Amazon DynamoDB as the underlying state store depending on which cloud provider was used to host the application. -Radius was designed from the start to support enterprises in implementing their multi-cloud strategy. Enterprises can use cloud vendor technologies, like DynamoDB, or they can build on open source technologies like Redis and Dapr. +Radius was designed from the start to support enterprises in implementing their multi-cloud strategy. Enterprises can use cloud vendor technologies, like DynamoDB, or they can build on open-source technologies like Redis and Dapr. ## Open-source Many enterprises use open-source technologies as a way of *achieving* their multi-cloud strategy. Kubernetes adoption is a great example of this trend. Customers building on Kubernetes can leverage their Kubernetes experience, tools, and practices with any cloud provider and they're confident Kubernetes, with it's broad community, will continue to be a multi-cloud technology. diff --git a/docs/content/concepts/overview/index.md b/docs/content/concepts/overview/index.md index c4b5da2e3..50d5a1d9f 100644 --- a/docs/content/concepts/overview/index.md +++ b/docs/content/concepts/overview/index.md @@ -11,7 +11,7 @@ toc_hide: true App teams today struggle to model and deploy their applications. Complex architectures, cross-platform portability requirements, and org-level best-practices all make it difficult to not only model and deploy, but also maintain and troubleshoot large applications. -Apps today are modeled and deployed with Dockerfiles, Kubernetes CRDs, Helm charts, and infrastructure-as-code templates, with scripts to glue it all together. Plus, the range of infrastructure types (cloud, on-premises, serverless) can double or triple the work as teams figure out how to move apps between platforms. +Apps today are modeled and deployed with Dockerfiles, Kubernetes custom resources (CRDs), Helm charts, and infrastructure-as-code templates, with scripts to glue it all together. Plus, the range of infrastructure types (cloud, on-premises, serverless) can double or triple the work as teams figure out how to move apps between platforms. {{< image alt="Diagram showing all of the technologies needed to model an application today" src="cloud-apps-today.png" width="600px" >}} diff --git a/docs/content/concepts/why-radius-concept/index.md b/docs/content/concepts/why-radius-concept/index.md index a570ebecc..b02491ea9 100644 --- a/docs/content/concepts/why-radius-concept/index.md +++ b/docs/content/concepts/why-radius-concept/index.md @@ -29,7 +29,7 @@ Our philosophy is to be inclusive when considering what is *part of the applicat ## Developers and platform engineers need to collaborate -Enterprises are creating specialized roles and initiatives to improve their speed, efficiency, and security when adopting the cloud. Platform engineering is an emerging discipline that's combining a product mindset with learnings from DevOps and DevSecOps teams to create internal development platforms. When successful, platform engineers deliver a set of tools that provide sufficient automation, tracking, governance, and observability that guide development teams naturally fall “into the pit of success.” Often these endeavors can come up a little short, looking like a set of repository templates, cloud resource templates, and a software catalog for application developers to use. Unfortunately, the tools and assets that are frequently used don't encourage collaboration between developers and the platform engineers supporting those developers. Platform engineering is new as a discipline, and the patterns that will make enterprises successful long-term are still emerging. +Enterprises are creating specialized roles and initiatives to improve their speed, efficiency, and security when adopting the cloud. Platform engineering is an emerging discipline that's combining a product mindset with learnings from DevOps and DevSecOps teams to create internal development platforms. When successful, platform engineers deliver a set of tools that provide sufficient automation, tracking, governance, and observability that guide development teams to naturally fall into "the pit of success." Often these endeavors can come up a little short, looking like a set of repository templates, cloud resource templates, and a software catalog for application developers to use. Unfortunately, the tools and assets that are frequently used don't encourage collaboration between developers and the platform engineers supporting those developers. Platform engineering is new as a discipline, and the patterns that will make enterprises successful long-term are still emerging. Radius provides concepts like Environments and Recipes that support a separation of concerns. Platform engineers can create repository templates with CI/CD pipelines and starter code for deployment. IT operators can deploy and govern the Environments where those pipelines deploy applications. Cloud and security experts can provide the Recipes used to create and update cloud resources. Developers are only responsible for describing the requirements and architecture of the application, understanding which environments to use, and choosing dependencies from the supported set of Recipes. diff --git a/docs/content/guides/author-apps/containers/overview/index.md b/docs/content/guides/author-apps/containers/overview/index.md index 5782682f0..2a7285725 100644 --- a/docs/content/guides/author-apps/containers/overview/index.md +++ b/docs/content/guides/author-apps/containers/overview/index.md @@ -28,7 +28,7 @@ Radius provides a way to apply custom Kubernetes configurations to container res ##### Base Kubernetes YAML -You can provide a Kubernetes YAML definition as a base or foundation upon which Radius will build your containers, enabling you to incrementally adopting Radius by starting with your existing YAML definition and use applying Radius customizations on top. The provided YAML is fully passed through to Kubernetes when Radius creates the container resource, which means that you may even provide a definition for a CRD that Radius has no visibility into. +You can provide a Kubernetes YAML definition as a base or foundation upon which Radius will build your containers, enabling you to incrementally adopting Radius by starting with your existing YAML definition and use applying Radius customizations on top. The provided YAML is fully passed through to Kubernetes when Radius creates the container resource, which means that you may even provide a definition for a custom resources (CRD) that Radius has no visibility into. Radius currently supports the following Kubernetes resource types for the `base` property: diff --git a/docs/content/guides/operations/control-plane/metrics/grafana/index.md b/docs/content/guides/operations/control-plane/metrics/grafana/index.md index 73e2cd9d8..8c6d2eefc 100644 --- a/docs/content/guides/operations/control-plane/metrics/grafana/index.md +++ b/docs/content/guides/operations/control-plane/metrics/grafana/index.md @@ -8,7 +8,7 @@ categories: "How-To" tags: ["metrics", "observability"] --- -[Grafana](https://grafana.com/) is an open source visualization and analytics tool that allows you to query, visualize, alert on, and explore your metrics. This guide will show you how to install Grafana and configure it to visualize the Radius control plane metrics from Prometheus. +[Grafana](https://grafana.com/) is an open-source visualization and analytics tool that allows you to query, visualize, alert on, and explore your metrics. This guide will show you how to install Grafana and configure it to visualize the Radius control plane metrics from Prometheus. ## Example dashboards diff --git a/docs/content/guides/operations/control-plane/traces/jaeger/index.md b/docs/content/guides/operations/control-plane/traces/jaeger/index.md index 637999290..9b4ebdbf3 100644 --- a/docs/content/guides/operations/control-plane/traces/jaeger/index.md +++ b/docs/content/guides/operations/control-plane/traces/jaeger/index.md @@ -8,7 +8,7 @@ categories: "How-To" tags: ["tracing", "observability"] --- -[Jaeger](https://www.jaegertracing.io/) is an open source distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. +[Jaeger](https://www.jaegertracing.io/) is an open-source distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. The following steps show you how to configure the Radius control plane to send distributed tracing data to Jaeger running as a container in your Kubernetes cluster and how to view the data. diff --git a/docs/content/guides/operations/control-plane/traces/zipkin/index.md b/docs/content/guides/operations/control-plane/traces/zipkin/index.md index c297e3396..a422eda1e 100644 --- a/docs/content/guides/operations/control-plane/traces/zipkin/index.md +++ b/docs/content/guides/operations/control-plane/traces/zipkin/index.md @@ -8,7 +8,7 @@ categories: "How-To" tags: ["tracing", "observability"] --- -[Zipkin](https://zipkin.io/) is an open source distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. +[Zipkin](https://zipkin.io/) is an open-source distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. The following steps show you how to configure the [Radius control plane]({{< ref architecture-concept >}}) components to send distributed tracing data to Zipkin running as a container in your Kubernetes cluster and how to view the data. diff --git a/docs/content/guides/operations/workspaces/howto-workspaces/index.md b/docs/content/guides/operations/workspaces/howto-workspaces/index.md index 65dd7b5d3..f2f1b74a9 100644 --- a/docs/content/guides/operations/workspaces/howto-workspaces/index.md +++ b/docs/content/guides/operations/workspaces/howto-workspaces/index.md @@ -22,41 +22,41 @@ When you have multiple environments initialized for different purposes workspace rad install kubernetes ``` -1. Create a resource group named `myworkspace` using [`rad group create`]({{< ref rad_group_create >}}): +1. Create a resource group named `mygroup` using [`rad group create`]({{< ref rad_group_create >}}): ```sh - rad group create myworkspace + rad group create mygroup ``` -1. Create an environment named `myworkspace` using [`rad env create`]({{< ref rad_env_create >}}): +1. Create an environment named `myenvironment` using [`rad env create`]({{< ref rad_env_create >}}): ```sh - rad env create myworkspace + rad env create myenvironment ``` 1. Create a workspace named `myworkspace` using [`rad workspace create`]({{< ref rad_workspace_create >}}): ```sh - rad workspace create kubernetes myworkspace --group myworkspace --environment myworkspace + rad workspace create kubernetes myworkspace --group mygroup --environment myenvironment ``` Radius writes the workspace details to your local configuration file (`~/.rad/config.yaml` on Linux and macOS, `%USERPROFILE%\.rad\config.yaml` on Windows). -1. Create another resource group named `yourworkspace` using [`rad group create`]({{< ref rad_group_create >}}): +1. Create another resource group named `yourgroup` using [`rad group create`]({{< ref rad_group_create >}}): ```sh - rad group create yourworkspace + rad group create yourgroup ``` -1. Create an environment named `yourworkspace` using [`rad env create`]({{< ref rad_env_create >}}): +1. Create an environment named `yourenvironment` using [`rad env create`]({{< ref rad_env_create >}}): ```sh - rad env create yourworkspace + rad env create yourenvironment ``` 1. Create a workspace named `yourworkspace` using [`rad workspace create`]({{< ref rad_workspace_create >}}): ```sh - rad workspace create kubernetes yourworkspace --group yourworkspace --environment yourworkspace + rad workspace create kubernetes yourworkspace --group yourgroup --environment yourenvironment ``` 1. Verify your `config.yaml` file. It should show both `myworkspace` and `yourworkspace` workspaces, with your environments: @@ -69,16 +69,16 @@ When you have multiple environments initialized for different purposes workspace connection: context: mycluster kind: kubernetes - environment: /planes/radius/local/resourcegroups/yourworkspace - /providers/applications.core/environments/yourworkspace - scope: /planes/radius/local/resourceGroups/yourworkspace + environment: /planes/radius/local/resourcegroups/yourgroup + /providers/applications.core/environments/yourenvironment + scope: /planes/radius/local/resourceGroups/yourgroup myworkspace: connection: context: mycluster kind: kubernetes - environment: /planes/radius/local/resourcegroups/myworkspace - /providers/applications.core/environments/myworkspace - scope: /planes/radius/local/resourceGroups/myworkspace + environment: /planes/radius/local/resourcegroups/mygroup + /providers/applications.core/environments/myenvironment + scope: /planes/radius/local/resourceGroups/mygroup ``` 1. You can now deploy applications to both myworkspace and yourworkspace using [`rad deploy`]({{< ref rad_deploy >}}), specifying the `-w` flag. diff --git a/docs/content/guides/operations/workspaces/overview/index.md b/docs/content/guides/operations/workspaces/overview/index.md index ea9eb1f7f..ed2eb8f01 100644 --- a/docs/content/guides/operations/workspaces/overview/index.md +++ b/docs/content/guides/operations/workspaces/overview/index.md @@ -30,7 +30,7 @@ rad workspace init kubernetes [rad workspace list]({{< ref rad_workspace_list >}}) lists all of the workspaces in your configuration file: ```bash -rad workspacae list +rad workspace list ``` {{% /codetab %}} diff --git a/docs/content/reference/api/resource-policies/_index.md b/docs/content/reference/api/resource-policies/_index.md index bcceebe1f..bab2d90da 100644 --- a/docs/content/reference/api/resource-policies/_index.md +++ b/docs/content/reference/api/resource-policies/_index.md @@ -33,7 +33,7 @@ The default timeout times are listed below but be aware that the asynchronous ti Each resource type controller decides whether it will retry to process the operation when it fails, but the current async operation controller immediately marks any errors as a `Failed` operation except for the following scenario: - Panic happens while processing the async operation by code defect (retry once, then mark the operation Failed) -- RP process exits by unexpected process crashes (such as node failure, memory leak) and redeploying Radius. (retry once , then mark the operation Failed) +- Resource provider process exits by unexpected process crashes (such as node failure, memory leak) and redeploying Radius. (retry once , then mark the operation Failed) #### Applications.Core resource provider @@ -59,7 +59,6 @@ Each resource type controller decides whether it will retry to process the opera | Applications.Dapr/stateStores | LIST/GET/PUT/PATCH/DELETE | Synchronous | default | | | Applications.Dapr/stateStores | POST ListSecret | Synchronous | default | | - #### Applications.Datastores resource providers | Resource Type | Operation | API Type | Server Timeout (Seconds) | Async Operation retry condition| diff --git a/docs/content/reference/limitations.md b/docs/content/reference/limitations.md index c6d3eb56f..4e882b6f8 100644 --- a/docs/content/reference/limitations.md +++ b/docs/content/reference/limitations.md @@ -39,7 +39,7 @@ See [app name constraints]({{< ref "resource-schema.md#common-values" >}}) for m ### Application and resource names are lower-cased after deployment After deploying an application with application name `AppNAME` and container name `CONTAINERname`, casing information about the casing is lost, resulting in names to be lower-cased. The result is: - + ```bash rad application list RESOURCE TYPE @@ -118,5 +118,3 @@ Some of the [AWS resource types](/resource-schema/aws) are 'non-idempotent', thi We are currently building support for non-idempotent resources in Radius. Please like and comment on this [this issue](https://github.com/radius-project/radius/issues/6227) if you are interested in the same. As a workaround, you can try using [Terraform Recipes]({{< ref "/guides/recipes/overview" >}}) to deploy and manage those non-idempotent resource types. - - diff --git a/docs/content/reference/resource-schema/aws/index.md b/docs/content/reference/resource-schema/aws/index.md index 995997ca7..49b8cb51a 100644 --- a/docs/content/reference/resource-schema/aws/index.md +++ b/docs/content/reference/resource-schema/aws/index.md @@ -6,7 +6,7 @@ description: "Learn about the supported AWS resource types in Radius" categories: "Schema" --- -Radius supports AWS resource types that are supported by the [AWS Cloud Control API](https://docs.aws.amazon.com/cloudcontrolapi/latest/userguide/what-is-cloudcontrolapi.html) +Radius supports AWS resource types that are supported by the [AWS Cloud Control API](https://docs.aws.amazon.com/cloudcontrolapi/latest/userguide/what-is-cloudcontrolapi.html). Following table lists the resource types that are currently supported and the limitations for each of the resource types. diff --git a/docs/content/reference/resource-schema/core-schema/extender/snippets/extender-recipe.bicep b/docs/content/reference/resource-schema/core-schema/extender/snippets/extender-recipe.bicep index 9723169f8..8b436cbe9 100644 --- a/docs/content/reference/resource-schema/core-schema/extender/snippets/extender-recipe.bicep +++ b/docs/content/reference/resource-schema/core-schema/extender/snippets/extender-recipe.bicep @@ -30,6 +30,3 @@ resource publisher 'Applications.Core/containers@2023-10-01-preview' = { } } } - - - diff --git a/docs/content/reference/resource-schema/core-schema/gateway/snippets/gateway.bicep b/docs/content/reference/resource-schema/core-schema/gateway/snippets/gateway.bicep index eefc5fa15..0af5ade47 100644 --- a/docs/content/reference/resource-schema/core-schema/gateway/snippets/gateway.bicep +++ b/docs/content/reference/resource-schema/core-schema/gateway/snippets/gateway.bicep @@ -16,7 +16,7 @@ resource gateway 'Applications.Core/gateways@2023-10-01-preview' = { application: app.id hostname: { // Omitting hostname properties results in gatewayname.appname.PUBLIC_HOSTNAME_OR_IP.nip.io - + // Results in prefix.appname.PUBLIC_HOSTNAME_OR_IP.nip.io prefix: 'prefix' // Alternately you can specify your own hostname that you've configured externally diff --git a/docs/content/reference/resource-schema/core-schema/volumes/volume-azure-keyvault/snippets/volume-keyvault.bicep b/docs/content/reference/resource-schema/core-schema/volumes/volume-azure-keyvault/snippets/volume-keyvault.bicep index 33cb3da31..9618054c6 100644 --- a/docs/content/reference/resource-schema/core-schema/volumes/volume-azure-keyvault/snippets/volume-keyvault.bicep +++ b/docs/content/reference/resource-schema/core-schema/volumes/volume-azure-keyvault/snippets/volume-keyvault.bicep @@ -46,8 +46,8 @@ resource volume 'Applications.Core/volumes@2023-10-01-preview' = { name: 'cert1' // required version: '1' // optional, defaults to latest version alias: 'certificatealias' // optional, defaults to certificate name (mycertificate) - encoding: 'base64' // optional, defaults to utf-8 - certType: 'privatekey' // optional, defaults to utf-8 + encoding: 'base64' // optional, defaults to utf-8, only available when value is privatekey + value: 'privatekey' // required format: 'pem' // optional, defaults to pfx } } diff --git a/docs/content/reference/resource-schema/dapr-schema/dapr-statestore/snippets/dapr-statestore-recipe.bicep b/docs/content/reference/resource-schema/dapr-schema/dapr-statestore/snippets/dapr-statestore-recipe.bicep index d19dfc521..7726cc1c6 100644 --- a/docs/content/reference/resource-schema/dapr-schema/dapr-statestore/snippets/dapr-statestore-recipe.bicep +++ b/docs/content/reference/resource-schema/dapr-schema/dapr-statestore/snippets/dapr-statestore-recipe.bicep @@ -26,7 +26,7 @@ resource myapp 'Applications.Core/containers@2023-10-01-preview' = { ] } } - + //SAMPLE resource statestore 'Applications.Dapr/stateStores@2023-10-01-preview' = { name: 'statestore' @@ -44,4 +44,3 @@ resource statestore 'Applications.Dapr/stateStores@2023-10-01-preview' = { } } //SAMPLE -