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) Separate zmq testing. Now we have hacks like skip_test_if_nozmq or
something like that.
Disadvantages are:
1) Synchronization changes with oslo.messaging (Changes to the
oslo.messaging API may break all things)
2) Additional effort for separate library management (releases so on)
As for me, I like the idea of separate repo for zmq driver because it
gives more freedom for driver extension.
There are some ideas that we can have more than a single zmq driver
implementation in future.
At least we may have different versions one for HA and one for
scalability based on different zmq patterns.
Thanks,
Oleksii Zamiatin
On 24.03.15 18:03, Ben Nemec wrote:
On 03/24/2015 10:31 AM, Li Ma wrote:
On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann <d...@doughellmann.com> wrote:
The goal we set at the Kilo summit was to have a group of people
interested in zmq start contributing to the driver, and I had hoped to
the library overall. How do we feel that is going?
That sounds great. I hope so.
One way to create a separate group to manage the zmq driver is to move
it to a separate repository. Is the internal API for messaging drivers
stable enough to do that?
Actually I'm not intended to move it to a separate repository. I just
want to make sure if it is possible to make a fixed online meeting for
zmq driver.
And personally I'd prefer not to split the repo. I'd rather explore the
idea of driver maintainers whose +1 on driver code counts as +2, like we
had/have with incubator. Splitting the repo brings up some sticky
issues with requirements syncs and such. I'd like to think that with
only three different drivers we don't need the overhead of managing
separate repos, but maybe I'm being optimistic. :-)
Kind of off topic since that's not what is being proposed here, but two
different people have mentioned it so I wanted to note my preference in
case it comes up again.
-Ben
__________________________________________________________________________
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
