OVSDB Reconciliation ¶

https://git.opendaylight.org/gerrit/#/q/topic:ovsdb-reconciliation

Add support for reconciliation in ovsdb for tunnel interfaces and bridges.

Problem description ¶

We don’t want anybody to tinker with switch configuration for entities owned by the controller, switch configuration should be identical to what is there in the controller config.

Use Cases ¶

The following usecases are supported

Use case 1: Reconciliation after controller reboot
Use case 2: Reconciliation after switch re-connection
Use case 3: Reconciliation after controller upgrade
Use case 4: Reconciliation after switch connects back to different controller in a cluster of controllers
Use case 5: Reconciliation should happen in both controller initiated and switch initiated connections

Controller should do reconciliation only on entities owned by the controller. For this we need to identify entities created by controller. Currently we use the key-value pair “opendaylight-iid:”operational datastore node Id” to stamp the entities created by the controller, but for a future proof solution this feature will add another key-value pair “created_by:odl” to stamp the entities created by the controller. This key-value pair will go in the external_ids column of ovsdb tables in switch.

This feature will support only create and delete reconciliation, create reconciliation is already implemented, see references 3 & 4. Update reconciliation is not supported in this feature. Bridge and tunnel interface delete reconciliations are handled in this feature. This feature should handle both switch initiated and controller initiated connections.

In order to handle reconciliation in a generic way, we will follow below steps

Switch connects
Check whether upgrade is going on
if upgrade flag is not set, reconcile and publish the switch
if flag is set, publish switch and reconcile when upgrade flag is down

In current implementation both reconciliation and publishing to Oper DS are two parallel tasks. Reconciliation will be done in datastore transact commands where we compare, switch configuration got from OVSDB monitor callback and what is there in config datastore.

The Scope of the reconciliation will be kept only to br-int bridge. Support for delete reconciliation for Qos Service is not in this scope of this spec.

Handling various scenarios

Non upgrade scenario(upgrade flag is down)
- New switch connects: There is no configuration in the controller and switch, first reconciliation kicks in, nothing to reconcile, then publishes switch to oper DS.
- Existing switch flaps: There is same configuration in both controller and switch, reconciliation code retains the same in switch, then switch gets published to OperDS Switch connect is not the trigger for every config reconciliation. Currently Bridge configuration reconciliation is getting triggered upon gaining eos ownership and TerminationPoint reconciliation is getting triggered after the bridge appears in oper datastore.
- Existing switch flaps with some change in configuration: Here create reconciliation should push the new configuration to switch, and delete reconciliation should delete the old ones, and push the switch to Oper DS.
Auto-Tunnel scenario (non upgrade, upgrade flag is down)
- New switch connects: same as above
- Existing switch flaps: same as above
- Existing switch flaps with change in tep/tz configuration: delete reconciliation should delete the old tunnels and publish to Oper DS, now auto-tunnel module should take care of creating new teps.
Upgrade scenario (replay based upgrade, upgrade flag will be set for sometime)
- New switch connects: if upgrade flag is set don’t reconcile, publish the switch to Oper DS, when upgrade flag is down, reconcile
- existing switch connects back: same as above
- existing switch connects back(auto-tunnel): when switch connects back, check upgrade flag. If flag is set, dont reconcile, publish switch to Oper DS. When upgrade flag becomes down, reconcile.

In certain scenarios there will be traffic hit, like when we do reconciliation while system is updrading

If Itm auto-tunnel module didn’t get a chance to run before upgrade flag goes down, and if ovsdb plugin runs first, then it will delete all the teps first, which will result in a traffic hit.
If switch connects after the upgrade flag is down, then reconciliation will delete all the teps, this also will result in a traffic hit

CLI ¶

None

Implementation ¶

Assignee(s)¶

Primary assignee:: Nobin Mathew
Other contributors:: Chetan Arakere Gowdru(chetan.arakere@altencalsoftlabs.com)

Work Items ¶

Add code to stamp entities created by controller by key-value pair
Add reconciliation
Add unit test cases for new reconciliation code
Scale test and measure the performance
Add CSIT for reconciliation

[3] Bug 5951: Termination point config reconciliation https://trello.com/c/ISZ4MTNs/74-bug-5951-termination-point-config-reconciliation

[4] Gerrit: Termination point config reconciliation https://git.opendaylight.org/gerrit/#/c/40506/

OVSDB Reconciliation ¶

Problem description ¶

Use Cases ¶

Proposed change ¶

Pipeline changes ¶

Yang changes ¶

Configuration impact ¶

Clustering considerations ¶

Other Infra considerations ¶

Security considerations ¶

Scale and Performance Impact ¶

Targeted Release ¶

Alternatives ¶

Usage ¶

Features to Install ¶

REST API ¶

CLI ¶

Implementation ¶

Assignee(s)¶

Work Items ¶

Dependencies ¶

Testing ¶

Unit Tests ¶

Integration Tests ¶

CSIT ¶

Documentation Impact ¶

References ¶