-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/17/2015 04:19 PM, Salvatore Orlando wrote: > My opinions inline. > > On 17 February 2015 at 16:04, Ihar Hrachyshka <ihrac...@redhat.com > <mailto:ihrac...@redhat.com>> wrote: > > Hi, > > response was huge so far :) so to add more traction, I have a > question for everyone. Let's assume we want to move entry points > for all services and agents into neutron/cmd/... If so, > > >> I don't have anything again this assumption. Also it seems other >> projects are already doing it this way so there is no >> "divergence" issue here. > > > - Do we want all existing tools stored in the path to be monkey > patched too? I would say 'yes', to make sure we run our unit tests > in the same environment as in real life; > > >> I say yes but mildly here. If you're referring to the tools used >> for running flake8 or unit tests in theory it should not really >> matter whether they're patched or not. However, I'm aware of unit >> tests which spawn eventlet threadpools, so it's definitely better >> to ensure all these tools are patched. >
No, I mean ovs_cleanup, sanity_check, usage_audit that are located in the neutron/cmd path but not patched. > > - Which parts of services we want to see there? Should they > include any real main() or register_options() code, or should they > be just a wrappers to call actual main() located somewhere in other > parts of the tree? I lean toward leaving just a one liner main() > under neutron/cmd/... that calls to 'real' main() located in a > different place in the tree. > > >> My vote is for the one-liner. > > > > Comments? > > /Ihar > > > On 02/13/2015 04:37 PM, Ihar Hrachyshka wrote: >> On 02/13/2015 02:33 AM, Kevin Benton wrote: >>> Why did the services fail with the stdlib patched? Are they >>> incompatible with eventlet? > >> It's not like *service entry points* are not ready for neutron.* >> to be monkey patched, but tools around it (flake8 that imports >> neutron.hacking.checks, setuptools that import hooks from >> neutron.hooks etc). It's also my belief that base library should >> not be monkey patched not to put additional assumptions onto >> consumers. > >> (Though I believe that all the code in the tree should be monkey >> patched, including those agents that currently run without the >> library patched - for consistency and to reflect the same test >> environment for unit tests that will be patched from >> neutron/tests/__init__.py). > >> /Ihar > >> __________________________________________________________________________ > >> > > OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU429PAAoJEC5aWaUY1u57IkcH/1HCRHYzeXfWE3I3ZamAJufI /1/CPcrzW3w3pJebfSLXDNbdv9ziQXwZogcM7JcDMeeYfWA42OexhFQJqerkoJnr oL3eqUOgh19pgVUgAah1n7yQEHxyzbnVR0TcdVOvMlxno8I3hUXy78WvBWQPYIpr NRDSbT+SiQv/OP6/zTkKLkk2SA88lJlKQpGg5Q0iRQTnqiNtF3REBdUTM/32aJyh h9ZxmR8wyrXJv6oEUfGj210vJHUvmPHk3SsH2udQjCG0MdbIQTIZJwgzMVxD4aIs 3uQ9ONqn8Fd2LKzfawHVwT0azd6kCkQjEalZx9Tn/58NPuQ4WERhHcCzBT8pNyI= =DGy3 -----END PGP SIGNATURE----- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev