================================== #opendaylight-meeting: MD-SAL call ================================== Meeting started by colindixon at 16:06:18 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-meeting/2014/md_sal_call/opendaylight-meeting-md_sal_call.2014-06-17-16.06.log.html . Meeting summary --------------- * status update (colindixon, 16:06:47) * LINK: https://meetings.webex.com/collabs/#/meetings/detail?uuid=MCQK23GTHZNO7LDV6UWT6KLYPV-9VIB&rnd=497132.35684 (tbachman, 16:08:24) * LINK: https://git.opendaylight.org/gerrit/#/c/8046/ colindixon points out that tony has pushed a patch with better documentation thats’s pretty interesting (colindixon, 16:08:33) * LINK: https://git.opendaylight.org/gerrit/#/q/status:merged+project:controller+topic:clustering,n,z - clustering patches (edwarnicke, 16:08:42) * LINK: https://git.opendaylight.org/gerrit/#/q/project:controller+topic:clustering,n,z (edwarnicke, 16:09:35) * the above patches are the start of clustering support, which is coming in bit-by-bit intentionally to allow it to be digested easily (colindixon, 16:10:26) * LINK: https://git.opendaylight.org/gerrit/8038 (tbachman, 16:11:29) * the above patch (8038) provides updated support for swagger description or RESTCONF APIs and interfaces (colindixon, 16:12:23) * LINK: https://git.opendaylight.org/gerrit/#/c/7917/ potentially interesting patch relating to adding XSQL support (colindixon, 16:13:28) * Krish asking about how to set up producers and consumers (colindixon, 16:15:08) * the confusion seems to be whether you should call ProviderContext.getSALService() vs. ProviderContext.getRpcService() (colindixon, 16:19:59) * at least one part of the answer is that getSALService() is for getting SAL infrastructure services, while getRpcService() is for getting services which are advertised through or via the SAL (colindixon, 16:20:44) * LLDPDiscoveryProvider.java provides an example where module X notifies module Y which notified module Z (devinavery, 16:22:25) * dbainbri asks if we should figure out if we need to disambiguate between the infrastructure services and the others? (colindixon, 16:22:31) * LLDPDiscoveryListener.java listens and then publishes the notifications. (devinavery, 16:23:16) * you can do similar things with RPCs that this example shows with notifications noted above. (devinavery, 16:25:56) * Krish asks if there’s any documentation that we could find, the answer is yes (colindixon, 16:26:54) * LINK: https://wiki.opendaylight.org/view/Example_Code Example code for interacting with MD-SAL (devinavery, 16:27:00) * LINK: https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/target/apidocs/org/opendaylight/controller/sal/binding/api/BindingAwareBroker.ProviderContext.html (colindixon, 16:29:14) * the LLDP example is using an AbstractBindingAwareProvider (LLDPActivator extends the aware provider) (devinavery, 16:31:31) * there’s a question about how to be both a provider and a consumer (colindixon, 16:36:53) * the answer is that a provider is a strict superset of consumer, meaning that if you want to be both, you should only extend the provider (colindixon, 16:37:38) * LINK: https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/target/apidocs/org/opendaylight/controller/sal/binding/api/BindingAwareBroker.ProviderContext.html (colindixon, 16:45:54) * ACTION: edwarnicke will take a first stab fix the comments (today) w.r.t. to the ProviderContext and ConsumerContext to fix the problem as well as we can now (colindixon, 16:48:32) * ACTION: edwarnicke will update comments on AbstractBindingAware{Provider,Consumer} and {Producer/Consumer}Context to be clearer that Provider is a superset of Consumer (edwarnicke, 16:48:57) * we will work on making the interfaces better on a deeper level going forward (colindixon, 16:49:02) * ACTION: devinavery will follow up on ed's comments (devinavery, 16:49:48) * Krish points out he’s also confused about the config subsystem, and is looking for help wherever he can get it: the wiki, humans, etc. (colindixon, 16:50:47) * the config subsytem (colindixon, 16:53:21) * suggestion by krish: in documentation put pointers to example code that does the thing being documented (lori, 16:56:13) * edwarnicke walks through the openflowplugin config xml (colindixon, 16:56:40) * it’s called 42-openflowplugin.xml and is in the openflowplugin-controller-config java project inside the openflowplugin repo (colindixon, 16:58:09) * the 42 is basically using /etc/init.d-style numbering (colindixon, 16:59:34) * this indicates the order in which configs are processed (colindixon, 17:00:10) * question asked why we are embedding numbers for ordering vs figuring out dependencies (devinavery, 17:01:22) * answer from ed: There is dependencies and deterministic start-up (devinavery, 17:01:41) * main argument from Ed - is deterministic start-up. Things get unpredictable in terms of start-up time etc. (devinavery, 17:02:55) * colindixon disagrees on that start-up timing. (devinavery, 17:03:25) * and deterministic start-up. (devinavery, 17:03:43) * dbainbri asks why we wrote our own version of Spring-style dependency injection (colindixon, 17:03:57) * Config System provides runtime reconfiguration of the system, and one other thing... (missed it) (devinavery, 17:05:19) * tony responds that there are two things they needed (i) two-phase resolution of dependencies and (ii) runtime config modification (colindixon, 17:05:43) * Argument for runtime configuration - if you have a running system, and now a new switch comes in a different port, so you can then change it live (add another listener on the new port). (devinavery, 17:06:41) * the two-phase resolution of dependencies I think is first doing wiring of dependencies and and then resolving the instances you need and spinning them up (colindixon, 17:06:42) * dbainbri expresses his doubt that we actually want to do this live reconfig, but edwarnicke argues vehemently on the other side (colindixon, 17:08:04) * dbainbri asks if we change the config file while it’s running, will the config update. Answer is no, but you can change it via JMX (I think). (colindixon, 17:08:35) * ongoing discussions about persisting config automatically (devinavery, 17:12:08) Meeting ended at 17:14:22 UTC. Action items, by person ----------------------- * devinavery * devinavery will follow up on ed's comments * edwarnicke * edwarnicke will take a first stab fix the comments (today) w.r.t. to the ProviderContext and ConsumerContext to fix the problem as well as we can now * edwarnicke will update comments on AbstractBindingAware{Provider,Consumer} and {Producer/Consumer}Context to be clearer that Provider is a superset of Consumer People present (lines said) --------------------------- * colindixon (49) * devinavery (14) * tbachman (9) * odl_meetbot (5) * lori (5) * edwarnicke (4) * dbainbri (4) * rovarga (1) Generated by `MeetBot`_ 0.1.4