Qpid support in ManageIQ Community Edition


#1

tl;dr. We’re seriously considering dropping Qpid support in ManageIQ.

Some background first…

How does ManageIQ use Qpid?

ManageIQ uses Qpid when connecting to OpenStack’s AMQP bus. This allows ManageIQ to grab events off the AMQP event stream and respond to actions taken outside of the ManageIQ web application that affect OpenStack.

Can we still get OpenStack Events without Qpid?

Yes. In fact, most upstream OpenStack implementations use RabbitMQ instead of Qpid for their AMQP bus. ManageIQ will still fully support RabbitMQ for AMQP integration with OpenStack.

Why do you want to abandon Qpid?

It’s a long story. But, it boils down to a few key points:

  1. The qpid_messaging rubygem that we use depends on files provided by the qpid-cpp-client-devel package in CentOS.
  2. For reasons outside our control, CentOS6 (which is based on RHEL6) does not ship qpid-cpp-client-devel, but it does ship qpid-cpp-client.
  3. Since CentOS6 contains Qpid packages in the base distribution, Qpid packages cannot live in EPEL.

Because of these three points, our nightly build process is at least an order of magnitude more complex than it should be. We’ve reached out to the Qpid team directly, and they’re basically facing the same problem we are for EL6 derivatives.

What about with EL7?

Qpid is no longer in the base OS for EL7 derivatives. This means that Qpid packages could live in EPEL and enjoy all the benefits from that. However, I don’t believe our release process is ready to adopt EL7 just yet. But, we’ll keep that in our back pocket.

What does this mean for me?

If you have a strong dependency on Qpid with ManageIQ Community Edition, then we want to hear from you (respond directly to this post). To be honest, in most cases we’re likely going to ask if you can switch to RabbitMQ for AMQP support in OpenStack. If there is enough opposition to removing Qpid from ManageIQ, then we’ll take a closer look at our approach here. At this point, we don’t know how to quantify “enough opposition”. But, honestly it will have to be pretty monumental to justify the extra work involved in the nightly build process.

When is Qpid support being removed from ManageIQ?

We don’t have a strict timeline yet. But, if we don’t hear a great deal of opposition to this, then it will probably be soon. I’ll let @jrafanie fill in details there.

We sincerely hope this doesn’t affect anyone. But, if it does, please add comments to this post so we know you’re out there.

Thanks!


#2

As @blomquisg stated, this is coming very soon. We are already testing against ruby 2.0.0 on master and building internal nightly build appliances utilizing ruby 2.0.0. Because we are upgrading ruby, we need to rebuild the qpid_messaging gem as part of the appliance build and this is not easy since the required qpid-cpp-client-devel package is not readily available.

It might be be possible we can package this ourselves but it’s an unknown amount of ongoing maintenance work with possibly very little benefit. If there isn’t a great need for qpid support and some assistance to package it, it’s probably better to focus our efforts on more important features.


#3

Apparently, this was in CentOS: http://vault.centos.org/6.3/updates/x86_64/Packages/qpid-cpp-client-devel-0.14-22.el6_3.x86_64.rpm and it was removed from CentOS because it was removed from RHEL. Is this the correct version of the pkg you need?


#4

@jasonbrooks Yes, that appears to be correct. As long as it’s compatible with the one that centos is currently shipping. I believe we are most concerned with the client and client-ssl component:
http://mirror.centos.org/centos/6/os/x86_64/Packages/qpid-cpp-client-ssl-0.14-22.el6_3.x86_64.rpm
http://mirror.centos.org/centos/6/os/x86_64/Packages/qpid-cpp-client-0.14-22.el6_3.x86_64.rpm