On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto <r...@midokura.com> wrote: > 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.
So if I understand you correctly, you suggest: 1) the (midonet/internal) low level API stays where it is and will still be called python-midonetclient. 2) the (neutron/external) high level API is moved into it's own project and will be called something like python-os-midonetclient. Sounds like a good compromise which addresses the most important points, thanks Ryu! I wasn't aware that these parts of the python-midonetclient are so clearly distinguishable/separable but if so, this makes perfect sense. Not perfectly happy with the naming, but I figure it's the way to go. -- Sandro __________________________________________________________________________ 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
