Provide linux-anvil-cuda on x64 with RHEL 8, consolidate image names, distinguish distro baseline in tag

[h-vetinari]

The other two architectures are already on UBI 8

For conda-forge/conda-forge.github.io#1941 / conda-forge/conda-forge-pinning-feedstock#6283

Check out the available tags; the required -devel-{distro} is only available for ppc if we use ubi8, so might as well use that distro for all architectures.

[jakirkham]

Thanks Axel! 🙏

Generally this seems reasonable

In the past when upgrading from CentOS 6 to 7, we added new images that were named linux-anvil-cos7-cuda ( #167 ). Am thinking it would make sense to do the same thing here and add linux-anvil-ubi8-cuda. Effectively this is just one more image (as the others are already on UBI 8)

Thinking this would minimize surprise for users as they would continue to get the same OS versions with the same image names (as they may have come to expect)

Admittedly CentOS 7 support is rolling off ( conda-forge/cuda-feedstock#28 ). So we may end up dropping the old image at that time

[h-vetinari]

Thanks for the review!

In the past when upgrading from CentOS 6 to 7, we added new images that were named linux-anvil-cos7-cuda ( #167 ). Am thinking it would make sense to do the same thing here and add linux-anvil-ubi8-cuda.

For the alma and CUDA images, we've been moving to image tags per distro version, which I think is more elegant. I don't want to go back to including the distro in the image name (I don't mind putting it in tag though, if we really want to keep a cos7 variant selectable).

Thinking this would minimize surprise for users as they would continue to get the same OS versions with the same image names (as they may have come to expect)

I was surprised to see that the image version (and distro) did not align for the cuda images between x64 resp. aarch/ppc, so I don't think there are many expectations of that sort (as the current situation is already inconsistent/confusing, and the image version doesn't matter in any practical sense since everything is based on the sysroot version). So I consider this a negligible risk, especially as all our infra will soon move to RHEL8-based images anyway.

PS. We've been waiting for ~2 weeks for a response from you in #287, please have a look at that PR as well. 🙏

[h-vetinari]

@jakirkham, if you'd like to make the distro-version selectable for the CUDA 11.8 images, I have a proposal for how this could look like in #293; if we decide not to encode the distro version (which is completely fine IMO, as it's effectively irrelevant, c.f. conda-forge/conda-forge-pinning-feedstock#6283), then this PR is ready.

[h-vetinari]

This now incorporates the discussion from #293, in particular, the move of the distroname into the tag, in order to support choosing this where necessary (e.g. for feedstocks that do binary repackaging).

[jakirkham]

Thanks Axel! 🙏

Just to clarify, the last comment is referring to issue ( #293 )?

[h-vetinari]

Just to clarify, the last comment is referring to issue ( #293 )?

Yes, I messed up the xref, sorry. I meant this comment

[h-vetinari]

More specifically, the CUDA 11.8 portion of that comment. For the rest of the renames, my intention was to first progress on conda-forge/conda-forge-pinning-feedstock#6626. I guess we could also do everything in one go, which would mean picking the additions from conda-forge/conda-forge-pinning-feedstock#6687 into the other PR.

[jakirkham]

All good. Just wanted to make sure I understood

Am happy with either approach

[h-vetinari]

I hadn't pushed 63a890c until today (even though I had prepared it a while ago) - to be clear, it came after your approval even though it's shown chronologically as before.

However, given that the remaining changes strictly follow what was discussed in #293 (and in core), I think this is good to go.

Thanks for the review! 🙏