SPK Fixes and Known Issues

This list highlights fixes and known issues for this SPK release.

SPK Release Information

Version: 1.7.13
Build: 1.7.13

Note: This content is current as of the software release date
Updates to bug information occur periodically. For the most up-to-date bug data, see Bug Tracker.


Cumulative fixes from SPK v1.7.13 that are included in this release
Known Issues in SPK v1.7.13

SPK Fixes

ID Number	Severity	Links to More Info	Description
1754669-1	2-Critical		F5SPKIngressHTTP2 configuration not applied to new F5-TMM pods during scale-up with ICNI 2.0
1772741-1	3-Major		TMM does not respect the client's advertised maximum DNS UDP message size

Cumulative fix details for SPK v1.7.13 that are included in this release

1754669-1 : F5SPKIngressHTTP2 configuration not applied to new F5-TMM pods during scale-up with ICNI 2.0

Component: SPK

Symptoms:
F5SPKIngressHTTP2 configuration may be excessively delayed or not sent to new f5-tmm pods during scale-up when ICNI 2.0 is enabled in the Helm overrides during SPK installation. As a result, the performance of ingressing HTTP2 traffic may not improve as expected when f5-tmm pods are scaled up.

Conditions:
- A Kubernetes environment with ICNI 2.0 (e.g., Red Hat OpenShift)
- ICNI 2.0 is enabled in the Helm overrides during SPK installation
- An instance of an F5SPKIngressHTTP2 custom resource is applied to a watched namespace.
- The f5-tmm pods are scaled up after the F5SPKIngressHTTP2 custom resource is applied

Impact:
HTTP2 traffic flows only through f5-tmm pods that were present at the time of custom resource was created, potentially preventing the system from achieving maximum performance.

Workaround:
Workaround Options:

1.Delete and Reapply the F5SPKIngressHTTP2 Custom Resource:
After scaling the f5-tmm pods, delete and reapply the F5SPKIngressHTTP2 custom resource. Ensure you wait at least 20 seconds or the duration of the configured `annotationDelay` (set in the Helm overrides), whichever is greater, before reapplying. Note: This option will interrupt ingress HTTP2 traffic.

2.Delete the F5Ingress Pod:
After the scaled f5-tmm pods are running, delete the F5Ingress pod. This action should not impact ingress HTTP2 traffic.

3.Edit and Reapply the F5SPKIngressHTTP2 Custom Resource:
Make a minor edit to the F5SPKIngressHTTP2 custom resource and reapply it after waiting at least 20 seconds or the configured annotationDelay. This option should not affect ingress HTTP2 traffic.

Fix:
F5SPKIngressHTTP2 configuration is now applied to scaled-up f5-tmm pods with minimal delay.

Summary of Code Level Change:
Updated f5ingress controller to get internal vlan map directly from the device mapping.

---

1772741-1 : TMM does not respect the client's advertised maximum DNS UDP message size.

Component: SPK

Symptoms:
The TMM does not respect the client's advertised maximum DNS UDP message size and may respond with DNS messages exceeding this maximum.

Conditions:
DNS requests are sent over UDP to a virtual configured by the F5SPKEgress CR.

Impact:
The larger than expected DNS response may be dropped either in the network or by the client. The client may fail to retry the query using TCP.

Workaround:
None.

Fix:
The TMM properly truncates DNS responses larger than the client's advertised maximum DNS UDP message size.

Summary of Code Level Change:
The UDP profile property's internal name was inconsistently renamed when migrating from classic BigIP to SPK.

---

Known Issues in SPK v1.7.13


SPK Issues

ID Number	Severity	Links to More Info	Description
1785989-1	2-Critical	BT1785989	Ingress traffic fails when the 'watchNamespace' is deleted and recreated with the apps
1789369-1	2-Critical	BT1785989	F5SPKIngressHTTP2 traffic may not pass after the F5SPKIngressHTTP2 CR is deleted and reapplied
1780257-1	3-Major		Open Telemetry (OTEL) does not receive the f5ingress stats immediately after an f5ingress restart.
1730993-2	3-Major		F5SPKIngressTCP custom resource status remains unchanged when referenced VLAN custom resource is deleted

Known Issue details for SPK v1.7.13

1780257-1 : Open Telemetry (OTEL) does not receive the f5ingress stats immediately after an f5ingress restart.

Component: SPK

Symptoms:
OTEL does not receive f5ingress stats immediately after an f5ingress restart. There is a delay of approximately 26 seconds to 1 minute before the stats appear in the OTEL logs.

Conditions:
1. Install the f5ingress pod with stats_collector (OTEL) enabled.
2. Restart the f5ingress pod.
3. Check the OTEL logs for the stats.

Impact:
There is a delay in statistics being sent to the OTEL collector.

Workaround:
None

---

1789369 : F5SPKIngressHTTP2 traffic may not pass after the F5SPKIngressHTTP2 CR is deleted and reapplied

Component: SPK

Symptoms:
When an instance of the F5SPKIngressHTTP2 CR is deleted and re-applied, followed by a scale-up event of the f5-tmm deployment, traffic to the pods associated with the F5SPKIngressHTTP2 CR may not pass.

Conditions:
- SPK is installed with an instance of F5SPKIngressHTTP2.
- The F5SPKIngressHTTP2 CR is deleted and re-applied.
- The f5-tmm deployment is scaled up after reapplying the F5SPKIngressHTTP2 CR.

Impact:
Traffic configured in the F5SPKIngressHTTP2 CR does not pass.

Workaround:
There are two possible alternatives to resolve this issue:

1. Scale the f5ingress deployment to 0 and back to 1 after deleting and re-applying an F5SPKIngressHTTP2 CR.
2. When deleting an F5SPKIngressHTTP2 CR, re-apply the CR with a different name each time.

---

1730993-2 : F5SPKIngressTCP custom resource status remains unchanged when referenced VLAN custom resource is deleted

Component: SPK

Symptoms:
F5SPKIngressTCP custom resource does not change its status to 'WAITING' when the referenced VLAN custom resource is deleted.

Conditions:
When you configure the F5SPKIngressTCP custom resource with one or more VLANs and their corresponding VLAN custom resources, the status of the F5SPKIngressTCP custom resource should change to "WAITING" if:

1. Any of the specified VLAN custom resources are missing.
2. Any of the VLAN custom resources that were initially set up are later removed.

However, in the second scenario, the status remains incorrectly reflected as "SUCCESS" instead of switching to "WAITING."

Impact:
You do not receive appropriate feedback regarding the missing child custom resource; however, there is no traffic disruption once the VLAN custom resource is restored

Workaround:
None

Fix:
The status of the F5SPKIngressTCP CR must be updated to reflect changes in the statuses of its referenced CRs.

---

1785989-1 : Ingress traffic fails when the 'watchNamespace' is deleted and recreated with the apps

Links to More Info: BT1785989

Component: SPK

Symptoms:
When a namespace from the 'watchNamespace' list is deleted and then recreated with the same application pods running, ingress traffic fails. The Controller does not remove the "k8s.ovn.org/routing-namespaces" annotations from the TMM pods when the namespace is deleted, nor does it add the annotation when the namespace is recreated. As a result, OVN routes between the application pods and TMM pods are not recreated, because no changes are detected in the TMM pod annotations.

Conditions:
Delete a namespace from the 'watchNamespace' list and recreate it. After recreating the namespace, deploy the same application pods.

Impact:
Ingress traffic fails and does not work even after recreating the namespace and deploying applications in it.

Workaround:
Scale down the TMM replicas to 0 and then scale them back up.