Open Stack

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 <ihrachys at 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-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



-- 
Akihiro Motoki <amotoki at gmail.com>