Thanks for the update Carl!
I spent some time trying to make the refactored base plugin class with the
IPAM driver.
I have been partially successful. The results are so far in [1] (it's a
patch that applies on top of Pavel's topmost patch); this patch will be
soon split into smaller patch which I
On Mar 15, 2015 6:42 PM, "Salvatore Orlando"
> * the ML2 plugin overrides several methods from the base "db" class. From
what I gather from unit tests results, we have not yet refactored it. I
think to provide users something usable in Kilo we should ensure the ML2
plugin at least works with the IP
On 17 March 2015 at 14:44, Carl Baldwin wrote:
>
> On Mar 15, 2015 6:42 PM, "Salvatore Orlando"
> > * the ML2 plugin overrides several methods from the base "db" class.
> From what I gather from unit tests results, we have not yet refactored it.
> I think to provide users something usable in Kilo
As pointed out by Pavel in yesterday's meeting, the refactor [1] cannot
assume that the DB transaction for IPAM operations will occur in a scope
different from the one for performing the API operation.
This is because most plugins, including ML2, use inheritance to perform
further operations on dat
On 3/20/15, 8:31 PM, "Salvatore Orlando"
mailto:sorla...@nicira.com>> wrote:
As the IPAM driver is called in NeutronDbPluginV2, this call happens while
another transaction is typically in progress. Initiating a separate session
within the IPAM driver causes the outer transaction to fail.
I d
Comments inline.
Salvatore
On 23 March 2015 at 15:41, John Belamaric wrote:
>
>
> On 3/20/15, 8:31 PM, "Salvatore Orlando" wrote:
>
>
> As the IPAM driver is called in NeutronDbPluginV2, this call happens
> while another transaction is typically in progress. Initiating a separate
> session
On 3/23/15, 11:03 AM, "Salvatore Orlando"
mailto:sorla...@nicira.com>> wrote:
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 o
On Mon, Mar 23, 2015 at 9:03 AM, Salvatore Orlando 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
>> alter
