On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys <san...@midokura.com> wrote: > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto <r...@midokura.com> wrote: > > 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.
Thanks for the endorsement. Yes, it is trivial to separate them (less than a day of work) because they are pretty much already separated. As for the naming, I think it's better to take a non-disruptive approach so that it's transparent to those currently developing the low level midonet client. To your question, however, I have another suggestion, which is that for the high level client code, it may also make sense to just include that as part of the plugin. It's such small code that it might not make sense to separate, and also likely to be used only by the plugin in the future. Which basically means that the plugin need not depend on any python client library at all. I think this will simplify even further. It should also be ok to be tied to the plugin release cycles as well assuming that's the only place the client is needed. Cheers, Ryu > > -- 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