16:01:34 <colindixon> #startmeeting MD-SAL interest call
16:01:34 <odl_meetbot> Meeting started Tue Mar 24 16:01:34 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:01:34 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:34 <odl_meetbot> The meeting name has been set to 'md_sal_interest_call'
16:01:39 <colindixon> #topic agenda bashing
16:01:45 <alagalah> :)
16:01:45 <tbachman> alagalah: the TWS
16:01:47 <tbachman> sorry
16:01:50 <tbachman> the MD-SAL meetign
16:01:52 <tbachman> meeting
16:02:11 <colindixon> huh
16:02:14 <tbachman> devinavery: we may have to do this again
16:02:16 <colindixon> *sigh*
16:02:20 <colindixon> that’s new
16:02:22 <tbachman> yeah
16:02:26 <tbachman> I’ve seen this before
16:02:32 <tbachman> I’ve made it “work” by entering the host key
16:02:34 <tbachman> not sure why
16:02:41 <tbachman> but we have the other problem
16:03:01 <tbachman> magic
16:03:03 <tbachman> it works
16:03:11 <tbachman> and then dies
16:03:12 <tbachman> lol
16:03:13 <alagalah> bzzzt
16:03:18 <alagalah> Want to use my personal room ?
16:03:22 <tbachman> the audio came on at least
16:03:25 <alagalah> colindixon: Want my personal room ?
16:03:32 <tbachman> devinavery: ^^^
16:03:33 <colindixon> it’s working now
16:04:10 <alagalah> yay
16:04:19 <colindixon> #info the webex didn’t have working audio, but now it seems to be back up and working correctly
16:04:58 <colindixon> #link https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Agenda the agenda in its usual place
16:05:27 <alagalah> phrobb: colindixon Also suspect when the host leaves the meeting without ending it..
16:05:30 <alagalah> ding ding ding
16:05:31 <alagalah> :)
16:05:37 <colindixon> alagalah: yeah
16:05:44 <alagalah> phrobb: <---- what he said :)
16:05:53 <odl_meetbot> devinavery: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:05:58 <tbachman> yeah
16:06:01 <tbachman> colindixon did
16:06:15 <alagalah> Can someone mute kk.pradeeban ?
16:06:26 <alagalah> phrobb: ???
16:06:32 <colindixon> #info first-up is is Andrew McLachlan on the MD-SAL message bus
16:07:40 <colindixon> #Info second-up is looking at Anton’s work on yangtools performance and address normalization in the MD-SAL to avoid bugs
16:07:44 <phrobb> hey alagalah not me, I'm not host :-)… Devin got it
16:07:53 <colindixon> #topic MD-SAL message bus
16:08:16 <phrobb> Are we recording?.. did we want to?
16:08:25 <colindixon> phrobb: yes
16:08:30 <alagalah> devinavery: recorde ?
16:08:31 <tbachman> devinavery: ^^^
16:08:57 <colindixon> #action Andrew and Tony to post slides after the call
16:09:15 <colindixon> #info (recording started just at the beginning of the presentation)
16:09:21 <alagalah> colindixon:  WOW, talk about a top-of-mind topic for me
16:10:38 <colindixon> #info the key idea here is to provide publish/subscribe interfaces from ODL
16:13:47 <colindixon> #info current appraoch focuses on event sources and user agents (e.g., XMPP, 0MQ, etc.)
16:14:56 <colindixon> #info core functions are: (i) an event source manager, (ii) an event source topology/inventory, (iii) topic creation/subscription API (basically filtering)
16:15:20 <colindixon> why isn’t this notifications (which we have) and filters (which people have been desperately asking for forever)?
16:16:45 <colindixon> #info colindixon asks why isn’t this notifications (which we have) and filters (which people have been desperately asking for forever)?
16:19:07 <colindixon> #info rovarga_ responds by saying that this is different because notifications are within the controller itself, and this is really about transporting events though the controller without modifying them
16:20:42 <rovarga_> #info this is the classing node-centric/network-centric conflict
16:21:28 <rovarga_> #info it is essentially the same thing, but MD-SAL APIs are node-centric (e.g. single node, the controller itself), whereas this plugs 'the same thing' at the network layer
16:21:31 <colindixon> rovarga_: it seems like the right thing to do is to provide very good tools around pub/sub of the notifations we already have
16:21:46 <colindixon> rovarga_: rather than create something new
16:22:41 <rovarga_> colindixon: well, you can do things two ways: assemble a lot of simple things in new ways, or provide a few complex things and use them in specialized ways
16:22:49 <rovarga_> colindixon: this is the former approach
16:22:50 <alagalah> colindixon: rovarga_ Would this be a new project or part of the MD-SAL capabiities ?
16:23:10 <colindixon> colindixon: this looks, feels and smells like the latter approach to me
16:23:26 <colindixon> which is creating a new abstraction that is form-fitted to a specific application
16:23:28 <rovarga_> alagalah: architecturally and design-wise, this is an application on top of MD-SAL
16:23:30 <colindixon> rather than using one that we have
16:24:04 <alagalah> colindixon: rovarga_ Ok... could we get Events on things OTHER than network elements? Selfishly, if we create an event due to a policy conflict, could we leverage this ?
16:24:05 <colindixon> rovarga_ and alagalah: is it expected to be a core part of the MD-SAL in the long run, that is are lots of people going to rely on it
16:24:21 <colindixon> alagalah: exactly!
16:26:53 <rovarga_> colindixon: think of it as a microservice
16:27:03 <rovarga_> colindixon: it is strictly not part of MD-SAL, but it is widely useful
16:27:41 <colindixon> rovarga_: I guess that’s my point, there’s a lot of value in having *one* way to do notifications/events
16:28:37 <colindixon> #info anton, andrew and rovarga_ discuss how you may or may not need to normalize models and events to make it easy to use
16:28:54 <rovarga_> colindixon: but that would mean that we *must* use something, which is model specific (the concept of a NE from network-topology model) into generic infrastructure
16:29:52 <colindixon> I mean, we’re a controller, the whole point is to normalize things into a sane development and managment evironment
16:30:50 <colindixon> the goal should be to provide some, small set of abstractions that apps can use to interact with the controller
16:31:21 <alagalah> rovarga_: Event management/notification is functionality I HAVE to build for Li... I'd like it to work with whatever functionality is available from the controller.
16:31:21 <colindixon> focing people to think about events vs. notifications and local vs. remote and device vs. controller seems like it runs very, very counter to that
16:33:12 <alagalah> rovarga_: I take it you are familiar with what is being presented, so before I ask my question on webex, is anyone going to talk about events being escalated/de-escalated based on change of state?
16:34:08 <colindixon> alagalah: I’d like to see a really simple widget get created which takes a data change listener and produces notifications whenever the data change fires
16:34:13 <colindixon> it’s not hard to build
16:35:35 <rovarga_> alagalah: not sure what you mean
16:37:09 <alagalah> rovarga_: "node5 went away" (event) ... when node 5 comes back "node5 is back" (one event/notification/"thing") .. . we can escalate these events based on other things going on, time etc... but not logging (ie separate notifications for each thing).
16:37:18 <colindixon> #info tonly goes thorugh the event diagram
16:40:26 <rovarga_> alagalah: well ... given the network-topology model, those events can we done via datachange notifications... I am not sure how we can provide a generic 'escalation' chain, but I can see how an app could plug into it
16:40:52 <alagalah> rovarga_: Thanks... I'll listen for now, will have more questions later
16:42:40 <colindixon> #info as far as I can tell, the key idea is two fold: (1) provide a way to push subscription to events/notifications outside the controller to devices and (2) a way to transport them outside the controller to various other “user-agents”, e.g., AQMP, 0MQ, etc.
16:50:34 <alagalah> rovarga_: Mate, I have a questions
16:50:36 <alagalah> question
16:51:10 <alagalah> rovarga_: But have to run to another meeting at 10am and don't want to interrupt, but perhaps I am missing what you are doing but tying this to topology seems like a bad idea
16:52:18 <rovarga_> alagalah: fair, I will need to go offline in 8 minutes
16:52:51 <alagalah> rovarga_: Apologies all...
16:53:05 <alagalah> rovarga_: This is very very important, as you can tell by the passion :)
16:54:27 <colindixon> #info there is a long debate about how different this is from the notifications we have already in YANG
16:54:43 <alagalah> rovarga_: FWIW, my background is SP, so understand the desire etc... but have some opinions on what I think is right for an SDN event/notification model
16:54:44 <colindixon> #info rovarga_ is strongly of the opinion that they are *very* different
16:54:59 <alagalah> I must run... I'll look for email
16:55:12 <colindixon> #info colindixon (and it seems a few others) seem less convinced that’s the case
16:55:39 <tbachman> TWS?
16:55:43 <alagalah> Yeah
16:55:44 <alagalah> TWS
16:55:56 <alagalah> But that's still with Andrew on leave
16:56:00 <alagalah> 10am Pac Mondays
16:56:07 <alagalah> Laters all
17:37:55 <devinavery> #endmeeting