17:03:16 #startmeeting TWS call 17:03:16 Meeting started Mon Oct 13 17:03:16 2014 UTC. The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html. 17:03:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:16 The meeting name has been set to 'tws_call' 17:05:02 #topic MD-SAL "Consumability" work 17:05:38 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:MD-SAL_Document_Review 17:11:11 #info Ramkumar need to document when and where the Config Subsystem configuration is warranted, and where it might be used under the covers. Is the config subsystem going to be the one and only way of configuring modules... is there a process to make a decision? 17:11:58 #action alagalah : dbrainbri brings up how do we get a stated direction on the config subsystem and ensure its part of this documentation process. action- alagalah 17:13:12 #info ram notes that the ping example from devin avery is in limbo but is a very realistic example and should be included. 17:13:13 #link https://git.opendaylight.org/gerrit/#/c/7249/ 17:13:30 #action rgowrishankar take action from ping example linked by flaviof above 17:14:06 #topic Clustering update from Moiz 17:16:47 #info moiz points out that this conversation is not about the AD-SAL/Infinispan clustering but MD-SAL/Akka based clustering 17:17:06 #link https://wiki.opendaylight.org/view/File:Lithium_Enhancements_141013.pptx Preso 17:18:38 #info Notes that persistence in Li will be configurable 17:19:06 #info notes also persistence will be Helium 1.0 17:19:18 #info Notes that no operational data should be persisted 17:22:47 #info dbainbri mentions that one consideration might be the age of the operational data 17:25:19 #info moiz notes that turning off the level of persistence will improve performance (based on the example dbainbri brought up of a controller in a cable env with hundeds of Ks of user CPE trying to register) 17:25:52 #info dbrainbri notes it would be useful to get the timestamp of the data from the operational/config store to decide if the data is useful (fresh) or not (stale) 17:26:45 #info moiz points out we want to do a test of every integration build with clustering turned on (currently seeking resources from linux foundation to support this) 17:27:10 #info moiz also points out that nightly automated build testing is a target for clustering 17:28:00 #info moiz notes that there is a utility for clustering deployment in the integration repo: Search: Cluster-deployer in the integration repo 17:28:59 #info Bugs: All bugs targeted for Helium1 fix are tagged appropriately in bugzilla with the target fix release 17:30:04 #info Lithium Enhancements: programmatic creating shards: new application had its own module anddata running in a cluster, if you want to create a shard dynamically for a module (currently static in He) for the case when we are dynamically creating modules... this wil be via API 17:30:40 #info Lithium Enhancements: Finer grained sharding. Everything is sharded on project. May want to break things down into smaller chunks. 17:31:42 #link https://github.com/opendaylight/integration/tree/master/test/tools/cluster-deployer 17:31:56 #info Lithium Enhancements: (cont) only way to find leader of a shard is via JMX. This may be an enhancement request for an API/notifier 17:32:39 flaviof: thanks bud 17:32:53 alagalah: np! 17:33:23 #action alagalah add FR: Lithium Enhancements: (cont) only way to find leader of a shard is via JMX. This may be an enhancement request for an API/notifier 17:35:00 #info moiz notes that there is a Feature Request to rebalance Leader shards, espec. in the case of a 2 node cluster (Performance enhancement) 17:36:29 #info Lithium Enhancements: Querying... : ie there is a listener for say the Inventory shard, listening on every instance on that cluster. Shard only notifies the local listener, not all nodes in the cluster. This way all instances of an application doesn't get all notifications and act on it. Li enhancement is to make this configurable to be [local|all] 17:36:50 #info Lithium Enhancements: Querying: This enhancement not just data notifications but also YANG notificatoins 17:37:20 #info alagalah is a doofus and Querying (above) should be Enhanced Notification delivery 17:40:11 #info Lithium Enhancements: 2node cluster: moiz points out that current implementation requires that a write be to a MAJORITY before its quiesced. In a 2 node cluster a majority is 2 nodes. This is being addressed 17:40:37 fyi transaction 'commit' in md-sal is called 'submit'. 17:40:40 #info Lithium Enhancements: Querying (for real) ... enhancements to the DOM data store are required for this. 17:40:50 flaviof: Thanks, quite right 17:41:55 #link https://meetings.webex.com/collabs/#/meetings/detail?uuid=MALTOMIMY5WPSZORCBFJSNI22V-9VIB&rnd=533135.16576 Clustering meeting 17:42:05 #link https://bugs.opendaylight.org/buglist.cgi?list_id=18545&query_format=advanced&resolution=---&short_desc=Clustering&short_desc_type=casesubstring Bugzilla 17:42:20 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustering 8am Tue Pac meeting 17:44:07 #info flaviof asks what is happening with AD-SAL clustering 17:44:42 #info moiz points out there used to be a clustering service in AD-SAL but it requires applications need to be clustering aware 17:47:37 #info moiz points out that he is not aware of anyone working on AD-SAL clustering. dbainbri mentions perhaps the TSC may want to wade in on this 17:53:19 #topic Future topics 17:57:20 #endmeeting