Hi, The general discussion is going in https://review.openstack.org/#/c/148318/. My opinions on the following specific topics inline.
2015-02-18 0:04 GMT+09:00 Ihar Hrachyshka <ihrac...@redhat.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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, > > - - Do we want all existing tools stored in the path to be monkey > patched too? I start to think neutron/cmd/eventlet/* can be an option. The single place to apply monkey-patch is nice, but I am not sure it is good that all commands in neutron/cmd are monkey-patched. At now we only have small tools in cmd and they are not affected even if monkey-patched. If we have non-eventlet version of commands/agents, where should we place them? I believe that a good naming convention helps new/most developers understand the code base. > I would say 'yes', to make sure we run our unit tests in > the same environment as in real life; Regarding our unit tests, I am not sure what way is good. At now most codes are run with monkey-patched version of stdlib, so apply monkey-pathc in neutron/tests/__init__.py sounds good. However, what can we do if some non-eventlet modules are available? These modules should not be monkey-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 one-liner main(). More precisely, codes which are directly related to eventlet monkey-patch should be placed. It seems config options are not related to event monkey-patch directly. If we have non-eventlet version of commands/agents, real 'main' can stay in the same place and we can just remove the corresponding part from neutron/cmd/. Thanks, Akihiro > > 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJU41iWAAoJEC5aWaUY1u57zBYIAIuobIYMZ1NJmm+7sV+NW6LS > ZS4PNKlwcYRrdfArGliUq7GLVi/ZRNPNgilF9RIJXQAiOXEc6PmKqpKw1JnwkQ7v > l3/NeciYmkMhSNRv1vIrOBHegAYx9Js6o2lOBCF7BFKIpu88OsC95oobcLGtcrYU > BxoBUM7DYvHssDhRp3NujNbyMrRkg4roer7+4qGE3a449tv4xViTcoUWg5MoNalY > vD1ld/Gg8LfKPt7v7FbF2YnHkMG+UJSk47rRd0yv9KGABS69TkNuvJXeJ14sgw0O > YqIY3oMO0nza+T8tdQGTrYv9N4rWOMFsJMyrOLIvoUyq526QQZ/K7Hrijj1IQjE= > =ZtVP > -----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 -- Akihiro Motoki <amot...@gmail.com> __________________________________________________________________________ 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