15:18:07 #startmeeting bgpvpn 15:18:09 Meeting started Tue Sep 1 15:18:07 2015 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:18:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:18:13 The meeting name has been set to 'bgpvpn' 15:18:24 hi 15:18:30 hi paul 15:18:40 #topic announces 15:18:45 hi doude 15:18:58 doude is not available today 15:19:02 ok 15:19:58 we've merged some work since last week 15:20:11 some uninteresting stuff to follow oslo changes 15:20:23 some devstack fixes 15:20:34 but also more significant stuff 15:20:58 the patch for the DB to accept the route_distinguishers field from svinota has been merged 15:21:31 and also the patch to allow us to specify the service_providers for BGPVPN in our own file (/etc/neutron/networking_bgpvpn.conf) 15:21:57 that last one was required since reading service providers from neutron.conf is now deprecated 15:22:43 also a patch to cleanup the bgpvpn_db file and not add checks/filters additionally to what is supposed to be already done through policy.json 15:22:53 #topic work in progress 15:22:56 #undo 15:22:57 Removing item from minutes: 15:23:05 anything else to announce ? 15:23:57 #topic work in progress 15:24:39 the new API is up for review 15:25:06 I just rebased it : https://review.openstack.org/#/c/207371/ 15:25:20 I took into account pcarver and tmorin reviews 15:25:29 (it seems it still needs a rebase though) 15:25:52 the neutronclient part is not yet done, I've just started working on it today 15:25:59 It's because svinota's patch just merged 15:26:13 indeed 15:26:37 I think the new API/DB patches mostly look good 15:26:51 we still need to figure out the policy.json part though 15:26:53 I know that doude had some concern about it 15:27:06 even for the old API, it seems that it doesn't do yet what it is supposed to 15:28:03 matrohon: doude comments were mostly minor I would say (some unneeded stuff we could remove) 15:28:07 he feels strange that the "get_bgpvpn" returns a network list, while 'network ' is not a bgpvpn attribute 15:28:43 tmorin : what comments are you talking about 15:28:46 but right now statement like " update_bgpvpn_connection:export_targets": "rule:admin_only" " do not work, a random tenant user can update route-targets 15:28:53 at least on my devstack 15:29:11 matrohon: comments he made privately to me 15:30:05 tmorin : can you open a bug concerning the policy issue 15:30:14 yes, I will 15:30:27 need to first check that the issue is not between the chair and the keyboard ;) 15:30:52 I suggested doude to file a bug on the improvements to do 15:31:57 matrohon: I did not get what you meant by "he feels strange that the "get_bgpvpn" returns a network list, while 'network ' is not a bgpvpn attribute" 15:32:10 Is there a local.conf somewhere that I should refer to? I've been reviewing code but haven't actually tested anything locally yet. 15:33:10 the README.md and README-bagpipe.md have the basic info on what you need to add in a local.conf 15:33:29 pcarver : I had some local.conf available on my github : https://github.com/mathieu-rohon/devstack-conf 15:33:32 tmorin: thanks, I'll take a closer look and try to set it up 15:33:34 and matrohon has a devstack with an example local.conf 15:33:35 yes 15:33:46 matrohon: thanks 15:34:26 I didn't try them since few days, maybe they are not compatible with recent patches 15:34:30 matrohon: your local.conf is not updated to add the service provider in the right file 15:34:38 tmorin : +1 15:34:54 I'll update them ASAP 15:35:36 concerning doude's comments : he should review the spec to make them public 15:36:09 matrohon: +1 (or I'll file a bug report...) 15:36:31 but in this patch : https://review.openstack.org/#/c/217038/3/networking_bgpvpn/neutron/db/bgpvpn_db.py 15:36:48 the get_bgpvpn will return the associated networks 15:37:25 and since networks are not an attribute of the bgpvpn resource anymore, he doesn't feel comfortable with this change 15:38:47 matrohon: I understand your/his comment now, but I've honestly no idea whether it should be considered an issue or not 15:40:06 me neither, let's wait for his comment on the spec 15:40:12 yes 15:40:43 the behavior is consistent with what we have written in the specs, and nobody commented that it would be an issue 15:41:27 there is something related that we will have to take care of 15:41:37 GET /bgpvpn/bgpvpns?network={network_uuid} 15:42:09 since networks is not an attribute of BGPVPN, it is a particular case that we'll need to look at 15:43:13 ok, next topic ? 15:43:27 what do we have to discuss ? 15:43:38 #topic driver implementation 15:44:09 I've a pending patch stop having the bagpipe driver prevent the deletion of a network 15:44:12 reviews welcome 15:44:19 #link https://review.openstack.org/218262 15:44:37 I started the patch to change the bagpipe driver so that it take account the split of the API 15:44:50 I have another one cooking so that the bagpipe driver does not need its own mech_driver to be notified about ports coming up or down 15:45:06 not ready and not yet pushed to gerrit though 15:45:33 doude has been making some progress on the contrail driver 15:45:45 still not ready for review either though 15:46:11 concerning 218268 15:46:30 it conflicting with the db change I pushed 15:46:52 218268 is a nova change ? typo ? 15:47:16 oups 218262 15:47:28 the one you just mentioned 15:47:40 it is conflicting with https://review.openstack.org/#/c/217038/3/networking_bgpvpn/neutron/db/bgpvpn_db.py 15:48:08 by using a foreign key, I prenvent the deletion of the netwok at the db layer 15:49:28 yes, but during API discussing, it was explained (can't remember by whom) that foreign keys accross openstack project should be avoided 15:50:39 and we also considered that from an API user point of view, there is no reason to block the deletion of the network, we should simply remove associations of this network 15:51:42 let's discuss that during reviews 15:52:09 janscheurich, any update for the ODL driver? 15:52:25 matrohon: ok 15:53:41 matrohon: unfortunately work has not yet started 15:53:54 janscheurich, ok 15:54:12 There is a dependency to ODL Neutron Northbound 15:54:39 BGPVPN must be modelled in Yang 15:54:57 That needs to be done before the driver can be implemented 15:55:08 janscheurich, fine 15:55:20 #topic : tokyo summit 15:55:43 unfortunately, the bgpvpn talk has not been selected 15:56:25 svinota, pcarver, janscheurich : will you attend the next summit? 15:56:29 but we still can discuss it, being there 15:56:36 matrohon: I'll be there 15:56:40 matrohon, yep, I will be at the summit 15:56:57 tmorin and I will be there too 15:57:07 We are still in planning phase. But someone from Ericsson Aachen will likely be there 15:57:12 I'll be in Tokyo too 15:57:20 Either me or Tim 15:57:26 I would like to schedule an ad hoc session 15:57:38 pcarver: +1 15:58:06 We've been talking to lots of people about BGPVPNs in various contexts and Margaret and I would like to try to get everyone together in the same room at some point 15:58:24 pcarver : makes sense 15:58:30 pcarver +1 15:58:31 a lot of sense, yes! 15:59:11 pcarver : do you think about a dedicated design summit session? 15:59:22 I'm expecting an Etherpad of design session proposals to come out soon. I was going to add BGPVPN to it 15:59:39 pcarver : +1 15:59:43 +1 15:59:51 tmorin: What about the BGPVPN TechTalk you suggested? 15:59:55 If it doesn't get selected then I figured just an email to the -dev list the week of the summit to announce an ad hoc meetup spot 16:00:14 pcarver : thanks 16:00:30 ok we have to leave! 16:00:41 thanks everyone 16:00:45 #endmeeting 16:00:45 bye 16:00:48 bye bye 16:00:49 Thanks, bye 16:00:50 thanks 16:01:00 adrian_otto: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 16:01:12 oh, im'not chairing this meeting :) 16:01:20 #endmeeting 16:01:23 who started the previous meeting, matrohon? 16:01:30 tmorin ^ 16:01:34 o/ 16:01:43 mfalatic: hold on just a moment 16:01:44 tmorin, can you end the meeting? 16:02:27 #endmeeting