Open Stack

On Mon, Mar 23, 2015 at 9:03 AM, Salvatore Orlando <sorlando at nicira.com> wrote:
>> Actually, I don't see this as a big deal or a failure. In fact, it may be
>> quite common and useful for a given driver to store some state in its own
>> tables (like the reference driver is doing). The primary goal is to enable
>> alternate IPAM implementations, whether external or completely local. That
>> goal is still achieved even with this change. So, I don't see a big problem
>> with the IPAM driver being session-aware.
>
>
> Whether is a big deal or a failure it depends on one's expectation. If the
> expectation is to enable external IPAM backends, then I agree that this is
> not a big deal.
> However, my expectation (and I hope I'm not the only one), was to
> disentangle IPAM logic from the API request processing code. In this way 3rd
> party backend transactions would have been executed independently of the
> database operation for processing the API request. Also, this would have
> enabled us to integrate tools like taskflow (I think Pavel looked into
> that). And most importantly avoid long database transactions which include
> remote calls as well.

+1.  Well said.

> However, this is not achievable - and mostly for an oversight on our side.
> So we should welcome passing down the context to the driver, with the goal
> of removing it in the next release. I think it will be fair to assume the
> interface "experimental" for this release cycle - and "stable" for the next
> one.

Agreed.  It isn't the ideal situation but even if we had achieved what
we were setting out to achieve it would probably still have been
prudent to consider the interface "experimental" for Kilo.

Carl