[Feature Request] Support external_ids field in VPC policyRoutes

[jimyag]

Description

Summary

Add support for custom external_ids in VPC spec.policyRoutes, allowing users to attach metadata to policy routes for tracking ownership and origin.

OVN's Logical_Router_Policy table natively supports external_ids (ref: ovn-nb man page), and kube-ovn's OVN-NB client already accepts this parameter. Only the CRD layer needs to be updated.

Current Behavior

The VPC CRD's PolicyRoute struct only exposes priority, match, action, and nextHopIP. Users cannot specify custom external_ids - the controller automatically sets {"vendor": "kube-ovn"}.

Expected Behavior

apiVersion: kubeovn.io/v1
kind: Vpc
metadata:
  name: my-vpc
spec:
  policyRoutes:
    - priority: 100
      match: "ip4.src == 10.0.0.0/24"
      action: allow
      externalIDs:
        created-by: my-controller
        purpose: egress-routing

The controller should merge user-specified external_ids with the default {"vendor": "kube-ovn"}.

Proposed Changes

1. Add ExternalIDs map[string]string field to PolicyRoute struct in pkg/apis/kubeovn/v1/vpc.go
2. Update VPC controller to merge user-specified external_ids
3. Update CRD definition

I'm willing to submit a PR for this feature.

Who will benefit from this feature?

Users who need to track the ownership and origin of policy routes in multi-controller or multi-team environments. This enables:

• Identifying which controller/operator created a specific policy route
• Debugging and auditing by recording the source of each policy
• Safe cleanup - controllers can manage only the routes they created

Anything else?

The infrastructure already supports this:

• pkg/ovsdb/ovnnb/logical_router_policy.go: ExternalIDs map[string]string
• pkg/ovs/ovn-nb-logical_router_policy.go: AddLogicalRouterPolicy(..., externalIDs map[string]string)

Ref: OVN-NB Logical_Router_Policy Table

[oilbeater]

While the feature is technically feasible, Kube-OVN is designed to manage only the resources it creates. Allowing external systems to attach metadata for Kube-OVN to manage would significantly increase complexity and blur ownership boundaries.

For resources created outside of Kube-OVN, we recommend using their respective controllers for management. This keeps the system modular and maintainable.

[SkalaNetworks]

If we stretch this, we could theorically add the ID to a bunch of resources Kube-OVN handles (and update every CRD to support this new field), but is it desirable?

That's why I asked you for your use case on the PR, I guess you have a very particular need regarding policyRoutes, and there may be a better way to approach it?

[jimyag]

Thanks for the discussion. After further consideration, I understand the community's concerns:

1. Opening this capability for policyRoutes may lead to requests for the same feature across all resources (subnet, vpc, nat, etc.), increasing maintenance burden

2. From OVN's perspective, kube-ovn is the CMS, and external_ids is designed for CMS use. User controllers are consumers of kube-ovn, not direct CMS of OVN

3. The traceability problem can be solved on the business side - controllers can maintain their own mapping of "which routes did I create".

For example, if the business side has an EgressPolicy CR that creates a corresponding policyRoute, querying "which route did this EgressPolicy create" is feasible since the business side can record this mapping.

However, the reverse lookup - seeing a route in kube-ovn/OVN and wanting to know which EgressPolicy it corresponds to - requires querying the business side, which is less convenient than having it recorded directly in external_ids.

[oilbeater]

You can try add the relationship in the CRs by annotations.