Merge branch 'v0.27' into aacrawfi/extender-docs

Signed-off-by: Aaron Crawfis <[email protected]>

.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

.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

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
 

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.

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,19 +29,19 @@ 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
 
 There were some enterprises that ran the same application in multiple clouds. Often these enterprises had business requirements that required them to use multiple cloud providers. For example, some financial services enterprises had to host their application and any data associated with the application in a particular country or geographic region. The enterprise would need their application to be deployable to whichever cloud provider was available in a specific country or region.
 
 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. 

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" >}}
 

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.
 

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. <!-- For more information on how to onboard existing Kubernetes resources into Radius, refer to the [base Kubernetes YAML guide]("guides/author-apps/kubernetes/how-to-yaml-base-support"). -->
+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. <!-- For more information on how to onboard existing Kubernetes resources into Radius, refer to the [base Kubernetes YAML guide]("guides/author-apps/kubernetes/how-to-yaml-base-support"). -->
 
 Radius currently supports the following Kubernetes resource types for the `base` property:
 

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
 

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.