Use minikube in Ubuntu based tests

[kashifest]

Recently we have seen that CentOS E2Es are failing in different tests since the CI infra shift. In contrast, ubuntu e2es are rather stable. CentOS failures are mostly causing problems and main branch PRs which are left hanging for unrelated issues. There are few steps which we can perform the phase out CentOS tests for the time being:

• Use minikube in Ubuntu to make sure ironic is deployed as k8s deployment instead of local containers as it is now. This is the fundamental difference currently between Ubuntu and CentOS tests - Make minikube the default ephemeral cluster #1404
• Phase out CentOS tests as required from prow in project-infra repo as well github branch protection settings.
• Bring back CentOS (if deemed necessary) once the CI infra has better hardware and tests are not flaky. CentOS periodics which are not being phased out can signal this.

[kashifest]

/triage accepted

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[Rozzii]

/remove-lifecycle stale

[Rozzii]

@Sunnatillo @kashifest my memory is fogy about this wasn't there more progress on this one?

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[dtantsur]

/remove-lifecycle stale

Starting Ironic locally will not be compatible with ironic-standalone-operator (unless metal3-io/ironic-standalone-operator#86 is done), so I highly vote for using minikube on Ubuntu as well.

[tuminoid]

I guess the only argument keeping it off minikube is to simulate cases where Ironic is not installed in k8s, which has sometimes revealed some assumptions. This is of course not IRSO compatible, and it does not need to be. I agree with the maintenance burden though, so it should be considered if its worth it or not for the sake of testing.

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[tuminoid]

/remove-lifecycle stale

[Rozzii]

The future of this Issue is unclear to me, we started moving to minikube but then now we have started moving to kind because of some minikube issues.

@lentzi90 could you please comment about the current situation? WDYT about the future of this ticket?

[lentzi90]

In BMO e2e we have switched to kind because of issues with minikube. I'm not sure what the situation is for metal3-dev-env. Are there frequent test failures due to this?

If I recall correctly, the main idea here was to focus on running ironic in k8s (instead of in a separate container directly on the host). We had issues with CI infra and wanted to make sure that this common scenario was well tested. I think things are much more stable now so it may not be as important now.

We can still migrate the ubuntu tests to minikube to make the tests more similar. However, we would then not test the scripts for running ironic locally on the host. I think it is important that we still test them as long as we want to support that way of running Ironic.

[kashifest]

I think @lentzi90 has nicely summed it up, yes it is still relevant for dev-env tests and we decided to run a few periodics to run kind and then all tests default to minikube. It is still in my todo list. Sorry for not managing time to focus on it. Will work it soonish.