What would you like to be added:
A conformance test where a second controller's status entries already exist on the shared objects (RouteParentStatus, Gateway and Listener conditions, policy ancestor status), asserting the implementation under test preserves those foreign entries verbatim: no removal, no reordering, no rewriting. Today the harness assumes a single suite.ControllerName throughout, for example RouteMustHaveParents compares the exact expected parent set with no room for entries owned by another controller, so this MUST has no coverage.
Why this is needed:
The spec requires implementations not to touch status they don't own, and two controllers on one cluster is a normal setup. An implementation can wipe foreign status today and still pass the suite. The harness side overlaps with #2641 (fake GatewayClass / controllerName pattern), so this would build on that. I already implement and test this behaviour in my implementation, and I can contribute the conformance test.
What would you like to be added:
A conformance test where a second controller's status entries already exist on the shared objects (RouteParentStatus, Gateway and Listener conditions, policy ancestor status), asserting the implementation under test preserves those foreign entries verbatim: no removal, no reordering, no rewriting. Today the harness assumes a single
suite.ControllerNamethroughout, for exampleRouteMustHaveParentscompares the exact expected parent set with no room for entries owned by another controller, so this MUST has no coverage.Why this is needed:
The spec requires implementations not to touch status they don't own, and two controllers on one cluster is a normal setup. An implementation can wipe foreign status today and still pass the suite. The harness side overlaps with #2641 (fake GatewayClass / controllerName pattern), so this would build on that. I already implement and test this behaviour in my implementation, and I can contribute the conformance test.