What happened

In #102354 (comment) @aojea brought up the fact that to get Service IPs we currently need to make an API call, i suppose that is suboptimal .

in a nutshell...

• We CREATE services in one place, and this returns the Service IP that we dont use at that time.

                          // kubemanager.go initializeCluster()
			createdPods = append(createdPods, kubePod)
			svc, err := k.createService(pod.Service())
			if err != nil {
				return err
			}

(model.go)

• We READ service IPs in another place, and we waste a query to apiserver for the data we just got above, and threw away.

                         // network_policy.go getK8sModelWithServiceIPs()
			service := pod.Service()
			kubeService, err := f.ClientSet.CoreV1().Services(pod.Namespace).Get(context.TODO(), service.Name, metav1.GetOptions{})
			if err != nil {

So we should in an ideal way, find a way to cache the data we get for free in the first bullet, with the function that reads the service data, in the second bullet.

basically any solution that makes this easier to deal with is probably a small win for us, so , good first issue to hack on :)

details

This is because we create the model using a function (rather then caching it somehow).

The functional approach imo is nice bc the model offers no gaurantees, so, we can call it as much as we want and have less state to carry over.

However, i think maybe at some point it would be faster to cache this data, and not call Spec.ClusterIP for ever pod on every test.

Fix

This is a good first issue i think: Take a look at the code path in the netpol suite, and see if you can get it to pass by extending the model class somehow, so that when we converge getK8SModel() and getK8sModelWithServiceIPs(), into a single call to getting the Model, which uses a cached model, that is capable of creating itself somehow, that way, once the model exists, it can be reused.

I think to merge this since we're adding state carry over,it would be interesting to measure wether the tests run any faster afterwards.

I dont have any strong opinions here, but thought i'd follow this as a follow on to #102354