opendaylight : getting flow statistics from a java applicaton fails - opendaylight

I am trying to read flow statistics from a java opendaylight application (run's as a karaf feature).
I see the following exception in my Java application (running as an opendaylight feature):
java.util.concurrent.ExecutionException: org.opendaylight.controller.md.sal.dom.api.DOMRpcImplementationNotAvailableException:
No implementation of RPC AbsoluteSchemaPath{path=[(urn:opendaylight:flow:statistics?revision=2013-08-19)get-aggregate-flow-statistics-from-flow-table-for-given-match]} available
The following features are installed in my container:
karaf> feature:list | grep openflow
odl-openflowplugin-app-forwardingrules-manager | 0.5.1 | | Started | odl-openflowplugin-app-forwardingrules-manager | OpenDaylight :: Openflow Plugin :: Application -
odl-openflowplugin-nxm-extensions | 0.5.1 | | Started | odl-openflowplugin-nxm-extensions | OpenDaylight :: Openflow Plugin :: Nicira Extensi
odl-openflowplugin-nsf-model | 0.5.1 | | Started | odl-openflowplugin-nsf-model | OpenDaylight :: OpenflowPlugin :: NSF :: Model
odl-openflowplugin-app-config-pusher | 0.5.1 | | Started | odl-openflowplugin-app-config-pusher | OpenDaylight :: Openflow Plugin :: Application -
odl-openflowplugin-southbound | 0.5.1 | | Started | openflowplugin-0.5.1 | OpenDaylight :: Openflow Plugin :: Li southbound
odl-openflowjava-protocol | 0.5.1 | | Started | odl-openflowjava-0.5.1 | ODL :: o openflowjava :: odl-openflowjava-protocol
odl-openflowplugin-app-topology | 0.5.1 | | Started | odl-openflowplugin-app-topology | OpenDaylight :: Openflow Plugin :: Application -
odl-openflowplugin-flow-services | 0.5.1 | | Started | odl-openflowplugin-flow-services | OpenDaylight :: Openflow Plugin :: Flow Services
odl-openflowplugin-app-reconciliation-framework | 0.5.1 | | Started | odl-openflowplugin-app-reconciliation-framework | OpenDaylight :: Openflow Plugin :: Application -
What service gets invoked in opendaylight when I issue the following REST RPC call?
curl -v -u admin:admin -X GET http://localhost:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/0
My goal is to do the same thing from an opendaylight java application ( running as a service in the container), but I don't know how to do that.
Not sure if I am following the right approach.
Thanks, Ranga

Figured out the answer (for nitrogen release of ODL). The error message in the exception is confusing. Here's how to do it:
In the code snippet below node is of type InstanceIdentifier
InstanceIdentifier outNode = node.firstIdentifierOf(Node.class);
NodeRef nodeRef = new NodeRef(outNode);
GetFlowStatisticsInputBuilder inputBuilder = new GetFlowStatisticsInputBuilder();
inputBuilder.setFlowName(flow.getFlowName());
inputBuilder.setMatch(flow.getMatch());
inputBuilder.setTableId(flow.getTableId());
inputBuilder.setInstructions(flow.getInstructions());
inputBuilder.setNode(nodeRef);
GetFlowStatisticsOutput output = directStatisticsService
.getFlowStatistics(inputBuilder.build()).get().getResult();
Hope this helps somebody.

Related

Distributed OSGi example with Apache Karaf Cellar - Client bundle can't activate because can't find distributed service

I am using Apache Karaf 4.1.1 and Karaf Cellar. I have written two bundles. The first bundle provides a service of type ITrackerManager. The second bundle has a component that references ITrackerManager. My end goal is to witness the component in the second bundle successfully get a reference to the ITrackerManager service in the first bundle which is running on a different node. This is all part of my exploration of distributed OSGi.
What is actually happening when I install that second bundle is that it gets installed but fails to activate due to missing the service reference. I must be conducting my test incorrectly. Any ideas on how I would go about demonstrating my end goal; component in bundle on Node B successfully uses service on Node A?
Here is how I have run my test so far.
Node A
karaf#root()> cluster:node-list
| Id | Alias | Host Name | Port
--+-------------------+-------+--------------+-----
x | 159.4.251.58:5701 | | 159.4.251.58 | 5701
| 159.4.251.58:5702 | | 159.4.251.58 | 5702
Node B
karaf#root()> cluster:node-list
| Id | Alias | Host Name | Port
--+-------------------+-------+--------------+-----
| 159.4.251.58:5701 | | 159.4.251.58 | 5701
x | 159.4.251.58:5702 | | 159.4.251.58 | 5702
So far so good. I am running two karaf instances on my computer. Both instances see each other. Now I want to install that first bundle onto Node A ONLY. To accomplish that, I install the bundle into the cluster, then specifically remove it from Node B.
Node A
karaf#root()> cluster:bundle-install -s default mvn:myCompany/dosgi-example-part1/1.0-SNAPSHOT
karaf#root()> cluster:bundle-list default
Bundles in cluster group default
ID | State | Lvl | Located | Blocked | Version | Name
---+----------+-----+---------------+---------+----------------+--------------------------------------------------------------
0 | Active | | cluster/local | | 5.6.2 | System Bundle
...
67 | Active | | cluster/local | | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 1
karaf#root()> cluster:service-list
Service Class | Provider Node
--------------------------+------------------
myCompany.ITrackerManager | 159.4.251.58:5701
| 159.4.251.58:5702
Still looking good. My bundle is in the cluster, is local on Node A (and Node B at this point), and the service is recognized by the cluster and is available on both Node A and Node B. Now to remove the bundle from Node B.
Node B
karaf#root()> cluster:bundle-list default
Bundles in cluster group default
ID | State | Lvl | Located | Blocked | Version | Name
---+----------+-----+---------------+---------+----------------+-------------------------------------------------------------
67 | Active | | cluster/local | | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 1
karaf#root()> bundle:list
START LEVEL 100 , List Threshold: 50
ID | State | Lvl | Version | Name
---+--------+-----+----------------+-----------------------------------------------
75 | Active | 80 | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 1
karaf#root()> bundle:uninstall 75
karaf#root()> cluster:bundle-list default
Bundles in cluster group default
ID | State | Lvl | Located | Blocked | Version | Name
---+----------+-----+---------------+---------+----------------+--------------------------------------------------------------
67 | Active | | cluster | | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 1
karaf#root()> cluster:service-list
Service Class | Provider Node
--------------------------+------------------
myCompany.ITrackerManager | 159.4.251.58:5701
Excellent. The first bundle has been removed from Node B but still shows up as being in the cluster. Both nodes agree that my service is only available on Node A now (since the bundle was removed from Node B). Now I will load my second bundle on Node B only. This is where I run into problems. I don't load the second bundle using the cluster:bundle-install command because I don't want it ending up on Node A. So instead I install my second bundle using the normal bundle:install command. This results in an error about an unsatisfied reference.
Node B
karaf#root()> bundle:install -s mvn:otherCompany/dosgi-example-part2/1.0-SNAPSHOT
Bundle ID: 76
Error executing command: Error installing bundles:
Unable to start bundle mvn:otherCompany/dosgi-example-part2/1.0-SNAPSHOT: org.osgi.framework.BundleException: Unable to resolve otherCompany.dosgi-example-part2 [76](R 76.0): missing requirement [otherCompany.dosgi-example-part2 [76](R 76.0)] osgi.wiring.package; (&(osgi.wiring.package=myCompany)(version>=1.0.0)(!(version>=2.0.0))) Unresolved requirements: [[otherCompany.dosgi-example-part2 [76](R 76.0)] osgi.wiring.package; (&(osgi.wiring.package=myCompany)(version>=1.0.0)(!(version>=2.0.0)))]
karaf#root()> bundle:list
START LEVEL 100 , List Threshold: 50
ID | State | Lvl | Version | Name
---+-----------+-----+----------------+-----------------------------------------------------------------------------------------------------
76 | Installed | 80 | 1.0.0.SNAPSHOT | Distributed OSGi Example Part 2
So there it is. I install the second bundle on NodeB only, expecting that it is able to successfully use the required service which resides on Node A only. Unfortunately that does not happen. Instead I get error message stating there are unresolved requirements. It seems to behave as if DOSGI is not available. If I install both bundles on the same node, the second bundle activates without any errors. Any insights you may have would be appreciated.
My problem was two-fold.
Stuff to be sent over DOSGI needs to be serializable. In my case, I was calling a method on a remote service that took an argument. That argument was a class type defined in a common API. That class type was not serializable. Once I made it serializable, it starting getting different errors. Which brings me to...
Normal name space rules apply. I will elaborate below.
My API defined two interfaces.
ITracker
ITrackerManager
That API bundle was installed into the cluster so it is available on all nodes. My Service bundle had a concrete implementation of ITrackerManager. When that bundle is installed locally on Node A, the cluster:service-list command correctly shows that Node A has a service of type ITrackerManager.
My Client bundle has a concrete implementation of ITracker that had a reference to ITrackerManager which was installed on Node B. The first thing the ITracker instance did in its activate method was call ITrackerManager.addTracker(this). What should have happened was that the instance of ITracker on Node B provided itself to the ITrackerManager running on Node A. Initially this failed because ITracker was not serializable. Once that was solved, I started seeing classNotFound exceptions on Node A.
Node A was trying to deserialize the ITracker instance locally. It was attempting to deserailize a concrete class (TheirTracker) which was not defined locally, it was only defined on Node B in the client bundle. This failed.
So the normal namespace rules apply. Even though the client bundle on Node B has a reference to a service running in a bundle Node A, the service bundle in Node A cannot create (i.e. deserialize) an instance of a class that only exists in the client bundle on Node B.
I switched up my interfaces so that ITrackerManager method does not take an ITracker arguement. Instead it takes a string. Invoking that method over DOSGi works fine.
While I understand why this problem exists, this undermines a core capability I was hoping to use with DOSGi. I want clients to be able to register with a central controller which will actively control them. This won't work because even though the clients implement the interface the central controller is looking for, the specific serialization fails at the central controller. The client concrete classes exist in a namespace unknown to the central controller, hence the client cannot successfully pass itself to the central controller.
This must be a way to achieve what I am looking for in DSOGi without making each of the multiple clients an exported DSOGi service. Any ideas?

apache karaf faild to load web bundle

I downloaded the apache karaf 4.x and installed the 'war' feature and the karaf-doc bundle using following commands:
feature:install war
bundle:install -s mvn:org.apache.karaf/manual/4.0.0/war
but karaf failed to load that web bundle:
2016-01-17 17:16:36,167 | ERROR | pool-4-thread-1 | RegisterWebAppVisitorWC | 64 - org.ops4j.pax.web.pax-web-extender-war - 3.2.6 | Registration exception. Skipping.
java.lang.NoClassDefFoundError: javax/servlet/Filter
at java.lang.ClassLoader.defineClass1(Native Method)[:1.7.0_45]
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)[:1.7.0_45]
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2279)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1501)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_45]
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1844)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:937)
at org.ops4j.pax.swissbox.core.BundleClassLoader.findClass(BundleClassLoader.java:176)
at org.ops4j.pax.swissbox.core.BundleClassLoader.loadClass(BundleClassLoader.java:194)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_45]
at org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisitorHS.loadClass(RegisterWebAppVisitorHS.java:244)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisitorWC.visit(RegisterWebAppVisitorWC.java:261)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.model.WebApp.accept(WebApp.java:652)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.register(WebAppPublisher.java:237)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.addingService(WebAppPublisher.java:182)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.addingService(WebAppPublisher.java:135)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:864)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:317)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)[karaf-org.osgi.core.jar:]
at org.ops4j.pax.web.extender.war.internal.WebAppPublisher.publish(WebAppPublisher.java:101)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.WebObserver.deploy(WebObserver.java:213)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.WebObserver$1.doStart(WebObserver.java:175)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.extender.SimpleExtension.start(SimpleExtension.java:58)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender$1.run(AbstractExtender.java:266)[64:org.ops4j.pax.web.pax-web-extender-war:3.2.6]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_45]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)[:1.7.0_45]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)[:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_45]
at java.lang.Thread.run(Thread.java:744)[:1.7.0_45]
How can I fix this ?
The Karaf doc bundle in 4.0.0 actually had an issue if you do:
feature:install war
bundle:install -s mvn:org.apache.karaf/manual/4.0.3/war
it's working right away.
Just navigate to
http://localhost:8181/karaf-doc/
you're able to see the deployed applications via:
karaf#root()> web:list
ID | State | Web-State | Level | Web-ContextPath | Name
-----------------------------------------------------------------------------------------
97 | Active | Deployed | 80 | /karaf-doc | Apache Karaf :: Manual (4.0.3)
I doubt that OSGi is dying, actually the other way round, but that is a biased opinion.
Apache Karaf and ServiceMix based on it are ready for production, don't know about Virgo.

Unable to install logtash contrib plugins?

I want to use logstash contrib plugin riemann in my config file. On running logstash error comes:
An unexpected error occurred. This is probably a bug. |
| You can find help with this problem in a few places: |
| |
| * chat: #logstash IRC channel on freenode irc. |
| IRC via the web: http://goo.gl/TI4Ro |
| * email: logstash-users#googlegroups.com |
| * bug system: https://logstash.jira.com/ |
| |
+---------------------------------------------------------+
The error reported is:
Couldn't find any output plugin named 'riemann'. Are you sure this is correct? Trying to load the riemann output plugin resulted in this error: no such file to load -- logstash/outputs/riemann
I have a folder inside which both the logstash and its contrib tar are present and extracted.
I am using logstash 1.4.1 and logstash-contrib-1.4.1.
I tried the manual installation for contrib too by :
./bin/plugin install contrib
but nothing appears on the console on running the command.
Any help?
EDIT
On ls the following is my directory structure:
ls
elasticsearch-1.1.1 kibana-3.1.0.tar.gz logstash-1.4.1.tar.gz logstash-contrib-1.4.1.tar.gz
elasticsearch-1.1.1.tar.gz logstash-1.4.1 logstash-contrib-1.4.1 riemann-0.2.5.tar.bz2
Thus I have untarred contrib in the same directory as logstash. Any IDEA??
You shall extract logstash-contrib-1.4.1.tar.gz inside logstash-1.4.1 directory with commands:
cd logstash-1.4.1
tar zxvf logstash-contrib-1.4.1.tar.gz --strip 1
Then check lib/logstash/outputs/riemann.rb is under logstash-1.4.1.

Test an application behind a proxy server using Robot Framework and Selenium2Library

I'm testing a web application behind a proxy server using both Robot Framework and Selenium2Library. In fact when the proxy is enabled in browser connexion setting , the keywords "Open browser" failed
when I disabled the Proxy server option , the browser windows is getting opened but i am not able to visit the application.
This happen with both IE en ff driver.
I want to know if there is any additional configuration to solve this problem?
The Selenium2Library documentation gives an example of using a proxy using the Create Webdriver keyword:
| | # use proxy for Firefox
| | ${proxy}= | Evaluate | sys.modules['selenium.webdriver'].Proxy() | sys, selenium.webdriver
| | ${proxy.http_proxy}= | Set Variable | localhost:8888
| | Create Webdriver | Firefox | proxy=${proxy}

Cannot access to the webconsole interface

Since few days, I am playing around with apache felix. Everything works fine as it can be seen when lauching the lb command:
START LEVEL 2
ID|State |Level|Name
0|Active | 0|System Bundle (4.0.3)
1|Active | 2|Apache Felix Bundle Repository (1.6.6)
2|Active | 2|Apache Felix Configuration Admin Service (1.6.0)
3|Active | 2|Apache Felix Gogo Command (0.12.0)
4|Active | 2|Apache Felix Gogo Runtime (0.10.0)
5|Active | 2|Apache Felix Gogo Shell (0.10.0)
6|Active | 2|Apache Felix Http Bundle (2.2.0)
7|Active | 2|Apache Felix iPOJO (1.8.6)
8|Active | 2|Apache Felix iPOJO OSGi Junit Runner (1.0.0)
9|Active | 2|Apache Felix Shell Service (1.4.3)
10|Active | 2|Apache Felix Web Management Console (3.1.8)
11|Installed | 3|[Optimacs/OSGi] DataService - Hello World (1.1.0)
12|Active | 2|[Optimacs/OSGi] DataService Model (0.4.1.SNAPSHOT)
13|Active | 2|[Optimacs/OSGi] DataService Network API (0.4.1.SNAPSHOT)
14|Active | 2|[Optimacs/OSGi] DataService Container (0.4.1.SNAPSHOT)
According to this list, I can use the web management console. To this aim I have set the org.osgi.service.http.port option to 8080.
My problem occurs when I open my browser (Chrome, the latest version) and try accessing to the web console (url = http://localhost:8080/system/console). I get an error 102 (connection refused).
Is there any particular configuration step I have missed?
EDIT
Running inspect cap service through the gogo shell reports the following about the HttpService:
org.apache.felix.http.bundle [6] provides:
------------------------------------------
service; javax.servlet.http.HttpServlet with properties:
http.felix.dispatcher = org.apache.felix.http.base.internal.DispatcherServlet
service.description = Dispatcher for bridged request handling
service.id = 20
service.vendor = The Apache Software Foundation
service; java.util.EventListener with properties:
http.felix.dispatcher = org.apache.felix.http.base.internal.EventDispatcher
service.description = Dispatcher for bridged HttpSession events
service.id = 21
service.vendor = The Apache Software Foundation
There is no indication about the used port unfortunately.
The issue has been resolved thanks to Neil's comment:
I wonder if the HttpService is present, could you do inspect cap service from the shell and scan through for HttpService? If it's there it should also report what port number it is using.

Resources