Open Stack

Mark, thanks for the input...

On Tue, Jan 29, 2013 at 9:14 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> In this case, there is a (performance) benefit to using the new feature
> so it probably does make sense to have an off-by-default feature which
> we'd enable by default for the H release.
>
> The config option should be documented though :)
>

I'm glad to hear there is a good chance that I can get this approved in a
single release and with a documented config option.

The other contention point is how the RPC msg_id sent in the message data
is used.  The (somewhat) short explanation is that if the new
implementation continues to use it as a unique identifier for the message
and the fast option is enabled, a NEW->OLD RPC call will get executed on
the server side, the response will be sent to a queue that will be
immediately deleted (auto-delete), the RPC call will timeout on the caller
side and no meaningful log entry will be produced.  There is an alternative
that makes msg_id the name of the response queue with the advantage that a
log entry can be generated on the caller side stating the called failed due
to calling a downlevel service.  This case is a user error.  The user
enabled the fast option while downlevel services are present.

I now favor the approach of leaving msg_id as the unique identifier of the
message, but just want to be clear of the consequences.  I will wait a
while to see if anyone cares and then resubmit the patch for code review
and hope we have reached a consensus.

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130129/1b526d3f/attachment.html>