Bug 1283062 - Updates and/or calls to MAC address Pool are not bound to DB transaction.
Summary: Updates and/or calls to MAC address Pool are not bound to DB transaction.
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.0.0-rc
: 4.0.0
Assignee: Martin Mucha
QA Contact: Meni Yakove
Depends On:
TreeView+ depends on / blocked
Reported: 2015-11-18 07:17 UTC by Martin Mucha
Modified: 2016-06-15 08:41 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-06-15 08:41:14 UTC
oVirt Team: Network
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
danken: devel_ack+
mavital: testing_ack+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 48817 0 master MERGED core: add 'completed' method to RollbackHandler 2016-01-11 08:28:52 UTC
oVirt gerrit 48859 0 master ABANDONED core: make pool transaction aware. 2016-07-03 01:56:35 UTC
oVirt gerrit 50154 0 master ABANDONED core: introducing bll compensation 2016-05-18 12:48:48 UTC
oVirt gerrit 50513 0 master MERGED core: remove 'initialize' method from MacPoolManagerStrategy interface 2016-04-17 07:58:45 UTC
oVirt gerrit 50514 0 master MERGED core: rename 2016-04-19 08:14:57 UTC
oVirt gerrit 50515 0 master MERGED core: extracted locking to proxy 2016-04-19 08:16:07 UTC
oVirt gerrit 50516 0 master ABANDONED core: Tx aware MAC pool. 2016-05-18 12:48:59 UTC
oVirt gerrit 50517 0 master MERGED core: call directly resetCompensation 2016-02-04 07:34:46 UTC
oVirt gerrit 50518 0 master ABANDONED core: using compensation aware macPool 2016-05-18 12:47:09 UTC
oVirt gerrit 50520 0 master ABANDONED core: propagate VmInterfaceManager instead creating one in SnapshotsManager 2016-05-18 12:48:44 UTC
oVirt gerrit 51545 0 master ABANDONED core: introducing compensation aware mac pool 2016-05-18 12:48:39 UTC
oVirt gerrit 54014 0 ovirt-engine-3.6 MERGED core: add 'completed' method to RollbackHandler 2016-07-11 14:15:00 UTC
oVirt gerrit 57642 0 master MERGED core: introducing pool awareness of transaction and compensation 2016-05-25 05:53:42 UTC

Description Martin Mucha 2015-11-18 07:17:30 UTC
Description of problem:

Updates to pool are not bound to transaction in any way. Any failure will block further processing and revert db. The only thing, which does not revert, and we do not even know how to do it(!), is macPool alteration. That means change pool settings, acquiring and returning macs. If that happens, some MACs may become erroneously marked as used or unused.

When updating pool ranges settings we currently use this strategy: do pool modification as a last action and 'hope' that this operation itself will not fail. If it will fail there, for any reason (incl. java.lang.Error)., in memory pool become corrupted, however it's quite unlikely that this will happen.

To fix this issue for acquiring/releasing macs we have to examine all usages and fix them some how, or better, we have to bound these actions on mac pool to current transaction and revert them, if that transaction is reverted. 

1) when updating pool, we must support 'undo'. That can be achieved via a) creating new instances and once they're ready swap them for original one. b) creating chain of instances representing performed actions — journal — and replay it back. Both will require new methods on pool.
2) all code acquiring / releasing mac from/to pool needs 'onrollback listener handler'. One possible solution would be, that pool itself remembers to/from whom he given/got certain mac and in which transaction. Using transaction completion listener he'd clear that list or reverted performed action. This will have to also grant, that released mac isn't actually available until COMMIT, and acquired mac won't be available until rollback even if transaction requiring it wasn't committed yet.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Comment 1 Dan Kenigsberg 2015-12-21 15:10:41 UTC
The solution seems complex, and the bug has existed since we have mac pools. I see no reason to backport it without clear customer case.

Comment 2 Mike McCune 2016-03-28 23:09:17 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 3 Sandro Bonazzola 2016-05-02 10:10:10 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 4 Yaniv Lavi 2016-05-23 13:26:03 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 5 Yaniv Lavi 2016-05-23 13:26:31 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Note You need to log in before you can comment on or make changes to this bug.