Configurable kubernetes namespace

[gdankov]

Maybe it would be better to mock all used k8s APIs and verify our interactions with them instead of relying on minikube? I am not sure how reliable minikube is — for example on this line i have to wait a second before getting all jobs, because jobs are not deleted immediately. One second sleep works on my minikube installation, but will it work on others as well? It would be easier to just verify the interaction.
This will also allow us to test all error conditions that are not currently covered.

Also, as a side note, maybe DeleteJob should be renamed to either Delete or DeleteTask because Job is a k8s abstraction, but Desirer interface works with Diego abstractions.

What do you think?

[herrjulz]

@gdankov I agree with mocking the used k8s APIs. That way we wouldn't rely on a minikube installation. The only thing i can consider right now with mocking the API is: what happens if the kube API changes? We could say our pipeline would fail in that case, which is fine I think.

Regarding DeleteJob: that was just a temp function I wrote to avoid polluting my minikube with stale jobs. However, we will need such a function as even if a (job) pod runs to completion the job stays around in Kubernetes and it's up to the user to delete unused jobs. And I think that is a Kube-Specific thing. I would expect that a successful job disappears after completion. So probably we will need to delete job always after completion and we will need something like a callback from recipe which tells eirini to delete the job (or we could poll) when successfully completed.

But, yes we will also need an issue for OPI. Something like "extend the OPI interface with 'updateDesiredTask' or/and 'deleteDesiredTask'".