[openstack-dev] [midonet] Split up python-midonetclient

Dan Mihai Dumitriu dan at midokura.com
Tue Dec 15 12:15:08 UTC 2015


Just leave it as is. This whole thread is a waste of time.
On Dec 15, 2015 18:52, "Jaume Devesa" <devvesa at 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+openstackml at midokura.com> wrote:
>
>>
>>
>> On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa <devvesa at 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 <ryu at midokura.com> wrote:
>>>
>>>> On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys <sandro at midokura.com>
>>>> wrote:
>>>> > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto <ryu at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151215/7daed47f/attachment.html>


More information about the OpenStack-dev mailing list