Add support for openSUSE Leap 15.6

[nuhakala]

This PR adds support for openSUSE Leap 15.6. It supports both kind and minikube.

• Install required packages in 01 script and add suse specific installation/configuration to ansible.
• Modify the network configurations to support also suse.
• Force ansible python interpreter, for some reason it does not use the correct python interpreter from the venv without explicitly specifying it.
• Add templates for provisioning suse images.
• Add cleanup for suse

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign tuminoid for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[nuhakala]

Minikube runs ironic inside a kubernetes pod, so it requires the ironic endpoint to be present only inside the VM. Ironic runs on the host with kind, so it requires the ironicendpoint interface to be present on the host. Furthermore, keepalived requires that the ironicendpoint interface has at least one IP-address assigned.

Hence we have effectively two different network setups and I separated those into different functions to make it more readable. I also believe that with this configuration we could make kind work also on centos, because the interface creation stuff should not be distro specific.

Another thing is that the kind network configuration is doing more or less the same thing as first half of ubuntu_bridge_network_configuration.sh. Hence it would not require much to also get rid of that script.

One thing is that how do we want to write the configuration? Do we want to explicitly write the configuration for different distros with if clauses or do we want to make the configuration depend on the used kubernetes provider?

tldr: should I refactor the networking setup even further or should I revert it and make some specific case only for suse?

[elfosardo]

/hold
@nuhakala hi! thanks for the effort but I believe adding support for yet another distribution needs to be discussed first, also considering that we don't have CI jobs running on Suse, and we don't have people in the team (AFAIK) that can maintain that

[Rozzii]

/hold @nuhakala hi! thanks for the effort but I believe adding support for yet another distribution needs to be discussed first, also considering that we don't have CI jobs running on Suse, and we don't have people in the team (AFAIK) that can maintain that

Just to reflect on the manpower issue, we are willing to maintain it and integrate it to the CI, work is already ongoing.
We have a need to test with the the community variants of all the 3 large enterprise distro Ubuntu, RHEL, SLES, and we have been thinking that we would share compatibility improvemens with the community, maybe it will come handy for others too.

I 100% agree that we have to discuss this with the community but AFAIK there won't be any negative side effect for the already supported distros and we are not aiming to design any SLES/LEAP specific use cases.

This dev-env support does not come with the requirement to build openSUSE based Ironic images either, we would just like to upstream code to dev-env to allow folks run dev-env on openSUSE.

[kashifest]

/hold @nuhakala hi! thanks for the effort but I believe adding support for yet another distribution needs to be discussed first, also considering that we don't have CI jobs running on Suse, and we don't have people in the team (AFAIK) that can maintain that

I think manpower and maintaining CI jobs wont be an issue as we are willing to maintain it along with other CI jobs as well.

[elfosardo]

my comment comes mainly from observation of the latest year and a half advancement in CI
the work to upgrade CI to current stable versions of ubuntu (ubuntu noble) and CentOS (CentOS Stream 10) is stagnating since a while, despite having full support in metal3-dev-env, so I don't see how we will be able to maintain also a third distribution
but again, we need to discuss this first, better if in a meeting

[kashifest]

my comment comes mainly from observation of the latest year and a half advancement in CI the work to upgrade CI to current stable versions of ubuntu (ubuntu noble) and CentOS (CentOS Stream 10) is stagnating since a while, despite having full support in metal3-dev-env, so I don't see how we will be able to maintain also a third distribution but again, we need to discuss this first, better if in a meeting

I think this is pretty orthogonal to the Ubuntu or CentOS work, but sure lets discuss in the upcoming community meeting so that we are on the same page.