Open Stack

Excerpts from Alec Hothan (ahothan)'s message of 2015-06-15 11:45:53 -0700:
> 
> On 6/12/15, 3:55 PM, "Clint Byrum" <clint at 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.