Without waiting for the next pipeconf watchdog periodic probe.
To support this, this patch extends the PiPipeconfService to advertise
pipeconf registration events.
Change-Id: Ib44f1813bd37083c666a5e7980de320ce469c2d2
When we want to create a meter, MeterManager & DefaultMeter.Builder gives the following error:
java.lang.IllegalArgumentException: Must specify a cell id.
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:134)
at org.onosproject.net.meter.DefaultMeter$Builder.build(DefaultMeter.java:241)
at org.onosproject.net.meter.DefaultMeter$Builder.build(DefaultMeter.java:184)
at org.onosproject.net.meter.impl.MeterManager.submit(MeterManager.java:204)
It seems that MeterManager still uses meter id instead of meter cell id. It must be changed with the proper value.
Change-Id: I623746b38af1148ca7f33efe5e48d6590a11051a
Note: Cord OLT application must create meters for the technology profile implementation and it uses 1.13.1 version.
Such as mapping from PiMatchFieldId to Criterion.Type. This should not
be required since the only translation happening is from north
(Criterion.Type) to south (PiMatchFieldId).
Change-Id: I204e0bd66b3996fd60bc11d4241e8a0408e11582
Clone sessions can now be created by defining groups with new type CLONE
The PI framework has been refactored to abstract commonality between
multicast groups and clone sessions as both are managed as part of the
P4Runtime packet replication engine (PRE).
Change-Id: I2f23c629b7de1931d5cab96ec76aef26130ce418
This change introduces a refactoring of the gRPC protocol subsystem that
allows the creation of a gRPC chanel independently of the client, while
allowing multiple clients to share the same channel (e.g. as in Stratum
where we use 3 clients).
Moreover, we refactor the P4RuntimeClient API to support multiple
P4Runtime-internal device ID using the same client. While before the
client was associated to one of such ID.
Finally, we provide an abstract implementation for gRPC-based driver
behaviors, reducing code duplication in P4Runtime, gNMI and gNOI drivers.
Change-Id: I1a46352bbbef1e0d24042f169ae8ba580202944f
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
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 (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
- 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
The new client API supports batching and provides detailed response for
write requests (e.g. if entity already exists when inserting), which was
not possible with the old one.
This patch includes:
- New more efficient implementation of P4RuntimeClient (no more locking,
use native gRPC executor, use stub deadlines)
- Ported all codecs to new AbstractCodec-based implementation (needed to
implement codec cache in the future)
- Uses batching in P4RuntimeFlowRuleProgrammable and
P4RuntimeGroupActionProgrammable
- Minor changes to PI framework runtime classes
Change-Id: I3fac42057bb4e1389d761006a32600c786598683
Also includes:
- New abstract P4Runtime codec implementation. Currently used for action
profile members/groups encoding/deconding, the plan is to handle all
other codecs via this.
- Improved read requests in P4RuntimeClientImpl
- Removed handling of max group size in P4Runtime driver. Instead, added
modified group translator to specify a max group size by using
information from the pipeline model.
Change-Id: I684bae0184d683bb448ba19863c561f9848479d2
Members can exist outside of a group. Previous naming was ambiguous
about this.
Action group -> action profile group
Action group member -> action profile member
Change-Id: I5097e92253353d355b864e689f9653df2d318230
