On Mon, Dec 14, 2015 at 6:34 PM, Sandro Mathys <san...@midokura.com> wrote: > On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro <g...@midokura.com> wrote: >> > Honestly, I don't think this discussion is leading anywhere. > Therefore, I'd like to request a decision by the MidoNet PTL as per > [1].
I apologize for jumping in a bit late. Clearly, we have those feeling passionate about both solutions, with good points made on both sides, so let me try to do the impossible task of making everyone happy (or at least, not completely ticked off!). I believe what we need is to come up with a solution that minimizes inconvenience to the developers and packagers alike, and not a one-sided solution. MidoNet client is currently a mix of the low level MidoNet API client and high level (Neutron) API client, and they are mutually exclusive, and the code can be cleanly separated easily. I propose that we extract the high level API client code and make it it's own project, and leave the low level MidoNet API client code as is. My reasons are as follows: * We should try our best to follow the conventions of the OSt model as much as possible. Without embracing their model, we are distancing ourselves further from becoming part of the Big Tent. So let's move the client code that the Neutron plugin depends on to a separate project (python-os-midonetclient?) so that it follows the convention, and will simplify things for OSt packagers. From OSt's point of view, python-midonetclient should be completely forgotten. * We should not cause inconvenience to the current developers of the low level MidoNet API, who develop python-midonetclient and midonet-cli for testing purposes (MDTS, for example). Because the testing framework is part of midonet, moving python-midonetclient out of midonet will cause awkward development process for the midonet developers who will need to go back and forth between the projects. Also, by keeping them inside midonet, no change is required for packaging of python-midonetclient. There are still users of the low level midonet API, so we will have to keep releasing the python-midonetclient package as we do now, but it does not necessarily have to be published for the OSt distributors. We have a clear separation of preferences among those that are from the OpenStack background and those that are not. Thus, it makes the most sense to separate the projects the same way so that each party is responsible for the part that they consume. I hope this achieves the right balance. Let me know if there are strong objections against this proposal. Best, Ryu __________________________________________________________________________ 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