[openstack-dev] [neutron] monkey patching strategy

Salvatore Orlando sorlando at nicira.com
Tue Feb 17 15:19:58 UTC 2015


My opinions inline.

On 17 February 2015 at 16:04, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> -----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,
>

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.

>
> - - 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://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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150217/9fa6ddc7/attachment.html>


More information about the OpenStack-dev mailing list