15:00:28 <regXboi> #startmeeting neutron_northbound
15:00:28 <odl_meetbot> Meeting started Fri Jul 17 15:00:28 2015 UTC.  The chair is regXboi. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:00:28 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:28 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
15:00:40 <regXboi> #topic agenda bashing and roll call
15:00:54 <regXboi> #info folks, please #info in if you are here
15:00:57 <regXboi> #info regXboi
15:01:22 <regXboi> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings#Agenda_for_Next_Meeting_.287.2F17.29 agenda in its usual place
15:01:40 <regXboi> #info please take a look at the agenda and suggest topics to be added
15:04:04 <regXboi> #info regXboi takes the general silence on now agenda items for no new issues
15:04:19 <flaviof> #info flaviof
15:04:30 <regXboi> #info that gives us quorum
15:04:42 <yamahata> #info yamahata
15:04:47 <regXboi> flaviof: you saved me from making this an info only meeting :)
15:05:10 <regXboi> #topic action items from last meeting
15:05:46 <regXboi> #info the first item is for folks to +1 cards on the trello board
15:06:08 <regXboi> #link https://trello.com/b/LhIIQ8Z0/odl-neutronnorthbound NN trello board
15:06:12 <regXboi> #chair flaviof
15:06:12 <odl_meetbot> Current chairs: flaviof regXboi
15:07:31 <regXboi> #info I don't see many +1s on topics - if folks aren't interested in committing time, then Be will be a real thin release...
15:07:54 <regXboi> #action everybody to +1 trello cards for Be items they are willing to work on
15:08:09 <flaviof> regXboi: maybe a agenda add: look at test results from #link http://logs.openstack.org/34/202834/2/check/gate-tempest-dsvm-networking-odl/0fd5781/ openstack ci
15:08:10 <regXboi> #info if you need access to the trello board, PM regXboi with your email address and he'll add you
15:08:26 <regXboi> flaviof: we'll cover it under the "open mike"
15:08:33 <flaviof> ack!
15:08:40 <yamahata> How can I +1?
15:09:02 <regXboi> yamahata: if you are a member of the trello board, select a card and add a comment with your +1
15:09:26 <yamahata> regXboi: got it. thanks.
15:09:39 <regXboi> #info item 2 - everybody to think about whether they want to volunteer to be a contact
15:09:51 <regXboi> #info in Be, we are going to need a testing contact and a documentation contact
15:10:00 <regXboi> #info regXboi looking for volunteers
15:10:10 <regXboi> #action everybody to think about whether they want to volunteer to be a contact
15:10:20 <regXboi> #info we'll set this in stone next week
15:10:39 <regXboi> #info item 3 - PTL selection
15:11:06 <regXboi> flaviof: I spoke to edwarnicke about this before he went on vacation and he doesn't want it
15:11:17 <regXboi> flaviof: are you interested, or should I do it again for Be?
15:11:24 <flaviof> regXboi: I echo his response.
15:11:33 <flaviof> :)
15:11:39 <regXboi> ok, I'm willing so, that can be settled
15:11:48 <regXboi> #agreed regXboi to be PTL for Be
15:12:05 <flaviof> regXboi: thanks!
15:12:10 <regXboi> #info fourth item: regXboi to consult with GBP folks about bug 3968.
15:12:28 <regXboi> #info regXboi wasn't able to hook up with alagalah this week, so this is still on my plate for next week
15:12:37 <regXboi> #action regXboi to consult with GBP folks about bug 3968 and why they are calling isXXX() methods directly
15:12:54 <regXboi> #info fifth item: well - that was done, or we wouldn't be having this meeting :)
15:12:58 <regXboi> but..
15:13:07 <regXboi> #action regXboi to update meeting minutes/agenda for next week
15:13:11 <regXboi> (so I don't forget)
15:13:20 <regXboi> #topic Planning for Berrylium
15:13:37 <raveek> Are we talking about changes needed in NN for supporting l2 gateway
15:13:52 <regXboi> raveek: welcome
15:14:10 <regXboi> raveek: if you look at the trello board, there is a card for l2gw
15:14:11 <raveek> Sorry I am new to this
15:14:24 <yamahata> I'm also interested in l2gw
15:14:27 <raveek> is there a audio for this meeting
15:14:29 <regXboi> if you are willing to contribute time in Be, please comment on the card with a +1
15:14:40 <regXboi> raveek: no, this is an IRC only meeting - no audio
15:14:43 <raveek> ok I will do that
15:15:07 <regXboi> raveek: if you don't have access to the trello board, PM me with your email address and I will add you when we are done
15:15:20 <raveek> We have defined REST API and related YANG and were made the code changes
15:15:41 <raveek> Ok I will that
15:15:41 <regXboi> raveek: the YANG model is likely going to be usable, the REST API, not so much
15:15:53 <regXboi> NN does not use RESTCONF
15:16:13 <raveek> ok
15:16:43 <flaviof> regXboi: ... ever?
15:16:47 <regXboi> flaviof: ever
15:17:11 <regXboi> supporting RESTCONF means breaking compatibility of networking-odl driver when we rev yang
15:17:19 <regXboi> that's too expensive
15:17:27 <regXboi> mestery: want to chime in?
15:17:48 <mestery> regXboi: What's the tl;dr for me to chime in on?
15:17:50 <yamahata> l2gw has its own driver interface. not ML2 mechanism driver
15:17:51 <flaviof> regXboi: ack. so how/what the yang models are shown?
15:18:03 <yamahata> we need write odl driver for l2gw in openstack neutron
15:18:06 <mestery> #info mestery
15:18:12 <regXboi> mestery: restconf support between NN and networking-odl
15:18:19 * mestery shudders
15:18:28 <mestery> That again? What's the benefit there?
15:18:32 <mestery> regXboi: Please help me understand.
15:18:59 <regXboi> mestery: there are folks that want to add support for networking-l2gw in Be
15:19:08 <regXboi> and have written a yang model and restconf API
15:19:17 <regXboi> and I'm saying the yang model is useful, but the restconf API isn't
15:20:03 <regXboi> yamahata: yes - the l2gw "driver" will need to be part of the networking-odl repository and pass the JSON down to ODL
15:20:04 <raveek> maruti from our team is wokring on neutron l2gateway service plugin and a plugin driver to to talk to NN
15:20:22 <mestery> regXboi: ++
15:20:30 <regXboi> raveek: the key is to keep the driver transparent
15:20:57 <regXboi> i.e. pass the json as it would be passed to the reference implementation or as it exists in the neutron DB
15:21:07 <regXboi> that's the Tao of NN
15:21:23 <flaviof> raveek: so the 'plugin driver' you mention is past of ml2 netwrking-odl?
15:21:29 <raveek> that's correct.
15:21:43 <flaviof> s/past/part
15:21:47 <flaviof> cool
15:21:52 <regXboi> flaviof, mestery: I expect you'll want to work with raveek on getting that upstreamed on the OS side
15:21:56 <regXboi> (OS = openstack)
15:22:02 <mestery> regXboi: ++
15:22:07 <flaviof> regXboi: ++
15:22:08 <raveek> plugin driver is separate or it could be part of networking-odl
15:22:40 <raveek> at present we plan to write a thin l2-gw plug-in driver
15:22:47 <regXboi> BTW, I want to finalize what we are doing in Be next meeting
15:22:49 <regXboi> so...
15:23:00 <mestery> raveek: I'd put it in networking-odl
15:23:04 <mestery> I don't see the reason to have a separate place for it
15:23:07 <regXboi> #action NN to finalize Be feature set at 7/24 meeting
15:23:11 <regXboi> mestery: ++
15:23:11 <mestery> The L3, LBaaS, and FWaaS plugins are there too
15:23:20 <raveek> Ok that can be done
15:23:49 <regXboi> ok - can we move on - we've got a few more items to cover
15:23:51 <raveek> We wanted to take you guys by-in before adding anything to networking-odl
15:24:17 <raveek> ok - I will send details on what we have done so far to DEL list
15:24:18 <regXboi> raveek: thanks :)
15:24:20 <raveek> thanks
15:24:33 <regXboi> and great discussion everybody :)
15:24:36 <regXboi> #topic bugs
15:24:37 <flaviof> raveek: ack. thanks. that is the best way, keep it under networking-odl
15:24:39 <raveek> I mean nn-dev list
15:24:49 <raveek> ok
15:24:51 <regXboi> #info I've noticed that we've got new ones coming in
15:24:54 <regXboi> #undo
15:24:54 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1ce0e90>
15:25:02 <regXboi> #info regXboi has noticed new ones are coming in
15:25:19 <regXboi> #info so we are going to need to bring them up during meetings going forward
15:25:31 <regXboi> #action regXboi to update Trello Board bug list
15:25:56 <regXboi> #info please take a look and if you are willing to address them, sign up for cards on the Trello Board
15:26:16 <regXboi> that's all I had for this week on this, but more are going to be coming
15:26:28 <regXboi> #topic Should we deprecate GET methods from the NB modules?
15:27:04 <regXboi> so, in revisiting what we do, the NN model currently supports collection and element GETs, *with* filtering, just like Neutron does
15:27:15 <regXboi> and I'm wondering, what's the use case for needing these?
15:27:22 <regXboi> I honestly can't think of one
15:27:33 <flaviof> regXboi: phew, you mean GET filters
15:27:45 <regXboi> flaviof: I mean the GET requests completely
15:28:02 <regXboi> here's my thinking
15:28:18 <flaviof> regXboi: ack, so GET with specific uuids.
15:28:28 <regXboi> up to Li, we had ConcurrentHashMaps storing objects
15:28:41 <regXboi> and the only way to check those maps was via the Northbound GETs
15:28:48 <regXboi> both collection and element
15:29:04 <regXboi> in Li, we started adding the MD-SAL models, but still have the CHMs
15:29:20 <regXboi> so we still could justify supporting the GET
15:29:28 <regXboi> in Be, we will be removing the CHMs
15:29:33 <flaviof> CHMs ?
15:29:38 <regXboi> ConcurrentHashMaps
15:29:41 <flaviof> ack
15:30:10 <regXboi> so in Be, both the I*Aware and MD-SAL interfaces will be based on data stored in the MD-SAL
15:30:23 <regXboi> at that point, I don't need the NN GETs to verify the data is there
15:30:39 <regXboi> so, my thought is to mark the GET interfaces as deprecated in Be and remove them in B
15:30:43 <flaviof> regXboi: fyi, filter in mdsal is a upcoming 'feature': #link https://lists.opendaylight.org/pipermail/ovsdb-dev/2015-July/001655.html restconf/mdsal wildcard queries
15:31:08 <regXboi> flaviof: that's sort of my point
15:31:18 <regXboi> so... this is a proposal on the table for people to think about
15:31:27 <regXboi> we don't need (and I don't want) to decide on it today
15:31:51 <regXboi> #info regXboi presents his reasoning for deprecating all GET methods - please see the log for details
15:32:03 <flaviof> regXboi: so I re-iterate what you are proposing:
15:32:17 * regXboi listens
15:32:46 <flaviof> folks who nned get, can obtain it via mdsal restconf. O/S api never needs it, so it may be deleted?
15:33:15 <regXboi> flaviof: yes - because AFAIK, nobody is using NN get
15:33:28 <regXboi> flaviof: if somebody is *using* NN get, then its a different story
15:33:33 <flaviof> mestery: yamahata: correct me if I'm wrong, but I do see GETs while doing re-sync, so networking-odl knows not to replay the objects. Is that a potential issue?
15:34:06 <mestery> flaviof: The GET is to verify if the object exists in NN DB I believe
15:34:29 <regXboi> flaviof, mestery, yamahata: so *that* issue is what I'm calling (on the trello board) "Solve the 'start up problem'"
15:34:41 <regXboi> we need to solve that anyway
15:34:52 <mestery> regXboi: ++
15:35:09 <regXboi> but I will grant that until that is solved, GET can be deprecated, but not removed
15:35:21 <flaviof> regXboi: ack. ok; so yes, once we solve that, I think GET is a good candidate for code cleanup.
15:35:31 <regXboi> ok, we are in agreement
15:35:34 <regXboi> ok... next topic
15:35:45 <regXboi> #topic should we remove checks on incoming items
15:36:00 <regXboi> here's the back story
15:36:15 <regXboi> NN was originally written based on a set of assumptions
15:36:34 <regXboi> mainly that it was going to check the incoming objects using the same set of rules as Neutron
15:36:39 <regXboi> (i.e. trust but verify)
15:36:56 <regXboi> what I'm seeing now is that the rules neutron uses are changing and not being well documented
15:37:16 <regXboi> and I'm also seeing that the update objects we are getting are different
15:37:35 <flaviof> ack, example is delta vs whole object, right?
15:37:44 <regXboi> lastly, NN has code to replicate the dependent object changes in neutron
15:37:48 <regXboi> flaviof: yes
15:38:10 <regXboi> I'm now questioning the usefulness of all of those checks an dependent object changes
15:38:18 <regXboi> er s/an/and/
15:38:47 <regXboi> as I'm adding tests, I'm finding that those tests aren't always useful, or correct anymore
15:38:55 <flaviof> regXboi: yes, i think less is more. besides, the really 'important' checks can migrate into the yang model itself, so there is not need for redandancy of checks.
15:39:12 <regXboi> and I'm wondering if we should invoke the "transparent" mantra and pull them out of the java code
15:39:26 <regXboi> flaviof: that's sort of where I'm thinking
15:39:33 <flaviof> ack
15:39:48 <regXboi> again - this is just a proposal at this point - we don't need (and I don't want) to decide today
15:40:01 <regXboi> #info regXboi lays out his thinking on this item - see the log for details
15:40:18 <regXboi> ok... that brings us to the open mike
15:40:24 <flaviof> regXboi: all valid points. I agree with you on all of them (so far :))
15:40:26 <regXboi> #topic open mike
15:40:37 <regXboi> flaviof: you wanted to discuss test failures?
15:40:39 <flaviof> I got a couple...
15:41:01 <flaviof> 1) this is more networking-odl related, so I'm glad mestery and yamahata are here.
15:41:07 <regXboi> flaviof: the floor is yours
15:41:30 * mestery listens
15:41:40 * regXboi goes to get caffiene - back in 5
15:41:44 <flaviof> on that, I'd like to have stable/kilo branch created soon. I see changes like: #link https://review.openstack.org/#/c/202834/ filter
15:41:55 <flaviof> and I'm confused if these are for kilo or liberty.
15:42:16 <flaviof> big thanks to yamahata for keeping on top of these, btw!
15:42:36 <flaviof> 2) would like to engace folks on nn to look at the ci tests
15:42:41 <flaviof> engage
15:42:54 <flaviof> nn as on odl neutron northbound project
15:43:27 <mestery> flaviof: Let me create the stable/kilo branch of networking-odl for you today, I jsut need to know the commit sha I should base it on
15:43:33 <flaviof> example ci I'm referring to: #link  http://logs.openstack.org/34/202834/2/check/gate-tempest-dsvm-networking-odl/0fd5781/ gate-tempest-dsvm-networking-odl
15:44:10 <flaviof> mestery: ack. thanks. I think it can be tip of master actually, granted there is nothing specific to liberty checked in so far
15:44:21 <mestery> flaviof: Even easier, I'll do that and report back
15:44:33 <flaviof> mestery: TY!
15:46:25 <flaviof> 3) I'm doing a talk with Armando at ODL Summit. My wonder is if folks could benefit in a deeper dive into the NN project, if that is already pretty well understood and covering networking-odl is more interesting.
15:46:34 <regXboi> #link  http://logs.openstack.org/34/202834/2/check/gate-tempest-dsvm-networking-odl/0fd5781/ gate-tempest-dsvm-networking-odl
15:46:41 <regXboi> #undo
15:46:41 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x1cb9e50>
15:46:48 <regXboi> #topic open mike
15:46:57 <regXboi> #link  http://logs.openstack.org/34/202834/2/check/gate-tempest-dsvm-networking-odl/0fd5781/ gate-tempest-dsvm-networking-odl
15:47:07 * regXboi goes and looks at link
15:47:07 <flaviof> regXboi: thanks.
15:47:34 <regXboi> flaviof: do we have pointers to errors in here?
15:47:46 <flaviof> #link http://logs.openstack.org/34/202834/2/check/gate-tempest-dsvm-networking-odl/0fd5781/logs/testr_results.html.gz summary of tests ran in gate-tempest-dsvm-networking-odl example
15:48:57 <regXboi> flaviof: so I can see some obvious failure items
15:49:34 <flaviof> regXboi: cool, I tought so. I think that is the CI we always hoped to have in LF infra for ODL, but never managed to pull off.
15:49:43 <mestery> flaviof: Branch created, this review updates .gitreview: https://review.openstack.org/#/c/203103/
15:49:44 <regXboi> and I think the best thing to do is get bugs filed on them so that we can (a) create new IT cases and (b) fix
15:49:50 <mestery> Here's how to grab the branch: http://paste.openstack.org/show/384025/
15:49:56 <flaviof> regXboi: regarless, these tests are awesome and should drive the trello cards in NN.
15:49:57 <mestery> yamahata armax: ^^^^^ FYI
15:50:12 <regXboi> flaviof: we also need to drive bugzillas
15:50:12 <yamahata> regXboi: +1 for filing bugs
15:50:15 <regXboi> er bugzilla
15:50:26 <flaviof> regXboi: ++
15:50:30 <regXboi> so for example
15:50:44 <regXboi> test_create_port_with_no_securitygroups[id-4179dcb9-1382-4ced-84fe-1b91c54f5735,smoke]
15:50:53 <regXboi> I'd like a bug for that, with enough information to create a new IT tests
15:50:55 <regXboi> er test
15:51:03 <regXboi> and then we can patch and have the IT test to avoid regression
15:51:38 <regXboi> now something like test_create_port_in_allowed_allocation_pools[id-0435f278-40ae-48cb-a404-b8a087bc09b1,smoke] would be another bug, etc. etc. etc.
15:51:57 <regXboi> regXboi and armax have done that for items in the past
15:52:01 <flaviof> regXboi: ack! awesome. Just wanted to advertise that the tests exist, huge thanks to mestery; and also to yamahata who has been fixing lots of issues
15:52:20 <mestery> yes, thanks yamahata! And thanks to armax too!
15:52:21 <regXboi> yes, many thanks!
15:52:23 <mestery> And flaviof : )
15:52:34 <flaviof> :)
15:52:40 <regXboi> I've realized that I have one last item for the open mike
15:52:48 <flaviof> that leaves me to #3
15:52:49 <flaviof> yup
15:52:51 <regXboi> reving yang model :(
15:53:00 <regXboi> so flaviof - your #3 is first
15:53:04 <flaviof> thanks!
15:53:17 <flaviof> it is more of a question.
15:53:46 <flaviof> I think we could use regXboi at the summit big time, if we were to talk a bit on the NN project, as well as networking odl.
15:53:48 <regXboi> I won't be at the summit, so I would suggest sending email out to the mailing list and discuss and get feedback that way
15:54:04 <regXboi> flaviof: I should say I won't be at the summit *in person*
15:54:20 <flaviof> #link http://opendaylightsummit2015.sched.org/event/d1856d548f5f4caa2f0c284055ab8f3c?iframe=yes&w=&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no  talk on NN
15:54:25 <regXboi> if there is a NN meetup - we should insist on one of the Ipads
15:54:30 <regXboi> so that I can be there remotely :)
15:54:39 <flaviof> regXboi: ack. I will definitely cc you as we make progress on this.
15:55:06 <regXboi> flaviof: if I were giving the talk, I would go 50/50 on it
15:55:11 <regXboi> so cover both networking-ODL and NN
15:55:11 <flaviof> meaning cc ML.
15:55:18 <regXboi> flaviof: ack
15:55:20 <flaviof> yup!
15:55:33 <flaviof> thanks, I'm done.
15:55:38 <regXboi> flaviof: thanks!
15:55:52 <regXboi> folks - it is (unfortunately) time to rev the yang model
15:56:16 <regXboi> if you look at the open patch sequence there are about 11 WIP patches related to problems I've found in the yang model (so far)
15:56:30 <regXboi> and I suspect that as I pull out the CHMs, I'm going to find more :(
15:56:40 <regXboi> again CHMs = ConcurrentHashMaps :)
15:56:46 <flaviof> :)
15:56:47 <regXboi> so we *are* going to have to do this
15:56:58 <regXboi> and that means we *are* going to break dependent projects when we do it
15:57:20 <regXboi> I sent email out preparing this, but I expect that we are going to be beat up about it when we do it
15:57:55 <regXboi> anyway - there will be more email as we get closer -
15:58:10 <flaviof> regXboi: is there a way to 'know' what projects will be affected? Is this a good use of Colin's 'for-all' script?
15:58:10 <regXboi> and we *might* rev the artifact versions when we do this as well
15:58:30 <regXboi> flaviof: I've sent email to the projects that are registered in jenkins as dependencies
15:58:55 <regXboi> the key to check is if the java code imports from the generated classes
15:59:03 <flaviof> ack. I suspect ovsdb is 'okay' as it is only using i*ware api, right?
15:59:05 <regXboi> and short of grep -r, I'm not sure how to do it
15:59:20 <regXboi> yes, you are ok for now
15:59:21 <flaviof> rephrase: this does not affect I*ware users, right?
15:59:26 <flaviof> ack, thanks.
15:59:27 <regXboi> flaviof: nope
15:59:32 <regXboi> flaviof: BUT
15:59:48 <regXboi> notice the trello card about marking I*aware as deprecated in Be
15:59:54 <regXboi> that *will* go away in B
16:00:29 <regXboi> one of my projects in Be is to create the MD-SAL aware dummy provider
16:00:43 <regXboi> at which point I hope to have a set of code templates that you can leverage
16:01:12 <regXboi> ok - we are at the top of the hour - great discussion folks
16:01:17 <regXboi> is there anything else?
16:01:28 <regXboi> otherwise...
16:01:32 <regXboi> #topic cookies :)
16:01:49 * regXboi waits for last calls before ending meeting
16:02:03 <regXboi> #endmeeting