=========================================== #opendaylight-meeting: MD-SAL interest call =========================================== Meeting started by devinavery at 16:09:06 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-meeting/2014/md_sal_interest_call/opendaylight-meeting-md_sal_interest_call.2014-08-19-16.09.log.html . Meeting summary --------------- * status update (devinavery, 16:09:11) * no new interesting status (devinavery, 16:09:20) * Karaf Features (Ed Presenting) (devinavery, 16:09:29) * If your features depend on features in another feature file you must add a repository entry to state that dependency (devinavery, 16:10:52) * Ed suggest some organization tips (devinavery, 16:11:30) * 1) have an odl--all fetter which installs everything (devinavery, 16:11:36) * 2) use the same order in the all feature as your features are listed / defined below (devinavery, 16:12:12) * Important note on pom.xml - you need to have dependencies on your features bundles otherwise your distributions may not get built correctly. (devinavery, 16:12:57) * Question from Robert - what is the minimum scope required for the feature dependency bundles? Answer: "compile" Reason: it has to do with the way karaf resolves dependencies. WE could look deeper to see if we can change that (devinavery, 16:14:03) * Ed create a simple loader test which tests that every feature in your feature.xml file loads cleanly at the OSGi window (devinavery, 16:14:28) * LINK: https://wiki.opendaylight.org/view/Karaf:Hands_On_Guide#Testing Goes over how to configure the features tests (devinavery, 16:15:26) * Ed shows what it looks like when the tests run and pass and now Ed is showing what it looks like when a feature fails to load (devinavery, 16:17:53) * Question: is it possible to get false positives because of load order? A: No - not with this tests. If your test was to randomly go in and install features in order then it could result in false positives. In this test, we install each feature into a clean OSGi by its self so one feature can't polite another feature (devinavery, 16:22:58) * Question: Any reason this is done using surefire and not failsafe. Answer: Ed just grabbed surfire instead of failsafe. And 2 Ed believes that this is more of a unit test of the features.xml file. Robert is suggesting that we only want to run these in Jenkins. Ed doesn't object to it just running on Jenkins or using failsafe. (devinavery, 16:25:29) * devinavery states that regardless of what we call it it must be a gating test which on failure blocks code submissions (devinavery, 16:27:33) * Ed is explaining how you can use the feature tests...see recording or wiki for more details (devinavery, 16:28:33) * Ed is demoing the odl-restconf feature install. (devinavery, 16:32:13) * Important Note: Karaf default to port 8181 instead of port 8080. The reason is that karaf comes with a built in tomcat on port 8080 which just works with standard northbound clients. So until we figure out what is happening restconf is on port 8181 (devinavery, 16:33:20) * Question from Madhu - does restconf work with json etc? Madhu tried and it didn't seem to work. Seemed like some strange behavior. Ultimate question: What is restconf using for parser? Answer: we use gson in restconf (devinavery, 16:37:22) * Question: this test is run on verify in the controller projects. What about the other projects? Answer: Ed is of the opinion that this should run on verify for all feature files everywhere. We due this using scan-dependencies section in surefire is because it allows you to include this in your pom file. (devinavery, 16:42:00) * Question: when do you think this will be ready to be consumed by other projects? Answer: The test is in there and it is working and there is a bare-bones wiki in place. Next step for Ed is to try this on a project (open flow) and document a clean easy pattern that others can follow from (devinavery, 16:43:07) * Questions from mailing list (devinavery, 16:48:39) * Showing question from the mailing list from Ramkumar about node augmentations. (devinavery, 16:49:15) * Question: How would a plugin get all objects of a given augmentation type on the nodes type - right now we need to iterate each Node checking for existence. Can we expose an API for this common use case of querying augmentations of nodes? (devinavery, 16:50:39) * Answer: Robert: Give me all nodes with a particular trait is a more complex problem which the query language may solve which colindixon and devinavery are working on. Not targeted for Helium. (devinavery, 16:52:30) * Ramkumar is suggest that we expose a new API, or helper code or something else for this common use case. (devinavery, 16:55:26) * Ramkumar ask if we can have a binding interface on top of the query language - answeR: sky is the limit - we will try and demo the prototypes in the near future. (devinavery, 16:58:40) Meeting ended at 16:58:43 UTC. People present (lines said) --------------------------- * devinavery (31) * Madhu (4) * odl_meetbot (3) Generated by `MeetBot`_ 0.1.4