On Tue, Aug 2, 2016 at 6:55 PM, Carl Baldwin wrote:
> On Aug 2, 2016 6:52 PM, "Kevin Benton" wrote:
> > If we decide to just fix the exception handler inside of ipam itself for
> rollbacks (which would be a quick fix), I would be okay with that but we
> need to be clear that any driver depending
On Aug 2, 2016 6:52 PM, "Kevin Benton" wrote:
>
> >It might be the wrong impression, but it was already given and there are
drivers which have been written under it. That's why I tend toward fixing
rollback instead of eliminating it.
>
> The reason I thought it was relevant to bring up is because
>It might be the wrong impression, but it was already given and there are
drivers which have been written under it. That's why I tend toward fixing
rollback instead of eliminating it.
The reason I thought it was relevant to bring up is because it's going to
be difficult to actually fix it. If any
On Tue, Aug 2, 2016 at 2:50 AM, Kevin Benton wrote:
> >Given that it shares the session, it wouldn't have to do anything. But,
> again, it wouldn't behave like an external driver.
>
Why not? The only additional thing an external driver would be doing at
> this step is calling an external system.
>Given that it shares the session, it wouldn't have to do anything. But,
again, it wouldn't behave like an external driver.
Why not? The only additional thing an external driver would be doing at
this step is calling an external system. Any local accounting in the DB
that driver would do would aut
On Mon, Aug 1, 2016 at 2:29 PM, Kevin Benton wrote:
> >We still want the exception to rollback the entire API operation and
> stopping it with a nested operation I think would mess that up.
>
> Well I think you would want to start a nested transaction, capture the
> duplicate, call the ipam delet
>We still want the exception to rollback the entire API operation and
stopping it with a nested operation I think would mess that up.
Well I think you would want to start a nested transaction, capture the
duplicate, call the ipam delete methods, then throw a retryrequest. The
exception will still
Hi all,
Last Thursday, I spent the afternoon looking in to a bug with pluggable
IPAM [1] which is preventing me from deciding to pull the trigger on
finally switching from the old non-pluggable reference implementation. I'd
*really* like to get this in shape for Newton but time is running out.
I'
