<div dir="auto">At  least in our case, Pulsar was developed in house here at Yahoo originally and we have very large deployments and many experts (most original major contributors) available directly. So, I’m a little biased. :D</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 15, 2022 at 21:31 Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Mon, 2022-02-14 at 10:32 -0600, Ben Nemec wrote:<br>
> First off I will note that we've had very bad luck in the past with <br>
> non-rabbit drivers getting traction either with developers or operators. <br>
> Most of them have bit-rotted and been removed at this point.<br>
> <br>
> That said, we do have a list of requirements for oslo.messaging drivers <br>
> in the documentation: <br>
> <a href="https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html" rel="noreferrer" target="_blank">https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html</a><br>
> <br>
> We realize those are non-trivial to achieve for a new driver, so in <br>
> discussions about other drivers we've pursued the option of developing <br>
> the new driver out of tree as either a third-party library or a feature <br>
> branch in oslo.messaging. For NATS[0] we ended up going with a feature <br>
> branch, although to my knowledge that hasn't really gone anywhere (see <br>
> above about having bad luck with this sort of thing).<br>
> <br>
> The other unfortunate reality is that we've lost the messaging experts <br>
> who would ideally have reviewed a new driver. Working in a feature <br>
> branch that doesn't affect the released library mitigates this somewhat <br>
> because issues can be worked out without affecting production <br>
> deployments, but unfortunately it is an obstacle.<br>
> <br>
> That said, if someone were to develop a new driver that would probably <br>
> go a long way toward making them a messaging expert so this might be a <br>
> good way to replenish our talent pool in this area. :-)<br>
> <br>
> I don't want to discourage anyone from writing a new driver (I think <br>
> everyone would love to get rid of rabbit), but before starting down that <br>
> path I think it's important to understand that there is a lot of inertia <br>
> behind rabbit and messaging is a complex topic. This is not a project <br>
> that will take a few weeks. Even a few months is a stretch. You're going <br>
> to need a rock solid driver implementation and then be able to show that <br>
> it's enough better than rabbit to convince people to switch.<br>
> <br>
> So, if after all this doom and gloom you still want to move forward, <br>
> feel free to write up a spec similar to the NATS one and we can get you <br>
> a feature branch or repo to work in.<br>
> <br>
> 0: <a href="https://review.opendev.org/c/openstack/oslo-specs/+/692784" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/oslo-specs/+/692784</a><br>
speaking of the NATS on is that actully moving forward.<br>
i had high hopes that NATS could be a scalable cloud native replecement for rabit<br>
im not familar with Apache Pulsar <a href="https://pulsar.apache.org/" rel="noreferrer" target="_blank">https://pulsar.apache.org/</a> perhaps it has a similar feature set to NATS <a href="https://nats.io/" rel="noreferrer" target="_blank">https://nats.io/</a>.<br>
lookign at it however Apache Pulsar seams to be written in java. not to be language<br>
snob but that might prove to be a barrier for deployment. that was an issue for monasca<br>
in the past. addign another language runtime to the requirement to you cluster like<br>
erlang is added by rabbit and java would be added by pulsar to me is a dissadvantage<br>
as it increase the treath domain form a secuirty perspecitve.<br>
<a href="https://github.com/apache/pulsar" rel="noreferrer" target="_blank">https://github.com/apache/pulsar</a><br>
<br>
NATS being written in go and therefor deployed a a single staticly linked binsary with no<br>
runtime deps is one of the advantages it brings <a href="https://github.com/nats-io/nats-server" rel="noreferrer" target="_blank">https://github.com/nats-io/nats-server</a><br>
<br>
is apache/pulsar somthign that you specificly have exprenice with or wanted to use or just the first<br>
non rabit solution that seamed to fit the requireemtns that you came across.<br>
if so i think it would be worth your time asseing NATS too and perhaps collaberate with teh previous effort<br>
or take it over if you find it equally suitable.<br>
> <br>
> On 2/13/22 20:54, liyang wrote:<br>
> > Hi  everyone,<br>
> >      I find Apache Pulsar is very popular in MQ area, especially in <br>
> > clound native area. Is there any body integrate this MQ to oslo.messaging?<br>
> >      Said to the truth. RabbitMQ developed in Erlang has very little <br>
> > source code level material, Qpid has very little operation practice in <br>
> > the internet. Kafka only support notification in oslo.messaging.<br>
> >      I think the Apache Pulsar  is clound native based. It may enforece <br>
> > the big scale in extension about Openstack deployment.<br>
> > <br>
> > <br>
> <br>
<br>
<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Thanks,<div>    --Adam</div></div></div>