<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa <span dir="ltr"><<a href="mailto:devvesa@gmail.com" target="_blank">devvesa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div 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 style="font-family:arial,helvetica,sans-serif">it in a separate project rather than into the plugin. Even if the code is tiny.<br></div></div></blockquote><div><br></div><div>Let me summarize it:<br><br></div><div>python-midonetclient: Low level API that lives and breathes in midonet/midonet.<br></div><div> Has the current cli.<br></div><div>python-os-midonetclient: High level API that is in openstack/python-midonetclient<br> (can be packaged with a different name).<br><br></div><div>Are you asking for python-os-midonetclient not to include the cli tool?<br><br></div><div>I would prefer to keep with the OpenStack practice [1] of having it together. I don't<br>think developing a python cli client for the new python-os-midonetclient that is<br></div><div>on par with the neutron cli tool would be that big of a task and I think it would<br></div><div>make operation nicer. It could even find the midonet-api from the zookeeper<br></div><div>registry like the other tools do.<br></div><div> <br>[1] <a href="https://github.com/openstack/python-neutronclient/blob/master/setup.cfg">https://github.com/openstack/python-neutronclient/blob/master/setup.cfg</a><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div 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 style="font-family:arial,helvetica,sans-serif">dragging the whole neutron project (networking-midonet depends on neutron).<br><br></div><div style="font-family:arial,helvetica,sans-serif">Regards,<br></div></div><div class="gmail_extra"><div><div class="h5"><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys <<a href="mailto:sandro@midokura.com" target="_blank">sandro@midokura.com</a>> wrote:<br>
> On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto <<a href="mailto:ryu@midokura.com" target="_blank">ryu@midokura.com</a>> wrote:<br>
><br>
</span><span>> 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><div><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></div></div><span class="">-- <br><div><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>
</span></div>
<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>
<br></blockquote></div><br></div></div>