- Fix scenario files to use correct deviceId
- More robust liveness check in bmv2.py
- Use different ports for stratum internal server
- Longer switch startup timeout in bmv2.py
- Ignore number of flow rules when checking summary (make scenario
independent of trellis implementation)
Change-Id: I206e5339d2e78ae9a025caa5ec4862a9d4c24871
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
To match what used in Stratum
Change-Id: Ic4b87bcad6c3da36030fa01ee4135f60c05fcd78
(cherry picked from commit 1a16f00d8ddfb47c6423e5bc70f5d362230debb7)
Needed to support TestON-based Segment Routing tests. All instances
started with internal ID = 0 (one PI/P4Runtime server procees is
executed for each simple_switch_grpc instance, i.e, there's no need to
use different internal IDs to distinguish between switch instances).
Log/conf files and bm-* commands are now based on switch name.
Change-Id: I34d3079d6dff5933ceb4d95f04863426af24eb81
- 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
Just a small change to make sure the gRPC port of simple_switch_grpc
is actually opened after startup, before ONOS gets the netcfg to try
to connect to the switch. Otherwise ONOS will receive a TCP RST from
the still closed port and the connection fails, rendering the switch
devices unavailable. Also included a timeout for port opening.
Change-Id: I1338a4ba24a14be57717f636e684c91c4cb12a7c
With options to delay pushing the netcfg for each device and generating
the full netcfg JSON for bmv2-demo.
Change-Id: I046a93a8c639f4bb4cf76cbd61b826473760bfb1
- Support devices with different pipeconfs (as in the HW testbed)
- Run UDP servers in Mininet hosts
- Wait before pushing config to ONOS
Change-Id: Ic400e0ac0949375a27aa9721b32dc57d5065fb1c
+ support fort device-specific default pipeconf
+ improvements to P4runtime and gRPC protocol stuff
Change-Id: I8986fce3959df564454ea3d31859860f61eabcae
- Starts BMv2 with empty.p4 as when running with --no-p4 the switch
crashes
- Automatically send a netcfg JSON to ONOS for each device
- Makefile to build all P4 programs (needed for empty.p4)
Change-Id: Ib872641751c543aac6c752610b1ce88a1a00d0d2
E.g. $ sudo -E python attmpls.py --cluster-size 3
Also, added option (--netcfg) to auto set netcfg at Mininet startup, and
added command to bring onos instances up/down to Mininet CLI.
Change-Id: Id02917fd5181af496b7d954da0ef3d5f2cbb970d
A set of mininet based HA tests based on onos.py
Currently includes the following tests:
- a control network partitioning test
- A dynamic cluster scaling test
Change-Id: I9a8e1019dcc51666fee1d933afd66ff390592525
multicluster.py creates two ONOS "clusters" (1 node by
default, though larger are possible), each of which
is responsible for a separate segment of the data network.
Change-Id: I233c9884b565bd6a28fa1a05e990e86207c88347
Previously we were only passing the first ONOSCluster
into MininetFacade, but lo and behold it supports as
many networks as you like! So we pass them all in the
case where we have multiple ONOSClusters.
Change-Id: If848886b958aa47d3e4834c44adc98fffd90453c
Since --custom files are execed, subsequently importing them
actually creates duplicate classes. This wouldn't be a problem
except that we depend on isinstance(). As a workaround, we allow
the class name to match if isinstance() fails, assuming it will
be a class that is compatible with ONOSCluster or ONOSNode.
Example: env PYTHONPATH=. mn --custom onos.py,mytest.py
where mytest.py imports onos
Change-Id: Ib4cda82fbdd612420de1e113ab768e2f137d5213
With multiple ONOS clusters, we want to make sure that the
forwarded port numbers don't collide. We add a portOffset
which is automatically incremented appropriately as more
ONOSClusters are created. It can also be specified explicitly.
Change-Id: I62977c3d4141668d9f541067db1a20ec0035489b
