There is a slight worry of backward compatibility, however, Set does not
guarantee the order anyway. So, the northbound interface users could not
rely on any ordering. This means that making the order deterministic and
easily human readable just improves the situation without much
overhead.
Change-Id: I8a4de3ecac87a7499a107ad12c7a3038332868cd
- Bug fix for case when all uplinks are gone, but dual-homed host continues to send packets to switch;
We now administratively take down the host port to force the host to use the other leaf in the pair.
- Restructured SR manager by creating a LinkHandler
- fixed/added some log messages
Change-Id: I3722cd364dc8798b16891519bec165627e92bd87
Avoids also log pollution.
Reason: This avoids one mastership recheck per instance every minute on unreachable AND unavailable device when role of instance is NONE.
Still treats the corner case where role is NONE and device is still available in the store.
Change-Id: I0bd0be5a9ed491a61cc1dc1e988dcf3a53e33993
- Better handling of BMv2 crashes in bmv2.py (with watchdog and logging)
- bm-* commands for easy access to BMv2 log, CLI, etc
Change-Id: I1c79acda641171566d8e1162442c7f377bb273fe
Rationale: appkryo returns immutable lists serializable
which do not support removeIf and addAll methods
Change-Id: I25f7f818677d78cad65122f476702f9e194fd620
Rationale: PW transit groups need to be filtered out
when retry hash and bucket correction happen (if mpls
ecmp is not supported)
Change-Id: I162ddb3d4d8760777b0cbd5bf250d6fcef8302df
The rationale for this change is: unhandled exceptions
prevent Runnable to be scheduled in future.
We need to protect the body of runnable.
Related to [CORD-2532] and [CORD-2533].
In the pipeliner we use checkers and groups listener
to get notification about groups. The error scenario:
unhandled exception in the context of a group checker
will kill the checker. We create a multicast group, which
requires firstly a l2interfacegroup. The latter has been
already created in the past. No notification from groups
and no checker -> failure. Multicast group is not created
and forwarding objective in pending (forever).
Potentially, it can fix other errors scenario.
Change-Id: I6ea0548c112002b9ce415103891dc01431bc1dc8
This code could also throw an NPE if called at the wrong time.
Fixed by saving the value to lock on before saving the new value.
Change-Id: I6a7570c00135d7cff31f3429af1067f4228e5189
Long values can be pooled and result in unwanted locking dependencies.
Created a specific unshared lock object.
Change-Id: Icd0035b5d27d564c9ac2f477eff9382b51d06edf
Nothing stops an OF agent to return zero for lambda values and ONOS
probably ought to not crash then.
One use case for this is when only one direction is supported on a port,
for example tx. Unfortunately, the openflow specification does not
separate the directions into different properties, so the agent
implementation has to return some frequency value for rx in this case
even if only the tx direction is supported. However, anything non-zero
would probably be untruthful as it would indicate valid reading to the
end user.
Even zero will be problematic for unsupported power reading in a
direction as 0 dBm is a valid value, but not sure how to deal with any
better.
Change-Id: I2597bd7d577d9c2e1a3b44421fe505b8b3b6cc92
Among other things, build now is not based on the upstream version of
onos-setup-p4-dev, but on the local one.
Change-Id: I270a324152a9349d6a9989aa8b5a38b45e1856d9
- Adding gNMI dependencies
- Updating PI and BMv2 to build with sysrepo support
- Building simple_switch_grpc with Thrift server
Change-Id: Ida69d80353652174b0bc61a16b6436bf78a2d194
