<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 21 févr. 2019 à 16:29, Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com">jim@jimrollenhagen.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Feb 21, 2019 at 10:02 AM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2019-02-21 at 08:12 -0500, Jim Rollenhagen wrote:<br>
> On Thu, Feb 21, 2019 at 7:37 AM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br>
> > On Wed, 2019-02-20 at 10:24 -0500, Mohammed Naser wrote:<br>
> > > Hi Chris,<br>
> > > <br>
> > > Thanks for kicking this off.  I've added my replies in-line.<br>
> > > <br>
> > > Thank you for your past term as well.<br>
> > > <br>
> > > Regards,<br>
> > > Mohammed<br>
> > > <br>
> > > On Wed, Feb 20, 2019 at 9:49 AM Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org" target="_blank">cdent+os@anticdent.org</a>> wrote:<br>
> > > >  <snip><br>
> > > > * If you had a magic wand and could inspire and make a single<br>
> > > >    sweeping architectural or software change across the services,<br>
> > > >    what would it be? For now, ignore legacy or upgrade concerns.<br>
> > > >    What role should the TC have in inspiring and driving such<br>
> > > >    changes?<br>
> > > <br>
> > > Oh.<br>
> > > <br>
> > > - Stop using RabbitMQ as an RPC, it's the worst most painful component<br>
> > >   to run in an entire OpenStack deployment.  It's always broken.  Switch<br>
> > >   into something that uses HTTP + service registration to find endpoints.<br>
> >     as an on looker i have mixed feeling about this statement.<br>
> >     RabbitMQ can have issue at scale but it morstly works when its not on fire.<br>
> >     Would you be advocating building a openstack specific RPC layer perhaps<br>
> >     using keystone as the service registry and a custom http mechanism or adopting<br>
> >     an existing technology like grpc?<br>
> > <br>
> >     investigating an alternative RPC backend has come up in the past (zeromq and qupid)<br>
> >     and i think it has merit but im not sure as a comunity creating a new RPC framework is<br>
> >     a project wide effort that openstack need to solve. that said zaqar is a thing<br>
> >     <a href="https://docs.openstack.org/zaqar/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/zaqar/latest/</a> if it is good enough for our endusers to consume<br>
> >     perhaps it would be up to the task of being openstack rpc transport layer.<br>
> > <br>
> >     anyway my main question was would you advocate adoption of an exisiting technology<br>
> >     or creating our own solution if we were to work on this goal as a community.<br>
> > <br>
> <br>
> I'll also chime in here since I agree with Mohammed.<br>
> <br>
> We're certainly going to have to write software to make this happen. Maybe<br>
> that's a new oslo.messaging driver, maybe it's a new equivalent of that layer.<br>
> <br>
> But we've re-invented enough software already. This isn't a place where we<br>
> should do it. We should use build on or glue together existing tools to build<br>
> something scalable and relatively simple to operate.<br>
> <br>
> Are your mixed feelings about this statement a concern about re-inventing<br>
> wheels, or about changing an underlying architectural thing at all?<br>
with re-inventing wheels.<br>
a new oslo.messaging driver i think would be perfectly fine. that said we<br>
dont want 50 of them as it will be impossible<br>
to test and maintain them all.<br>
my concern would be that even if we deveploped the perfect rpc layer for openstack<br>
ourselves it would be a lot of effort that could have been spent elsewhere.<br>
developing glue logic to use an alternitiv is much less invasive and achievable.<br>
<br>
the other thing i woudl say is if im felling pedantinc the fact that we have an rpc<br>
bus is an architecutal question as may in some cases be the perfromce or feature set<br>
the final system provide. but personally i dont see rabbitmq vs grps as an architectual<br>
question at all. the message bus is just an io device. we should be able to change<br>
that io device for another without it martially effecting our architecutre. if it does<br>
we are too tightly coupled to the implementation. <br></blockquote><div><br></div><div>+1. There's some question about our RPC casts that need to be addressed,</div><div>but agree in general. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
you can sub out rabbitmq today with qpid or activmq and in the past you could use<br>
zeromq too but rabbit more or less one out over that set of message queue. <br>
there is also limited support for kafka. kafka is pretty heavy weight as is itsio from<br>
what i have heard so im not sure they would be a good replacement for small cloud but i<br>
belive they are ment to scale well.<br>
<br>
grpc and nats are proably the two rabitmq alternative is would personally consider but i know<br>
some projects hack etcd to act as a psudo rpc bus.<br>
this type of change is something i could see as a comunity goal eventually but would like to<br>
see done with one project first before it got to that point.<br></blockquote><div><br></div><div>Agree with that. I don't want to get into implementation details here. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
there is value in useing 1 or 2 rpc buses istead of support many and this is the type of change<br>
i hope would be guided by measurement and community feedback.<br></blockquote><div><br></div><div>100%, the first steps to doing anything like this is to measure performance</div><div>today, identify other options,  measure performance on those. This is a</div><div>high-effort change, and it'd be crazy to do it without data.</div><div><br></div></div></div></blockquote><div><br></div><div><br></div><div>Yup, all this. If we want things to happen, we need first to identify the pain points and have people acting on those. </div><div>All of that can happen with or without the TC scope, to answer the original concern. I'm just glad Chris pointed out this question because now we can start brainstorming about this at the PTG.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>// jim</div></div></div>
</blockquote></div></div>