Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
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
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 harlo...@outlook.com wrote: Doug Hellmann wrote: On Nov 17, 2014, at 10:01 AM, Denis Makogondmako...@mirantis.com wrote: On Mon, Nov 17, 2014 at 4:26 PM, James Pagejames.p...@ubuntu.com 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
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
-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] [oslo.messaging] ZeroMQ driver maintenance next steps
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
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
-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 list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
On Mon, Nov 17, 2014 at 4:26 PM, James Page james.p...@ubuntu.com 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 that message... The only thing that i'm woried about is that we could eventually eat all meeting time. That's why i try to build out drive maintaining/contribution
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
On Mon, Nov 17, 2014 at 8:43 AM, Denis Makogon dmako...@mirantis.com 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
On Mon, Nov 17, 2014 at 5:12 PM, Eric Windisch e...@windisch.us wrote: On Mon, Nov 17, 2014 at 8:43 AM, Denis Makogon dmako...@mirantis.com 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
-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
-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
понедельник, 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
понедельник, 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 javascript:; jamesp...@debian.org javascript:; -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 javascript:; 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
On Nov 17, 2014, at 10:01 AM, Denis Makogon dmako...@mirantis.com wrote: On Mon, Nov 17, 2014 at 4:26 PM, James Page james.p...@ubuntu.com 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 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
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
On Nov 17, 2014, at 12:48 PM, Mehdi Abaakouk sil...@sileht.net 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
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 Abaakouksil...@sileht.net 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 http://www.getpostbox.com ___ 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
Doug Hellmann wrote: On Nov 17, 2014, at 10:01 AM, Denis Makogondmako...@mirantis.com wrote: On Mon, Nov 17, 2014 at 4:26 PM, James Pagejames.p...@ubuntu.com 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
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
On Nov 17, 2014, at 3:36 PM, Joshua Harlow harlo...@outlook.com wrote: Doug Hellmann wrote: On Nov 17, 2014, at 10:01 AM, Denis Makogondmako...@mirantis.com wrote: On Mon, Nov 17, 2014 at 4:26 PM, James Pagejames.p...@ubuntu.com 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.). 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
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
On Mon, Nov 17, 2014 at 3:33 PM, Joshua Harlow 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
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
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 harlo...@outlook.com 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
-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
вторник, 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
