1. Handled the case when InternalNetworkConfigListener in DeviceManager recieves an event associated with PortAnotationConfig class.
2. Added CONFIG_REMOVED event type in InternalNetworkConfigListener in DeviceManager.
3. Changed comine function in PortAnnotationOperator to take care of removing old annotations from PortDescription which are not in current
PortAnnotationConfig.
Tested using 'annotate-ports' command and 'ports' command
Change-Id: Ie4d2b529c2f559a40a296d916193318e0ccc7b93
(due to possible race condition)
2019-02-15 11:18:45,407 | WARN | -event-barrier-1 | LocalCache | 94 | Exception thrown by removal listener
java.lang.NullPointerException
at org.onosproject.net.flow.impl.FlowRuleManager$InternalStoreDelegate.notify(FlowRuleManager.java:639)
at org.onosproject.net.flow.impl.FlowRuleManager$InternalStoreDelegate.notify(FlowRuleManager.java:591)
at org.onosproject.store.AbstractStore.notifyDelegate(AbstractStore.java:58)
at org.onosproject.store.flow.impl.ECFlowRuleStore.batchOperationComplete(ECFlowRuleStore.java:638)
at org.onosproject.net.flow.impl.FlowRuleManager$InternalFlowRuleProviderService.batchOperationCompleted(FlowRuleManager.java:577)
at org.onosproject.provider.of.flow.impl.OpenFlowRuleProvider.lambda$createBatchCache$0(OpenFlowRuleProvider.java:231)
at com.google.common.cache.LocalCache.processPendingNotifications(LocalCache.java:1967)[94:com.google.guava:22.0.0]
at com.google.common.cache.LocalCache$Segment.runUnlockedCleanup(LocalCache.java:3642)[94:com.google.guava:22.0.0]
at com.google.common.cache.LocalCache$Segment.postWriteCleanup(LocalCache.java:3618)[94:com.google.guava:22.0.0]
at com.google.common.cache.LocalCache$Segment.remove(LocalCache.java:3246)[94:com.google.guava:22.0.0]
at com.google.common.cache.LocalCache.remove(LocalCache.java:4413)[94:com.google.guava:22.0.0]
at com.google.common.cache.LocalCache$LocalManualCache.invalidate(LocalCache.java:5081)[94:com.google.guava:22.0.0]
at org.onosproject.provider.of.flow.impl.OpenFlowRuleProvider$InternalFlowProvider.handleMessage(OpenFlowRuleProvider.java:466)[170:org.onosproject.onos-providers-openflow-flow:1.12.2.SNAPSHOT]
at org.onosproject.openflow.controller.impl.OpenFlowControllerImpl$OFMessageHandler.run(OpenFlowControllerImpl.java:773)[167:org.onosproject.onos-protocols-openflow-ctl:1.12.2.SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_192]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_192]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_192]
Change-Id: I6eb64524c5e209c4a6d6a6f147d7ab0c86137246
- Workaround for PI bug that ignores max_group_size
- Use max_group_size and not buckets size when translating groups
Change-Id: Id12a12311b20ca8fb4e785e1c5a4f0f4215d1bbf
- catch errors in the cfgdef tool and abort compilation if a mismatch
is seen
- Fix mismatches in the code discovered by the tool
Change-Id: Icd9a15eb9312bba6c2208b0b2a684062fcdc19c3
Since Stratum persists pipeline config across reboots, the
GeneralDeviceProvider was marking the device available as the device
had a pipeline config set right after the connection open event, but we
had to wait for the periodic PipeconfWatchdog check to mark the pipeline
as READY. Now we trigger a PipeconfWatchdog check after every device
availability change event.
Change-Id: I11a6f52ff5ea5304aa26dbe39786a25055b828aa
The GeneralDeviceProvider works with device IDs with prefix "device:",
which is the same leadership topic prefix used by the Mastership
service. This caused an issue when any app was creating leadership
contests with topic deviceId.toString() (e.g. XConnectManager,
DefaultRoutingHandler, etc), as the resulting leadership events where
picked by the mastership service and propagated, because of the "device:"
prefix.
This patch minimizes the occurrence of such issue by choosing a more
specific leadership topic prefix for the mastership service. However,
the right solution would be to add isolation of leadership contests
between different services/apps.
Change-Id: I333fd9796a66bb4ca04cd2facd337ac57a2947b2
This change also includes:
- Refactoring of gNMI protocol+driver to take advantage of the recent
changes to the gRPC protocol subsystem (e.g. no more locking, start RPC
with timeouts, etc.).
- Fixed Stratum driver to work after GeneralDeviceProvider refactoring
- Updated bmv2.py to generate ChassisConfig for stratum_bmv2
- Fixed portstate command to use the same port name as in the store
Change-Id: I0dad3bc73e4b6d907b5cf6b7b9a2852943226be7
This is achieved by optimistically updating the P4Runtime mirror using
the write request (instead of waiting for a response) and by serializing
building write requests for the same device.
This change requires updating the P4Runtime protocol classes to expose
the content of the write request.
It also includes:
- force member weight to 1 when reading groups (some server
implementation still fails to be compliant to the spec)
- remove unused operation timeout handling in GDP (now all RPCz have a
timeout)
Change-Id: Ib4f99a6085c1283f46a2797e0c883d96954e02e9
This (big) change aims at solving the issue observed with mastership flapping
and device connection/disconnection with P4Runtime.
Channel handling is now based on the underlying gRPC channel state. Before,
channel events (open/close/error) were generated as a consequence of P4Runtime
StreamChannel events, making device availability dependent on mastership. Now
Stream Channel events only affect mastership (MASTER/STANDBY or NONE when the
SteamChannel RPC is not active).
Mastership handling has been refactored to generate P4Runtime election IDs that
are compatible with the mastership preference decided by the MastershipService.
GeneralDeviceProvider has been re-implemented to support in-order
device event processing and to reduce implementation complexity. Stats polling
has been moved to a separate component, and netcfg handling updated to only
depend on BasicDeviceConfig, augmented with a pipeconf field, and re-using the
managementAddress field to set the gRPC server endpoints (e.g.
grpc://myswitch.local:50051). Before it was depending on 3 different config
classes, making hard to detect changes.
Finally, this change affects some core interfaces:
- Adds a method to DeviceProvider and DeviceHandshaker to check for device
availability, making the meaning of availability device-specific. This is needed
in cases where the device manager needs to change the availability state of a
device (as in change #20842)
- Support device providers not capable of reconciling mastership role responses
with requests (like P4Runtime).
- Clarify the meaning of "connection" in the DeviceConnect behavior.
- Allows driver-based providers to check devices for reachability and
availability without probing the device via the network.
Change-Id: I7ff30d29f5d02ad938e3171536e54ae2916629a2
Allows to provide a different input port to be considered when emitting
the packet. It is useful on OpenFlow devices so one can use ALL or FLOOD
actions as output and not have the packet sent back on the input port.
Default is controller port, as it was before.
The required changes were also implemented in OpenFlowPacketProvider
Change-Id: I0a050b983b5de9935254599e8093dc59ad7a4ccf
- removed soft fail
- fixed property reference in DriverRegistryManager that had been refactored out
- fixed property references in FlowObjectiveManager so that property name and
variable name match
Change-Id: I1324c0553e0f6945087b29794f0a06ae6dd8ab10
- OchSignal constructor
- unfiltered connect point methods in single point to multi point intents
- useBackup() method from disjoint paths
- ChannelAdapter class
- getLastUpdatedInstant() method from cluster store
- switchWorkingPath() method from protection config behaviour
- getVersion() method from partition
- getFlowRulesById() method from flow rule service
Change-Id: I5c6c2f31725f7e7e44ac2abb18ce3fb96b09d93e
