Comment 30 for bug 1649707

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/28962
Committed: http://github.com/Juniper/contrail-controller/commit/a35e554b534061a4de05f74efaac537ee1befccf
Submitter: Zuul (<email address hidden>)
Branch: master

commit a35e554b534061a4de05f74efaac537ee1befccf
Author: srinivn <email address hidden>
Date: Mon Feb 20 22:00:31 2017 -0800

Support single-active BGPaaS object attached to multiple VMIs

Closes-Bug: #1649707

Vrouter-Agent changes to support the multiple VMI interfaces for the given
BGPAAS session
- Changes to tweak the BGP service port number.
1. If the given BGP service port is X then the same will be
shifted by the N number of bits to accomodate the additional
VMI interfaces who are sharing this port.
2. It results in the different service port number during the flow
configuration for each VMI interface.
- Changes to configure the number of bits reserved to share
the same service port across VMI interfaces
1. Added new varaible under SERVICE section vrouter-agent.conf file
to configre the number of bits reserved to hold the multiple VMI interfaces.
- Changes in the UT test cases to validate these changes
1. Test cases are added to share the same service port across
multiple VMI interfaces
2. Test cases are added to valdiate the new variable addition to
agent.conf file.

UT Failure Fix :
The changes added to verify the reverse flow in test_bgp_service is not
working when the same test cases are run multiple times. This behavior
is observed irrespective of the new changes. So to proceed further on
this change, we have reverted those reverse flwo checks.

Review Comments Handling :
In the proposed change, have used local index allocator to keep track
the usage of service ports by multiple VMI interfaces. It leads to store
this local index across the reboots of compute nodes and will result in
additional burden to resource manager to maintain one more state to keep
track theses indexes for each service port.
To avoid this additional burden, it is decided to re-use the VMI index
which are allocated by the agent during the interface creation. This
index will be used to identify the each VMI uniquely for the given
service port.
Some of the caveats with this re-use model as follows,
- the reserved shift bits are not directly working with allocatted index,
since both are defined seperately and working independently
- if the VMI index is going beyond the allocated bits space then same
will not be fit in the reserved space, eventhough there is enough
space to store the indexes
Assumption:
- In the case of re-usage of same index during the VMI deletion and
addition, the corresponding flows of deleted VMI interfaces will be
deleted before adding the newer VMI with re-used index.
Have handles all the review comments
- updating the source port with newer source port, since the same will
be used during the flow configuration.
- Retained older source port to identify the users of the given service
port from the config

Review Comments Hanling-II:
After discussion, the logic for the derived port is changed as per the
below comment,
https://bugs.launchpad.net/juniperopenstack/+bug/1649707/comments/17

Change-Id: Ia282380dfc3dd209d3916d8f64bce89e89c27994