Open Stack

On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto <ryu at midokura.com> wrote:
> 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.

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.

-- Sandro