Excerpts from Alec Hothan (ahothan)'s message of 2015-06-15 11:45:53 -0700: > > On 6/12/15, 3:55 PM, "Clint Byrum" <cl...@fewbar.com> wrote: > > > > >> > > > >I think you missed "it is not tested in the gate" as a root cause for > >some of the ambiguity. Anecdotes and bug reports are super important for > >knowing where to invest next, but a test suite would at least establish a > >base line and prevent the sort of thrashing and confusion that comes from > >such a diverse community of users feeding bug reports into the system. > > I agree with you that zmq needs to pass whatever oslo messaging test is > currently available however this won't remove all the > semantical/behavioral ambiguities. > This kind of ambiguities could be fixed by enhancing the API documentation > - always good to do even if a bit late - and by developing the associated > test cases (although they tend to be harder to write). > Another (ugly) strategy could be to simply say that the intended behavior > is the one exposed by the rabbitMQ based implementation (by means of > seniority and/or actual deployment mileage). > > For example, what happens if a recipient of a CALL or CAST message dies > before the message is sent. > Is the API supposed to return an error and if yes how quickly? RabbitMQ > based implementation will > likely return a success (since the message will sit in a queue in the > broker until the consumer reconnects - which could be a long time) while > ZMQ based will depend on the type of pattern used. Which is the behavior > desired by apps and which is the behavior "advertised" by the oslo > messaging API? > > Another example relates to flow control conditions (sender sends lots of > CAST, receiver very slow to consume). Should the sender > - always receive success and all messages will be queued without limit, > - always receive success and all messages will be queued up to a certain > point and new messages will be dropped silently > - or receive an EAGAIN error (socket behavior)? > > In these unclear conditions, switching to a different transport driver is > going to be tricky because apps may have been written/patched to assume a > certain behavior and might no longer behave properly if the expected > behavior changes (even if it is for the better) and may require adjusting > existing apps (to support a different behavior of the API). > Note that "switching to a different transport" is not just about testing > it in devstack but also about deploying it at scale on real production > environment and testing at scale.
Alec, you bring up fantastic and importan points above. However, lets stay on track. We're not even testing to see if nova-api can talk to nova-conductor via the current zmq driver. It's entirely possible it simply does not work for any number of reasons. A devstack-gate job is the _minimum_ needed. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
