Hi folks,
Just wanted to sum up a little bit from the discussions at Mitaka summit
(etherpad available [0]).
General for oslo.messaging:
- Implement single-machine failover test suite using multiprocessing +
iptables for network failures emulation.
Needed for emulating different
+1 from me
9/24/15 20:12, Doug Hellmann пишет:
Oslo team,
I am nominating Brant Knudson for Oslo core.
As liaison from the Keystone team Brant has participated in meetings,
summit sessions, and other discussions at a level higher than some
of our own core team members. He is already core on
Hi All,
I'm excited to report that today we have merged [1] new zmq driver into
oslo.messaging master branch.
The driver is not completely done yet, so we are going to continue
developing it on the master branch now.
What we've reached for now is passing functional tests gate (we are
going
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
Hi,
The gate is 'non-voting' so it actually doesn't block the merge.
But in console I see such errors:
TypeError: Unicode-objects must be encoded before hashing
which means py34 compatibility is broken in code (not by you maybe, but
it is).
If you will fix it in your next patches your team
that we should
not make such changes
so fast.
Thanks,
Oleksii
6/18/15 16:36, Sean Dague пишет:
On 06/18/2015 06:49 AM, Sean Dague wrote:
On 06/18/2015 03:28 AM, ozamiatin wrote:
Hi, please don't remove zmq support from devstack.
We are now in progress of writing a new version of the driver.
I
Hi, please don't remove zmq support from devstack.
We are now in progress of writing a new version of the driver.
I use devstack each time to check the driver functionality.
When the implementation become public it will be even more
important to have a possibility to check it on devstack.
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
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')
+1 from me
5/20/15 22:23, Joshua Harlow пишет:
+1
Robert is really great, helpful, and always welcoming!
Get er' done :-)
Davanum Srinivas wrote:
Hi Team,
I'd like to invite Robert Collins (aka lifeless) as an Oslo core.
Robert has been a long time contributor to a whole bunch of OpenStack
Hi,
I generally like the idea of async CALL. Is there a place in Nova (or
other services) where the new CALL may be applied to see advantage?
Thanks,
Oleksii Zamiatin
07.05.15 12:34, Sahid Orentino Ferdjaoui пишет:
Hi,
The primary point of this expected discussion around asynchronous
+1 for adding Mehdi to oslo-core!
Thanks,
Oleksii Zamiatin
07.05.15 17:36, Davanum Srinivas пишет:
Dear Oslo folks,
I'd like to propose adding Mehdi Abaakouk to oslo-core. He is already
leading the oslo.messaging team and helping with Tooz, and futurist
efforts.
I am hoping to get Mehdi more
Hi,
Does anyone use any version of ZeroMQ driver in production deployment?
If you do, please leave your comments in [1], or reply to this letter.
[1] https://review.openstack.org/#/c/171131/
Thanks,
Oleksii Zamiatin
__
Hi,
Sorry for not replying on [1] comments too long.
I'm almost ready to return to the spec with updates.
The main lack of current zmq-driver implementation is that
it manually implements REQ/REP on top of PUSH/PULL.
It results in:
1. PUSH/PULL is one way directed socket (reply needs another
Hi,
+1 for subgroup meeting
Does the separate repository mean separate library (python package) with
its own release cycles so on?
As I can see the separate library makes it easy:
1) To support optional (for oslo.messaging) requirements specific for
zmq driver like pyzmq, redis so on
2)
Hi Li Ma,
Thank you very much for your reply
On 06.03.15 05:01, Li Ma wrote:
Hi all, actually I'm writing the same mail topic for zeromq driver,
but I haven't done it yet. Thank you for proposing this topic,
ozamiatin.
1. ZeroMQ functionality
Actually I proposed a session topic in the coming
Hi, Eric
Thanks a lot for your comments.
On 06.03.15 06:21, Eric Windisch wrote:
On Wed, Mar 4, 2015 at 12:10 PM, ozamiatin ozamia...@mirantis.com
mailto:ozamia...@mirantis.com wrote:
Hi,
By this e-mail I'd like to start a discussion about current zmq
driver internal design
Hi,
By this e-mail I'd like to start a discussion about current zmq driver
internal design problems I've found out.
I wish to collect here all proposals and known issues. I hope this
discussion will be continued on Liberty design summit.
And hope it will drive our further zmq driver
Hi,
This week I've tried to install devstack with zmq. So small status update:
The main problem is that Neutron fails with redis connection refused.
Maybe [1] and [2] will fix this.
Smaller ones (I've managed them locally):
[6] No redis, pyzmq in requirements.txt -
Hi,
Working on zmq driver I've noticed that for now zmq.Context is created
per socket which is definitely redundant. That was introduced by the change
https://review.openstack.org/#/c/126914/5/oslo/messaging/_drivers/impl_zmq.py
It makes the correct thing reducing the global context
+1 To wiki page.
I also tried to deploy devstack with zmq, and met the same problems
https://bugs.launchpad.net/devstack/+bug/1397999
https://bugs.launchpad.net/oslo.messaging/+bug/1395721
We also have some unimplemented closures in zmq driver:
one of them:
We should build a simple app using the Oslo libraries that we can place in the
oslo.messaging source tree to use for exercising the communication patterns of
the library with different drivers. Ideally that would be a single app (or set
of apps) that could be used to test all drivers, with
23 matches
Mail list logo
