Open Stack

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. 😅

On Tue, Feb 15, 2022 at 1:36 Ben Nemec <openstack at nemebean.com> wrote:

> 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.
> >
> >
>
> --
Thanks,
    --Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220215/c78a2b0f/attachment-0001.htm>