16:05:00 <edwarnicke> #startmeeting MD-SAL meeting
16:05:00 <odl_meetbot> Meeting started Tue Jun 24 16:05:00 2014 UTC.  The chair is edwarnicke. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:05:00 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:05:00 <odl_meetbot> The meeting name has been set to 'md_sal_meeting'
16:05:04 <edwarnicke> #info  https://meetings.webex.com/collabs/#/meetings/detail?uuid=MCQK23GTHZNO7LDV6UWT6KLYPV-9VIB&rnd=497132.35684
16:05:13 <devinavery> #info https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call
16:05:21 <edwarnicke> #link https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call
16:05:27 <edwarnicke> #link https://meetings.webex.com/collabs/#/meetings/detail?uuid=MCQK23GTHZNO7LDV6UWT6KLYPV-9VIB&rnd=497132.35684
16:05:36 <edwarnicke> #topic Weekly Status
16:07:02 <edwarnicke> devinavery: Could we get a link to the change you are speaking of?
16:09:47 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/c/8046/ - Updates to DataBroker javadocs
16:11:01 <devinavery> #link https://git.opendaylight.org/gerrit/#/c/8168 - Updates to the toaster example to just the new DataBroker as documented
16:11:36 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/project:controller+branch:master+topic:clustering,n,z - clustering patches
16:15:06 <devinavery> #link https://git.opendaylight.org/gerrit/#/c/8255/ Adding documentation to the opendaylight-invetory.yang file.
16:16:30 <edwarnicke> #chair devinavery
16:16:30 <odl_meetbot> Current chairs: devinavery edwarnicke
16:17:57 <edwarnicke> #info Colin raised possible future discussion about what you can understand from yang vs java
16:18:04 <colindixon> thanks
16:18:16 <edwarnicke> #info alagalah raised (potentially separable) question about what you can *do* from yang vs java
16:18:23 <alagalah> Thank you sir
16:18:51 <colindixon> #info I think alagalah’s point was actually what *should be done* in Yang vs. Java, but all 3 are worth talking about
16:18:57 <alagalah> Not so much what you CAN do, as to what you SHOULD do
16:19:06 <colindixon> :p
16:19:09 <alagalah> colindixon: ack
16:20:11 <kw_> re: yang vs java, sounds like an interesting discussion, too bad i can't make next week's meeting
16:20:49 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/message:XSQL,n,z - XSQL patches Sharon would like to present next week
16:20:53 <alagalah> kw_: Its quite interesting
16:21:22 <edwarnicke> kw_: You will be missed
16:22:06 <colindixon> ugh, tony was *so* audible yesterday
16:22:21 <colindixon> and he’s back to so quiet it hurts :-(
16:22:24 <alagalah> colindixon: welcome to the interwebs
16:23:36 <devinavery> #topic Operational vs Config Datastores
16:23:48 <devinavery> #info Operational datastore is always a superset of the configuration datastore.
16:26:03 <devinavery> #info - apx 22 minutes in Ed is sharing screen which provides example of this
16:26:04 <rgowrishankar> #info if you add the line "config false" to a property, it will exist only in the operational datastore
16:30:59 <devinavery> #info Q: if you have a config attr called "port" how would you keep them in sync? Does MD-SAL provide this? Or is it the responsibility of the app?
16:31:49 <devinavery> #info A from Ed: It is the responsibility of the app - there is no way for MD-SAL to understand the operational attributes and how they are used.
16:32:54 <devinavery> #info A from Ed continue: The operational and config can be out of sync for a valid reason - you want something configured, but it couldn't be applied to operational correctly
16:33:11 <devinavery> #info Q from Colin: could we have good defaults like sync config to operational by default?
16:33:32 <devinavery> #info A from Ed: We need to explore the use-cases where sync from config to operational is desired.
16:34:37 <devinavery> #info Colin points out that config is the intent, and operational is the application of the intent. Colin suggests improving documentation to make this easier to understand and use.
16:35:06 <colindixon> yes!
16:35:07 <colindixon> that!
16:35:56 <devinavery> #info Recommendation from Ramkumar - good improvement would be an easy way to correlate between the config and operational trees. For example, given node 1 in the config tree, get me the same node in the operational
16:36:02 <colindixon> +10 to that
16:36:54 <devinavery> #info From Tony - use the same instance identifier in the operational store to get the same information that you did from the config store (i.e. opendaylight-inventory:nodes/node/myCustomNode is the ID in both datastores
16:37:09 <colindixon> devinavery: I should stop trying to take notes
16:37:14 <colindixon> you’re faster :p
16:37:17 <devinavery> :P
16:37:46 <devinavery> #info "A node has an address - It should have the same address in config and operational."
16:40:28 <devinavery> #info If lead Foo { config: false } is defined, then you can not put foo=5 into the config store (since it is an operational attribute)
16:40:55 <edwarnicke> #info examples of how I tend to represent nodes tersely
16:41:26 <edwarnicke> #info nodes->node[nodeId]- the node with nodeId
16:41:37 <devinavery> #info Are the stores enforcing the config false?
16:42:12 <edwarnicke> #info nodes->node[nodeId](flowcapable) -> tables -> table[tableId] - the table with tableId in a flowcapable augmented node with nodeId
16:44:25 <devinavery> #info no, The stores are not enforcing the config = false because the data stores for the binding aware enforce that. It complicates the case where people read from one store and writing to other and would complicate the binding aware logic
16:45:45 <devinavery> #info Question - what is a use case to copy from operational to config? A: Example - you query the switch for the current values and then write to the current config (which is stored in the operational) to the config
16:46:46 <colindixon> devinavery: let me know if you want me to take  over scribing
16:46:54 <devinavery> #info Q: If we are not going to enforce this flag, why do we even have the flag  and confuse people?
16:47:17 <devinavery> colindixon: sorry :) When I am not talking I am happy to type. :) Will let you know if I stop
16:47:42 <colindixon> scribing always makes sure you understand what’s going on
16:49:28 <devinavery> #info A: Having two datastores makes sense to separate what the user wants for a config and what it actually comes as (example, MTU size)
16:50:36 <devinavery> #info Suggestion (POV) - ONLY the data read from the network should be written to operational
16:51:13 <devinavery> #info Further clarification. Operational is a feedback loop, providing information from the real world, and the config is the intent.
16:51:47 <colindixon> I am now even more confused about things
16:52:19 <colindixon> I have (at least) two different ideas about how to do things should be separated between operational and config
16:52:40 <colindixon> one is that config is intent and operational is expression
16:52:57 <colindixon> the other is that config is for writing and opeartaional is for reading (loosely)
16:53:14 <devinavery> #info Some comments on phone suggest that we should have a config attribute and a separate operational attribute
16:53:23 <colindixon> this is sounding like we have a powerful mechanism and it can be used in a variety of patterns
16:53:53 <uchau> Question: The diagram labels some nodes as flowcapable and others as vswitchcapable, are they bound to an underlying protocol plugin to for operational and config data processing?
16:54:08 <colindixon> and we need to demonstrate those patterns and possibly build helper code to make common patterns easily
16:54:10 <colindixon> esier
16:54:12 <colindixon> easier
16:56:20 <devinavery> #info Q: Should we enforce the config: false in the MD-SAL? some thoughts that we should enforce it
16:57:27 <devinavery> #info A: Sounds like general concensus that we should enforce this at the config datastore level
16:58:00 <devinavery> #info recommendation - suggestion that you just ignore the config attributes, or possible create an object which has a copy constructor in the java class
17:00:44 <devinavery> #info Need an enhancement to have the config store enforce this.
17:01:28 <devinavery> #info Suggestion that if someone writes operational data to config store it should be a hard fail
17:01:30 <colindixon> #info colindixon just wants to point out that he’s now confused about how we should use operational vs. config—some people are saying it’s intent vs. expression and others are saying that it’s user expressed data vs. measured data—and it’s sounding like this separation may more of a mechanism that can be used for different things and we should define common patters
17:03:48 <edwarnicke> #endmeeting