+1 I think it is good compromise. Thanks Ryu!
I understand the CLI will belong to the external part. I much prefer to have it in a separate project rather than into the plugin. Even if the code is tiny. If you will want to just do midonet calls for debugging or check the MidoNet virtual infrastructure, it will be cleaner to install it without dependencies than dragging the whole neutron project (networking-midonet depends on neutron). Regards, On 14 December 2015 at 17:32, Ryu Ishimoto <r...@midokura.com> wrote: > 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 > -- Jaume Devesa Software Engineer at Midokura
__________________________________________________________________________ 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
