<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">+1 <br><br>I think it is good compromise. Thanks Ryu!<br><br>I understand the CLI will belong to the external part. I much prefer to have<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">it in a separate project rather than into the plugin. Even if the code is tiny.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If you will want to just do midonet calls for debugging or check the MidoNet<br>virtual infrastructure, it will be cleaner to install it without dependencies than<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">dragging the whole neutron project (networking-midonet depends on neutron).<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regards,<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 December 2015 at 17:32, Ryu Ishimoto <span dir="ltr"><<a href="mailto:ryu@midokura.com" target="_blank">ryu@midokura.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys <<a href="mailto:sandro@midokura.com">sandro@midokura.com</a>> wrote:<br>
> On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto <<a href="mailto:ryu@midokura.com">ryu@midokura.com</a>> wrote:<br>
><br>
</span><span class="">> So if I understand you correctly, you suggest:<br>
> 1) the (midonet/internal) low level API stays where it is and will<br>
> still be called python-midonetclient.<br>
> 2) the (neutron/external) high level API is moved into it's own<br>
> project and will be called something like python-os-midonetclient.<br>
><br>
> Sounds like a good compromise which addresses the most important<br>
> points, thanks Ryu! I wasn't aware that these parts of the<br>
> python-midonetclient are so clearly distinguishable/separable but if<br>
> so, this makes perfect sense. Not perfectly happy with the naming, but<br>
> I figure it's the way to go.<br>
<br>
</span>Thanks for the endorsement.  Yes, it is trivial to separate them (less<br>
than a day of work) because they are pretty much already separated.<br>
<br>
As for the naming, I think it's better to take a non-disruptive<br>
approach so that it's transparent to those currently developing the<br>
low level midonet client.  To your question, however, I have another<br>
suggestion, which is that for the high level client code, it may also<br>
make sense to just include that as part of the plugin.  It's such<br>
small code that it might not make sense to separate, and also likely<br>
to be used only by the plugin in the future.  Which basically means<br>
that the plugin need not depend on any python client library at all.<br>
I think this will simplify even further.  It should also be ok to be<br>
tied to the plugin release cycles as well assuming that's the only<br>
place the client is needed.<br>
<br>
Cheers,<br>
Ryu<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
> -- Sandro<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><font face="tahoma, sans-serif">Jaume Devesa</font><div><font face="tahoma, sans-serif">Software Engineer at Midokura</font></div></div></div>
</div>