Open Stack

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 <doug at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev