can CIS or AS3 have an "ignore and continue" behaviour when receiving 422 errors?

[mikeoleary]

Setup Details

CIS Version : 2.19
Build: f5networks/k8s-bigip-ctlr:latest
BIGIP Version: Big IP 17.1.1

Description

Customer reports that when a duplicate IP address and port are accidentally configured in CRD's in K8s, the resulting 422 response from BIG-IP to CIS causes all new changes in K8s to fail to be processed by CIS.

Customer admits that creating 2x CRD's with the same IP:port is a mistake on their end, but these are mistakes from other teams that the F5 admin cannot control.

Is there a way for CIS to ignore CRD's that cause duplicate IP:port, or ignore the 422 response from BIG-IP, and continue processing remaining changes?

This is a problem for multiple customers: One mistake in a CRD causes CIS to effectively stop communicating changes to BIG-IP until it is fixed, but usually discovery of this mistake is difficult and many hours/days after it happens.

Basically, can CIS or AS3 have an "ignore and continue" behaviour?

Steps To Reproduce

1. Create TransportServer with CRD with specific IP:port combination
2. Let CIS create VS on BIG-IP
3. Create another TS CRD with same IP:port combo.
4. CIS will receive error from BIG-IP due to duplicate IP:port combo and stop processing any new changes to K8s objects.

Expected Result

CIS could ignore errors caused by duplicate IP:ports on BIG-IP and continue to process new changes.

Actual Result

CIS re-sends declaration, continuously receving 422 errors.

Diagnostic Information

<Configuration files, error messages, logs>
Note: Sanitize the data. For example, be mindful of IPs, ports, application names and URLs
Note: The following F5 article outlines the information required when opening an issue.
https://support.f5.com/csp/article/K60974137

Observations (if any)

[avinashchundu9]

Yes, I agree. We also encounter the same issue where users make configuration errors, leading CIS to repeatedly push configurations with error 442. This results in unnecessary resource consumption on both CIS and F5, and subsequent changes continue to fail until the issue is resolved. Unfortunately, no errors are reported as status in Kubernetes, leaving the user unaware of the problem and the need for correction.
To address this, when such issues occur, CIS should post a status error in Kubernetes for the affected resource and ignore that resource until it is fixed or updated.

[trinaths]

Created [CONTCNTR-5241] for internal tracking.