cilium: test encryption workflows for GKE

[jrfastab]

Test work flows with encryption and GKE.

This adds an additional run of cilium test connectivity to the gke workflow, but this time with encryption enabled. After this commit the workflow is the following.

cilium install ...
cilium hubble enable
kubectl port-forward ...
cilium connectivity test
cilium uninstall
cilium install --encryption ...
cilium hubble enable
kubectl port-forward
kubectl delete pod  ... // delete cilium-test pods
cilium connectivity test

above omits a few --wait ops and the cluster setup for clarity. For now I manually delete the pods to work-around issue, cilium/cilium-cli#156, where the uninstall does not delete cilium-test pods and the --restart-pods on install does not restart them.

I've done multiple runs of the workflow and most passed. I observed two errors that seem unrelated to this PR. First sometimes the cleanup fails with,

Error: We are currently unable to download the log. Please try again later.

And then once the initial (without encryption) connectivity test failed the pod->world test. It seems like a flake.

[jrfastab]

Looks like its working... succeeded 2 minutes ago in 12m 20s

[jrfastab]

This is consistently passing the tests portion, but I see an occasional,

Error: We are currently unable to download the log. Please try again later.

from the cleanup step. Is this a known issue?

[nbusseneau]

This is consistently passing the tests portion, but I see an occasional,

Error: We are currently unable to download the log. Please try again later.

from the cleanup step. Is this a known issue?

I have seen that sometimes, but not much. I wonder if it's a GH related issue (i.e. not being able to retrieve workflow logs from the underlying machines for some reason, and we can't do anything about it), or if it's just that we hit the timeout-minutes specified for the job, which might explain why you have seen much more than I did (since you increased the running time).

Perhaps we ought to bump it to 20 or 25?

Actually, this also begs the question: do we want to split workflows so as not to test encryption when unnecessary, keeping the testing lean and fast?

[jrfastab]

It might be useful to split workflows so we can test one without the other.

[jrfastab]

@aanm wdyt split this into its own workflow or keep them together?

[aanm]

@jrfastab I think we should keep the encryption in the same workflow. Are the encryption tests taking that much time? It is preferable to test all things than test a couple things and then things end up breaking.

@nbusseneau what's the downside of enabling the workflow by default on all PRs with the test-me-please?

[jrfastab]

@aanm works for me. This is probably ready to go and deciding how/where to enable this can happen as a follow up?

[aanm]

@aanm works for me. This is probably ready to go and deciding how/where to enable this can happen as a follow up?

correct

[nbusseneau]

@nbusseneau what's the downside of enabling the workflow by default on all PRs with the test-me-please?

For potential external readers: discussed in community meeting => we are going to trigger the workflows with test-me-please on top of the existing Jenkins jobs.

@aanm works for me. This is probably ready to go and deciding how/where to enable this can happen as a follow up?

Do you think we should increase timeout from 20 to 25, as per proposed above?

[jrfastab]

I don't think there is any reason to run all tests for a workflow change.