Open Stack

On Mon, 2022-02-14 at 10:32 -0600, Ben Nemec 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
speaking of the NATS on is that actully moving forward.
i had high hopes that NATS could be a scalable cloud native replecement for rabit
im not familar with Apache Pulsar https://pulsar.apache.org/ perhaps it has a similar feature set to NATS https://nats.io/.
lookign at it however Apache Pulsar seams to be written in java. not to be language
snob but that might prove to be a barrier for deployment. that was an issue for monasca
in the past. addign another language runtime to the requirement to you cluster like
erlang is added by rabbit and java would be added by pulsar to me is a dissadvantage
as it increase the treath domain form a secuirty perspecitve.
https://github.com/apache/pulsar

NATS being written in go and therefor deployed a a single staticly linked binsary with no
runtime deps is one of the advantages it brings https://github.com/nats-io/nats-server

is apache/pulsar somthign that you specificly have exprenice with or wanted to use or just the first
non rabit solution that seamed to fit the requireemtns that you came across.
if so i think it would be worth your time asseing NATS too and perhaps collaberate with teh previous effort
or take it over if you find it equally suitable.
> 
> 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.
> > 
> > 
>