oslo.messaging integration development
flux.adam at gmail.com
Tue Feb 15 14:44:27 UTC 2022
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
On Tue, Feb 15, 2022 at 21:31 Sean Mooney <smooney at redhat.com> wrote:
> 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:
> > 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 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
> 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
> as it increase the treath domain form a secuirty perspecitve.
> 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
> 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
> 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
> > > 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
> > > the big scale in extension about Openstack deployment.
> > >
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss