16:06:18 <colindixon> #startmeeting MD-SAL call
16:06:18 <odl_meetbot> Meeting started Tue Jun 17 16:06:18 2014 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:06:18 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:06:18 <odl_meetbot> The meeting name has been set to 'md_sal_call'
16:06:31 <colindixon> #chair devinavery
16:06:31 <odl_meetbot> Current chairs: colindixon devinavery
16:06:43 <tbachman> Can someone cut/paste the link her?
16:06:47 <colindixon> #topic status update
16:07:38 <colindixon> tbachman https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call
16:07:50 <colindixon> that should have the most up-to-date webex link
16:07:55 <tbachman> colindixon: thx!
16:08:24 <tbachman> https://meetings.webex.com/collabs/#/meetings/detail?uuid=MCQK23GTHZNO7LDV6UWT6KLYPV-9VIB&rnd=497132.35684
16:08:33 <tbachman> not sure if that will work for everybody
16:08:33 <colindixon> #link https://git.opendaylight.org/gerrit/#/c/8046/ colindixon points out that tony has pushed a patch with better documentation thats’s pretty interesting
16:08:42 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/status:merged+project:controller+topic:clustering,n,z - clustering patches
16:09:35 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/project:controller+topic:clustering,n,z
16:09:45 <colindixon> #chair edwarnicke
16:09:45 <odl_meetbot> Current chairs: colindixon devinavery edwarnicke
16:10:26 <colindixon> #info the above patches are the start of clustering support, which is coming in bit-by-bit intentionally to allow it to be digested easily
16:11:23 * edwarnicke foiled again at chair dodging! :)
16:11:29 <tbachman> #link https://git.opendaylight.org/gerrit/8038
16:11:52 <colindixon> tbachman and all: you can add text after the link so that we get a line with the link and the patch
16:12:03 <tbachman> colindixon: good point
16:12:23 <colindixon> #info the above patch (8038) provides updated support for swagger description or RESTCONF APIs and interfaces
16:12:42 <tbachman> colindixon: thx!
16:13:11 <colindixon> tbachman: no worries, I got a lot of experience with meetbot while running the hydrogen release
16:13:19 <tbachman> :)
16:13:28 <colindixon> #link https://git.opendaylight.org/gerrit/#/c/7917/ potentially interesting patch relating to adding XSQL support
16:15:08 <colindixon> #topic Krish asking about how to set up producers and consumers
16:17:30 <dbainbri> should we use a single method to get / publish a service regardless if it is a SAL "core" service or not?
16:19:59 <colindixon> #info the confusion seems to be whether you should call ProviderContext.getSALService() vs. ProviderContext.getRpcService()
16:20:44 <colindixon> #info 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
16:21:14 * tbachman hands ttkacik a megaphone
16:21:48 <colindixon> dbainbri: I think the issue is whether it’s the services manage the service registry, or just a plain old service
16:21:52 <colindixon> dbainbri: but I agree
16:22:25 <devinavery> #info LLDPDiscoveryProvider.java provides an example where module X notifies module Y which notified module Z
16:22:31 <colindixon> #info dbainbri asks if we should figure out if we need to disambiguate between the infrastructure services and the others?
16:22:37 <dbainbri> It would simplify things, as well as establish a way to even replace core SAL services if someone wanted a custom implementation.
16:23:09 <colindixon> thanks for that note devinavery
16:23:16 <devinavery> #info LLDPDiscoveryListener.java listens and then publishes the notifications.
16:25:56 <devinavery> #info you can do similar things with RPCs that this example shows with notifications noted above.
16:26:22 <colindixon> by the way, the fact that I had to go from ProviderContext => ConsumerContext => RpcConsumerRegistry to find the getRpcService() function is really, really *wrong*
16:26:33 <colindixon> that’s is too much “enterprise grade”
16:26:54 <colindixon> #info Krish asks if there’s any documentation that we could find, the answer is yes
16:27:00 <devinavery> #link https://wiki.opendaylight.org/view/Example_Code Example code for interacting with MD-SAL
16:27:12 <rovarga> colindixon: I would say javadoc site would've made it more clear, I think
16:28:32 <colindixon> rovarga: fair, this is more understandable https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/target/apidocs/index.html?org/opendaylight/controller/hosttracker/IfIptoHost.html
16:28:56 <colindixon> although there’s no documentation explaining when to call which
16:29:09 <colindixon> wrong link
16:29:14 <colindixon> https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/target/apidocs/org/opendaylight/controller/sal/binding/api/BindingAwareBroker.ProviderContext.html
16:29:19 <colindixon> that’s the right link
16:31:31 <devinavery> #info the LLDP example is using an AbstractBindingAwareProvider (LLDPActivator extends the aware provider)
16:36:05 <dbainbri> so another simplifying questions. why not have a single "Component" class as opposed to a consumer and provider class. and then the implementation can choose to register implementation or not.
16:36:30 <dbainbri> what is the value of enforcing by having final methods in the consumer class
16:36:53 <colindixon> #info there’s a question about how to be both a provider and a consumer
16:37:38 <colindixon> #info 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
16:45:54 <colindixon> https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/target/apidocs/org/opendaylight/controller/sal/binding/api/BindingAwareBroker.ProviderContext.html
16:46:11 <colindixon> it’s marking the registerFunctionality() as deprecated now
16:48:32 <colindixon> #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
16:48:57 <edwarnicke> #action edwarnicke will update comments on AbstractBindingAware{Provider,Consumer} and {Producer/Consumer}Context to be clearer that Provider is a superset of Consumer
16:49:02 <colindixon> #info we will work on making the interfaces better on a deeper level going forward
16:49:48 <devinavery> #action devinavery will follow up on ed's comments
16:50:47 <colindixon> #info 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.
16:53:21 <colindixon> #topic the config subsytem
16:54:47 <lori> very good suggestion by krish: in documentation put pointers to example code that does the thing being documented
16:55:10 <lori> can someone #info in?
16:55:16 <colindixon> lori: you can
16:55:23 <colindixon> the #info command is for everyone
16:55:31 <lori> ah, I thought only chairs
16:55:31 <lori> ok
16:55:53 <colindixon> only chairs can do #topic and #endmeeting, but otherwise I think it’s all up
16:56:13 <lori> #info suggestion by krish: in documentation put pointers to example code that does the thing being documented
16:56:40 <colindixon> #info edwarnicke walks through the openflowplugin config xml
16:58:09 <colindixon> #info it’s called 42-openflowplugin.xml and is in the openflowplugin-controller-config java project inside the openflowplugin repo
16:59:34 <colindixon> #info the 42 is basically using /etc/init.d-style numbering
17:00:10 <colindixon> #info this indicates the order in which configs are processed
17:01:22 <devinavery> #info question asked why we are embedding numbers for ordering vs figuring out dependencies
17:01:41 <devinavery> #info answer from ed: There is dependencies and deterministic start-up
17:02:55 <devinavery> #info main argument from Ed - is deterministic start-up. Things get unpredictable in terms of start-up time etc.
17:03:25 <devinavery> #info colindixon disagrees on that start-up timing.
17:03:43 <devinavery> #info and deterministic start-up.
17:03:57 <colindixon> #info dbainbri asks why we wrote our own version of Spring-style dependency injection
17:05:19 <devinavery> #info Config System provides runtime reconfiguration of the system, and one other thing... (missed it)
17:05:43 <colindixon> #info tony responds that there are two things they needed (i) two-phase resolution of dependencies and (ii) runtime config modification
17:06:41 <devinavery> #info 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).
17:06:42 <colindixon> #info 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
17:07:19 <colindixon> I’m not sure that’s 100% right, but that was what I heard
17:08:04 <colindixon> #info dbainbri expresses his doubt that we actually want to do this live reconfig, but edwarnicke argues vehemently on the other side
17:08:35 <colindixon> #info 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).
17:12:08 <devinavery> #info ongoing discussions about persisting config automatically
17:14:22 <colindixon> #endmeeting