inline
On 14.07.2015 18:59, Alec Hothan (ahothan) wrote:
inline...
On 7/8/15, 8:23 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote:
I believe Oleksii is already working on it.
On all above I believe it is best to keep oslo messaging simple and
predictable, then have apps deal
On 7/20/15, 5:24 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote:
inline
On 14.07.2015 18:59, Alec Hothan (ahothan) wrote:
inline...
On 7/8/15, 8:23 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote:
I believe Oleksii is already working on it.
On all above I believe it is
inline...
On 7/8/15, 8:23 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote:
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
Spec [1] is updated and ready for review.
Thanks everyone for taking part in the discussion.
Regards,
Oleksii
[1] - https://review.openstack.org/#/c/187338
6/22/15 13:14, Sean Dague пишет:
On 06/19/2015 08:18 PM, Alec Hothan (ahothan) wrote:
Do we have a good understanding of what is
On 06/19/2015 08:18 PM, Alec Hothan (ahothan) wrote:
Do we have a good understanding of what is expected of zmq wrt rabbitMQ?
Like in what part of the bell curve or use cases would you see it? Or
indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could
handle better?
I have
Alec Hothan (ahothan) wrote:
Do we have a good understanding of what is expected of zmq wrt rabbitMQ?
Like in what part of the bell curve or use cases would you see it? Or
indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could
handle better?
I have tried to find any information
Do we have a good understanding of what is expected of zmq wrt rabbitMQ?
Like in what part of the bell curve or use cases would you see it? Or
indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could
handle better?
I have tried to find any information on very large scale deployment
Excerpts from Alec Hothan (ahothan)'s message of 2015-06-19 17:18:41 -0700:
Do we have a good understanding of what is expected of zmq wrt rabbitMQ?
Like in what part of the bell curve or use cases would you see it? Or
indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could
Flavio Percoco wrote:
There's a 95% of deployments using rabbit not because rabbit is the
best solution for all OpenStack problems but because it was the one
that works best now. The lack of support on other drivers caused this
and as long this lack of support on such drivers persist, it won't
On 06/16/2015 08:51 PM, Alec Hothan (ahothan) wrote:
I saw Sean Dague mention in another email that RabbitMQ is used by 95% of
OpenStack users - and therefore does it make sense to invest in ZMQ (legit
question).
I believe it's used by 95% of users because there is as yet no
compelling
On 16/06/15 19:51 +, Alec Hothan (ahothan) wrote:
Gordon,
These are all great points for RPC messages (also called CALL in oslo
messaging). There are similar ambiguous contracts for the other types of
messages (CAST and FANOUT).
I am worried about the general lack of interest from the
On 06/12/2015 09:41 PM, Alec Hothan (ahothan) wrote:
One long standing issue I can see is the fact that the oslo messaging API
documentation is sorely lacking details on critical areas such as API
behavior during fault conditions, load conditions and scale conditions.
I very much agree,
Gordon,
These are all great points for RPC messages (also called CALL in oslo
messaging). There are similar ambiguous contracts for the other types of
messages (CAST and FANOUT).
I am worried about the general lack of interest from the community to fix
this as it looks like most people assume
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
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
6/13/15 01:55, Clint Byrum пишет:
Excerpts from Alec Hothan (ahothan)'s message of 2015-06-12 13:41:17 -0700:
On 6/1/15, 5:03 PM, Davanum Srinivas dava...@gmail.com wrote:
fyi, the spec for zeromq driver in oslo.messaging is here:
Hi, Alec
Thanks for email threads investigation.
I've decided to spend more time to dig into old zmq-related threads too.
Some notes inline.
6/12/15 23:41, Alec Hothan (ahothan) пишет:
On 6/1/15, 5:03 PM, Davanum Srinivas dava...@gmail.com wrote:
fyi, the spec for zeromq driver in
On 6/1/15, 5:03 PM, Davanum Srinivas dava...@gmail.com wrote:
fyi, the spec for zeromq driver in oslo.messaging is here:
https://review.openstack.org/#/c/187338/1/specs/liberty/zmq-patterns-usage
.rst,unified
-- dims
I was about to provide some email comments on the above review off gerrit,
Excerpts from Alec Hothan (ahothan)'s message of 2015-06-12 13:41:17 -0700:
On 6/1/15, 5:03 PM, Davanum Srinivas dava...@gmail.com wrote:
fyi, the spec for zeromq driver in oslo.messaging is here:
https://review.openstack.org/#/c/187338/1/specs/liberty/zmq-patterns-usage
.rst,unified
--
@lists.openstack.org
Date: Wednesday, May 27, 2015 at 3:52 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo.messaging][zeromq] Next step
Hi,
I'll try to address the question about Proxy process.
AFAIK
-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo.messaging][zeromq] Next step
Hi,
I'll try to address the question about Proxy process.
AFAIK there is no way yet in zmq to bind more than once to a specific port
(e.g. tcp://*:9501).
Apparently we can:
socket1.bind('tcp://node1:9501
Hi,
I'll try to address the question about Proxy process.
AFAIK there is no way yet in zmq to bind more than once to a specific
port (e.g. tcp://*:9501).
Apparently we can:
socket1.bind('tcp://node1:9501')
socket2.bind('tcp://node2:9501')
but we can not:
socket1.bind('tcp://*:9501')
Alec,
Here are the slides:
http://www.slideshare.net/davanum/oslomessaging-new-0mq-driver-proposal
All the 0mq patches to date should be either already merged in trunk
or waiting for review on trunk.
Oleksii, Li Ma,
Can you please address the other questions?
thanks,
Dims
On Tue, May 26, 2015
Looking at what is the next step following the design summit meeting on
0MQ as the etherpad does not provide too much information.
Few questions:
- would it be possible to have the slides presented (showing the proposed
changes in the 0MQ driver design) to be available somewhere?
- is there a
24 matches
Mail list logo
