- 25 Apr, 2016 4 commits
-
-
We now can use start-stop-daemon (debian), daemon() shell function (centos), or sudo (others) to start onos-service. It should be backward compatible on systemd systems. Tested on Ubuntu 14 and CentOS 6. Should also work on Ubuntu 15/16, CentOS 7, Debian, and Fedora. (Note that we should test this against various OSes, preferably automatically rather than manually!) Addresses at least part of ONOS-2907 Change-Id: I4ded98baf02321a5a9db37fdff19e1ce4a3d23d2
Bob Lantz authored
-
- 23 Apr, 2016 1 commit
-
-
- Change name: McastEventHandler -> McastHandler - Separate HostHandler from SRManager - Move storekeys to a dedicated package - Replace SRObjevtiveContext and BridgeTableObjectiveContext with DefaultObjectiveContext Change-Id: Iab25529487004759105e5ba60c1d2a3852ac45e6
Charles Chan authored
-
- 22 Apr, 2016 7 commits
-
-
Stream processes by Lambda queries in collection objects has a known performance bottleneck. For each create and update link data operations, this kind of queries are frequently used and this causes inefficient topology discovery operation. For to solve that problem i analize thread dump during discovery process and i saw that especially getAllProviders method uses high cpu. than i change the provider search operation with additional map data which holds linkkey and its providers. by this way provider search operation not only gets faster but also uses minimum resource. Before that change, i can discover only 4XX number of switches at one controller, but later number grows to 15XX switches Change-Id: I65ed71b7f295917c818b2f9227d0fc070aa4a29b
kircaali authored -
- Do not handle packet in messages inside ControllerImpl class Change-Id: Idcb26b277b790125bd6b3ba8f10bb4c60e2a3c58
Jian Li authored
- 21 Apr, 2016 8 commits
-
-
This commit resolves some issues on generating REST API request, such as incorrect content-type generation for http DELETE request. Change-Id: I70bf18247f95ccf22b1fd77bc48ce9977ff57212
Jian Li authored
- 20 Apr, 2016 8 commits
-
-
Grizzly2 test framework does not produce the same test results compare to production REST API test through jetty web server. By default Jersey 2.x uses the Grizzly2 test framework, this commit tries to replace this test framework to Jetty based http test framework. Change-Id: I7bcb19bf73801cc66036487fd5a964e32ce1ba61
Jian Li authored -
- Supports east-west routing traffic - Fixes javadocs Change-Id: I23d9b9497cc2be667fbc9554812c7f5b49c35364
Kyuhwi Choi authored -
- tests were failing due to missing resources in incubator/api - commented out dependency in openstackrouting - duplicate dependency in apps/faultmanagement Change-Id: Ie9e9430d5707b0e2ab07338fdb8a5095126102f8
Ray Milkey authored
- 19 Apr, 2016 12 commits
-
-
- Do not include known peers in heartbeat message and instead each node relies on cluster metadata to add/remove nodes from inventory - Ignore heartbeats from nodes that are removed Change-Id: Ia20ce84ad88aa6c723a21af1fe7f6899821181ed
Madan Jampani authored -
- Use execute instead of submit so that uncaught Exception will be dealt and logged by ExecutorService's handler. - Use component's own logger Change-Id: I761264aea00748980929b5048e111756776dd2f6
HIGUCHI Yuta authored -
Remove network-cfg Each app has its own way to interpret the config. Therefore it doesn't make sense to keep a generic one In long term, each app should have a json schema that explain the meaning Remove network-cfg-fabric4x4 It does not provide more info than 2x2 Remove network-cfg-fabric2x2-default-route and network-cfg-fabric2x2-xconnect Keeping features in different configs doesn't help much but make people confused Also it's hard to maintain so many samples Add network-cfg-fabric-2x2-all Full fabric config with readme The html documentation is just temporary. We will have a json schema Rename/update network-cfg-fabric-2x2-min.json Minimum config required by the fabric Change-Id: I93332d8166c264b9dbb7819b90099c2f19fcf3b5Charles Chan authored
-
