17:04:41 <phrobb> #startmeeting TWS call Devin Avery leading a discussion on the MD-SAL
17:04:41 <odl_meetbot> Meeting started Mon May 19 17:04:41 2014 UTC.  The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:04:41 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:04:41 <odl_meetbot> The meeting name has been set to 'tws_call_devin_avery_leading_a_discussion_on_the_md_sal'
17:05:05 <Madhu> phrobb: can u pls add me as a chair as well ? i will contribute to notes
17:05:11 <phrobb> #chair edwarnicke Madhu alagalah
17:05:11 <odl_meetbot> Current chairs: Madhu alagalah edwarnicke phrobb
17:05:47 <alagalah> Oh dear I got chaired
17:05:58 <phrobb> @alagalah :-)
17:06:14 <edwarnicke> alagalah: Dodge faster :)
17:10:34 <phrobb> #info Key underlying theme is to increase the transparancy of the MD-SAL
17:11:12 <Madhu> #info Transparency = Whats working, Whats not working, Whats the current status,
17:11:51 <dbainbri> What about questions in MD-SAL about where, when, or if tools like xtend should be used?
17:12:19 <Madhu> #info Sharing the knowledge is critical to get the community around MD-SAL development.
17:12:51 <dbainbri> (as MD-SAL and yang tools are intimately tied)
17:14:07 <edwarnicke> dbainbri: We are actively trying to reduce/eliminate xtend outside of specifically code generation kinds of things where its appropriate
17:14:08 <Madhu> #question dbainbri: What about questions in MD-SAL about where, when, or if tools like xtend should be used?
17:14:34 <rovarga> appropriate: we use xtend for templating
17:14:45 <rovarga> everything else is done in java
17:15:19 <Madhu> #info make the backlog publicly visible for everyone from the community to contribute.
17:15:45 <Madhu> #idea weekly dedicated md-sal status call.
17:15:54 <dbainbri> xtend is difficult to support (imho) as it causes indirection when debugging. i also have issues with code generation in terms of debugging / support as well. you can't step through generated code.
17:16:18 <rovarga> that is the case for any templating language
17:17:03 <rovarga> so the last think I worked on is yangtools/code-generator/binding-generator-impl/src/main/java/org/opendaylight/yangtools/sal/binding/generator/impl/TransformerGenerator.xtend
17:17:11 <Madhu> #info proposal : Identify Feature gap.
17:17:16 <dbainbri> rovarga, agreed, which is why i wouldn't use a templating language for a product (opinion) as that indirection makes debugging and support difficult (opinion)
17:17:16 <rovarga> note how it has a clear interface to the rest of the package
17:17:42 <edwarnicke> dbainbri: dbainbri I think that there is a distinction between 'xtend for code generation (for example what yangtools does)' and 'why is xtend being used here?'
17:17:48 <Madhu> #info proposal : Prioritize the features, bugs, enhancements into public backlog which is reviewed weekly.
17:17:53 <rovarga> so if you have a proposal, please start with replacing that class ...
17:18:14 <rovarga> e.g. the .xtend file with some other class, which implents the abstract interface
17:18:53 <edwarnicke> dbainbri: I'm not dismissing your point about xtend at all... (as I said, its being rooted out most places)
17:19:22 <edwarnicke> dbainbri: Let me be more concrete... if you can point out places you think xtend is used inappropriately, would *very* much like the pointer :)
17:19:24 <dbainbri> rovarga: if we would like more people to contribute to yang-tools and md-sal core (i.e., behind that clear interface) I think (opinion) xtend is a barrier. we have thought about replacing xtend, but it is unclear if those changes would be accepted back as contributions.
17:20:09 <edwarnicke> dbainbri: there are a bunch of patches here: https://git.opendaylight.org/gerrit/#/q/status:merged+message:%22xtend%22+branch:master+project:controller,n,z where xtend is being rooted out of mdsal core
17:20:12 <rovarga> dbainbri: I personally hate xtend, but understand that there are areas where it's actually needed
17:20:26 <dbainbri> edwarnicke: to be fair, i would remove all xtend. so it isn't, in my opinion, where it is appropriate, i think it should be removed altogether.
17:20:26 <edwarnicke> dbainbri: I would suggest its productive to talk about places you think it should be rooted out :)
17:20:32 <rovarga> dbainbri: or some other templating solution
17:20:43 <Madhu> #info dlenrow: question existing design and decide as a community if some design needs attention and maybe replace with better ones ?
17:20:48 <phrobb> #info  Continued and deeper sharing of knowledge of the MD-SAL's inner workings is needed
17:20:57 <rovarga> dbainbri: as for patches, I don't see a reason why not, as long as the result is improved maintainability
17:21:02 <raghu67> #idea sometime ago, we had talked about conducting a md-sal workshop. Couple of days  dedicated to vision/status/planning of md-sal. Some how it fizzled out. If there is interest,we should look at that
17:21:24 <edwarnicke> dbainbri: I think I am hearing from you 'I don't want to do the work if this patch will be unwelcome'... I completely understand that concern
17:21:45 <edwarnicke> dbainbri: Which is why I suggested pointing to specific places you think it should be rooted out :)
17:22:13 <dbainbri> edwarnicke: that was the feeling yes. i know there are supporters of xtend. i may be the odd man out, i can understand that. so until there is consensus, not sure the work would be worth it.
17:22:56 <Madhu> #info md-sal workshop is a good idea to begin with. But this needs to be an ongoing community driven activity.
17:23:00 <dbainbri> +1 for status meeting.
17:23:07 <Madhu> +1
17:23:08 <alagalah> +1
17:23:08 <dave_tucker> +1
17:23:14 <edwarnicke> +1 for status meeting
17:23:19 <dvorkinista> +1
17:23:31 <edwarnicke> dbainbri: I think there are a variety of view on xtend. Lets get them out theree
17:23:32 <rovarga> +1 as long as it's the format is very quick
17:23:36 <alagalah> Is that colin talking?
17:23:37 <rovarga> there are a lot of meetings :)
17:23:44 <cdub> colindixon: +1
17:24:14 <alagalah> hang on
17:24:17 <Madhu> colindixon: can u please #info it on ?
17:24:18 <alagalah> Thats the wrong Q
17:24:24 <Madhu> i didn't get the point.
17:24:39 <alagalah> lost audio
17:24:41 <colindixon> dbainbri: I think that with xtend, like a lot of things, there generally three camps of people: (1) people who actively use it and like it, (2) people who are generally opposed to it, and (3) people who have no opinion because they haven’t had time to look at it
17:24:49 <rovarga> dbainbri: so I would suggest to pick up BUG-614 and fix all its blockers
17:25:01 <colindixon> and too many people fall into (3)
17:25:08 <colindixon> Madhu: sure two secs
17:25:31 <colindixon> #info if we have to have a 2-3 day in-person workshop for people to get involved in MD-SAL, that’s a bad sign
17:25:47 <Madhu> thanks colindixon
17:26:09 <colindixon> #info it’s not necessarily a bad idea, but we need to find a way for people to get into the MD-SAL on an ongoing basis, which is what this call is about
17:26:13 <dbainbri> colindixon: i quickly became a member of camp 2 after attempting to debug the toaster example early on both in terms of tracing back from Java to xtend as well as attempting to step through generated code (which i closely relate in my mind to the xtend work)
17:26:32 <edwarnicke> colindixon: I would put myself in the fourth camp: I think there are a class of problems its well suited to, and those problems are real, but its a valid question whether or not its the optimal solution to those problems, and its been overused in a lot of places
17:26:44 <edwarnicke> dbainbri: I feel your pain on debugging
17:26:48 <regXboi> edwarnicke: +1
17:26:49 <colindixon> dbainbri: yeah, I generally fall on the side of seems to cause more problems than it solves
17:26:52 <edwarnicke> Been there, done that, have those scars
17:27:26 <colindixon> #info networkstatic says that he’d love to see more examples than toaster, the toaster example always rang a big hollow to him
17:27:43 <edwarnicke> +1 to gluten free examples
17:28:10 <dbainbri> rovarga: lol, bug 614 i would characterize as the remove xtend bug ;)
17:28:28 <rovarga> dbainbri: yeah, almost
17:28:30 <colindixon> #info devinavery says they’re working on such examples now, which is really good
17:28:40 <rovarga> it has specific subtasks, which are easily done
17:29:34 <dbainbri> edwarnicke: can you info your last comment, had audio issues?
17:30:11 <edwarnicke> dbainbri: sure
17:30:47 <edwarnicke> #info folks who'd contributed longer term to MD-SAL were being quieter on the call because we wanted to *listen*, not because we were not engaged :)
17:31:13 <dbainbri> tony: are you suggesting that you are looking for contributions in MD-SAL, but not so much at the yang-tools layer?
17:31:16 <alagalah> Well..
17:31:41 <alagalah> May I make a suggestion ?
17:31:44 <edwarnicke> dbainbri: That's Robert's speaking... but I don't think he's implying contributions to yangtools are unwelcome
17:31:51 <edwarnicke> alagalah: Please :)
17:32:06 <Madhu> rovarga: can u please info it in ? it is hard to hear
17:32:13 <dbainbri> (sorry Robert, my apologies)
17:32:51 <alagalah> Whoever is speaking right now, you are making sense... we need to stop the boat.
17:32:52 <dbainbri> edwarnicke: agreed, but difference between unwelcome and really looking at yang-tools as more stable and so not so much help needed there.
17:32:55 <phrobb> #info Q:  Yang Tools and MD-SAL are at various ponts of development, what are the MD-SAL committers feelings toward accepting in and mentoring new developers into the internals of the MD-SAL
17:33:08 <lenrow> Can yang and yang tools model N-deep multitenancy across all our infra?
17:33:26 <edwarnicke> lenrow: Topic for conversation, definitely
17:33:27 <phrobb> #info A:  edwarnicke would throw a parade for new folks coming to work on the internals of MD-SAL.
17:33:41 <colindixon> phrobb: that’s *the* question
17:33:41 <Madhu> #question lenrow: Can yang and yang tools model N-deep multitenancy across all our infra?
17:33:43 <regXboi> lenrow: N-deep?
17:33:44 <edwarnicke> phrobb: We've had some (Devin et al) but would love more
17:34:44 <alagalah> +1 brent
17:34:48 <lenrow> facilities provider has tenants who are virtual providers who have tenants who are corporations who have tenants who are BU's etc. isolation/hiding across whole heirarchy
17:35:10 <regXboi> That's what I thought you meant, but wanted to be sure
17:35:19 <lenrow> clarity is good
17:35:20 <Madhu> #info request is to slow down to let the community catch up ?
17:35:52 <alagalah> Madhu: This is inline with what you suggested re: code stability
17:36:04 <Madhu> alagalah: yep.
17:36:21 <regXboi> lenrow: I'm not sure, but there is a thought in my mind that yang isn't 100% happy with recursive references
17:36:28 <regXboi> i.e. X containing X
17:36:51 <edwarnicke> regXboi: I *think* that it can be handled with references... but we'd need to have a longer discussion to make sure
17:37:02 <alagalah> edwarnicke: regXboi listen to Rob
17:37:13 <lenrow> Possible and non-painful may diverge here :-)
17:37:15 <edwarnicke> alagalah: definitely listening :)
17:37:20 <Madhu> #info rob adams : Request is to pause & look at usability aspects of MD-SAL.
17:37:25 <regXboi> alagalah: ack
17:37:59 <edwarnicke> #info wants to look at async nature of rpc invocations
17:38:07 <dbainbri> +1 for testability (and +1 for supportabiliity)
17:38:08 <regXboi> readams +max_u64_int
17:38:43 <alagalah> Yes
17:38:44 <phrobb> #info rob adams asks to address the MD-SAL to allow for solid unit testing / usability / supportability
17:38:46 <edwarnicke> #info readams has specific recommendations for improving testability
17:38:48 <lenrow> To me entire value prop for MD-SAL is to find common abstractions to overlay the SBIs. Community has spent exactly zero seconds pursuing this..Just saying
17:38:49 <alagalah> +1 Rob
17:38:50 <Madhu> readams: can u please #info it in. very useful requests
17:39:03 <phudgins> +1
17:39:07 <edwarnicke> lenrow: Would love to work more on that :)
17:39:48 <dbainbri> I would also like to have a clear semantics for when RPC and when data store updates + notification to cause change (i know people have talked about when and where to use both, but the "if it is a resource" rule can be used (many times) to choose A | B and i think that may lead to inconsistencies across MD-SAL based projects.
17:42:37 <edwarnicke> dbainbri: I have opinions on that, but would be curious to hear other thoughts :)
17:44:00 <phrobb> #info Devin asks that the MD-SAL status meeting have all developers on/around the MD-SAL to report "this is what we did", "This is what we're doing", and "This is what we are blocked-on".. recent issues, need/call-for help, etc
17:44:52 * regXboi raises hand
17:45:39 <Madhu> #idea in the long-run TSC should become a place where we drive the architecture for ODL core components
17:45:39 <phrobb> #info readams notes the TSC should become more of a call to push forward the architecture of the overall project… goals for the system what the project needs overall to create a robust, and usable controller platform
17:46:14 <dbainbri> edwarmocke: i have opinion on that as well (shock). i think the community needs to set down some best practices with some level of checking / enforcement
17:46:20 <Madhu> networkstatic: can u please #info on your initial issues that with ofplugin that you shared today ?
17:47:26 <lenrow> Let's buy  RegXboi a pretty calendar
17:48:04 <readams> agree with Ryan: need counters, event logs for operational state; need AAA for config state
17:48:14 <icbts> Per user histories?
17:49:10 <Madhu> #info debugability is critical for MD-SAL deployment
17:49:53 <Madhu> #action wiki page to track the issues, feature requests, feature gaps, work being done, status, etc..
17:49:58 <cdub> #info debugability is both developer level _and_ operator level (tracing/auditing, etc)
17:49:59 <rovarga> regXboi: auditing can be cleanly fitted into the core
17:50:17 <regXboi> lenrow: the calendar is always pretty to begin with - it's after I get it that it gets ugly :)
17:50:39 <rovarga> there are natural surfaces to add hooks -- a few aspects (with LTW) and you're done
17:51:43 <alagalah> MAte, sure, meeting ok but as long as it has actions
17:51:48 <ghall> what meeting today keeps the Controller release plan in sync?
17:51:51 <dbainbri> +1 initial gathering and prioritization via wiki / email
17:51:56 <dbainbri> then a meeting.
17:52:03 * regXboi raises hand again :)
17:52:24 <alagalah> regXboi: I need to send you some 10lb weights
17:52:40 <alagalah> regXboi: Cos you raise your hand so much, you would be buff with some weights
17:53:03 <readams> I suspect raising your hand in IRC will not at any point result in a window appearing on the call :-)
17:55:10 <cdub> readams: need to get meetbot to do that ;)
17:55:36 <tbachman> #raisehand causes beeps in WebEx ;)
17:55:52 <cdub> this is an example of why blueprints and/or design docs, etc are useful
17:56:07 <cdub> it shows owner, and can be tied to bz
17:56:32 <alagalah> cdub: blueprints?
17:56:38 * edwarnicke opines that bugs are an excellent thing, but I think I am hearing a desire for some higher level (probably several higher level) things on top of bugs
17:56:42 <colindixon> rovarga: so, were you refering to the openflowjava/openflowplugin/yangtools effor?
17:56:46 <alagalah> cdub: we don't need no stinking blue prints
17:57:10 <cdub> alagalah: it's tradeoffs
17:57:21 <alagalah> cdub: oh shit
17:57:27 <alagalah> did regXboi just say that?
17:57:34 <rovarga> colindixon: also bgpcep, controller (config, netconf, md-sal) are tracked through bugzilla
17:57:35 <cdub> alagalah: too much formalism stinks, not enough and it's hard to see what's going on
17:58:03 <alagalah> wow
17:58:10 <alagalah> sounds like so hippy
17:58:12 <Madhu> #info meeting_notes | 0,$s/core/critical/g
17:58:15 <cdub> s/core/fundamental/ ?
17:58:28 <alagalah> cdub: makes you feel better?
17:58:47 <edwarnicke> colindixon: As someone who had a little bit to do with the openflowplugin culture around getting things done... part of why it works is because it evolved as part of getting that project working together (and honestly, it was challenging and took some figuring out by trial and error)
17:58:59 <edwarnicke> s/core/fnord/
17:59:24 <colindixon> rovarga: I think the issue is that it’s a great tool if you’re tracking low-level details, but really, really doesn’t work for new people to push on things or learn
18:00:17 <flaviof> colindixon: +1
18:00:28 <rovarga> colindixon: not sure what you mean... what tools would you suggest?
18:00:34 <edwarnicke> +1 status meeting
18:00:39 <raghu67> +1 status meeting
18:00:43 <colindixon> +1
18:00:44 <flaviof> +1 status meeting
18:00:47 <rovarga> +1
18:00:49 <Madhu> +1
18:00:53 <rovarga> let's keep it short, though
18:01:09 <edwarnicke> If folks would like, I am willing to pull together a 'what is happening in MD-SAL readout' (target time slice: 5 minutes)
18:01:18 <cdub> is it crazy to use md-sal session on tue as starting point?
18:01:25 <rovarga> #info: when filing bugs for what you are working on, please also set a deadline (when you expect to have results)
18:01:29 <lenrow> +1 existing meeting
18:01:32 <Madhu> #info Devin Avery will be running the weekly status calls
18:01:59 <lenrow> non-majority call management leads to good balance
18:01:59 <GiovanniMeo> cdub +1 to use MDSAL call on TUE
18:02:03 <alagalah> yeah lets keep it simple
18:02:04 <edwarnicke> cdub: I had hoped the mdsal meeting would turn out to be a lot like what devinavery describes... so color me preliminarily supportive (meaning I've not thought it all the way through, but it sounds good :) )
18:02:16 <cdub> i don't think we need 2 md-sal meetings per week
18:02:23 <phrobb> #endmeeting