No visible python-39-c9s images on quay.io about s2i-python-container HOT 21 CLOSED

Hi @michael131468, thanks for spotting this! This is a leftover from before RHEL9 release, when we only had Centos Stream 9 content available. As the Python 3.9 is now available as an UBI image, it no longer makes sense to maintain Centos Stream 9 images, so the repository (and references to it) will be removed.

Just wondering, is there some use case that the UBI images do not cover for you and the Centos Stream 9 images do?

from s2i-python-container.

Hi @pkubatrh, thanks for replying. I think removing the references make sense. Actually I was just poking my nose through the project and was only curious about the cs9 images. I have no real use case for them.

from s2i-python-container.

Hi @pkubatrh! Would you reconsider this decision?
Because as you mentioned, there are definitely use cases where UBI images don't cover all use cases. For example, installing R on UBI images is not possible, as required libraries are not available in UBI repos or Epel.
I have other use cases, almost all related to fancy data science libraries than we want to brinh to Open Data Hub or OpenShift Data Science.
Up until now I had been maintaining my own builb pipelines to create those c9s images (basically mimicking everything done there), but if I can have them from a more official repo, that would be best.

from s2i-python-container.

Hi @guimou. Thanks for reaching out to us. I think we can discuss this at our meeting next week. Could you please provide some examples of packages that are not available in UBI/Epel but in C9S?

from s2i-python-container.

Hi @frenzymadness ! Sure thing.
I have created two log files from two of the images I'm building to use with Open Data Hub, but instead of starting from c9s, I'm starting from ubi9 (I extracted only the relevant parts/commands).

• One is fairly mainstream, it's just to create an R Kernel/RStudio deployment:
  ubi9-opencv-pytorch.log
  Main missing packages would be: tex, xdg-utils, flexiblas-devel, tcl-devel, tk-devel.
  Btw, the exact same code works perfectly if you start from ubi9 and subscribe to RHEL because all the packages are in RHEL9.
• The other one is definitely more fancy, I would not ask for this to always work. It's a base image with OpenCV and PyTorch built from source using some optimization:
  ubi9-opencv-pytorch.log
  Here the missing packages would be: tbb-devel, libv4l-devel, eigen3-devel, freeglut-devel, mesa-, libGL-devel, boost, boost-thread, boost-devel, gstreamer1-plugins-base-devel, lapack, lapack-devel, lmdb-devel, tesseract-devel
  Again, this second case simply illustrates that UBI images are great to install things, but not that much to be used as compiling platforms. Which raises another question: what to use to compile software that will be later installed on UBI9 (with a docker multistage build)? Compile on RHEL and inject in UBI, or compile on CentOS? I guess the two are equivalent in content, or close enough, but then I don't really know how this works from a Licensing perspective...

from s2i-python-container.

Note that we already had a similar request in the past for centos8 (also R related) #347, which resulted in the request to increase UBI repository content (https://bugzilla.redhat.com/show_bug.cgi?id=1774783) but unfortunately got closed.

@fatherlinux might want to be aware that we got more interest for this.

from s2i-python-container.

Which raises another question: what to use to compile software that will be later installed on UBI9 (with a docker multistage build)? Compile on RHEL and inject in UBI, or compile on CentOS?

Definitely compile on RHEL and inject into UBI. Centos Stream 9 always tracks future RHEL9 minor version, so you might get some incompatibilities if you build on that.

from s2i-python-container.

Thanks a lot for your answer, but I want to make sure about something: if I start from a RHEL base (using my developer free licence for example), install some needed packages, compile my stuff, then inject it on a UBI image, isn't it like going over licensing?
Moreover, even if I compile some of the packages myself, I may still need some supporting libraries that are not in UBI anyway (e.g. lapack).
And I knew about this bugzilla, and already discussed the issue briefly with @fatherlinux when he was in Quebec a few months ago. As he put in the thread, if UBI is still mostly targeted towards "standard" app development, then it's a kind of dead end.
Anyway, only having the c9s-py29 "official" prebuilt images would be enough for ODH/RHODS purposes, and easier than trying to fit in too many fancy things into UBI images.

from s2i-python-container.

I am not a license expert so I would rather not go into licensing discussions as that may backfire quickly. Maybe @fatherlinux would be in a better place to answer that question.

However, what occurred to me is that we recently introduced 3.9-minimal and have also discussed whether we actually want to have it be based on top of UBI or use Centos Stream instead. In this case, since the image is not officially supported by Red Hat in any way (it's not shipped through Red Hat registries, just quay.io) we have more leeway what we can do with it.
So I was wondering, would a 3.9-minimal image based on c9s cover you use cases?

from s2i-python-container.

Definitely! I'd add myself headers, compilers,... only if and when needed.
It's easier than starting from s2i-base and copy/maintain the Python boilerplate.
Plus it makes a better image anyway as I don't get npm or nodejs that I don't need.

from s2i-python-container.

@frenzymadness What do you think about the proposal to move 3.9-minimal to c8s (and introduce for c9s) to cover this case?

from s2i-python-container.

I think we don't have to move it. We can add them. We need more testers for the concept of the minimal images and this looks like a good way to get them 😄 Let me take a look at this.

from s2i-python-container.

Is there any equivalent for ubi-minimal for centos stream? I've found only this repo on quay: https://quay.io/repository/centos/centos?tab=tags But there is no minimal image to build on. Do you know where to raise a question like this?

from s2i-python-container.

Ah right, that might be an issue :/ I expect Josh Boyer would be able to help out or at least point you to the correct people to talk to.

As a workaround until a proper Centos Stream minimal image we could just make a multistage build and create a minimal-like image ourselves, similarly as we do for micro images in httpd and nginx.

from s2i-python-container.

Centos stream 9 minimal images are available on quay.io so I'm proposing Python 3.9 minimal on top of C9S in #579 . If you can help me with testing, that would be great.

from s2i-python-container.

python-39-minimal-c9s and python-39-c9s are available and fresh. Would you have time to test them?

from s2i-python-container.

Thanks a lot @frenzymadness! It will be difficult this week, but I just booked a whole pm next week to test that.
Quick question though: why did you skip Python 3.10 (I see only 3.9 and 3.11)? Many libraries are not yet fully 3.11-compatible, or have been for a few weeks only if not days.

from s2i-python-container.

Python 3.10 is not available in Centos Stream or RHEL. We have a container image based on Fedora with Python 3.10 but that will soon be EOL because it's based on Fedora 36 with EOL date in the middle of May this year.

from s2i-python-container.

And Python 3.9 is the main version in RHEL 9 with full 10 years of support so together with Python 3.6, those are the most important versions for us now.

from s2i-python-container.

Makes total sense. I guess I'll simply follow the same pattern then, stay with 3.9 for a while, then jump to 3.11 when the rest is ready to follow. Thanks!

from s2i-python-container.

So, because we have Python 3.9 and 3.11 available on CS and RHEL, I'm closing this issue now.

from s2i-python-container.