policy: Add e2e egress tests

[zaharidichev]

This change adds e2e EgressNetwork tests that exercise:

• default policy
• explicit allows via route types
• routing of egress traffic to in-cluster services via backend refs

Signed-off-by: Zahari Dichev [email protected]

[adleong]

Would it make sense to await for the egressnetwork to become accepted before attempting to send traffic?

[zaharidichev]

Yes this makes sense. We should do that.

[adleong]

is there a potential race condition where we send this traffic before the policy control picks up the update to the egressnetwork? is there something we can await on to wait until we know the policy control has picked up the update? or should we just retry the curl so that if the update hasn't been picked up yet we can try again?

[zaharidichev]

Good call, we can await on a condition here just to make sure the update is reflected in the kuberntes API. When it comes to making sure the policy controller has picked up the update, I am not sure what exactly we can do here.

Retrying the curl request feels like an overkill to me.

[olix0r]

Should this also include something like

egress_net
    .status
    .conditions
    .iter()
    .any(|c| c.type_ == "Accepted" && c.status == "True")

to make sure the status controller has consumed it?

I notice there are some other places in tests, though, where we don't check statuses fully so maybe that's not necessary? E.g. pub async fn await_grpc_route_status

[zaharidichev]

Good point, I will do one more pass over the tests and see whether there are opportunities to tighten things up in terms of status checking.

[zaharidichev]

I have added code to assert that egress network is accepted after creation or update in d99216a

We can consider tightening up the assertions around route statuses as well as this is done sporadically now. I think however that this is beyond the cope of this PR as it spans most of the outbound API tests, not only the egress ones. It is a good change however.