20:12:31 <colindixon> #startmeeting better host tracker interns
20:12:31 <odl_meetbot> Meeting started Tue Jul  1 20:12:31 2014 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
20:12:31 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:12:31 <odl_meetbot> The meeting name has been set to 'better_host_tracker_interns'
20:14:47 <evanz> djx: good question
20:15:32 <djx> I don't know if the InstanceIdentifier is that one
20:15:42 <djx> on line 48
20:19:31 <evanz> let me see if I understand this
20:20:16 <evanz> InstanceIdentifier does what?
20:20:32 <evanz> builds up the type for AddressCapableNodeConnector?
20:20:41 <djx> yup
20:20:55 <djx> It's what I think..
20:22:11 <evanz> and then tells the databroker to listen to changes
20:22:25 <djx> yup
20:22:37 <evanz> can I run this somehow?
20:22:43 <djx> I didn't try it
20:22:56 <djx> But I think it's runnable
20:24:40 <colindixon> sorry, give me two secs
20:38:52 <evanz> djx: gonna try to import into eclipse
20:39:18 <evanz> I thought we were gonna move the model into opendaylight/betterhosttracker/model
20:40:04 <djx> Oh I didn't remember that
20:40:33 <djx> that's not a big deal for the moment but I can change that after this meeting
20:40:46 <evanz> ok
20:42:00 <evanz> I think we just wanted a subdir of opendaylight, since we're not really part of md-sal
20:42:08 <evanz> colindixon can correct me if I'm wrong
20:42:51 <djx> there's a northbound/hosttracker inside the controller
20:55:31 <djx> evanz does it work?
20:56:33 <evanz> I was able to import now I have betterhosttracker-impl project
20:56:51 <evanz> complaining about the pom though
20:56:55 <evanz> maybe I should import fresh
20:59:48 <djx> I never get errors from poms on netbean, only when trying to compile
21:00:02 <evanz> imported it by itself
21:00:07 <evanz> no problems
21:00:28 <evanz> maybe we should try writing a unit test or something
21:04:58 <djx> that's a good idea
21:05:07 <djx> colindixon, where are you?
21:07:28 <colindixon> sorry
21:07:31 <colindixon> back
21:07:35 <colindixon> wound up having to take a phone call
21:07:41 <djx> oh ok
21:07:51 <djx> no problem
21:08:36 <colindixon> so, do you still have time? or should we punt ’til tomorrow?
21:08:44 <djx> I've ime
21:08:55 <djx> it's earlier :-)
21:09:01 <evanz> ya no problems here
21:09:28 <colindixon> lol
21:09:30 <colindixon> ok
21:09:49 <colindixon> #topic status update
21:09:56 <colindixon> so, I’m going to look at the github now
21:09:59 <evanz> #info some impl is up on the github
21:10:06 <djx> ok
21:10:17 <evanz> #link https://github.com/nilok/betterhosttracker/tree/master/opendaylight/md-sal/betterhosttracker/plugin/src/main/java/org/opendaylight/controller/betterhosttracker/plugin/internal
21:11:07 <colindixon> cool
21:11:23 <colindixon> this looks good
21:11:31 <evanz> djx had a question
21:11:36 <djx> colindixon line 40
21:11:39 <evanz> line 40
21:11:51 <evanz> of Impl
21:11:55 <colindixon> ok
21:12:02 <colindixon> looking at it right now
21:12:21 <evanz> and there was the question of the directory structure, right now things are still in odl/md-sal
21:12:30 <colindixon> so, I think we really want to listen for AddressCapabaleNodeConnectors
21:13:02 <djx> colindixon I think that's what is done right now on registerAsDataChangeListener method
21:13:38 <colindixon> ok
21:14:43 <colindixon> then you should get back AddressCapableNodeConnectors, which you can check for with instanceof
21:15:24 <colindixon> the data objects you get
21:15:34 <colindixon> should be AddressCapableNodeConnectors
21:15:55 <colindixon> although, frustratingly, we’re going to need to see if the l2switch address tracker is implemented yet
21:16:17 <djx> colindixon the key of the giving map?
21:16:24 <djx> on the onDataChanged method?
21:16:25 <colindixon> which is not
21:16:38 <colindixon> the map Map<InstanceIdentifier<?>, DataObject>
21:16:47 <djx> but like evanz said, we can create a unit test, no?
21:17:04 <colindixon> yeah
21:17:09 <colindixon> you could create a unit test
21:17:21 <colindixon> although you’d need to figure out what you expect to come back
21:17:28 <djx> right
21:18:07 <colindixon> which in and of itself is painful
21:18:56 <djx> But I don't understand one thing what are the values from the  Map<InstanceIdentifier<?>, DataObject> ?
21:19:29 <colindixon> so, InstanceIdentifier<?> is actually going to be a path
21:20:02 <colindixon> let me see if I can get an example
21:21:11 <colindixon> https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin::End_to_End_Inventory
21:21:34 <colindixon> so, the instance identifier is going to be something like “opendaylight-inventory:nodes/node/openflow:1”
21:21:48 <colindixon> except it’s going to keep going
21:22:18 <djx> right, the keep going until reaches AddressCapabaleNodeConnectors right?
21:22:39 <colindixon> yes
21:22:44 <colindixon> so that’s what you’re going to get back
21:22:47 <colindixon> a path
21:22:51 <colindixon> and then the DataObject
21:23:00 <djx> right, what is that DataObject?
21:23:01 <colindixon> AddressCapabaleNodeConnector
21:23:09 <colindixon> it should be that
21:23:09 <djx> really?
21:23:19 <colindixon> yes
21:23:43 <colindixon> that should be it
21:23:55 <djx> why a Map?
21:24:04 <colindixon> because there could be multiple changes
21:24:13 <colindixon> well, two reasons:
21:24:13 <djx> ah
21:24:24 <colindixon> first, you need a list because there could be multiple changes
21:24:24 <djx> because java doesn't support tuples
21:24:37 <colindixon> but that isn’t a map
21:24:48 <colindixon> you need map because you need both the path and the data
21:25:10 <colindixon> because the AddressCapabaleNodeConnector doesn’t actually tell you what Node it’s attached to
21:25:16 <colindixon> you need to infer that from the path
21:25:21 <colindixon> I think
21:25:22 <djx> right
21:25:45 <djx> what do I with that?
21:26:06 <djx> what can I do with that*
21:31:25 <colindixon> ok
21:31:38 <colindixon> so, with that, you should be able to extract addresses
21:34:36 <colindixon> AddressCapableNodeConnector extends AddressNodeConnector which has a method getAddresses() which returns a List of Addresses
21:34:54 <colindixon> Addresses have methods for getIp(), getMac(), etc.
21:35:29 <colindixon> #info the DataObject that comes back from the data changed notification should be an AddressCapableNodeConnector
21:35:32 <djx> Yes I'm seeing that
21:35:37 <colindixon> #info AddressCapableNodeConnector extends AddressNodeConnector which has a method getAddresses() which returns a List of Addresses
21:35:42 <colindixon> #info Addresses have methods for getIp(), getMac(), etc.
21:36:01 <colindixon> so, that’s how you get addresses from the data changed notification
21:36:08 <djx> ok this should be straightforward
21:36:17 <colindixon> and you could even subscribe for Addresses directly I tihnk
21:36:27 <djx> what do you mean?
21:37:03 <colindixon> instead of this: InstanceIdentifier<AddressCapableNodeConnector> addrCapableNodeConnectors = //
21:37:04 <colindixon> InstanceIdentifier.builder(Nodes.class) //
21:37:05 <colindixon> .child(Node.class).child(NodeConnector.class) //
21:37:05 <colindixon> .augmentation(AddressCapableNodeConnector.class).build();
21:37:33 <colindixon> InstanceIdentifier<AddressCapableNodeConnector> addrCapableNodeConnectors = //
21:37:34 <colindixon> InstanceIdentifier.builder(Nodes.class) //
21:37:35 <colindixon> .child(Node.class).child(NodeConnector.class) //
21:37:35 <colindixon> .augmentation(AddressCapableNodeConnector.class).child(Addresses).build();
21:37:37 <colindixon> I think
21:37:44 <colindixon> or something like it
21:37:57 <djx> on the registerAsDataChangeListener method?
21:38:05 <colindixon> yeah
21:38:20 <djx> why?
21:39:15 <colindixon> given that you don’t actually care about the AddressCapableNodeConnector and only actually care about the Addresses, that seem easier
21:39:34 <colindixon> but both work
21:39:48 <colindixon> it’s whatever’s easy
21:39:49 <djx> So hosttracker will be listening for address changes instead of node connector changes?
21:39:55 <colindixon> yeah
21:40:12 <colindixon> because you really only care if there are new Addresses under the node connector, right?
21:40:33 <djx> yeah but I care the node connector itself, no?
21:40:42 <colindixon> sure, but you get that from the path
21:40:46 <colindixon> in the instanceidentifier
21:40:58 <djx> right I was think that
21:41:13 <evanz> I imagine you care more about the nodeconnector because if it goes down
21:41:17 <evanz> everything behind it is gone
21:41:21 <evanz> or something like that
21:42:09 <evanz> not for the observations
21:42:10 <djx> should that be our problem?
21:42:26 <djx> I mean, we have the last time we saw an address on that port
21:43:57 <colindixon> well, lets get it to work just ingesting things for now
21:44:17 <colindixon> we can deal with what to do when/if a port goes down next
21:44:40 <colindixon> so, you may be able fake the data you need by making RESTCONF POST queries
21:44:42 <djx> okay
21:44:42 <colindixon> that’s the other thing
21:44:51 <colindixon> how to create Addresses so you can test stuff
21:44:57 <colindixon> given that the address tracker doesn’t exist
21:45:08 <colindixon> evanz: do you know anything about the status of the address tracker?
21:45:09 <djx> evanz, can you deal with the tests and that?
21:45:26 <colindixon> does this at least make sense now?
21:45:38 <djx> for me yes, I'm much clear now
21:45:41 <colindixon> ok
21:45:41 <colindixon> good
21:45:42 <evanz> colindixon djx: sure
21:45:48 <evanz> yes things are clearer now
21:45:49 <colindixon> sorry I was awol :p
21:46:05 <evanz> before I had no idea about dataservice and InstanceIdentifier
21:46:24 <evanz> colindixon: I just pulled latest from l2switch repo and no at impl yet
21:46:27 <evanz> as far as I can tell
21:46:57 <colindixon> #action djx to work on setting things up to get the data changed notifications and pull out the the Addresses (or AddressCapableNodeConnector) and path to to generate an observation of a NodeConnector, IP and MAC
21:47:18 <colindixon> #action evanz to work on how to write test cases, either by faking the data with RESTCONF or just writing good unit tests
21:47:29 <colindixon> evanz: yeah
21:47:34 <colindixon> that’s what I saw
21:47:45 <colindixon> I’ll send an e-mail and ask
21:48:01 <djx> colindixon that observations will be saved on a Map<NodeConnector, X>?
21:48:15 <djx> If yes, what will be X, our yang model of host?
21:49:07 <colindixon> well, really the information should be List<X>
21:49:13 <colindixon> where X is our model of a host right
21:49:20 <djx> ah okay
21:49:21 <colindixon> since it should also have a nodeconnector in it?
21:49:26 <colindixon> or actually a list of nodeconnectors
21:49:37 <djx> yes I think the yang have that
21:50:24 <colindixon> #info internally, we should track a list of our modeled hosts
21:50:39 <colindixon> #info and eventually publish them into the data store
21:50:42 <colindixon> ok
21:50:49 <djx> #action djx will change the path of yang model previously created
21:51:14 <colindixon> ok
21:51:17 <colindixon> that sounds good
21:51:26 <colindixon> so, if you guys are happy with what you know now
21:51:30 <colindixon> I’m happy to let you guys go
21:51:37 <djx> one more thing
21:51:45 <colindixon> sure
21:51:48 <djx> evanz and I were talking
21:51:51 <colindixon> djx: what do you mean by “change the path”
21:51:56 <djx> yes, that
21:52:06 <djx> the path of the project
21:52:11 <djx> of the yang model
21:52:12 <colindixon> ah
21:52:13 <colindixon> ok
21:52:17 <evanz> colindixon we mentioned opendaylight/betterhosttracker/model
21:52:24 <colindixon> that sounds good to me
21:52:24 <evanz> and opendaylight/betterhosttracker/implementation
21:52:27 <evanz> if I remember correctly
21:52:32 <evanz> instead of using odl/md-sal
21:52:37 <colindixon> yeah
21:52:43 <djx> ok, sounds great
21:52:43 <colindixon> I was just thinking we’d mirror what l2 switch was doing
21:52:46 <colindixon> ok
21:52:49 <colindixon> ttyl
21:52:54 <colindixon> thanks for staying
21:52:57 <colindixon> #endmeeting