17:00:50 <colindixon> #startmeeting tws
17:00:50 <odl_meetbot> Meeting started Mon Aug 15 17:00:50 2016 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:00:50 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:50 <odl_meetbot> The meeting name has been set to 'tws'
17:03:11 <colindixon> #topic agenda bashing
17:03:12 <colindixon> #info we have two topics for today: (1) cluster testing robot macros and (2) the YANG/Java binding spec v2
17:06:09 <colindixon> #topic binding spec v2
17:06:26 <colindixon> anipbu, adetalhouet if you could help take notes for 2-3 secs that would be aweomse
17:08:04 <adetalhouet> #info starts with what already exist since Helium.
17:08:35 <adetalhouet> #info YANG modeled data to respective Java Object structures and DTOs (compiled time & runtime)
17:09:15 <adetalhouet> #info Binding Spec v1 was introduces in Hydrogen, Binding Spec v2 started to emerge early Boron
17:09:35 <colindixon> adetalhouet: thanks
17:09:40 <colindixon> I'm back
17:09:46 <adetalhouet> #info Decision was to start from scratch for the Binding Spec v2
17:10:31 <colindixon> #info the binding v2 spec is done, but the implementation is still in process
17:11:16 <colindixon> #link https://gist.github.com/tonydamage/82b15f0cd1f39b729d4e binding v2 spec
17:11:30 <colindixon> fwiw, copying hex is annoying :p
17:13:16 <colindixon> #info some of the goals of the v2 spec are bugs from v1 spec
17:13:43 <colindixon> #link https://gist.github.com/tonydamage/82b15f0cd1f39b729d4e#known-problems-of-binding-specification-v1 this has links to teh bugs from the v1 spec
17:17:52 <colindixon> #info one example is that YANG has 5 namespaes for different types, but they're mapped onto one namepace in java, so you have to fix that, e.g., a grouping, vs. a container, vs. ...
17:18:36 <colindixon> #info colindixon asks why we are thinking of using pakcage names for that instead of using the class name, e.g., org.opendaylight.yang.grouping.Example vs. org.opendaylight.yang.ExampleGrouping
17:19:29 <colindixon> #info rovarga says at least one reason is that YANG names are freeform, so you could have example and example-grouping both being types
17:19:50 <colindixon> rovarga: I'm still not sure that causes a problem as long as you *know* that all generated java classes have to have their name end in the type right
17:19:56 <colindixon> there would be no ambiguity
17:19:59 <colindixon> or am I wrong
17:21:44 <colindixon> #link https://github.com/opendaylight/mdsal/blob/master/binding2/mdsal-binding2-spec/src/site/asciidoc/binding-2.adoc binding spec v2 docs
17:23:30 <colindixon> #info note the above doesn't have the images linked appropropately, but the recording does
17:25:50 <colindixon> #Info there's an example with a a bunch fo foos, indentifiers, and unions showing how type names are mapped in a combination of package names and class names
17:29:05 <colindixon> #info colindixon asks what happens if you have two modules with the grouping simple, answer is that the package names here aren't complete and in the future you will have to have the module namespace as part of the package name as well
17:31:13 <colindixon> #info colindixon asks when classes get a suffix, e.g., data.top.Foo vs. grp.simple.FooData
17:32:06 <colindixon> #info the answer seems to be that if you are a "foreign" type, e.g., if you're data in the grp namespace
17:34:13 <colindixon> #info in part, this is because the intantiation of a grouping is different from the grouping itself in v2, this fixes the semantics of augmentation
17:35:52 <rovarga> colindixon: the biggest problem is adding elements to a model, where all bets are pretty much off. while we can expect yang to enforce namespace clashes within a namespace, we cannot do so across namespaces. that would mean that we have to do a ... three-phase name mapping and recheck all mappings against all namespaces
17:36:37 <colindixon> rovarga: are you sure, I mean, if you just say, we will always add the "namespace" to the end of the class name, then you could (logically) strip that first and thus you know there are no collisions
17:36:59 <colindixon> e.g., you coudn't take example-grouping to ExampleGrouping because it would be ExampleGroupingGroupuing, which would be fine
17:45:01 <colindixon> #info vishnoianil asks if we have examples in code, martin says some of that exists
17:47:01 <colindixon> #info vishnoianil asks  if there's an impact analayis, martin and rovarga say that v1 and v2 can coexist, so that there should be no impact, but projects will be generally expected to move from v1 to v2 over time
17:48:45 <colindixon> #info vishnoianil asks what if people depend on projects that use v2, will they have to move, the answer is no because you go through binding independent DTOs which are the unerlying common element between v1 and v2
17:49:00 <colindixon> #info you could make an RPC call from v2 to a provider using v1 and it should just work
17:49:34 <colindixon> #info colindixon encourages other people to go look at this
17:50:15 <colindixon> #topic cluster testing robot macros
17:50:40 <rovarga> colindixon: rgiht ... there was a reason for not doing that ... I think it revolved about supporting tooling, JLS and whatnot
17:50:57 <colindixon> rovarga: it would be good to understand
17:51:08 <colindixon> not havint o refer to classes via FQCN would be helpful
17:51:24 <rovarga> colindixon: also, I think it was also around the fact that a piece of code deals either with instantiations or groupings...
17:52:07 <rovarga> colindixon: so cross-namespace imports would not be as frequent
17:52:19 <rovarga> colindixon: it was a long time ago, memory is sketchy :-/
17:52:34 <colindixon> ok
17:52:35 <colindixon> I might poke on the mailing list
17:52:41 <colindixon> I've imported way too many different node classes and had to use 400+ character class names
17:52:42 <colindixon> :p
17:53:06 <colindixon> #info we started cluster testing in the past, but we didn't have a set of simple, clear, generic resources
17:53:43 <colindixon> #link http://docs.opendaylight.org/en/latest/_static/integration/robot/ClusterManagement.robot.html docs
17:54:13 <rovarga> colindixon: yeah, but that could be seen as a Java language problem. other languages deal with this by allowing you to rename the import
17:54:14 <colindixon> #info luis goes over the keywords
17:54:31 <colindixon> rovarga: sure, I try not to punish users for their languages transgressions
17:54:42 <colindixon> espeically when we (sort of) chose that language
17:54:49 <colindixon> but if this is what makes the most sense, so be it
17:56:08 <colindixon> #info keywords are 5 bins: (1) shard setup, (2) shard state, (3) entity owner, (4) cluster member operations, (5) rest operations
17:57:40 <colindixon> #info for those watching the webex recording, the cluster testing starts around 44 minutes in the recording
17:59:32 <colindixon> #info luis shows a bunch of exampel tests that already use the cluster management keywords
17:59:55 <colindixon> #info this includes bgpcep, controller, netconf, netvirt, openflowplugin, ovsdb, ...
18:00:50 <colindixon> #info luis thanks vrpolak and a few others for all their help
18:01:17 <colindixon> #endmeeting