Unexpected failures were triaged and reran. All but autoscaling tests passed.
As mentioned by Tommie McAfee , we need to exclude the custom metric deployment from STRICT mode, this was done by creating a new PeerAuthentication Rule:
apiVersion: "security.istio.io/v1beta1"
|
kind: "PeerAuthentication"
|
metadata:
|
name: "peer-authentication-custom-metrics"
|
namespace: "istio-system"
|
spec:
|
selector:
|
matchLabels:
|
app: "custom-metrics-apiserver"
|
mtls:
|
mode: PERMISSIVE
|
This created the rule however the tests did not pass with STRICT mode applied to other workloads.
Status of the pods:
Prateeks-MacBook-Pro:Downloads prateekkumar$ kubectl get pods -n test-t5mqp
|
NAME READY STATUS RESTARTS AGE
|
couchbase-operator-6d8f5d7445-grzm6 2/2 Running 1 81s
|
custom-metrics-apiserver-59fb9797c4-7x9m9 2/2 Running 2 28s
|
test-couchbase-6brcx-0000 2/2 Running 0 45s
|
Logs have been shared with Tommie, and once he confirms that the metric deployment is not running with STRICT mode, we will investigate further.
Upon completion of this exercise, QE will sign off on ISTIO STRICT testing with 2.2.1-117 build.
P.S. : The categories of failures which are expected over mTLS STRICT : XDCR, Sync Gateway Remote, Backup TLS and TLS
We should see failures as there is an Istio issue - I would expect us to see them in the resize test cases. If we are not we need to expand our testing until it is picking up these failures.
Separately we may see failures in a subset of tests due to the Istio configuration, e.g. remote XDCR, sync gateway and SDK tests. These are not actual issues but will require cluster configuration or skipping on Istio.