[openstack-dev] [midonet] Split up python-midonetclient
Antoni Segura Puimedon
toni+openstackml at midokura.com
Mon Dec 14 17:43:45 UTC 2015
On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa <devvesa at gmail.com> wrote:
> I think it is good compromise. Thanks Ryu!
> I understand the CLI will belong to the external part. I much prefer to
> it in a separate project rather than into the plugin. Even if the code is
Let me summarize it:
python-midonetclient: Low level API that lives and breathes in
Has the current cli.
python-os-midonetclient: High level API that is in
(can be packaged with a different
Are you asking for python-os-midonetclient not to include the cli tool?
I would prefer to keep with the OpenStack practice  of having it
together. I don't
think developing a python cli client for the new python-os-midonetclient
on par with the neutron cli tool would be that big of a task and I think it
make operation nicer. It could even find the midonet-api from the zookeeper
registry like the other tools do.
> If you will want to just do midonet calls for debugging or check the
> virtual infrastructure, it will be cleaner to install it without
> dependencies than
> dragging the whole neutron project (networking-midonet depends on neutron).
> 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>
>> > On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto <ryu at midokura.com>
>> > 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.
>> > -- Sandro
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> Jaume Devesa
> Software Engineer at Midokura
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev