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

• new route types implemented
• existing test suite expanded to cover new route types

Validation

• tests pass

Fixes Partially Addresses

• policy: Support Gateway API GRPCRoute resources #12404

[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 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 = "..." }

[adleong]

This is looking great!

[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

[adleong]

Nice!

[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.