[openstack-dev] [neutron] monkey patching strategy
Ihar Hrachyshka
ihrachys at redhat.com
Tue Feb 17 16:41:51 UTC 2015
-----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 <ihrachys at redhat.com
> <mailto:ihrachys at 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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at 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-----
More information about the OpenStack-dev
mailing list