Open Stack

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