When should a trace be considered as failed?
viniarck opened this issue · comments
If a trace is sent for a match that will never happen (or a flow entry that never got installed for some reason) or a switch that's not connected it'll stay as type: starting indefinitely. For instance:
{
"trace": {
"switch": {
"dpid": "00:00:00:00:00:00:00:01",
"in_port": 1
}
}
}
{
"result": [
{
"dpid": "00:00:00:00:00:00:00:01",
"port": 1,
"time": "2022-02-01 18:08:31.970954",
"type": "starting"
}
]
}
❯ ovs-ofctl -O OpenFlow13 dump-flows s1
cookie=0x0, duration=60.673s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=50000,dl_src=ee:ee:ee:ee:ee:02 actions=CONTROLLER:65535
cookie=0xab00000000000001, duration=62.625s, table=0, n_packets=21, n_bytes=882, send_flow_rem priority=1000,dl_vlan=3799,dl_type=0x88cc actions=CONTROLLER:65535
Originally how was it envisioned to report trace failures? Maybe fail fast calls would be easier to maintain and delegate the retries for callers to pace accordingly, assuming the API will continue to work synchronously?
sdntrace_cp or sdntrace?
@jab1982 sdntrace_cp
@gretelliz, can we close this issue? Based on how things have evolved/implemented, the type property in the response when it's "incomplete" or "loop" now clearly represents a failure. I've noticed though that the type last hasn't been documented, since it's been used for representing a successful trace we should do it.