layered future: indicate whether a policy is implemented by the waypoint
Opened this issue · 7 comments
Describe the feature request
Implementations with variance from stock MUST adopt the mechanism used by the Gateway API specification to indicate whether a policy is successfully implemented by a Waypoint. See PolicyAncestorStatus and in particular PolicyConditionReason. For clarity stock OSS Istio will adopt the same mechanism and use the ACCEPTED state to indicate support for its own APIs.
Describe alternatives you've considered
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[X] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
Additional context
Istio’s Layered Future, Policy and Conformance
It looks like the way to do this might be to add new functionality to our generation tooling to support a flag like "pasgwstatus".
// +cue-gen:VirtualService:subresource:pasgwstatus
The k8s gw status stuff is not a new subresource, just a new struct within status
So just a new field in IstioStatus
Thanks John. The intent was to find a way to selectively add it. Are we OK with all the Istio resources getting these fields and we'll just ignore them if they're not useful then?
The crd is just
status:
type: object
x-kubernetes-preserve-unknown-fields: true
anyways.
Also your example was for VirtualService -- I assume we actually want it for almost everything but VS (and GW/DR)?
Yeah, Virtual service is not where we want it. It was just a proto where I found the marker for a (admittedly sloppy) copy/paste example. Sorry for the confusion there.
This seems good - would we additionally want to consider implementing https://gateway-api.sigs.k8s.io/geps/gep-2162/ on the istio-waypoint GatewayClass if that hasn't been done already, and encourage implementing it for any pluggable waypoint implementations, to advertise which features are supported?