15:01:55 #startmeeting neutron_northbound 15:01:55 Meeting started Wed May 11 15:01:55 2016 UTC. The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html. 15:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:55 The meeting name has been set to 'neutron_northbound' 15:02:02 #chair vthapar asomya 15:02:02 Current chairs: asomya vthapar yamahata 15:02:08 #topic agenda bashing and roll call 15:02:14 #info yamahata 15:02:27 today mike and odded won't attend due to the national holiday 15:02:41 #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings meeting adenda 15:02:58 is there any other topics today in addition? 15:04:56 seems nothing else. 15:05:10 #topic Announcements 15:05:47 networking-odl for mitaka has been released 15:05:56 and the stable/mitaka branch has been also cut 15:06:07 #link https://review.openstack.org/#/c/312331/ 15:06:07 Release networking-odl 2.0.0 (mitaka) release 15:06:42 launchpad/networking-odl allows blueprint 15:07:08 #link https://blueprints.launchpad.net/networking-odl blueprint 15:07:15 any other announcement? 15:07:46 yamahata: any submissions for ODL Summit from Neutron? 15:08:15 vthapar: Yes. I submit CFP on networking-odl integration 15:08:39 I'm reusing same topic... Maybe I have to find new topic, though. 15:08:44 cool 15:09:11 anything else? 15:09:39 #topic action items from last meeting 15:10:02 yamahata updated pypi ownership 15:10:15 patch/bug reviews were done 15:10:33 next topic is management related 15:10:42 #topic blueprint management 15:11:05 This week we don't have mike and oded. So we would like to continue discussion next week. 15:11:23 #action yamahata send summary mail for odl neutron mailing list 15:11:37 now we have launchpad blueprint available. 15:11:51 Do we want to use blueprint/spec process for networking-odl? 15:12:00 For now we have several blueprints registered. 15:12:10 #link https://blueprints.launchpad.net/networking-odl blueprints 15:12:35 For major feature i think it's a good idea 15:12:41 Given that the team size is small, we don't have to use heavy process like core neutron. 15:12:47 not for all features 15:13:12 asomya: +1 15:13:16 I think we should track/coordinate major features. 15:13:20 Okay. 15:13:41 Do we want to have spec? at least major feature. like sfc, qos support. 15:14:17 yamahata: From my experience in neutron, the spec review process doesn't seem to help much 15:14:18 IMHO, light spec will help. But full neutron spec would be too heavy, though. It would be case-by-case, though. 15:14:50 yamahata: +1 for light spec 15:15:04 yamahata: +1 15:15:35 we have consensus. anyway I'll sent a mail to get feedback. 15:15:50 Next week, let's decide it. 15:16:01 any other thoughts/comments? 15:17:21 okay move on 15:17:23 #topic patches/bugs 15:17:35 any patches/bugs that need attention? 15:17:50 * yamahata is a bit behind review. today will catch them up 15:18:02 https://review.openstack.org/#/c/305132/ is ready for merge i think 15:18:51 Cool. I'll check it to merge it 15:18:59 #action yamahata review/merge https://review.openstack.org/#/c/305132/ 15:19:55 how about https://review.openstack.org/#/c/307171/ ? 15:20:05 I'll review it today. 15:21:40 okay. any other bugs/patches? 15:22:49 seems nothing else. 15:22:59 #topic ML2 ODL driver rewrite 15:23:17 I suppose we can cover this topic as normal patch/bug session. 15:23:33 So I'm wondering dropping this from agenda. 15:24:09 #topic Boron planning 15:24:10 yamahata: +1, most of the bug discussions center around it anyways 15:24:22 #undo 15:24:22 Removing item from minutes: 15:25:01 oaky, next topic 15:25:04 #topic Boron planning 15:25:22 in M2, we had several dependency notification from ODL project 15:25:34 netvirt, GBP, vtn, vpnservice 15:25:59 I suppose there are more projects which haven't notify dependency officially 15:26:06 that's all this week 15:26:14 #topic open mike 15:26:22 any thing else to discuss? 15:26:46 yamahata: Bluejeans sessiion postponed to next week? 15:26:56 since mike and oded aren't available 15:27:01 asomya: yes as mike and oded are off today 15:27:42 anything else or the remaining time will be given back. 15:28:24 Neutron northbound bugs and patches? 15:28:35 Ah yes. 15:28:44 the yang model changes in NN 15:28:46 Right now I'm working on patches to update yang models. 15:29:14 I hit a bug of yangtools or mdsal. 15:29:33 So it would take a while to upload new patches. 15:29:50 similar to issue I mailed ovsdb-dev half an hour ago? 15:30:05 I haven't the mail yet. 15:30:14 https://git.opendaylight.org/gerrit/#/c/38664/ 15:30:21 The issue is that yang union under indentityref 15:30:58 okay, this one was about yang choice. 15:31:27 also wanted to close out decision on https://bugs.opendaylight.org/show_bug.cgi?id=5735 15:32:10 vthapar: yes. We have to decide how to fix it. 15:32:47 I was thinking more on lines of making ip-address field a list of ip-addresses and retaining subnet as they only key 15:32:51 #action yamahata look into https://bugs.opendaylight.org/show_bug.cgi?id=5735 15:33:47 I see. 15:34:51 On the other hand, in neutron the pair (subnetid, ip-address) is stored. 15:35:16 I'm wondering if we should follow openstack neutron way or do it in different way. 15:35:18 what about multiple IPs for given subnet? 15:35:30 when we get fixed IPs we get them as a list. 15:36:32 The primary key for the table is (network-id, subnet-id, ip-address) 15:36:50 neutron port has a relationship to it. 15:36:53 as list 15:37:22 I assumes the list of fixed ip addresses is short. 15:37:30 e.g. 3 or 4 at most. 15:37:53 So I suppose looping over the list won't be an issue. 15:38:06 vthapar: do you have any concern? 15:38:32 I also understand {} 15:38:37 oops 15:38:44 yamahata: I would prefer model that corresponds to what we get in JSON, if it is subnetId - Ip, am okay with that. 15:39:20 I'll probably have to check what json we get. I thought it was list of IPs per subnetid so was going with that. 15:39:27 I also understand {'subnet-id': [ip-address0, ...], 'subnet-id-1', ...} is easy to handle by vpnservice or netvirt 15:39:54 vthapar: I greed that we should check the resulted JSON. 15:40:18 yes, it comes in handy from netvirt perspective, don't need to know the IP to fetch it for a given subnet, which tends to be use case for extra routes etc. 15:40:28 #link http://developer.openstack.org/api-ref-networking-v2.html neutron api doc 15:40:56 #link http://developer.openstack.org/api-ref-networking-v2.html#listPorts list port 15:41:11 Here we can see the example of json 15:42:18 but it only covers single fixed Ip. I should have it in my q-svc.log somewhere. will update the bug with it and then we can decide on how to fix it. 15:42:38 I'll also look at different ways how it is used in vpnservice/netvirt. 15:42:52 Please notice "[{}, ]". It's a list of dict. 15:43:33 yeah, it suggests subnet-ipaddress will be better. 15:44:02 we do want NN to be as transparent as possible so should come up with model that aligns with what we get. 15:44:09 Cool. 15:44:24 Can you please give the patch the explicit comment for record? 15:44:28 Then, I'll update the patch. 15:45:07 we don't have patch for this yet, only the bug. 15:45:17 Ah, then on the bug report 15:45:28 I held off to patch as was wondering if we want to take it up as part of the bigger patch where we're modifying all yangs. 15:45:44 would make sense, else we will end up causing disruption twice. 15:46:00 yeah, will add to bug report. 15:46:01 Agree. I don't want two disruptions. 15:46:11 (or even one disrutpion if possible) 15:46:49 one disruption can be avoided by using revision and new yangfile with revision in file name. 15:47:15 onus would be on others to modify code to use new yangs, but nothing would break. 15:49:04 I see. 15:49:49 anything else to discuss? 15:50:15 nothing from me. 15:50:34 okay I'll give you 10min back 15:50:42 thank you, everybody 15:50:44 #topic cookies 15:50:53 #endmeeting