Skip to content

Conversation

sk593
Copy link
Contributor

@sk593 sk593 commented Sep 15, 2025

This PR adds Recipes for the Routes resource type. Since Routes need a container for the connection to work, this PR also adds a simple container Recipe

@sk593 sk593 force-pushed the add-routes-recipes branch 2 times, most recently from 14ccfb6 to c66dfe9 Compare September 15, 2025 17:05
Signed-off-by: sk593 <[email protected]>
@sk593 sk593 force-pushed the add-routes-recipes branch 2 times, most recently from 0b3251e to 465b405 Compare September 15, 2025 18:21
Signed-off-by: sk593 <[email protected]>
@sk593 sk593 force-pushed the add-routes-recipes branch 3 times, most recently from 92aa70e to de46894 Compare September 15, 2025 22:30
# Define common configuration
setup_config() {
resource_folders=("Security")
# Define specific resource types to test instead of entire folders
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updating the workflow to allow testing to be added for individual resources instead of a namespace

@sk593 sk593 force-pushed the add-routes-recipes branch 2 times, most recently from a130182 to 26f04ab Compare September 15, 2025 23:51
@sk593 sk593 force-pushed the add-routes-recipes branch from 26f04ab to 801d78a Compare September 15, 2025 23:58
gateway_name = "gateway-${local.resource_id_hash}"
}

variable "context" {
Copy link
Contributor

@lakshmimsft lakshmimsft Sep 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this doesn't seem right/necessary. context will be populated into tf module
we can set

variable "context" {
  description = "This variable contains Radius recipe context."
  type        = any
} 

}
}

resource myContainer 'Radius.Compute/containers@2025-08-01-preview' = {
Copy link
Contributor Author

@sk593 sk593 Sep 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added this application template as an example of how the routes resource can be deployed. I'm not sure that we'd want this to be a test scenario for the repo since it's more of an integration/E2E test and it'd require the Gateway CRD to be installed on the test cluster (I set up the CRDs and necessary RBAC to deploy this when manually testing to verify that it'd work)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm open to suggestions on if this should be included in this repo's test framework

}

# Create Gateway for routing
resource "kubernetes_manifest" "gateway" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see you have a Gateway and a listener resource in the recipe, plus a reference to Contour. Which makes sense since there are pointers like Route → Gateway → Contour and listener. This is problematic since most clusters don't use Contour and we also don't know what listener the platform engineer wants/needs. 
 
The way I imagined this is:
• Platform engineer installs a Gateway Controller like NGINX. As part of that, the platform engineer creates the Gateway resource that has the listener and the GatewayClass. NGINX actually creates this as part of the install.
• Then the platform engineer sets the parentRefs as a parameter on the Recipe.
The pros of this approach is we enforce separation of concerns. HTTPRoutes is the application part. Gateway and listener are platform engineering tasks. The con is that in order for a Routes resource to work, the Gateway Controller and the parameter must be set correct.
 
I recommend we remove the Gateway resource from the Recipe. Do you have other ideas about how this workflow should work between platform engineer and developers?

namespace: context.runtime.kubernetes.namespace
}
]
hostnames: length(hostnames) > 0 ? hostnames : ['localhost']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than defaulting to localhost, I think this should be not specified if it is not provided. From the docs:

If no hostname is specified, traffic is routed based on HTTPRoute rules and filters (optional).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

backendRefs: [
{
name: '${toLower(last(split(rule.destinationContainer.resourceId, '/')))}-${rule.destinationContainer.containerName}'
port: 80
Copy link
Contributor

@zachcasper zachcasper Sep 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs reference rule.destinationContainer.containerPortName. We cannot assume a port number.

@sk593 sk593 marked this pull request as ready for review September 30, 2025 18:42
@sk593 sk593 requested review from a team as code owners September 30, 2025 18:42
Signed-off-by: sk593 <[email protected]>
@sk593 sk593 force-pushed the add-routes-recipes branch from c60f4df to 20f2eb0 Compare September 30, 2025 19:21
@lakshmimsft
Copy link
Contributor

application is set to required in the schema.

required: [environment, application, rules]

But it's not required in the recipe. Pls check if we need to update schema to align with recipe.

@lakshmimsft
Copy link
Contributor

@zachcasper , @sk593 perhaps this was discussed already but should include gRPC as another route_kind in the yaml and update the recipe for it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants