Adding OpenSUSE support for AdoptOpenJDK

[james-crowley]

This PR will add support for two OpenSUSE based containers, Tumbleweed and Leap.

Currently, Leap lacks support for s390x but should be address soon. See #388 (comment).

This will fix #388.

Additionally, adding support for OpenSUSE based images will help improve AdoptOpenJDKs test coverage. Currently, the Docker pipeline in openjdk-tests lacks any testing for OpenSUSE images.

[james-crowley]

Also note there is no slim images. I removed generation for slim variants because the needed packages are not currently in OpenSUSE. Nor does our slim script support zypper based installs.

[aahlenst]

What is the impact on resource usage (machine time, people needing to triage tests)? If that is substantial, TSC approval might be necessary.

[james-crowley]

@aahlenst I am not sure on exact impact. The new distro will need to be added to the Docker pipeline which @smlambert and @llxia manage. I can help with adding support for the new distros as I have done it before.

A problem that already exist is the lack of resources to fully outright test all the images and variants in a timely fashion. I been working on helping complete the pipeline outlined in adoptium/aqa-tests#1843 and #228.

When the scanner tool runs, there are usually a good deal of images (~500) that are deemed needed to be tested. While 500 images might not seem like a crazy amount when you break it down, we need to test for each architecture. So, 500 images become 500 tests for each architecture, roughly ~2,500. This number only gets more problematic when you talk about architectures with limited machines like s390x or aarch64.

I don’t think adding openSUSE support is anything special when compared to adding any other distro. It is currently an area where we are lacking in testing. We have plenty of Debian/Ubuntu distros being tested, but lack openSUSE. The lack of openSUSE can lead to missing issues only present on certain distros (missing certain lib packages for acceleration, issues with JIT performance, etc.) There have been a couple issues related to certain distros and I do not want openSUSE to slip through the cracks.

[aahlenst]

I support adding OpenSUSE.

Because I'm not familiar enough with OpenSUSE: Is Tumbleweed popular enough (if that's the right word) to deserve separate images? I consider it as some sort of development version like Debian Sid.

[dinogun]

@james-crowley Our current policy has been to support only one variant of the distro (The exception being windows but since we are not producing those images, it doesnt have any additional impact for us). Based on this I have the same question as @aahlenst, any reason why we have to support both Tumbleweed and Leap. Do you know of projects that use Tumbleweed, esp public projects that make use of this will certainly help. Thanks !

[james-crowley]

@aahlenst Tumbleweed is openSUSE’s rolling release. Tumbleweed could be compared to Fedora’s releases, mostly cutting edged stuff.

Leap is more stable and has a solid end of life/LTS support.

@dinogun Ideally, I would just want support for Leap but as mentioned in this comment, #388 (comment), Leap support for s390x is still in the works.

For testing purposes, I need an openSUSE release that supports s390x. There have been some issues/bugs brought to our attention dealing with AdoptOpenJDK and system libraries on certain distros. Hence, I want images produced so I can go add the test case over in the openjdk-tests repo.

Tumbleweed support would only be needed until an s390x release comes out for Leap. After that we can drop support. I don’t need openSUSE support in the official images for now. This would only be for producing images for test purposes.

[dinogun]

lgtm

[aahlenst]

FYI: We had a discussion about this during today's TSC call. The plan is to review our entire lineup of container images and to reduce or expand where appropriate.

My personal take: If support for SUSE should be improved, there are probably better ways than using OpenSUSE container images, especially on architectures like PPC or s390x that are usually used by companies with support contracts. Therefore, SLES would likely be more appropriate.