- fix issues detected
- YANG custom registrator should be subject to checkstyle
- fix Java 8 syntax related violations
Change-Id: I0fc52c6612a40d851fd9bc3bf019621776b1f92a
- extended interface with default method implementation
- modified DeviceManager to exploit the new provider feature
- refactored a number of device providers to use the new method
instead of relying on indirect DEVICE_REMOVED events
Change-Id: Ib315357ef06463012fcf26bbe937c8cdccbf3a94
reconnect in support of ONOS-7645 (device driver change)
- added device listener to OpenFlowDeviceProvider to properly disconnect switch
- removed device listener from OpenFlowControllerImpl
- augmented DriverManager to consult NetworkConfigService as a primary source
Change-Id: I1aa8e9cc7e81ff3af7a72145f4e51f3e32022806
This patch depends on 17671 onos-loxi patch. When we make
the new loxi release we need to change the prebuild
openflowj in lib/BUCK to that of the actual release number.
It provides support for programming l2 unfiltered groups,
the egress vlan table and the egress tpid table.
Depends-On: I3cea6ed2234147c8dbe440ae1701856a60706e7c
Change-Id: I7525f5856300eac25548b5219a5dffed12b291ad
- Tricky part of DriverService API:
DriverService#getDriver(DeviceId) can either return null or throw exception when not found
DriverService#getDriver(String mfr, String hw, String sw) will return null when not found
- might fix ONOS-7558
Change-Id: I0a49ab1d94f12e7fda00aa5e8e4bc42820f67dfe
java.lang.NullPointerException
at org.onosproject.provider.of.flow.impl.FlowStatsCollector.stop(FlowStatsCollector.java:96)[180:org.onosproject.onos-providers-openflow-flow:1.12.1.SNAPSHOT]
at org.onosproject.provider.of.flow.impl.OpenFlowRuleProvider.stopCollectorIfNeeded(OpenFlowRuleProvider.java:263)[180:org.onosproject.onos-providers-openflow-flow:1.12.1.SNAPSHOT]
at org.onosproject.provider.of.flow.impl.OpenFlowRuleProvider.access$400(OpenFlowRuleProvider.java:112)[180:org.onosproject.onos-providers-openflow-flow:1.12.1.SNAPSHOT]
at org.onosproject.provider.of.flow.impl.OpenFlowRuleProvider$InternalFlowProvider.switchRemoved(OpenFlowRuleProvider.java:417)[180:org.onosproject.onos-providers-openflow-flow:1.12.1.SNAPSHOT]
at org.onosproject.openflow.controller.impl.OpenFlowControllerImpl$OpenFlowSwitchAgent.removeConnectedSwitch(OpenFlowControllerImpl.java:783)[177:org.onosproject.onos-protocols-openflow-ctl:1.12.1.SNAPSHOT]
at org.onosproject.openflow.controller.driver.AbstractOpenFlowSwitch.removeConnectedSwitch(AbstractOpenFlowSwitch.java:344)[164:org.onosproject.onos-protocols-openflow-api:1.12.1.SNAPSHOT]
at org.onosproject.openflow.controller.impl.OFChannelHandler.channelInactive(OFChannelHandler.java:1288)[177:org.onosproject.onos-protocols-openflow-ctl:1.12.1.SNAPSHOT]
Change-Id: Iae3150f9eb3767c4b579d6b287dededb2da76997
The issue arrise when switch does not support GROUP_STATS capabilities,
then the group statistic request is never sent, however reply is still
expected to populate groups list.
Solution is to populate group list based on group desc statistic replay,
which contains essential information.
Change-Id: I7dde05ecfe4ca9e497787ef42d0966fa5eef30f0
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
- OFPortDesc cache managed by AbstractOpenFlowSwitch was not always maintained properly.
reorganized data structure to maintain per OFPortDesc, last known instance
Change-Id: I1b26d7ca284e44bf9744c30374394c581653d78f
