Story (Required)

Background and Approach (Required)

In the 'challenging cases Argo Agent must handle' document (https://docs.google.com/document/d/1NwQaYxmRva8irx_clPTqRu_YQ8MNeFNXSTJoOgv7ZRs/edit?tab=t.0), a set of use cases were identified that cause incorrect behaviour in the Argo Agent, at present.

We aim to fix those as part of GITOPS-5919.

It would be beneficial for us to:

• A) Verify that these have been solved
• B) Verify that we do not regress them.

The best way to do this is to implement E2E tests that reproduce the issue (where possible).

The other story, GITOPS-5921, aims to implement E2E tests for challenging cases A and B.

HOWEVER, this story, GITOPS-5922, aims to investigate whether IT IS POSSIBLE to implement C, D and E.

• C, D and E, are tough to simulate from K8s, because they require the ability to temporarily block network traffic between two pods.

This story is thus an investigate story. How can we programmatically block traffic between two pods? Will NetworkPolicy work?

• "When the set of NetworkPolicies that applies to an existing connection changes - this could happen [due to] a change in NetworkPolicies (...) - it is implementation defined as to whether the change will take effect for that existing connection or not."
• If the K8s versions we test on (presently, microk8s, openshift) use a network implementation that breaks existing connections, then this will work.
• https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-s-impact-on-existing-connections

Another possible option is service mesh, but this feels to heavyweight for what we need, here.

Acceptance Criteria (Mandatory)

• Investigate whether or not it is possible to make changes to the test framework to allow us to temporarily block network traffic between agent and principal.
  • For example, using NetworkPolicy
  • If yes/no, propose solution or data to the team.