policy(feat): `GrpcRoute` status support

[the-wondersmith]

Subject

Enable handling of Gateway GRPCRoute resources in linkerd-policy-controller-k8s-status.

Problem

In order to support driving traffic via Gateway GRPCRoute resources, the policy controller's status component must be made aware of both the different route type(s) (and their associated "sources") as well as how to handle them.

Solution

• [X] new route types implemented
• [X] existing test suite expanded to cover new route types

Validation

• [X] tests pass

~~Fixes~~ Partially Addresses

• #12404

[the-wondersmith]

@olix0r

This is looking generally right to me.

💪😁

Small nit: We generally have moved to stop using 'mod.rs' files, so in the case of policy-controller/k8s/status/src/tests/routes/mod.rs, we would typically name that controller/k8s/status/src/tests/routes.rs.

I want to make sure I action this correctly - for context I organized the tests as a mirror of the crate itself, so because src/routes/ is specifically structured so that anything generic / that applies to any route type lives at crate::routes::GenericRouteThing, everything that applies to a specific route subtype would live at crate::routes::subtype::SpecificRouteThing.

Is the nit about the partitioning of the route types into discrete submodules? Or does the nit just mean that this the preferred style / convention for linkerd crates?

├── Cargo.toml
└── src
   ├── ...
   ├── routes
   │  ├── grpc.rs
   │  └── http.rs
   ├── routes.rs
   └── tests
      ├── mod.rs
      ├── routes
      │  ├── grpc.rs
      │  └── http.rs
      └── routes.rs

I assume we need to (temporarily, just for the sake of seeing it work end-to-end) add a patch our Cargo.toml to take your branch of the k8s-gateway-api? Something like

[patch.crates-io]
k8s-gateway-api = { git = "https://github.com/the-wondersmith/k8s-gateway-api-rs", branch = "..." }

Yes. Locally, I've got essentially that in a .cargo/config.toml (just pointing to the local directory instead of the remote repo). There's an open PR in that repo as well.

[olix0r]

Is the nit about the partitioning of the route types into discrete submodules? Or does the nit just mean that this the preferred style / convention for linkerd crates?

It's limited to the mod.rs files. We usually avoid mod.rs files now, e.g. tests.rs instead of tests/mod.rs, etc.

[the-wondersmith]

@olix0r

Is the nit about the partitioning of the route types into discrete submodules? Or does the nit just mean that this the preferred style / convention for linkerd crates?

It's limited to the mod.rs files. We usually avoid mod.rs files now, e.g. tests.rs instead of tests/mod.rs, etc.

Gotcha. Given that the tests/mod.rs predates these changes, I want to make sure I action the feedback correctly.

If you'll confirm that this is the desired structure for the crate, I'll push the relevant changes:

├── Cargo.toml
└── src
   ├── index.rs
   ├── lib.rs
   ├── resource_id.rs
   ├── routes
   │  ├── grpc.rs
   │  └── http.rs
   ├── routes.rs
   ├── service.rs
   ├── tests
   │  ├── routes
   │  │  ├── grpc.rs
   │  │  └── http.rs
   │  └── routes.rs
   └── tests.rs

[olix0r]

I'm +0 on renaming the existing tests/mod.rs (sgtm, tioli).

[the-wondersmith]

I'm +0 on renaming the existing tests/mod.rs (sgtm, tioli).

Apologies for the pedantry here, just want to be sure I'm understanding correctly.

You do want:

• src/routes/mod.rs -> src/routes.rs
• src/tests/routes/mod.rs -> src/tests/routes.rs

You don't have strong feelings either way about:

• src/tests/mod.rs -> src/tests.rs

Is that correct?

[the-wondersmith]

@olix0r made a pushed the relevant changes, if you'd eyeball everything again whenever time allows 😁

[olix0r]

The audit CI failure is expected, but it looks like this is still depending on a version of the gateway bindings with timeout -- I think a cargo update -p k8s-gateway-api should fix it?

[the-wondersmith]

@olix0r good catch. Should be fixed now.

[the-wondersmith]

Just commenting for historical context purposes -

PR was opened to facilitate code review, but its overall size and content doesn't mesh with internal change management strategy. I'm closing this PR now that code review is complete and will be breaking the changes out into smaller chunks of mergeable changes.