14:59:14 <regXboi> #startmeeting neutron_northbound
14:59:14 <odl_meetbot> Meeting started Fri Aug 28 14:59:14 2015 UTC.  The chair is regXboi. Information about MeetBot at http://ci.openstack.org/meetbot.html.
14:59:14 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:14 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
14:59:27 <regXboi> #topic agenda bash and roll call
14:59:29 <regXboi> #info regXboi
14:59:39 <regXboi> #info flaviof will not be here - he has a meeting conflict
15:00:39 <regXboi> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings agenda in its usual place
15:01:18 * regXboi hopes for a quorum
15:03:12 <yamahata> #info yamahata
15:05:01 <regXboi> edwarnicke: you joining us?
15:06:25 <regXboi> well... I *hope* edwarnicke will appear, but until then we are lacking a quorum, so this is will be info only
15:06:50 <regXboi> #info at this point, we are lacking a committer quorum so the meeting is info only until a quorum is achieved
15:06:57 <regXboi> #topic action items from last meeting
15:07:08 <regXboi> #info none (how the heck did *that* happen)
15:07:21 <regXboi> #topic beryllium
15:07:41 <regXboi> #info M2 deadline for us was yesterday - the project plan has been submitted
15:08:04 <regXboi> #link #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000323.html M2 Email
15:08:08 <regXboi> #undo
15:08:08 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x1c3e410>
15:08:12 <regXboi> #link https://lists.opendaylight.org/pipermail/neutron-dev/2015-August/000323.html M2 Email
15:08:36 <regXboi> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium_Release_Plan Be Release Plan
15:08:59 <regXboi> #info Bugs w/o patch sets
15:09:01 <regXboi> #undo
15:09:01 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1c3e210>
15:09:08 <regXboi> #topic bugs w/o patch sets
15:09:18 <regXboi> ##link https://bugs.opendaylight.org/show_bug.cgi?id=3990 bug 3990
15:09:42 <regXboi> is this still a problem?
15:10:00 <yamahata> No for me. I filed it as a record.
15:10:35 <yamahata> I mean it fails. but I think no one complains about it.
15:11:37 <regXboi> I've not seen this
15:11:57 <regXboi> nor (iirc) has the gate
15:13:44 <regXboi> so I'm not sure what's going on
15:14:14 <regXboi> #action edwarnicke, flaviof, regXboi to look at bug 3990
15:14:29 <regXboi> ##link https://bugs.opendaylight.org/show_bug.cgi?id=4026 bug 4026
15:14:35 <regXboi> #undo
15:14:35 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x1d33710>
15:14:41 <regXboi> #action edwarnicke, flaviof, regXboi to look at bug 3990
15:14:47 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=4026 bug 4026
15:15:38 <yamahata> I suppose 811dfecc6053f9d27cd2e94e305423a21965ed6c would fix it. But  I haven't confirmed it hoping flavio would.
15:15:59 <yamahata> I'll check it and comment on it.
15:16:29 <regXboi> so, this can be addressed in one of two ways (and I think both should be done)
15:16:42 <regXboi> (a) the N-ODL code should hand the *whole* object to us
15:16:54 <regXboi> (b) we should patch the object we get with the UUID if it doesn't have it
15:17:21 <regXboi> yamahata: thanks for checking and commenting
15:17:29 <regXboi> #action yamahata to check and comment on bug 4026
15:17:41 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=4027 bug 4027
15:18:53 <yamahata> I think 4027 is stale because concurrent hash map in router code was eliminated.
15:19:16 <regXboi> yamahata: that would be great if true, but I remain suspicious
15:19:33 <regXboi> this looks like another case of N-ODL not handing us the whole object
15:19:33 <yamahata> regXboi: yeah, at least it should be tested.
15:19:59 <regXboi> yeah, I can do that
15:20:10 <regXboi> #action regXboi to add IT test case for bug 4027
15:20:21 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=4043 bug 4043
15:21:58 <yamahata> I haven't looked at it yet. I try to look it.
15:22:00 <regXboi> somebody needs to bend an optic on that
15:22:04 <yamahata> Is it high priority?
15:22:42 <regXboi> it's major
15:22:51 <regXboi> there is only critical and blocker above that
15:22:58 <yamahata> Okay I'll take it. Probably next week.
15:23:35 <regXboi> #action yamahata to look at bug 4043
15:23:54 <regXboi> thanks, which leaves us with
15:23:55 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=4044 bug 4044
15:24:11 <regXboi> oh yeah, this one :)
15:24:19 <yamahata> :)
15:24:22 <regXboi> so this is not a bug on us, it is a bug on upsream
15:24:24 <yamahata> So how to fix it?
15:24:25 <regXboi> er upstream
15:24:39 <yamahata> confirt at ODL neutorn northbound? or convert at N-ODL driver?
15:25:03 <regXboi> IIRC we already have code in the transcriber to convert from 32 hex to IETF
15:25:11 <regXboi> all we need is the code to convert back
15:25:35 <regXboi> let me dbl chk that
15:25:43 <yamahata> So we'd like to convert ODL transcriber layer?
15:26:01 <wojdec> actually, are we sure that this isn't a bug in the specs?
15:26:03 <yamahata> I thought it would be easier at N-ODL. but it implies wire protocol change.
15:26:32 <yamahata> To be honest, I don't care whether it's a bug or not. I'll just address it.
15:26:33 <wojdec> in Ostack deployments I have running, binding_host id is basically the name of the node
15:26:45 <wojdec> not a uuid
15:26:58 <yamahata> Oh, I misunderstood it as other bug.
15:27:07 <yamahata> host_id is string. not uuid.
15:27:19 <yamahata> actually hostname usually
15:27:25 <regXboi> hold on
15:27:26 <wojdec> ah yes
15:27:30 <regXboi> maybe I'm confused :)
15:27:39 <regXboi> and maybe I've already patches this
15:27:40 <wojdec> so it should be string
15:27:49 <wojdec> not uuid
15:28:05 <wojdec> a change of the yang model then too
15:28:06 <yamahata> Yes, we fixed it by 14dc16c209ef4eaaae9a76f31519bb9872330a29
15:28:12 <yamahata> we can mark the bug resolved.
15:28:24 <regXboi> yamahata: that is what I remember
15:29:08 <regXboi> and so done
15:29:34 <regXboi> now ...
15:29:44 <regXboi> #topic Bugs w/Patch sets
15:29:54 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=3968 bug 3968
15:29:57 <wojdec> i actually commented on that in the original yang model commit… seems to have reverted to uuid and now back again, anyway
15:30:35 <regXboi> #link https://git.opendaylight.org/gerrit/#/c/23939/ patch set for bug 3968
15:31:49 <regXboi> so, I'm not a fan of this patch set (obviously)
15:32:27 <regXboi> and frankly, this only comes about if we aren't getting the full object from N-ODL
15:32:46 <regXboi> so I'd want it ultimately fixed there
15:33:37 <regXboi> but in the meantime, I think we have to ensure that all non basic things are defined and given default values (sigh)
15:34:21 <regXboi> so it needs code, just not the code that is in the patch set
15:34:56 <regXboi> I'm not going to hand out an action item on this one, I want to noodle some more
15:35:05 <regXboi> next
15:35:07 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=4157 bug 4157
15:35:15 <regXboi> and
15:35:16 <regXboi> #link https://git.opendaylight.org/gerrit/#/c/25500/ patch for bug 4157
15:35:38 <yamahata> Yeah, this bug
15:35:40 <regXboi> yamahata: *THIS* is the one I was thinking of above
15:36:00 <regXboi> and that patch set isn't the way to fix this
15:36:03 <yamahata> Anyway I'll take care of it.
15:36:14 <regXboi> we already have code to handle in toUuid() to patch one way
15:36:20 <regXboi> we just need to patch the other way
15:36:32 <yamahata> Okay.
15:36:38 <regXboi> #action yamahata to fix up https://git.opendaylight.org/gerrit/#/c/25500/
15:36:48 <regXboi> yamahata: thanks and I look forward to it
15:37:00 <regXboi> last in this set
15:37:01 <regXboi> #link https://bugs.opendaylight.org/show_bug.cgi?id=4188 bug 4188
15:37:02 <regXboi> and
15:37:08 <regXboi> #link https://git.opendaylight.org/gerrit/#/c/25997/ patch for bug 4188
15:37:36 <regXboi> yamahata: so how do you even *GET* this?
15:37:53 <yamahata> By running tempest.
15:38:04 <regXboi> in what type of setup?
15:38:16 <yamahata> sometimes the rest requests from N-ODL are reordered
15:38:22 <regXboi> um
15:38:36 <regXboi> I'm sorry but that MUST NOT happen
15:38:38 <yamahata> at rest request level, the creation of network and subnet is out-of-order
15:39:17 <regXboi> seriously, if N-ODL is reordering requests then that needs to stop
15:39:22 <yamahata> neutron is multi-threaded so it can happend even with single server
15:39:54 <regXboi> I don't care
15:39:57 <yamahata> with ha with neutron, re-order easily happen.
15:40:02 <regXboi> reordering rest requests is EVIL
15:40:27 <regXboi> especially when the requests contain pointers to each other
15:40:42 <regXboi> well I should say the later requests contain pointers to the earlier request
15:41:43 <yamahata> It may be evil, but it happens. It's distributed systems.
15:42:01 <yamahata> we have to accept reorder somehow.
15:42:43 <regXboi> well
15:43:52 <regXboi> you can't do what you've done in this patch
15:44:07 <regXboi> because you are changing the POJO to be different from what neutron tells us
15:44:11 <regXboi> and that's not acceptable
15:44:16 <wojdec> FWIW I think this is an ML2 driver issue as per: https://wiki.opendaylight.org/images/8/8d/Experiences_with_Neutron.pdf issue 6
15:44:26 <wojdec> (and 2 + 3)
15:45:03 <yamahata> agreed to not change pojo. okay.
15:45:15 <regXboi> so we may have to accept re-ordering, but we have to be smarter about it
15:45:27 <wojdec> a fix should address ML2 + NN
15:46:08 <regXboi> yamahata: I would take out the code where we update the subnet entry in the network on the incoming subnet
15:46:13 <regXboi> that *should* address the problem
15:46:24 <regXboi> now it means that you can't trust that field of the network object
15:46:32 <regXboi> but we say that in large letters and move on
15:47:43 <regXboi> and we should add various IT tests where things come in out of order to make sure we aren't tripping on anything else
15:48:19 <regXboi> #action regXboi to look at adding out of order IT tests to catch other issues like bug 4188
15:48:30 <regXboi> yamahata: that work?
15:48:42 <yamahata> regXboi: yeah, thanks.
15:48:56 <wojdec> this doesn't sound like a good idea
15:49:11 <regXboi> wojdec: which *this*?
15:50:10 <wojdec> the suggested fix… in essence, ports need subnets, subnets need networks
15:51:11 <wojdec> if we allow for a situation where users of the data, eg netvirt/whoever get a port, but can't create a valid config out of it (becuase of missing subnet or network), that will be pretty awful to the user;
15:51:32 <wojdec> the neutron DB in ostack will invariably show all objects being there
15:51:42 <wojdec> ODL don't throw any error
15:51:49 <regXboi> the other option is to enforce reordering at N-ODL
15:52:15 <regXboi> which is my preferred choice (by the way)
15:53:07 <yamahata> state syncing is planned at ML2 layer.
15:53:16 <yamahata> it would address it to some extent.
15:53:21 <wojdec> i would suggest an alternative: if NN gets a subnet/port/whatever, that is dependent on an object it realizes it doesn't have, it would be smart for it to ask neutron for it
15:53:32 <regXboi> u
15:53:33 <regXboi> er um
15:53:55 <regXboi> actually, that's not a pretty solution
15:54:18 <wojdec> then failing, is ok
15:54:30 <regXboi> unless you clarify what "ask neutron for it" means
15:54:38 <wojdec> ie if the object is not there, throw back the error up to ostack
15:54:52 <wojdec> for the bug at hand
15:55:04 <wojdec> network object isn' there
15:55:15 <wojdec> odl may ask ostack for the network
15:55:19 <regXboi> how
15:55:27 <regXboi> I'm being pedantic: how
15:55:29 <wojdec> using the neutron API
15:55:32 <regXboi> no
15:55:35 <regXboi> oh heck no
15:55:38 <wojdec> why?
15:55:52 <regXboi> you don't come from the back end and go around to the front end
15:56:07 <regXboi> that creates all sorts of headaches around authentication
15:56:22 <wojdec> yes, granted, authentication is a challenge
15:56:34 <regXboi> I'd much rather go about it this way
15:56:48 <regXboi> if we are going to look at some sort of sync state between N-ODL and NN
15:57:07 <regXboi> then N-ODL checks to see if the antecedent objects of anything have already been passed
15:57:21 <regXboi> and if not, they get inserted into the stream before the out of order object
15:57:37 <regXboi> which means that when the antecedent object later appears, it doesn't go down because it already has
15:58:14 <regXboi> a pretty blatant reorder hack
15:58:28 <regXboi> anyway... this needs more looking
15:58:54 <regXboi> #action everybody to think about how to deal with issues like https://bugs.opendaylight.org/show_bug.cgi?id=4188
15:59:21 <regXboi> we'll defer the rest of the agenda because we are nearing the top of the hour and I've got a couple of fires I have to go fight
15:59:36 <regXboi> #topic remaining agenda deferred
15:59:44 <regXboi> #endmeeting