bzp2010 opened a new pull request, #2877: URL: https://github.com/apache/apisix-ingress-controller/pull/2877
<!-- Please answer these questions before submitting a pull request --> ### Type of change: <!-- Please delete options that are not relevant. --> <!-- Select all the options from below that matches the type your PR best --> - [ ] Bugfix - [x] New feature provided - [ ] Improve performance - [ ] Backport patches - [ ] Documentation - [ ] Refactor - [ ] Chore - [ ] CI/CD or Tests ### What this PR does / why we need it: AIC pushes a GatewayProxy's whole resource snapshot on every sync round, and apisix-standalone validates a configuration document as a whole. One resource the data plane rejects therefore blocks that GatewayProxy from converging: the same rejected content is resent every round, and every other resource's pending changes wait behind it indefinitely. This PR isolates such a resource, so the rest applies: 1. **Attribution.** `cache.Store` records which Kubernetes resource produced each top-level ADC resource (service, ssl, consumer, global_rule, plugin_metadata) at the moment it is written, from the labels the caller already passes in, rather than searching the wire objects afterwards. Nested resources (route, stream route, named upstream, credential) are resolved through the `parentId` ADC reports, which also tells apart upstreams that share an id across services. 2. **Isolation.** A rejected resource is mapped to the unit that has to be dropped for the rest to apply, and that unit is left out of every later push. A named upstream takes its service with it, since the service's traffic-split refers to it by id and would otherwise be left dangling; a route or stream route of a Gateway API route takes its whole rule, which is the granularity the Gateway API reports drops at. Everything else is dropped on its own. 3. **Convergence.** A round that newly excluded something pushes again immediately instead of waiting for the retry backoff, since that push differs from the one that just failed and carries every other resource's pending changes. A failure reported against content the store has since replaced is ignored, so an in-flight result cannot exclude the fix that just arrived. An excluded resource is admitted again when its owner's translated content changes.API's `Dropped Rule` semantics; one with nothing left reports `Accepted=False` with `SyncFailed`. Plugins and plugin metadata declared by a GatewayProxy get a new `PluginsProgrammed` condition on the GatewayProxy, instead of being folded into `DataPlaneAvailable`, which is about instance reachability. A rejected Gateway listener certificate is reported on that listener by the Gateway controller, which stays the only writer of listener status. An Ingress, whose status has no conditions, gets a Warning event. 5. **Storage.** `global_rule` and `plugin_metadata` now live in the same per-GatewayProxy cache as every other resource, one row per plugin name. A global rule row carries its own owner: `GatewayProxy.Spec.Plugins` are written by a Gateway or IngressClass reconcile but belong to the GatewayProxy, and an ApisixGlobalRule contributes to the same key space independently. Consumer credentials now also get a stable id. Without one, ADC derives an id of its own that AIC cannot match a reported failure back to. Behaviour worth knowing: - Re-admission follows the translated content, not the reconcile: a reconcile that rewrites identical content does not retry a known-bad resource, which is what keeps a resource whose reconcile is triggered by unrelated events from failing every round. A fix made outside Kubernetes, such as installing a plugin the data plane was missing, needs the resource touched or the controller restarted. - When a Gateway or IngressClass stops referencing a GatewayProxy, that GatewayProxy's own plugins and plugin metadata stay in its own configuration, since they were never the Gateway's to begin with. - No CRD, API or wire format change. ### Pre-submission checklist: <!-- Please follow the requirements: 1. Use Draft if the PR is not ready to be reviewed 2. Test is required for the feat/fix PR, unless you have a good reason 3. Doc is required for the feat PR 4. Use a new commit to resolve review instead of `push -f` 5. Use "request review" to notify the reviewer once you have resolved the review --> - [x] Did you explain what problem does this PR solve? Or what new features have been added? - [x] Have you added corresponding test cases? - [ ] Have you modified the corresponding document? - [x] Is this PR backward compatible? **If it is not backward compatible, please discuss on the [mailing list](https://github.com/apache/apisix-ingress-controller#community) first** -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
