Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-12-08 Thread Li Ma 
Hi all, I tried to deploy zeromq by devstack and it definitely failed 
with lots of problems, like dependencies, topics, matchmaker setup, etc. 
I've already registered a blueprint for devstack-zeromq [1].


Besides, I suggest to build a wiki page in order to trace all the 
workitems related with ZeroMQ. The general sections may be [Why ZeroMQ], 
[Current Bugs & Reviews], [Future Plan & Blueprints], [Discussions], 
[Resources], etc.


Any comments?

[1] https://blueprints.launchpad.net/devstack/+spec/zeromq

cheers,
Li Ma

On 2014/11/18 21:46, James Page wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/11/14 00:55, Denis Makogon wrote:


So if zmq driver support in devstack is fixed, we can easily add a
new job to run them in the same way.


Btw this is a good question. I will take look at current state of
zmq in devstack.

I don't think its that far off and its broken rather than missing -
the rpc backend code needs updating to use oslo.messaging rather than
project specific copies of the rpc common codebase (pre oslo).
Devstack should be able to run with the local matchmaker in most
scenarios but it looks like there was support for the redis matchmaker
as well.

If you could take some time to fixup that would be awesome!

- -- 
James Page

Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIbBAEBCAAGBQJUa03HAAoJEL/srsug59jDdZQP+IeEvXAcfxNs2Tgvt5trnjgg
cnTrJPLbr6i/uIXKjRvNDSkJEdv//EjL/IRVRIf0ld09FpRnyKzUDMPq1CzFJqdo
45RqFWwJ46NVA4ApLZVugJvKc4tlouZQvizqCBzDKA6yUsUoGmRpYFAQ3rN6Gs9h
Q/8XSAmHQF1nyTarxvylZgnqhqWX0p8n1+fckQeq2y7s3D3WxfM71ftiLrmQCWir
aPkH7/0qvW+XiOtBXVTXDb/7pocNZg+jtBkUcokORXbJCmiCN36DBXv9LPIYgfhe
/cC/wQFH4RUSkoj7SYPAafX4J2lTMjAd+GwdV6ppKy4DbPZdNty8c9cbG29KUK40
TSCz8U3tUcaFGDQdBB5Kg85c1aYri6dmLxJlk7d8pOXLTb0bfnzdl+b6UsLkhXqB
P4Uc+IaV9vxoqmYZAzuqyWm9QriYlcYeaIJ9Ma5fN+CqxnIaCS7UbSxHj0yzTaUb
4XgmcQBwHe22ouwBmk2RGzLc1Rv8EzMLbbrGhtTu459WnAZCrXOTPOCn54PoIgZD
bK/Om+nmTxepWD1lExHIYk3BXyZObxPO00UJHdxvSAIh45ROlh8jW8hQA9lJ9QVu
Cz775xVlh4DRYgenN34c2afOrhhdq4V1OmjYUBf5M4gS6iKa20LsMjp7NqT0jzzB
tRDFb67u28jxnIXR16g=
=+k0M
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-18 Thread James Page 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/11/14 00:55, Denis Makogon wrote:
> 
> 
> So if zmq driver support in devstack is fixed, we can easily add a 
> new job to run them in the same way.
> 
> 
> Btw this is a good question. I will take look at current state of
> zmq in devstack.

I don't think its that far off and its broken rather than missing -
the rpc backend code needs updating to use oslo.messaging rather than
project specific copies of the rpc common codebase (pre oslo).
Devstack should be able to run with the local matchmaker in most
scenarios but it looks like there was support for the redis matchmaker
as well.

If you could take some time to fixup that would be awesome!

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIbBAEBCAAGBQJUa03HAAoJEL/srsug59jDdZQP+IeEvXAcfxNs2Tgvt5trnjgg
cnTrJPLbr6i/uIXKjRvNDSkJEdv//EjL/IRVRIf0ld09FpRnyKzUDMPq1CzFJqdo
45RqFWwJ46NVA4ApLZVugJvKc4tlouZQvizqCBzDKA6yUsUoGmRpYFAQ3rN6Gs9h
Q/8XSAmHQF1nyTarxvylZgnqhqWX0p8n1+fckQeq2y7s3D3WxfM71ftiLrmQCWir
aPkH7/0qvW+XiOtBXVTXDb/7pocNZg+jtBkUcokORXbJCmiCN36DBXv9LPIYgfhe
/cC/wQFH4RUSkoj7SYPAafX4J2lTMjAd+GwdV6ppKy4DbPZdNty8c9cbG29KUK40
TSCz8U3tUcaFGDQdBB5Kg85c1aYri6dmLxJlk7d8pOXLTb0bfnzdl+b6UsLkhXqB
P4Uc+IaV9vxoqmYZAzuqyWm9QriYlcYeaIJ9Ma5fN+CqxnIaCS7UbSxHj0yzTaUb
4XgmcQBwHe22ouwBmk2RGzLc1Rv8EzMLbbrGhtTu459WnAZCrXOTPOCn54PoIgZD
bK/Om+nmTxepWD1lExHIYk3BXyZObxPO00UJHdxvSAIh45ROlh8jW8hQA9lJ9QVu
Cz775xVlh4DRYgenN34c2afOrhhdq4V1OmjYUBf5M4gS6iKa20LsMjp7NqT0jzzB
tRDFb67u28jxnIXR16g=
=+k0M
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-18 Thread ozamiatin 

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 tests written against the 
app rather than the driver. Once we have the app and tests, we can define a new 
gate job to run those tests just for oslo.messaging, with a different 
configuration for each driver we support.

Doug


Provided a blueprint for it 
https://blueprints.launchpad.net/oslo.messaging/+spec/oslo-functional-testing-apps


On 17.11.14 23:53, Doug Hellmann wrote:

On Nov 17, 2014, at 3:36 PM, Joshua Harlow  wrote:


Doug Hellmann wrote:

On Nov 17, 2014, at 10:01 AM, Denis Makogon  wrote:


On Mon, Nov 17, 2014 at 4:26 PM, James Page  wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Denis

On 17/11/14 07:43, Denis Makogon wrote:

During Paris Design summit oslo.messaging session was raised good
question about maintaining ZeroMQ driver in upstream (see section
“dropping ZeroMQ support in oslo.messaging” at [1]) . As we all
know, good thoughts are comming always after. I’d like to propose
several improvements in process of maintaining and developing of
ZeroMQ driver in upstream.

Contribution focus. As we all see, that there are enough patches
that are trying to address certain problems related to ZeroMQ
driver.

Few of them trying to add functional tests, which is definitely
good, but … there’s always ‘but’, they are not “gate”-able.

I'm not sure I understand you statement about them not being
"gate"-able - the functional/unit tests currently proposed for the zmq
driver run fine as part of the standard test suite execution - maybe
the confusion is over what 'functional' actually means, but in my
opinion until we have some level of testing of this driver, we can't
effectively make changes and fix bugs.


I do agree that there's a confusion what "functional testing" means.
Another thing, what the best solution is? Unit tests are welcome, but they
are still remain to be units (they are using mocks, etc.)
I'd try to define what 'fuctional testing' means for me. Functional testing
in oslo.messaging means that we've been using real service for messaging
(in this case - deployed 0mq). So, the simple definition, in term os
OpenStack integration, we should be able to run full Tempest test suit for
OpenStack services that are using oslo.messaging with enabled zmq driver.
Am i right or not?

That’s a good goal, but that’s not what I had in mind for in-tree functional 
tests.

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 tests written against the 
app rather than the driver. Once we have the app and tests, we can define a new 
gate job to run those tests just for oslo.messaging, with a different 
configuration for each driver we support.

Doug

An interesting idea that might be useful that taskflow implemented/has done...

The examples @ 
https://github.com/openstack/taskflow/tree/master/taskflow/examples all get 
tested during unit test runs to ensure they work as expected. This seems close 
to your 'simple app' (where app is replaced with example), it might be nice to 
have a similar approach for oslo.messaging that has 'examples' that are these 
apps that get ran to probe the functionality of oslo.messaging (as well as 
useful for documentation to show people how to use it, which is the other usage 
taskflow has for these examples)

The hacky example tester could likely be shared (or refactored, since it 
probably needs it), 
https://github.com/openstack/taskflow/blob/master/taskflow/tests/test_examples.py#L91

Sure, that would be a good way to do it, too.

Doug


My proposal for this topic is to change contribution focus from
oslo.messaging by itself to OpenStack/Infra project and DevStack
(subsequently to devstack-gate too).

I guess there would be questions “why?”.  I think the answer is
pretty obvious: we have driver that is not being tested at all
within DevStack and project integration.

This was discussed in the oslo.messaging summit session, and
re-enabling zeromq support in devstack is definately on my todo list,
but I don't think the should block landing of the currently proposed
unit tests on oslo.messaging.

For example https://review.openstack.org/#/c/128233/ says about adding

functional and units. I'm ok with units, but what about functional tests?
Which oslo.messaging gate job runs them?



Also i’d say that such focus re-orientation would be very useful
as source of use cases and bugs eventually. Here’s a list of what
we, as team, should do first:

1.

Ensure that DevStack can successfully:

1.

Install ZeroMQ.

2.

Configure  each proj

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Denis Makogon 
вторник, 18 ноября 2014 г. пользователь Mehdi Abaakouk написал:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> Le 2014-11-17 22:53, Doug Hellmann a écrit :
>
>  That’s a good goal, but that’s not what I had in mind for in-tree
 functional tests.


>>> An interesting idea that might be useful that taskflow implemented/has
>>> done...
>>>
>>> The examples @ https://github.com/openstack/
>>> taskflow/tree/master/taskflow/examples all get tested during unit test
>>> runs to ensure they work as expected. This seems close to your 'simple app'
>>> (where app is replaced with example), it might be nice to have a similar
>>> approach for oslo.messaging that has 'examples' that are these apps that
>>> get ran to probe the functionality of oslo.messaging (as well as useful for
>>> documentation to show people how to use it, which is the other usage
>>> taskflow has for these examples)
>>>
>>> The hacky example tester could likely be shared (or refactored, since it
>>> probably needs it), https://github.com/openstack/
>>> taskflow/blob/master/taskflow/tests/test_examples.py#L91
>>>
>>
>> Sure, that would be a good way to do it, too.
>>
>
> We already have some works done in that ways. Gordon Sim have wrote some
> tests that use only the public API to test a driver:
> https://github.com/openstack/oslo.messaging/blob/master/
> tests/functional/test_functional.py
>
> You just have to set the TRANSPORT_URL environment variable to start them.
>
> I'm working to run them on a devstack vm for rabbit, qpid, amqp1.0 driver,
> the infra patch that add experimental jobs have just landed:
> https://review.openstack.org/#/c/130370/
>
>
Amazing work, Mehdi.


> I have two other patches waiting to make it works:
> * https://review.openstack.org/#/c/130370/
> * https://review.openstack.org/#/c/130437/
>
>
Will take a look at them asap.


> So if zmq driver support in devstack is fixed, we can easily add a new job
> to run them in the same way.
>
>
Btw this is a good question. I will take look at current state of zmq in
devstack.


>
> - ---
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
> -BEGIN PGP SIGNATURE-
> Version: OpenPGP.js v.1.20131017
> Comment: http://openpgpjs.org
>
> wkYEAREIABAFAlRq6p4JEJZbdE7sD8foAAAWnACdHPwDAbga4mfP/tIL1Z9q
> A0w2zvAAnA/tvfXnAJO4a2n4TKiZYiVGbUdT
> =BVDs
> -END PGP SIGNATURE-
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Mehdi Abaakouk 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Le 2014-11-17 22:53, Doug Hellmann a écrit :

That’s a good goal, but that’s not what I had in mind for in-tree 
functional tests.




An interesting idea that might be useful that taskflow implemented/has 
done...


The examples @ 
https://github.com/openstack/taskflow/tree/master/taskflow/examples 
all get tested during unit test runs to ensure they work as expected. 
This seems close to your 'simple app' (where app is replaced with 
example), it might be nice to have a similar approach for 
oslo.messaging that has 'examples' that are these apps that get ran to 
probe the functionality of oslo.messaging (as well as useful for 
documentation to show people how to use it, which is the other usage 
taskflow has for these examples)


The hacky example tester could likely be shared (or refactored, since 
it probably needs it), 
https://github.com/openstack/taskflow/blob/master/taskflow/tests/test_examples.py#L91


Sure, that would be a good way to do it, too.


We already have some works done in that ways. Gordon Sim have wrote some 
tests that use only the public API to test a driver: 
https://github.com/openstack/oslo.messaging/blob/master/tests/functional/test_functional.py


You just have to set the TRANSPORT_URL environment variable to start 
them.


I'm working to run them on a devstack vm for rabbit, qpid, amqp1.0 
driver, the infra patch that add experimental jobs have just landed: 
https://review.openstack.org/#/c/130370/


I have two other patches waiting to make it works:
* https://review.openstack.org/#/c/130370/
* https://review.openstack.org/#/c/130437/

So if zmq driver support in devstack is fixed, we can easily add a new 
job to run them in the same way.



- ---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht
-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v.1.20131017
Comment: http://openpgpjs.org

wkYEAREIABAFAlRq6p4JEJZbdE7sD8foAAAWnACdHPwDAbga4mfP/tIL1Z9q
A0w2zvAAnA/tvfXnAJO4a2n4TKiZYiVGbUdT
=BVDs
-END PGP SIGNATURE-


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Joshua Harlow 

Ok, it depends on what features are needed in said driver.

Things like http://redis.io/commands/psetex (and others) that might be 
used only exist in newer versions > 2.2.0, if these aren't used then it 
doesn't matter (basic support/functionality exists in 2.2.0 for all the 
common things).


Eric Windisch wrote:



On Mon, Nov 17, 2014 at 3:33 PM, Joshua Harlow mailto:harlo...@outlook.com>> wrote:

It should already be running.

Tooz has been testing with it[1]. Whats running in ubuntu is an
older redis though so don't expect some of the new > 2.2.0 features
to work until the ubuntu version is pushed out to all projects.

The redis (soft) requirement for the ZeroMQ driver shouldn't require a
newer version at all.

Also, since I have a platform, I'll note that the redis "matchmaker"
driver is just a reference implementation I tossed together in a day.
It's convenient because it eliminates the need for a static
configuration, making tempest tests much easier to run and generally
easier for anyone to deploy, but it's intended to be an example of
hooking into an inventory service, not necessarily the defacto solution.

--
Regards,
Eric Windisch

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Eric Windisch 
On Mon, Nov 17, 2014 at 3:33 PM, Joshua Harlow  wrote:

> It should already be running.
>
> Tooz has been testing with it[1]. Whats running in ubuntu is an older
> redis though so don't expect some of the new > 2.2.0 features to work until
> the ubuntu version is pushed out to all projects.


The redis (soft) requirement for the ZeroMQ driver shouldn't require a
newer version at all.

Also, since I have a platform, I'll note that the redis "matchmaker" driver
is just a reference implementation I tossed together in a day.  It's
convenient because it eliminates the need for a static configuration,
making tempest tests much easier to run and generally easier for anyone to
deploy, but it's intended to be an example of hooking into an inventory
service, not necessarily the defacto solution.


-- 
Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Doug Hellmann 

On Nov 17, 2014, at 3:36 PM, Joshua Harlow  wrote:

> Doug Hellmann wrote:
>> On Nov 17, 2014, at 10:01 AM, Denis Makogon  wrote:
>> 
>>> On Mon, Nov 17, 2014 at 4:26 PM, James Page  wrote:
>>> 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Hi Denis
 
 On 17/11/14 07:43, Denis Makogon wrote:
> During Paris Design summit oslo.messaging session was raised good
> question about maintaining ZeroMQ driver in upstream (see section
> “dropping ZeroMQ support in oslo.messaging” at [1]) . As we all
> know, good thoughts are comming always after. I’d like to propose
> several improvements in process of maintaining and developing of
> ZeroMQ driver in upstream.
> 
> Contribution focus. As we all see, that there are enough patches
> that are trying to address certain problems related to ZeroMQ
> driver.
> 
> Few of them trying to add functional tests, which is definitely
> good, but … there’s always ‘but’, they are not “gate”-able.
 I'm not sure I understand you statement about them not being
 "gate"-able - the functional/unit tests currently proposed for the zmq
 driver run fine as part of the standard test suite execution - maybe
 the confusion is over what 'functional' actually means, but in my
 opinion until we have some level of testing of this driver, we can't
 effectively make changes and fix bugs.
 
>>> I do agree that there's a confusion what "functional testing" means.
>>> Another thing, what the best solution is? Unit tests are welcome, but they
>>> are still remain to be units (they are using mocks, etc.)
>>> I'd try to define what 'fuctional testing' means for me. Functional testing
>>> in oslo.messaging means that we've been using real service for messaging
>>> (in this case - deployed 0mq). So, the simple definition, in term os
>>> OpenStack integration, we should be able to run full Tempest test suit for
>>> OpenStack services that are using oslo.messaging with enabled zmq driver.
>>> Am i right or not?
>> 
>> That’s a good goal, but that’s not what I had in mind for in-tree functional 
>> tests.
>> 
>> 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 
>> tests written against the app rather than the driver. Once we have the app 
>> and tests, we can define a new gate job to run those tests just for 
>> oslo.messaging, with a different configuration for each driver we support.
>> 
>> Doug
> 
> An interesting idea that might be useful that taskflow implemented/has done...
> 
> The examples @ 
> https://github.com/openstack/taskflow/tree/master/taskflow/examples all get 
> tested during unit test runs to ensure they work as expected. This seems 
> close to your 'simple app' (where app is replaced with example), it might be 
> nice to have a similar approach for oslo.messaging that has 'examples' that 
> are these apps that get ran to probe the functionality of oslo.messaging (as 
> well as useful for documentation to show people how to use it, which is the 
> other usage taskflow has for these examples)
> 
> The hacky example tester could likely be shared (or refactored, since it 
> probably needs it), 
> https://github.com/openstack/taskflow/blob/master/taskflow/tests/test_examples.py#L91

Sure, that would be a good way to do it, too.

Doug

> 
>> 
>>> 
> My proposal for this topic is to change contribution focus from
> oslo.messaging by itself to OpenStack/Infra project and DevStack
> (subsequently to devstack-gate too).
> 
> I guess there would be questions “why?”.  I think the answer is
> pretty obvious: we have driver that is not being tested at all
> within DevStack and project integration.
 This was discussed in the oslo.messaging summit session, and
 re-enabling zeromq support in devstack is definately on my todo list,
 but I don't think the should block landing of the currently proposed
 unit tests on oslo.messaging.
 
 For example https://review.openstack.org/#/c/128233/ says about adding
>>> functional and units. I'm ok with units, but what about functional tests?
>>> Which oslo.messaging gate job runs them?
>>> 
>>> 
> Also i’d say that such focus re-orientation would be very useful
> as source of use cases and bugs eventually. Here’s a list of what
> we, as team, should do first:
> 
> 1.
> 
> Ensure that DevStack can successfully:
> 
> 1.
> 
> Install ZeroMQ.
> 
> 2.
> 
> Configure  each project to work with zmq driver from
> oslo.messaging.
> 
> 2.
> 
> Ensure that we can run successfully simple test plan for each
> project (like boot VM, fill object store container, spin up volume,
> etc.).
>>

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Joshua Harlow 

Doug Hellmann wrote:

On Nov 17, 2014, at 10:01 AM, Denis Makogon  wrote:


On Mon, Nov 17, 2014 at 4:26 PM, James Page  wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Denis

On 17/11/14 07:43, Denis Makogon wrote:

During Paris Design summit oslo.messaging session was raised good
question about maintaining ZeroMQ driver in upstream (see section
“dropping ZeroMQ support in oslo.messaging” at [1]) . As we all
know, good thoughts are comming always after. I’d like to propose
several improvements in process of maintaining and developing of
ZeroMQ driver in upstream.

Contribution focus. As we all see, that there are enough patches
that are trying to address certain problems related to ZeroMQ
driver.

Few of them trying to add functional tests, which is definitely
good, but … there’s always ‘but’, they are not “gate”-able.

I'm not sure I understand you statement about them not being
"gate"-able - the functional/unit tests currently proposed for the zmq
driver run fine as part of the standard test suite execution - maybe
the confusion is over what 'functional' actually means, but in my
opinion until we have some level of testing of this driver, we can't
effectively make changes and fix bugs.


I do agree that there's a confusion what "functional testing" means.
Another thing, what the best solution is? Unit tests are welcome, but they
are still remain to be units (they are using mocks, etc.)
I'd try to define what 'fuctional testing' means for me. Functional testing
in oslo.messaging means that we've been using real service for messaging
(in this case - deployed 0mq). So, the simple definition, in term os
OpenStack integration, we should be able to run full Tempest test suit for
OpenStack services that are using oslo.messaging with enabled zmq driver.
Am i right or not?


That’s a good goal, but that’s not what I had in mind for in-tree functional 
tests.

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 tests written against the 
app rather than the driver. Once we have the app and tests, we can define a new 
gate job to run those tests just for oslo.messaging, with a different 
configuration for each driver we support.

Doug


An interesting idea that might be useful that taskflow implemented/has 
done...


The examples @ 
https://github.com/openstack/taskflow/tree/master/taskflow/examples all 
get tested during unit test runs to ensure they work as expected. This 
seems close to your 'simple app' (where app is replaced with example), 
it might be nice to have a similar approach for oslo.messaging that has 
'examples' that are these apps that get ran to probe the functionality 
of oslo.messaging (as well as useful for documentation to show people 
how to use it, which is the other usage taskflow has for these examples)


The hacky example tester could likely be shared (or refactored, since it 
probably needs it), 
https://github.com/openstack/taskflow/blob/master/taskflow/tests/test_examples.py#L91







My proposal for this topic is to change contribution focus from
oslo.messaging by itself to OpenStack/Infra project and DevStack
(subsequently to devstack-gate too).

I guess there would be questions “why?”.  I think the answer is
pretty obvious: we have driver that is not being tested at all
within DevStack and project integration.

This was discussed in the oslo.messaging summit session, and
re-enabling zeromq support in devstack is definately on my todo list,
but I don't think the should block landing of the currently proposed
unit tests on oslo.messaging.

For example https://review.openstack.org/#/c/128233/ says about adding

functional and units. I'm ok with units, but what about functional tests?
Which oslo.messaging gate job runs them?



Also i’d say that such focus re-orientation would be very useful
as source of use cases and bugs eventually. Here’s a list of what
we, as team, should do first:

1.

Ensure that DevStack can successfully:

1.

Install ZeroMQ.

2.

Configure  each project to work with zmq driver from
oslo.messaging.

2.

Ensure that we can run successfully simple test plan for each
project (like boot VM, fill object store container, spin up volume,
etc.).

A better objective would be able to run a full tempest test as
conducted with the RabbitMQ driver IMHO.



I do agree with this too. But we should define step-by-step plan for this
type of testing. Since we want to see quick gate feedback adding full test
suit would be an overhead, at least for now.



ZeroMQ driver maintainers communityorganization. During design
session was raised question about who uses zmq driver in
production.

I’ve seen folks from Canonical and few other companies. So, here’s
my proposals around improving process of maintaining of given
driver:

1.

Wit

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Joshua Harlow 

It should already be running.

Tooz has been testing with it[1]. Whats running in ubuntu is an older 
redis though so don't expect some of the new > 2.2.0 features to work 
until the ubuntu version is pushed out to all projects.


https://github.com/stackforge/tooz/blob/master/tooz/drivers/redis.py#L132

Doug Hellmann wrote:

On Nov 17, 2014, at 12:48 PM, Mehdi Abaakouk  wrote:


Signed PGP part
Le 2014-11-17 15:26, James Page a écrit :

This was discussed in the oslo.messaging summit session, and
re-enabling zeromq support in devstack is definately on my todo list,
but I don't think the should block landing of the currently proposed
unit tests on oslo.messaging.

I would like to see this tests landed too, even we need to install redis
or whatever and
to start them manually. This will help a lot to review zmq stuffs and
ensure fixed thing are not broken again.


What’s blocking us from setting that up? Is redis available in the CI 
environment?

Doug


---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Sent with Postbox 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Doug Hellmann 

On Nov 17, 2014, at 12:48 PM, Mehdi Abaakouk  wrote:

> 
> Signed PGP part
> Le 2014-11-17 15:26, James Page a écrit :
> > This was discussed in the oslo.messaging summit session, and
> > re-enabling zeromq support in devstack is definately on my todo list,
> > but I don't think the should block landing of the currently proposed
> > unit tests on oslo.messaging.
> 
> I would like to see this tests landed too, even we need to install redis
> or whatever and
> to start them manually. This will help a lot to review zmq stuffs and
> ensure fixed thing are not broken again.

What’s blocking us from setting that up? Is redis available in the CI 
environment?

Doug

> 
> ---
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Doug Hellmann 

On Nov 17, 2014, at 10:01 AM, Denis Makogon  wrote:

> On Mon, Nov 17, 2014 at 4:26 PM, James Page  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Hi Denis
>> 
>> On 17/11/14 07:43, Denis Makogon wrote:
>>> During Paris Design summit oslo.messaging session was raised good
>>> question about maintaining ZeroMQ driver in upstream (see section
>>> “dropping ZeroMQ support in oslo.messaging” at [1]) . As we all
>>> know, good thoughts are comming always after. I’d like to propose
>>> several improvements in process of maintaining and developing of
>>> ZeroMQ driver in upstream.
>>> 
>>> Contribution focus. As we all see, that there are enough patches
>>> that are trying to address certain problems related to ZeroMQ
>>> driver.
>>> 
>>> Few of them trying to add functional tests, which is definitely
>>> good, but … there’s always ‘but’, they are not “gate”-able.
>> 
>> I'm not sure I understand you statement about them not being
>> "gate"-able - the functional/unit tests currently proposed for the zmq
>> driver run fine as part of the standard test suite execution - maybe
>> the confusion is over what 'functional' actually means, but in my
>> opinion until we have some level of testing of this driver, we can't
>> effectively make changes and fix bugs.
>> 
> 
> I do agree that there's a confusion what "functional testing" means.
> Another thing, what the best solution is? Unit tests are welcome, but they
> are still remain to be units (they are using mocks, etc.)
> I'd try to define what 'fuctional testing' means for me. Functional testing
> in oslo.messaging means that we've been using real service for messaging
> (in this case - deployed 0mq). So, the simple definition, in term os
> OpenStack integration, we should be able to run full Tempest test suit for
> OpenStack services that are using oslo.messaging with enabled zmq driver.
> Am i right or not?

That’s a good goal, but that’s not what I had in mind for in-tree functional 
tests.

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 tests written against the 
app rather than the driver. Once we have the app and tests, we can define a new 
gate job to run those tests just for oslo.messaging, with a different 
configuration for each driver we support.

Doug

> 
> 
>>> My proposal for this topic is to change contribution focus from
>>> oslo.messaging by itself to OpenStack/Infra project and DevStack
>>> (subsequently to devstack-gate too).
>>> 
>>> I guess there would be questions “why?”.  I think the answer is
>>> pretty obvious: we have driver that is not being tested at all
>>> within DevStack and project integration.
>> 
>> This was discussed in the oslo.messaging summit session, and
>> re-enabling zeromq support in devstack is definately on my todo list,
>> but I don't think the should block landing of the currently proposed
>> unit tests on oslo.messaging.
>> 
>> For example https://review.openstack.org/#/c/128233/ says about adding
> functional and units. I'm ok with units, but what about functional tests?
> Which oslo.messaging gate job runs them?
> 
> 
>>> Also i’d say that such focus re-orientation would be very useful
>>> as source of use cases and bugs eventually. Here’s a list of what
>>> we, as team, should do first:
>>> 
>>> 1.
>>> 
>>> Ensure that DevStack can successfully:
>>> 
>>> 1.
>>> 
>>> Install ZeroMQ.
>>> 
>>> 2.
>>> 
>>> Configure  each project to work with zmq driver from
>>> oslo.messaging.
>>> 
>>> 2.
>>> 
>>> Ensure that we can run successfully simple test plan for each
>>> project (like boot VM, fill object store container, spin up volume,
>>> etc.).
>> 
>> A better objective would be able to run a full tempest test as
>> conducted with the RabbitMQ driver IMHO.
>> 
>> 
> I do agree with this too. But we should define step-by-step plan for this
> type of testing. Since we want to see quick gate feedback adding full test
> suit would be an overhead, at least for now.
> 
> 
>>> ZeroMQ driver maintainers communityorganization. During design
>>> session was raised question about who uses zmq driver in
>>> production.
>>> 
>>> I’ve seen folks from Canonical and few other companies. So, here’s
>>> my proposals around improving process of maintaining of given
>>> driver:
>>> 
>>> 1.
>>> 
>>> With respect to best practices of driver maintaining procedure, we
>>> might need to set up community sub-group. What would it give to us
>>> and to the project subsequently? It’s not pretty obvious, at least
>>> for now, but i’d try to light out couple moments:
>>> 
>>> 1.
>>> 
>>> continuous driver stability
>>> 
>>> 2.
>>> 
>>> continuous community support (across all OpenStack Project that are
>>> using same model: driver should have maintaining team, would it be
>>> a company or c

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Denis Makogon 
понедельник, 17 ноября 2014 г. пользователь James Page написал:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 17/11/14 09:01, Denis Makogon wrote:
> > I'm not sure I understand you statement about them not being
> > "gate"-able - the functional/unit tests currently proposed for the
> > zmq driver run fine as part of the standard test suite execution -
> > maybe the confusion is over what 'functional' actually means, but
> > in my opinion until we have some level of testing of this driver,
> > we can't effectively make changes and fix bugs.
> >
> > I do agree that there's a confusion what "functional testing"
> > means. Another thing, what the best solution is? Unit tests are
> > welcome, but they are still remain to be units (they are using
> > mocks, etc.) I'd try to define what 'fuctional testing' means for
> > me. Functional testing in oslo.messaging means that we've been
> > using real service for messaging (in this case - deployed 0mq). So,
> > the simple definition, in term os OpenStack integration, we should
> > be able to run full Tempest test suit for OpenStack services that
> > are using oslo.messaging with enabled zmq driver. Am i right or
> > not?
>
> 0mq is just a set of messaging semantics on top of tcp/ipc sockets; so
> its possible to test the entire tcp/ipc messaging flow standalone i.e.
> without involving any openstack services.  That's what the current
> test proposal includes - unit tests which mock out most things, and
> base functional tests that validate the tcp/icp messaging flows via
> the zmq-receiver proxy.  These are things that *just work* under a tox
> environment and don't require any special setup.
>
> Hm, I see what you've been trying to say. But unfortunately it breaks
whole idea of TDD. Why can't we just spend some time on getting non-voting
gates? Ok, let me describe what would satisfy all of us: Lest write up docs
that are describes how to setup(manually) environment to test out income
patches.

So, in any way. This topic is not for disagreement. It's for building out
team relationship.
I'd like to discuss next steps on developing zmq driver.

Kind regards,
Denis M.







> This will be supplemented with good devstack support and full tempest
> gate, but lets start from the bottom up please!  The work that's been
> done so far allows us to move forward with bug fixing and re-factoring
> that's backed up on having a base level of unit/functional tests.
>
> - --
> James Page
> Ubuntu and Debian Developer
> james.p...@ubuntu.com 
> jamesp...@debian.org 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJUajaZAAoJEL/srsug59jDm2wP/1xW99gc/63CXnNowJLwgCAK
> AflhWs4SAUSF0VizOFoys6j1ApjAwWDG33B927REH/YDNwmAd7PgHRilgcaBjR5w
> pgaPRctCHPpWtJCWRCAmgkogqJotN3gTDKORxRNaWo9otzjQQbyPP5sEzuLl86/8
> 0n9KjwhjdJV42fcoKYvWt18uvz9yVOQLlPqj0WhAuzfpeP/5ZkXkd/dOvh6rwJnk
> wc+ZExPBhdeMNwaJFPZvle++Ki6tZCV8P8+Be5rqTZxdnGxoct72YnIohW48E9Nu
> 1sjdJCg42vxIMZi8NfkJDDfTBWzOmkab2jcViIJd9ycTn8CT/e62ZK8nN/hnIjla
> qU8pdRxNkY7xY3AuVoTWYRZGAon+Pp6Xw3J+lh7xUYukKtP/PaN+PjLCmVYrfca0
> JQnc8N5bLfcZkz/tx8R09hxqV7cpaRZh/lM6D62XEMRQJ7y9rcUIaJQnHbsmqLw9
> lwriXjNE/77eyttQlGnItyBZrTFjCFED9zg6ihK5w0DNXQr3CbIvlgCjiWkXfxDD
> 1QK05SbsukSlnO+Aqfs/HNICMdiZmqxcqcUcVs/XnKXf5Bi/Y/P0haLb43nFoa3E
> FaOYvY/T5HSJDvrFK6+kzPgT2zF3sWy4bZjRwKLl8GM8Mm7K65nfd5APhVCnQq5X
> yZOvpJehduiy6W/lQgzk
> =HAiM
> -END PGP SIGNATURE-
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Denis Makogon 
понедельник, 17 ноября 2014 г. пользователь Mehdi Abaakouk написал:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Le 2014-11-17 15:26, James Page a écrit :
>
>> This was discussed in the oslo.messaging summit session, and
>> re-enabling zeromq support in devstack is definately on my todo list,
>> but I don't think the should block landing of the currently proposed
>> unit tests on oslo.messaging.
>>
>
> I would like to see this tests landed too, even we need to install redis
> or whatever and
> to start them manually. This will help a lot to review zmq stuffs and
> ensure fixed thing are not broken again.
>
>
I do agree that we need to find a way to prevent blocking of zmq
development. But I don't think that such testing way eventually will lead
us to failure. Why not just focus on setting up testing environment that
can be used for gating? Just as another example, we can consider on getting
at least 3d party CI for zmq driver until we have infra gating environment.


> - ---
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
> -BEGIN PGP SIGNATURE-
> Version: OpenPGP.js v.1.20131017
> Comment: http://openpgpjs.org
>
> wsFcBAEBCAAQBQJUajTzCRAYkrQvzqrryAAAN3AP+QEdd4/kc0y+6WB4d3Tu
> g19EfSLR/1ekSBK0AeBc7z7hlDh5wVnQF1t0cm4Kv/fg2+59+Kjc0FhoBeDR
> DbOe75vlJTkkUIK+RgPiFLm2prjV7oHQVA7x5E75IhewG+jlLtPm47Wj2b12
> wRpeIJC3ofR8OETZ6yxr8NVUvdEWrQk+E2XfDrs3SC55RMYl+so9/FxVlR4y
> qwg2EKyhBvjCF8B7j0f3kZqrOCUTi00ivLEN2t+gqCA1WDm7o0cqSVLGvqDW
> +HvgJTnVeCu9F+OgsSjpfrVcAiWsF4K5sxZtLv76fLL75simDVG04gOTi5ZL
> UtZ2HSQGHrdamTz/qu9FckdhMWoGeUq9XeJf1ulCqJ/9Q4GWlh3KwM/h0hws
> A3lKBRxwdiG4afkddhXH3CXa2WyN/genTEaitbk0rk0Q6Q0dumiLPC+P5txB
> Fpn1DgwXYMdKVOVWGhUuKVtVWHN35+bJIaGXA/j9MuzEVyTkxhQsOl2aC992
> SrQzLvOE9Ao9o4zQCChDnKPfVg8NcxFsljnf55uLBCWQT6zrKNLL18EY1JvL
> kacwKipFWyW4TGYQc33ibV66353W8WY6L07ihDFWYo5Ww0NTWtgNM2FUpM2L
> QgiP9DcGsOMJ+Ez41uXVLzPueal0KCkgXFbl4Vrrk5PflTvZx8kaXf8TTbei
> Kcmc
> =hgqJ
> -END PGP SIGNATURE-
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Kind regards,
Denis M.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread James Page 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/11/14 09:01, Denis Makogon wrote:
> I'm not sure I understand you statement about them not being 
> "gate"-able - the functional/unit tests currently proposed for the
> zmq driver run fine as part of the standard test suite execution -
> maybe the confusion is over what 'functional' actually means, but
> in my opinion until we have some level of testing of this driver,
> we can't effectively make changes and fix bugs.
> 
> I do agree that there's a confusion what "functional testing"
> means. Another thing, what the best solution is? Unit tests are
> welcome, but they are still remain to be units (they are using
> mocks, etc.) I'd try to define what 'fuctional testing' means for
> me. Functional testing in oslo.messaging means that we've been
> using real service for messaging (in this case - deployed 0mq). So,
> the simple definition, in term os OpenStack integration, we should
> be able to run full Tempest test suit for OpenStack services that
> are using oslo.messaging with enabled zmq driver. Am i right or
> not?

0mq is just a set of messaging semantics on top of tcp/ipc sockets; so
its possible to test the entire tcp/ipc messaging flow standalone i.e.
without involving any openstack services.  That's what the current
test proposal includes - unit tests which mock out most things, and
base functional tests that validate the tcp/icp messaging flows via
the zmq-receiver proxy.  These are things that *just work* under a tox
environment and don't require any special setup.

This will be supplemented with good devstack support and full tempest
gate, but lets start from the bottom up please!  The work that's been
done so far allows us to move forward with bug fixing and re-factoring
that's backed up on having a base level of unit/functional tests.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUajaZAAoJEL/srsug59jDm2wP/1xW99gc/63CXnNowJLwgCAK
AflhWs4SAUSF0VizOFoys6j1ApjAwWDG33B927REH/YDNwmAd7PgHRilgcaBjR5w
pgaPRctCHPpWtJCWRCAmgkogqJotN3gTDKORxRNaWo9otzjQQbyPP5sEzuLl86/8
0n9KjwhjdJV42fcoKYvWt18uvz9yVOQLlPqj0WhAuzfpeP/5ZkXkd/dOvh6rwJnk
wc+ZExPBhdeMNwaJFPZvle++Ki6tZCV8P8+Be5rqTZxdnGxoct72YnIohW48E9Nu
1sjdJCg42vxIMZi8NfkJDDfTBWzOmkab2jcViIJd9ycTn8CT/e62ZK8nN/hnIjla
qU8pdRxNkY7xY3AuVoTWYRZGAon+Pp6Xw3J+lh7xUYukKtP/PaN+PjLCmVYrfca0
JQnc8N5bLfcZkz/tx8R09hxqV7cpaRZh/lM6D62XEMRQJ7y9rcUIaJQnHbsmqLw9
lwriXjNE/77eyttQlGnItyBZrTFjCFED9zg6ihK5w0DNXQr3CbIvlgCjiWkXfxDD
1QK05SbsukSlnO+Aqfs/HNICMdiZmqxcqcUcVs/XnKXf5Bi/Y/P0haLb43nFoa3E
FaOYvY/T5HSJDvrFK6+kzPgT2zF3sWy4bZjRwKLl8GM8Mm7K65nfd5APhVCnQq5X
yZOvpJehduiy6W/lQgzk
=HAiM
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Mehdi Abaakouk 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 2014-11-17 15:26, James Page a écrit :

This was discussed in the oslo.messaging summit session, and
re-enabling zeromq support in devstack is definately on my todo list,
but I don't think the should block landing of the currently proposed
unit tests on oslo.messaging.


I would like to see this tests landed too, even we need to install redis 
or whatever and
to start them manually. This will help a lot to review zmq stuffs and 
ensure fixed thing are not broken again.


- ---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

-BEGIN PGP SIGNATURE-
Version: OpenPGP.js v.1.20131017
Comment: http://openpgpjs.org

wsFcBAEBCAAQBQJUajTzCRAYkrQvzqrryAAAN3AP+QEdd4/kc0y+6WB4d3Tu
g19EfSLR/1ekSBK0AeBc7z7hlDh5wVnQF1t0cm4Kv/fg2+59+Kjc0FhoBeDR
DbOe75vlJTkkUIK+RgPiFLm2prjV7oHQVA7x5E75IhewG+jlLtPm47Wj2b12
wRpeIJC3ofR8OETZ6yxr8NVUvdEWrQk+E2XfDrs3SC55RMYl+so9/FxVlR4y
qwg2EKyhBvjCF8B7j0f3kZqrOCUTi00ivLEN2t+gqCA1WDm7o0cqSVLGvqDW
+HvgJTnVeCu9F+OgsSjpfrVcAiWsF4K5sxZtLv76fLL75simDVG04gOTi5ZL
UtZ2HSQGHrdamTz/qu9FckdhMWoGeUq9XeJf1ulCqJ/9Q4GWlh3KwM/h0hws
A3lKBRxwdiG4afkddhXH3CXa2WyN/genTEaitbk0rk0Q6Q0dumiLPC+P5txB
Fpn1DgwXYMdKVOVWGhUuKVtVWHN35+bJIaGXA/j9MuzEVyTkxhQsOl2aC992
SrQzLvOE9Ao9o4zQCChDnKPfVg8NcxFsljnf55uLBCWQT6zrKNLL18EY1JvL
kacwKipFWyW4TGYQc33ibV66353W8WY6L07ihDFWYo5Ww0NTWtgNM2FUpM2L
QgiP9DcGsOMJ+Ez41uXVLzPueal0KCkgXFbl4Vrrk5PflTvZx8kaXf8TTbei
Kcmc
=hgqJ
-END PGP SIGNATURE-


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Denis Makogon 
On Mon, Nov 17, 2014 at 5:12 PM, Eric Windisch  wrote:

>
>
> On Mon, Nov 17, 2014 at 8:43 AM, Denis Makogon 
> wrote:
>
>> Good day, Stackers.
>>
>>
>> During Paris Design summit oslo.messaging session was raised good
>> question about maintaining ZeroMQ driver in upstream (see section “dropping
>> ZeroMQ support in oslo.messaging” at [1]) . As we all know, good
>> thoughts are comming always after. I’d like to propose several improvements
>> in process of maintaining and developing of ZeroMQ driver in upstream.
>>
>>
>>
> I'm glad to see the community looking to revive this driver. What I think
> could be valuable if there are enough developers is a sub-team as is done
> with Nova. That doesn't mean to splinter the community, but to provide a
> focal point for interested developers to interact.
>
>
Yes, that's what i've been trying to say, sub-group'ing doing mean
"completely new community". The reason why i've proposed it is a need to
maintain driver by those who's interested in it. As already said, there're
not so many of us who uses (or considering) zmq driver. So, eventually,
we're on the same boat - let's co-work on making it better than it is now.


> I agree with the idea that this should be tested via Tempest. It's easy
> enough to mask off the failing tests and enable more tests as either the
> driver itself improves, or support in consuming projects and/or
> oslo.messaging itself improves. I'd suggest that effort is better spent
> there than building new bespoke tests.
>
> Thanks and good luck! :)
>
> Regards,
> Eric Windisch
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
Best regards,
Denis M.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Eric Windisch 
On Mon, Nov 17, 2014 at 8:43 AM, Denis Makogon 
wrote:

> Good day, Stackers.
>
>
> During Paris Design summit oslo.messaging session was raised good question
> about maintaining ZeroMQ driver in upstream (see section “dropping ZeroMQ
> support in oslo.messaging” at [1]) . As we all know, good thoughts are
> comming always after. I’d like to propose several improvements in process
> of maintaining and developing of ZeroMQ driver in upstream.
>
>
>
I'm glad to see the community looking to revive this driver. What I think
could be valuable if there are enough developers is a sub-team as is done
with Nova. That doesn't mean to splinter the community, but to provide a
focal point for interested developers to interact.

I agree with the idea that this should be tested via Tempest. It's easy
enough to mask off the failing tests and enable more tests as either the
driver itself improves, or support in consuming projects and/or
oslo.messaging itself improves. I'd suggest that effort is better spent
there than building new bespoke tests.

Thanks and good luck! :)

Regards,
Eric Windisch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Denis Makogon 
On Mon, Nov 17, 2014 at 4:26 PM, James Page  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Denis
>
> On 17/11/14 07:43, Denis Makogon wrote:
> > During Paris Design summit oslo.messaging session was raised good
> > question about maintaining ZeroMQ driver in upstream (see section
> > “dropping ZeroMQ support in oslo.messaging” at [1]) . As we all
> > know, good thoughts are comming always after. I’d like to propose
> > several improvements in process of maintaining and developing of
> > ZeroMQ driver in upstream.
> >
> > Contribution focus. As we all see, that there are enough patches
> > that are trying to address certain problems related to ZeroMQ
> > driver.
> >
> > Few of them trying to add functional tests, which is definitely
> > good, but … there’s always ‘but’, they are not “gate”-able.
>
> I'm not sure I understand you statement about them not being
> "gate"-able - the functional/unit tests currently proposed for the zmq
> driver run fine as part of the standard test suite execution - maybe
> the confusion is over what 'functional' actually means, but in my
> opinion until we have some level of testing of this driver, we can't
> effectively make changes and fix bugs.
>

I do agree that there's a confusion what "functional testing" means.
Another thing, what the best solution is? Unit tests are welcome, but they
are still remain to be units (they are using mocks, etc.)
I'd try to define what 'fuctional testing' means for me. Functional testing
in oslo.messaging means that we've been using real service for messaging
(in this case - deployed 0mq). So, the simple definition, in term os
OpenStack integration, we should be able to run full Tempest test suit for
OpenStack services that are using oslo.messaging with enabled zmq driver.
Am i right or not?


> > My proposal for this topic is to change contribution focus from
> > oslo.messaging by itself to OpenStack/Infra project and DevStack
> > (subsequently to devstack-gate too).
> >
> > I guess there would be questions “why?”.  I think the answer is
> > pretty obvious: we have driver that is not being tested at all
> > within DevStack and project integration.
>
> This was discussed in the oslo.messaging summit session, and
> re-enabling zeromq support in devstack is definately on my todo list,
> but I don't think the should block landing of the currently proposed
> unit tests on oslo.messaging.
>
> For example https://review.openstack.org/#/c/128233/ says about adding
functional and units. I'm ok with units, but what about functional tests?
Which oslo.messaging gate job runs them?


> > Also i’d say that such focus re-orientation would be very useful
> > as source of use cases and bugs eventually. Here’s a list of what
> > we, as team, should do first:
> >
> > 1.
> >
> > Ensure that DevStack can successfully:
> >
> > 1.
> >
> > Install ZeroMQ.
> >
> > 2.
> >
> > Configure  each project to work with zmq driver from
> > oslo.messaging.
> >
> > 2.
> >
> > Ensure that we can run successfully simple test plan for each
> > project (like boot VM, fill object store container, spin up volume,
> > etc.).
>
> A better objective would be able to run a full tempest test as
> conducted with the RabbitMQ driver IMHO.
>
>
I do agree with this too. But we should define step-by-step plan for this
type of testing. Since we want to see quick gate feedback adding full test
suit would be an overhead, at least for now.


> > ZeroMQ driver maintainers communityorganization. During design
> > session was raised question about who uses zmq driver in
> > production.
> >
> > I’ve seen folks from Canonical and few other companies. So, here’s
> > my proposals around improving process of maintaining of given
> > driver:
> >
> > 1.
> >
> > With respect to best practices of driver maintaining procedure, we
> > might need to set up community sub-group. What would it give to us
> > and to the project subsequently? It’s not pretty obvious, at least
> > for now, but i’d try to light out couple moments:
> >
> > 1.
> >
> > continuous driver stability
> >
> > 2.
> >
> > continuous community support (across all OpenStack Project that are
> > using same model: driver should have maintaining team, would it be
> > a company or community sub-group)
> >
> > 2.
> >
> > As sub-group we would need to have our own weekly meeting. Separate
> > meeting would keep us, as sub-group, pretty focused on zmq driver
> > only (but it doesn’t mean that we should not participate in regular
> > meetings). Same question. What it would give us and to the project?
> > I’d say that the only one valid answer is: we’d not disturb other
> > folk that are not actually interested in given topic and in zqm
> > drive too.
>
> I'd prefer that we continue to discuss ZMQ on the broader
> oslo.messaging context; I'm keen that the OpenStack community
> understands that we want ZMQ to be a first tier driver like qpid and
> rmq, and I'm not convinced that pushing discussion out to a separate
> sub-group enforces

Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread James Page 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Denis

On 17/11/14 07:43, Denis Makogon wrote:
> During Paris Design summit oslo.messaging session was raised good 
> question about maintaining ZeroMQ driver in upstream (see section 
> “dropping ZeroMQ support in oslo.messaging” at [1]) . As we all
> know, good thoughts are comming always after. I’d like to propose
> several improvements in process of maintaining and developing of
> ZeroMQ driver in upstream.
> 
> Contribution focus. As we all see, that there are enough patches
> that are trying to address certain problems related to ZeroMQ
> driver.
> 
> Few of them trying to add functional tests, which is definitely
> good, but … there’s always ‘but’, they are not “gate”-able.

I'm not sure I understand you statement about them not being
"gate"-able - the functional/unit tests currently proposed for the zmq
driver run fine as part of the standard test suite execution - maybe
the confusion is over what 'functional' actually means, but in my
opinion until we have some level of testing of this driver, we can't
effectively make changes and fix bugs.

> My proposal for this topic is to change contribution focus from 
> oslo.messaging by itself to OpenStack/Infra project and DevStack 
> (subsequently to devstack-gate too).
> 
> I guess there would be questions “why?”.  I think the answer is
> pretty obvious: we have driver that is not being tested at all
> within DevStack and project integration.

This was discussed in the oslo.messaging summit session, and
re-enabling zeromq support in devstack is definately on my todo list,
but I don't think the should block landing of the currently proposed
unit tests on oslo.messaging.

> Also i’d say that such focus re-orientation would be very useful
> as source of use cases and bugs eventually. Here’s a list of what
> we, as team, should do first:
> 
> 1.
> 
> Ensure that DevStack can successfully:
> 
> 1.
> 
> Install ZeroMQ.
> 
> 2.
> 
> Configure  each project to work with zmq driver from 
> oslo.messaging.
> 
> 2.
> 
> Ensure that we can run successfully simple test plan for each 
> project (like boot VM, fill object store container, spin up volume,
> etc.).

A better objective would be able to run a full tempest test as
conducted with the RabbitMQ driver IMHO.

> ZeroMQ driver maintainers communityorganization. During design
> session was raised question about who uses zmq driver in
> production.
> 
> I’ve seen folks from Canonical and few other companies. So, here’s
> my proposals around improving process of maintaining of given
> driver:
> 
> 1.
> 
> With respect to best practices of driver maintaining procedure, we
> might need to set up community sub-group. What would it give to us
> and to the project subsequently? It’s not pretty obvious, at least
> for now, but i’d try to light out couple moments:
> 
> 1.
> 
> continuous driver stability
> 
> 2.
> 
> continuous community support (across all OpenStack Project that are
> using same model: driver should have maintaining team, would it be
> a company or community sub-group)
> 
> 2.
> 
> As sub-group we would need to have our own weekly meeting. Separate
> meeting would keep us, as sub-group, pretty focused on zmq driver
> only (but it doesn’t mean that we should not participate in regular
> meetings). Same question. What it would give us and to the project?
> I’d say that the only one valid answer is: we’d not disturb other
> folk that are not actually interested in given topic and in zqm
> drive too.

I'd prefer that we continue to discuss ZMQ on the broader
oslo.messaging context; I'm keen that the OpenStack community
understands that we want ZMQ to be a first tier driver like qpid and
rmq, and I'm not convinced that pushing discussion out to a separate
sub-group enforces that message...

> So, in the end, taking into account words above i’d like to get 
> feedback from all folks. I’m pretty open for discussion, and if
> needed i can commit myself for driving such activities in
> oslo.messaging.

- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUagWDAAoJEL/srsug59jDWncP/2PVkA3tDHxLILjdyXKdLLy6
fsj5yovho45T9LtSrLXD1Y+CT3pQqGDnglB+J8kUBkX56zJLWzSH1szWfRo5Y4Ms
kI0c3K8LxJ6PT4+j/A5JzNt37IhAwBTJ25QcRdzAUgV06IZ3F9ctz9F9lW1GDx/q
u5XvctYacKWhXH/Z/5Y2g3VE2aJSZNlgLA3PxLZeUEQaREj7XeC5x77FZbBYHVI6
E8E8B2H5nf+wln80zIm5rax3vzGh0rZVT/fgUgVcQan33XaFl64zrimjhEUXHUVF
QHIVJ4PNVklqMAEliAq0JMe6ewo1rgbS6DOcB8yOD3RWNo+d/MwSbYiwM/iXI9ya
DpqXK0HVfSbXgoAAqNl2eP5TfvZCtlRk1h3hqhc+843c7i+i2psMZ2mVN6LeJKdt
7EvwY8xQErjKSbsmEjtV069ajjipP3hnmhyUwwJiFM2q8eKMIWRn+WDol88+f4Ke
NmguGjNzKkqqvWSS/IJVT+qHYEsm3GalLT1ZTDaagHpreIJ7vcXxSZTcoGLO6Nhs
445cPZcek6jS+lhf81S13+hmfA1ZgQW2f4Yz5hv15xn90K/OaWE2/Z9AFfsOGWOA
0FoyNY5FSGsNCG/km1BlfVSMWzB4wWpWzunMPFmwme/FoqAjvD4kt6kFKLu9DI1g
/L5WRZfi7Cu7eCC/X6c7
=NBH2
-END PGP SIGNATURE-

___
OpenStack-dev mailing l

[openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps

2014-11-17 Thread Denis Makogon 
Good day, Stackers.


During Paris Design summit oslo.messaging session was raised good question
about maintaining ZeroMQ driver in upstream (see section “dropping ZeroMQ
support in oslo.messaging” at [1]) . As we all know, good thoughts are
comming always after. I’d like to propose several improvements in process
of maintaining and developing of ZeroMQ driver in upstream.


Contribution focus. As we all see, that there are enough patches that are
trying to address certain problems related to ZeroMQ driver.

Few of them trying to add functional tests, which is definitely good, but …
there’s always ‘but’, they are not “gate”-able.

My proposal for this topic is to change contribution focus from
oslo.messaging by itself to OpenStack/Infra project and DevStack
(subsequently to devstack-gate too).

I guess there would be questions “why?”.  I think the answer is pretty
obvious: we have driver that is not being tested at all within DevStack and
project integration.

Also i’d say that such focus re-orientation would be very useful as source
of use cases and bugs eventually. Here’s a list of what we, as team, should
do first:

   1.

  Ensure that DevStack can successfully:
  1.

 Install ZeroMQ.
 2.

 Configure  each project to work with zmq driver from
 oslo.messaging.
 2.

  Ensure that we can run successfully simple test plan for each project
  (like boot VM, fill object store container, spin up volume, etc.).


ZeroMQ driver maintainers community organization. During design session was
raised question about who uses zmq driver in production.

I’ve seen folks from Canonical and few other companies. So, here’s my
proposals around improving process of maintaining of given driver:

   1.

  With respect to best practices of driver maintaining procedure, we
  might need to set up community sub-group. What would it give to us and to
  the project subsequently? It’s not pretty obvious, at least for now, but
  i’d try to light out couple moments:
  1.

 continuous driver stability
 2.

 continuous community support (across all OpenStack Project that
 are using same model: driver should have maintaining team,
would it be a
 company or community sub-group)
 2.

  As sub-group we would need to have our own weekly meeting. Separate
  meeting would keep us, as sub-group, pretty focused on zmq
driver only (but
  it doesn’t mean that we should not participate in regular meetings). Same
  question. What it would give us and to the project? I’d say that the only
  one valid answer is: we’d not disturb other folk that are not actually
  interested in given topic and in zqm drive too.


So, in the end, taking into account words above i’d like to get
feedback from all folks. I’m pretty open for discussion, and if needed i
can commit myself for driving such activities in oslo.messaging.


[1] https://etherpad.openstack.org/p/kilo-oslo-oslo.messaging


Kind regards,

Denis M.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev