Add ubi10 CI images

[Jakuje]

SUMMARY

It looks like the crb in ubi10 does not have python3-cython which prevents adding this version. Some WIP branch where I tried to add the rest of the stuff is here:

https://github.com/Jakuje/pylibssh/tree/ubi10

ISSUE TYPE

• CI/CD

[webknjaz]

Some WIP branch

Feel free to keep it as a draft PR for visibility..

[webknjaz]

Thinking of dropping UBI9. Having doubts whether it's really needed in CI...

[Jakuje]

Thinking of dropping UBI9. Having doubts whether it's really needed in CI...

There are some inconsistencies in older rhel versions of libssh so in that regard, I kind of find it useful to be able to run the tests with the old libssh.

Though, centos stream following the latest Y stream should do good enough for 90% cases

[webknjaz]

It's just a bit annoying to run old systems. E.g., I'd like to apply a0c63d8, for example but it currently breaks on F42 and all of UBI. Originally, I've been trying to add as many things into the CI matrix as possible, which has proven to be quite tiring. This was my personal kink and was never a documented goal, though.

I suppose, we could address this by bringing back some of the complexity I removed in a6afd83#diff-964dcb02b155ba5a5eda105064bca49bdb7bc21547b6c9b5d559ce284488ae35L45.
Would that be alright with you?

Is the old libssh the only reason for having these in your opinion? I've been meaning to look into the possibility of feeding an arbitrary libssh headers path into the build backend, which would allow us to have more flexibility in terms of sourcing the underlying lib and we could cover it in some other way. Besides, do we need to run multiple runtimes/Pythons with the old libssh if we just want to check for the API compatibility mainly? Also, in that case, we could define the oldest supported libssh in the docs/infra rather than having something undefined that happens to run.

I think it'd be good to document what we're willing to support vs. what are the non-goals too.

[Jakuje]

I think that would be up to a discussion with the Ansible team what Python, RHEL and libssh versions they care about. But I agree that it would be a good thing to have it formalized.

My understanding of including the ubi images was to make sure it builds and runs correctly against all the OS dependencies. If you include the above change a0c63d8, are we going to be able to build the rpm package in RHELs?

If it would be addressed by the complexity, I am not excited to see more complexity, but if it would make it working and allow some less complexity elsewhere, I think its ok. I really do not have much python packaging experience though.

[webknjaz]

a discussion with the Ansible team

This is a bit too generic. Multiple people assign different meanings to "Ansible". For me, as a part of the Ansible Core Team, it's ansible/ansible (aka ansible-core on PyPI). For some, it's the Ansible Community (all the collections and stuff around). For others, it's somehow AAP for whatever reason.
Did you mean the Ansible Networking Team in this case?

My understanding of including the ubi images was to make sure it builds and runs correctly against all the OS dependencies. If you include the above change a0c63d8, are we going to be able to build the rpm package in RHELs?

Well, that spec file was due to me wanting to explore what the RPM packaging world looks like. And so I added #205 initially, and then, when I learned of Packit, I came up with #227 having asked for some help from Tomáš.

As a result, I've got a bunch of sdists from PyPI bundled in SRPMs as it was not really possible to get the deps necessary from the distro repos. IIRC, it was mostly fine w/ Fedora but anything with older software turned out to be unusable even more. Requesting things to be added to the repos available in UBI was being rejected.

So that's the story behind either getting the deps from EPEL and similar or PyPI. And downstreams don't use our spec file anyway, AFAIK. I thought that it might've been cool to have Packit publish things to COPR or offer updates to downstreams but never got to fully integrating that.

This is definitely painful to maintain upstream but the amount of complexity that needs to be brought back should be smaller than what a0c63d8 got rid of — the only blocker is setuptools being too ancient and it doesn't have any deps so if we just get its sdist from PyPI, that should be enough and all those other source entries shouldn't be needed. Now that I think about it, recovering about two lines out of that doesn't seem too bad, I suppose.

[Jakuje]

Probably yes, ansible networking team or the team that is doing the downstream packaging and making sure this works in RHEL, however they do that. What spec file is used downstream? Is it something that could be reused so we prevent surprises for the downstream packaging?

If this is not a concern for a downstream, changing just tor run against latest fedora with updated dependencies sounds to me like an ok solution from upstream perspective, especially when maintaining some compatibility with older Fedoras and ELs is that complex due to having outdated dependencies.

Fedora 42 is going to be EOL soon so that should not be an issue.

[webknjaz]

No idea what downstream uses but I'd probably not use their thing because it might rely on RPMs unavailable upstream + the way we integrate with Packit is probably more coherent, anyway.