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.
>
>Also, not having a test in the gate is a serious infraction now, and will
>lead to zmq's removal from oslo.messaging now that we have a ratified
>policy requiring this. I suggest a first step being to strive to get a
>devstack-gate job that runs using zmq instead of rabbitmq. You can
>trigger it in oslo.messaging's check pipeline, and make it non-voting,
>but eventually it needs to get into nova, neutron, cinder, heat, etc.
>etc. Without that, you'll find that the community of potential
>benefactors of any effort you put into zmq will shrink dramatically when
>we are forced to remove the driver from oslo.messaging (it can of course
>live on out of tree).
>
>__________________________________________________________________________
>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
__________________________________________________________________________
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
