Added BGP tunnelling and received routes.
Added pushing groups and can now ping through the router.
Change-Id: I21a265bd72e40fc430bd392201fadccbdd67be94
Added a number of app.xml files for built-in apps.
Added ability to install & activate in one command.
Change-Id: I3fa5fa487ef76d9fe3da4d6dce8045d538cba423
The main goal of this is to allow routing code to be used by multiple
applications.
Changes include:
* Created an onos-app-routing bundle and moved BGP code and routing code
into it.
* Created an onos-app-routing-api bundle as a common API bundle between
onos-app-routing and onos-app-sdnip, to prevent circular dependencies.
* Moved API classes into onos-app-routing-api bundle.
* Made Router and BgpSessionManager into OSGi components. This is not quite
clean, because there is still a chain of start() method calls from SdnIp
through to BgpSessionManager to preserve startup order. This should be
revisted so components can be started using activate()
* Created BgpService and RoutingService APIs to glue different components
together.
* Many unit test changes. A lot of the previous unit tests spanned the
Router and IntentSynchronizer classes, but this is not possible any more
since these classes are in different bundles. I had to rewrite some of
these tests so that each unit test class only tests one real class. A
nice side-effect is that the tests are now simpler because each test
tests less functionality.
* Removed SdnIp test seeing as it doesn't run automatically, was already
broken and has been largely superseded by other unit tests and the nightly
functional tests.
Change-Id: I70ecf5391aa353e99e7cdcf7ed38a530c87571bb
Revising some implementations and adding tests.
Removing fingerprint and extension concept for now.
Change-Id: Id50faf29e4590b08e0c2b385ae8d4bb0c453f37e
for the other device providers
initial null provider directory structure
Change-Id: Ib7a766a854ba1863564ce2dc950f597a41a4e545
better with files
Change-Id: I041ea7bb718748e5f72ccaf06836c322b4e411d6
no binaries needed
Change-Id: I0bc978dd5bf6d20968bd1a28c6165b9f49ba585b
start nulldeviceprovider
Change-Id: If75bced900c185ca58a9302130c4d4a3cc18f12d
null device provider trivial implementation
supports hardcoded number of devices and ports, this will ultimately be extented to cli/rest configuration.
Change-Id: Iaeffc5526526b90fb1ecbcc0bd8b88103bdb921a
Having onlab-rest in onos-api creates a dependency issue because the
dependencies of onlab-rest are not included in onos-api. Usually people don't
see an issue because they also have another rest/web feature installed.
Fixes ONOS-505.
Change-Id: Ifd1526491eb526bb2d751d915fc97cceef5a64a9
(cherry picked from commit 449bd5bc62f5723f914efe8117f19190d1b9ff49)
Change-Id: I1ac2f5a6b7efbc7c940c6d7c371af4f5befcd676
using a timer to pace ourselves
Change-Id: Ia58698f950bbbc958ad002ed56dfe54b90f317ab
all good blasts intents
Change-Id: Ia85df5ad211c01d22d4088403d789b3d6a2292f7
clean up
Change-Id: I1a6dde05f57d0e4866d3255fc28836dfa7e7c190
It can be used as an Intent-related event and event metrics collector.
It can be loaded by one of the following two (new) features:
onos-app-metrics, onos-app-metrics-intent
After loading the module, it subscribes for intent-related events
and keeps the following state:
(a) The last 100 events
(b) The timestamp of the last event (ms after epoch) as observed by this
module for each event type: SUBMITTED, INSTALLED, WITHDRAWN.
The missing event type is the equivalent of "Withdraw Requested"
(c) The rate of each intent event type: count, median rate, average rate
over the last 1, 5 or 15 minutes
The following CLI commands are added:
* onos:intents-events
Shows the last 100 intent events
* onos:intents-events-metrics
Shows the timestamp of the last event (ms after epoch) as observed by
this module for each event type, and the rate of the topology
events (for each event type): see (b) and (c) above
Change-Id: I9f23e9086bbd433b8f24283539abdeb97e199e2e
event metrics collector. It can be loaded by one of the following two (new)
features: onos-app-metrics, onos-app-metrics-topology
After loading the module, it subscribes for topology-related events
and keeps the following state:
(a) The last 10 events
(b) The timestamp of the last event (ms after epoch) as observed by this
module
(c) The rate of the topology events: count, median rate, average rate
over the last 1, 5 or 15 minutes
The following CLI commands are added:
* onos:topology-events
Shows the last 10 topology events
* onos:topology-events-metrics
Shows the timestamp of the last event, and the rate of the topology
events: see (b) and (c) above
