Just leave it as is. This whole thread is a waste of time. On Dec 15, 2015 18:52, "Jaume Devesa" <devv...@gmail.com> wrote:
> No. I'm saying that I prefer python-os-midonetclient to be a project by > its own > instead of being merged inside the neutron plugin repo. > > On 14 December 2015 at 18:43, Antoni Segura Puimedon < > toni+openstac...@midokura.com> wrote: > >> >> >> On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa <devv...@gmail.com> wrote: >> >>> +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. >>> >> >> Let me summarize it: >> >> python-midonetclient: Low level API that lives and breathes in >> midonet/midonet. >> Has the current cli. >> python-os-midonetclient: High level API that is in >> openstack/python-midonetclient >> (can be packaged with a >> different name). >> >> Are you asking for python-os-midonetclient not to include the cli tool? >> >> I would prefer to keep with the OpenStack practice [1] of having it >> together. I don't >> think developing a python cli client for the new python-os-midonetclient >> that is >> on par with the neutron cli tool would be that big of a task and I think >> it would >> make operation nicer. It could even find the midonet-api from the >> zookeeper >> registry like the other tools do. >> >> [1] >> https://github.com/openstack/python-neutronclient/blob/master/setup.cfg >> >>> >>> 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 >>> >>> >> >> __________________________________________________________________________ >> 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 > >
__________________________________________________________________________ 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