[openstack-dev] [midonet] Split up python-midonetclient
Ryu Ishimoto
ryu at midokura.com
Mon Dec 14 15:02:54 UTC 2015
On Mon, Dec 14, 2015 at 6:34 PM, Sandro Mathys <sandro at midokura.com> wrote:
> On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro <galo at midokura.com> wrote:
>>
> Honestly, I don't think this discussion is leading anywhere.
> Therefore, I'd like to request a decision by the MidoNet PTL as per
> [1].
I apologize for jumping in a bit late. Clearly, we have those feeling
passionate about both solutions, with good points made on both sides,
so let me try to do the impossible task of making everyone happy (or
at least, not completely ticked off!).
I believe what we need is to come up with a solution that minimizes
inconvenience to the developers and packagers alike, and not a
one-sided solution. MidoNet client is currently a mix of the low
level MidoNet API client and high level (Neutron) API client, and they
are mutually exclusive, and the code can be cleanly separated easily.
I propose that we extract the high level API client code and make it
it's own project, and leave the low level MidoNet API client code as
is.
My reasons are as follows:
* We should try our best to follow the conventions of the OSt model as
much as possible. Without embracing their model, we are distancing
ourselves further from becoming part of the Big Tent. So let's move
the client code that the Neutron plugin depends on to a separate
project (python-os-midonetclient?) so that it follows the convention,
and will simplify things for OSt packagers. From OSt's point of view,
python-midonetclient should be completely forgotten.
* We should not cause inconvenience to the current developers of the
low level MidoNet API, who develop python-midonetclient and
midonet-cli for testing purposes (MDTS, for example). Because the
testing framework is part of midonet, moving python-midonetclient out
of midonet will cause awkward development process for the midonet
developers who will need to go back and forth between the projects.
Also, by keeping them inside midonet, no change is required for
packaging of python-midonetclient. There are still users of the low
level midonet API, so we will have to keep releasing the
python-midonetclient package as we do now, but it does not necessarily
have to be published for the OSt distributors.
We have a clear separation of preferences among those that are from
the OpenStack background and those that are not. Thus, it makes the
most sense to separate the projects the same way so that each party is
responsible for the part that they consume.
I hope this achieves the right balance. Let me know if there are
strong objections against this proposal.
Best,
Ryu
More information about the OpenStack-dev
mailing list