Operating System: Linux
Platform: All

When we increase waiting time of controller status from 32 to 40s, the issue 503 error code is not reproducible.

(In reply to Karthik Sivasamy from comment #1)
> When we increase waiting time of controller status from 32 to 40s, the issue
> 503 error code is not reproducible.

Did you submit the change to the vtn.git?

Could you add more explanation?

(In reply to Hideyuki Tai from comment #2)
> (In reply to Karthik Sivasamy from comment #1)
> > When we increase waiting time of controller status from 32 to 40s, the issue
> > 503 error code is not reproducible.
>
> Did you submit the change to the vtn.git?
>
> Could you add more explanation?

> Analysing the issue why VTN coordinator returns 503 when wait time is 32s, as controller status is UP, test case fail in creating VTN configurations i.e, (503 service unavailable) error returns.

Observation:
1.There is a fraction of delay between the controller status becoming “up” and then AUDIT operation actually completing. Between, next REST API gets executed in this time.
2. This causes higher layer module to fail the commit operation by returning SYSTEM BUSY(503) error as AUDIT is yet to complete with all components.

Workaround:
a.Create Controller with “Audit Disable”
b.Wait for atleast 10sec for controller to become ready for Audit from down state.
c.Manually trigger AUDIT using the AUDIT Controller REST API
d.Then continue the rest of TESTS.

> b.Wait for atleast 10sec for controller to become ready for Audit from down
state.

Previously it took longer. My brain pattern-matched the change to a change in test setup: value of odcdrv_ping_interval in /usr/local/vtn/modules/odcdriver.conf was changed from 30 (seconds) to 10. As ping itself takes some time, actual test waits up to 12 seconds.

To me, it looks like the system under test waits for a ping to succeed (perhaps two pings separated by the interval?).

As a committer on Integration project, I am willing to accept the new test (which hides the 503 issue) as soon as test case documentation points to this Bug discussion.

Hi Vratko,

Actually it is a little different. The issue reported here is about the time taken for the "AUDIT" operation to complete. The ping interval was made as 10 seconds for a different scneario. This paramter controls the frequency in which the vtn coordinator tries to chck if the ODL is connected. It is for the "down" state checking when setting wrong IP address. We are checking the same.

This issue occurs only when testing vtn coordinator in csit.

Occurance of the issue:
1) Add a controller.
2) Check controller status if "UP"
3) Add vtn, vbr (Here it returns error as SYSTEM BUSY).

Reason of the issue:
1.There is a fraction of delay between the controller status becoming “up” and then AUDIT operation actually completing. Between, next REST API gets (VTN and VBR creation)executed in this time.
2. This causes higher layer module to fail the commit operation by returning SYSTEM BUSY(503) error as AUDIT is yet to complete with all components.And it is confirmed it is know behaviour to overcome this we need to do trigger manual audit in the test case after adding controller.

This issue is ressolved by fixing manually trigerring audit in the CSIT test cases.

The patch for this bug is fixed in CSIT test cases of vtn and it is merged in "integration branch". Please find the below link for the same,
https://git.opendaylight.org/gerrit/#/c/24860/