I think that would apply if there was actually code being written, but it sounds like this would be a drop in, if Pulsar is able to use an AMQP compatibility plugin and essentially act as though it was RMQ. I’m curious to see if that works as expected.
If not, then I agree it is a very complex thing to build a new messaging interface, and that is why I had previously expressed caution to our team when it was brought up as an option. I’m only cautiously optimistic now that someone else has broached the subject, and we do have at least some interest still in assisting. I’d just like to see if the “free” approach will bear fruit before starting down that treacherous path. 😅
First off I will note that we've had very bad luck in the past with
non-rabbit drivers getting traction either with developers or operators.
Most of them have bit-rotted and been removed at this point.
That said, we do have a list of requirements for oslo.messaging drivers
in the documentation:
https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html
We realize those are non-trivial to achieve for a new driver, so in
discussions about other drivers we've pursued the option of developing
the new driver out of tree as either a third-party library or a feature
branch in oslo.messaging. For NATS[0] we ended up going with a feature
branch, although to my knowledge that hasn't really gone anywhere (see
above about having bad luck with this sort of thing).
The other unfortunate reality is that we've lost the messaging experts
who would ideally have reviewed a new driver. Working in a feature
branch that doesn't affect the released library mitigates this somewhat
because issues can be worked out without affecting production
deployments, but unfortunately it is an obstacle.
That said, if someone were to develop a new driver that would probably
go a long way toward making them a messaging expert so this might be a
good way to replenish our talent pool in this area. :-)
I don't want to discourage anyone from writing a new driver (I think
everyone would love to get rid of rabbit), but before starting down that
path I think it's important to understand that there is a lot of inertia
behind rabbit and messaging is a complex topic. This is not a project
that will take a few weeks. Even a few months is a stretch. You're going
to need a rock solid driver implementation and then be able to show that
it's enough better than rabbit to convince people to switch.
So, if after all this doom and gloom you still want to move forward,
feel free to write up a spec similar to the NATS one and we can get you
a feature branch or repo to work in.
0: https://review.opendev.org/c/openstack/oslo-specs/+/692784
On 2/13/22 20:54, liyang wrote:
> Hi everyone,
> I find Apache Pulsar is very popular in MQ area, especially in
> clound native area. Is there any body integrate this MQ to oslo.messaging?
> Said to the truth. RabbitMQ developed in Erlang has very little
> source code level material, Qpid has very little operation practice in
> the internet. Kafka only support notification in oslo.messaging.
> I think the Apache Pulsar is clound native based. It may enforece
> the big scale in extension about Openstack deployment.
>
>