Issues with qpid-proton due to 0.35.0 release in EPEL

Development
1

This affects all released versions of Katello.

A new version of qpid-proton was released to EPEL 7. This required us to get a release of the qpid_proton gem at version 0.35.0 and then build tfm-rubygem-qpid_proton across all applicable Katello’s and release it.

However, there seems to be a bigger issue this time around:

Error: Package: python-qpid-proton-0.14.0-2.el7.x86_64 (extras)
           Requires: qpid-proton-c(x86-64) = 0.14.0-2.el7
           Installed: qpid-proton-c-0.35.0-1.el7.x86_64 (@epel)
               qpid-proton-c(x86-64) = 0.35.0-1.el7
           Available: qpid-proton-c-0.14.0-2.el7.x86_64 (extras)
               qpid-proton-c(x86-64) = 0.14.0-2.el7
Error: Package: python-qpid-proton-0.14.0-2.el7.x86_64 (extras)
           Requires: libqpid-proton.so.8()(64bit)
           Available: qpid-proton-c-0.14.0-2.el7.x86_64 (extras)
               libqpid-proton.so.8()(64bit)
           Installed: qpid-proton-c-0.35.0-1.el7.x86_64 (@epel)
              ~libqpid-proton.so.11()(64bit)

My cursory examination is that the previous python-qpid-proton that was available in EPEL was pulled in favor of a Python 3 based version:

https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/p/python36-qpid-proton-0.35.0-1.el7.x86_64.rpm

At this point, I’m not sure what the right approach is:

  • Ask maintainers to publish to EPEL a python2-qpid-proton at the right version
  • Update (I think) gofer on EL7 to use Python 3
  • Build the whole stack ourselves like we do on EL8 and backport this all the places
  • Try to find, build and carry a python 2 version of of qpid-proton at the right version in our repositories
1 Like
2

I’m going to weigh in here, as a user/admin, not as a developer.

I’d suspect that from a long term maintainability perspective that updating gofer to Python 3 is the closest to an ideal solution. It’s probably more work in the short term. Python 2, though, is effectively dead, and efforts probably should be made to leave that environment. I’m not sure that’s it’s reasonable to ask the EPEL folks to maintain a specific package for this, and setting up your own build stack seems like effort that could be better spent elsewhere.

3

I’d start with this.

I also came to the conclusion that gofer is our only consumer of it. We already build it against Python 3 for EL8 so I’d expect it to work on EL7 as well. The only consumer of gofer is katello-host-tools. That only has minimal dependencies. However, it does have a lot of conditionals for various distros and versions.

We have qpid-proton in our repositories (https://github.com/theforeman/foreman-packaging/blob/rpm/develop/packages/katello/qpid-proton/qpid-proton.spec) but it’s at version 0.32.0. Using that on EL7 is probably a good recipe for conflicts. EPEL7 is also present and if they update, they’ll be newer and thus preferred.

My preference is pretty much the order you posted: first try to ask the maintainers for python-qpid-proton. It’d be the safest also for existing installations. If they don’t want to, I’d prefer change our stack to use Python 3.

4

From a user’s perspective, I’d agree that trying to convince EPEL maintainers to keep pulishing python2 versions of the package would be the best solution. We hit this problem last week when trying to update our old stack (Katello 3.15) to a current release. Assuming that we most likely are not the only folks stuck on an old version, fixing this for everyone on the Foreman/Katello side of things would mean that either a lot of old versions would need updating or that only some people get a fix for a problem everyone is facing.
As much as I dislike using EPEL will be actively unsupported on EL8, I am as much looking forward to not having my update procedure broken (again) due to EPEL maintainers deciding to release another breaking change.

On a side note: What are we actually still using gofer and qpid for? As far as I am aware and from what I found in the changelog, Katello’s internal communication has switched from qpid to Artemis with 3.16. Is it only katello-agent that still relies on qpid? If so, katello-agent has been deprecated since 3.15, so maybe this would be a good reason to let go sooner rather than later, since updates in EPEL broke the qpid stack multiple times over the last few years.

5

There is the need to have a solution using pull instead of push in some environments, so removal has to wait until the pull-based provider for REX is ready and then there will be one release offering both options for an easier upgrade, but I am also happy when it is gone! :wink:

2 Likes
6

You are both correct: gofer and qpid are needed for katello-agent. It is indeed also deprecated, but there is no pull replacement. For actively reachable machines (using SSH) it is indeed entirely possible to avoid the issue that is now left. If you need to pull (other than with a cronjob or similar tools) there’s nothing to replace it yet.

1 Like
7

FWIW, I tried to build python2-qpid by reverting the change that dropped, and it seemed to work fine: Index of /evgeni/qpid-proton-0.35

Will talk together with @Justin_Sherrill to the qpid maintainers if they want to re-introduce the package.

1 Like
8

I’ve reached out to the QPID Team, so let’s see.

9

So Python2 is not supported in qpid-proton 0.35 (which I find totally understandable) and thus the build was disabled.
However, the qpid team operates a copr, which contains a 0.34 build that should also work with the 0.35 library. I’m currently running a CentOS7 pipeline with that copr enabled, but purely looking at the package metadata I tend to agree, this should work for us.

Now, waiting on the pipeline, I wonder how we should utilize and communicate this.

For our pipelines to work, it’d be sufficient to add the copr to the katello_repositories role we have, and stuff will turn green again.
But what about users? They’d need to enable that copr on every client system that is still using katello-agent. Is that “good enough” given katello-agent is technically deprecated?

@Justin_Sherrill @Jonathon_Turel et all, please speak up :slight_smile:

2 Likes
10

the pipeline changes are in https://github.com/theforeman/forklift/pull/1412, but seems it’s actually not working.

@Jonathon_Turel is looking into it.

11

It starts working once I do yum downgrade python36-qpid-proton-0.34.0-2.el7.x86_64 qpid-proton-c-0.34.0-2.el7.x86_64 https://yum.theforeman.org/katello/4.1/katello/el7/x86_64/tfm-rubygem-qpid_proton-0.34.0-3.el7.x86_64.rpm, but with 0.35 it seems Katello doesn’t talk to Qpid properly :frowning:

12

progress in https://github.com/Katello/katello/pull/9639

1 Like
13

And a bit of follow up on the python2-qpid side:

  • pipelines should now consume python2-qpid from the copr via https://github.com/theforeman/forklift/pull/1412
  • users consuming the foreman-release-client RPM will get the new repo there: nightly, 3.0, 2.5, 2.4
  • Katello users who mirror the repos locally, will need to include the copr in their content views – is this documented somewhere?

And for qpid_proton 0.35 itself:
Katello in nightly is now compatible with qpid_proton 0.35 via https://github.com/Katello/katello/pull/9639, but I’ve also opened https://github.com/Katello/katello/pull/9642 and https://github.com/Katello/katello/pull/9643 for two better solutions. Once the full path forward has been decided and tested, this will require backports to the supported stable branches.

14

Encountered this issue while updating 4.18, and was able to work around it by excluding the packages with yum update -x qpid-proton-c,qpid-dispatch-router

15

I have just noticed the new repository after updating foreman-client-release on my test client.

I am not using katello-agent anywhere, so it’s my understanding that I don’t need that repository, because qpid is not used. Correct?

And for the katello server itself it’s not necessary, either. Correct?

16

Correct.

17

If we don’t use katello-agent (we use subscription-manager on RHEL), is there a way to just remove the support from the foreman/katello server so qpid is no longer needed?

18

Using foreman-installer --foreman-proxy-enable-katello-agent false should disable it (Feature #32037: Disable katello-agent and infrastructure by default and allow users to enable it on new installs or disable it on upgrades - Installer - Foreman). That was released as part of foreman-installer-katello-2.5.0.

3 Likes
19

Maybe its foreman-installer -S katello --foreman-proxy-content-enable-katello-agent false
This works well, but qpid-proton still can’t uninstall because of dependency on katello and tfm-rubygem-katello package. (Foreman 2.5.3)

2 Likes
20

Hi all,

any news about this issue ?

Thanks

1 Like