Open Stack

This is an LBaaS topic bud I'd like to get some Neutron Core members to
give their opinions on this matter so I've just directed this to Neutron
proper.

The design for the new API and object model for LBaaS needs to be locked
down before the hackathon in a couple of weeks and there are some
questions that need answered.  This is pretty urgent to come on to a
decision on and to get a clear strategy defined so we can actually do
real code during the hackathon instead of wasting some of that valuable
time discussing this.


Implementation must be backwards compatible

There are 2 ways that have come up on how to do this:

1) New API and object model are created in the same extension and plugin
as the old.  Any API requests structured for the old API will be
translated/adapted to the into the new object model.
PROS:
-Only one extension and plugin
-Mostly true backwards compatibility
-Do not have to rename unchanged resources and models
CONS:
-May end up being confusing to an end-user.
-Separation of old api and new api is less clear
-Deprecating and removing old api and object model will take a bit more
work
-This is basically API versioning the wrong way

2) A new extension and plugin are created for the new API and object
model.  Each API would live side by side.  New API would need to have
different names for resources and object models from Old API resources
and object models.
PROS:
-Clean demarcation point between old and new
-No translation layer needed
-Do not need to modify existing API and object model, no new bugs
-Drivers do not need to be immediately modified
-Easy to deprecate and remove old API and object model later
CONS:
-Separate extensions and object model will be confusing to end-users
-Code reuse by copy paste since old extension and plugin will be
deprecated and removed.
-This is basically API versioning the wrong way

Now if #2 is chosen to be feasible and acceptable then there are a
number of ways to actually do that.  I won't bring those up until a
clear decision is made on which strategy above is the most acceptable.

Thanks,
Brandon