15:02:01 #startmeeting bgpvpn 15:02:02 Meeting started Tue Aug 25 15:02:01 2015 UTC and is due to finish in 60 minutes. The chair is matrohon. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:04 Hi! 15:02:05 The meeting name has been set to 'bgpvpn' 15:02:08 matrohon: yes 15:02:34 #topic : announcement 15:02:49 not much to announce for me 15:02:52 any one? 15:03:44 ok let's move to the next topic 15:04:10 #topic : split to attachment extension 15:04:34 so we had an interesting discussion on the ML this week 15:04:49 #link https://www.mail-archive.com/search?l=openstack-dev@lists.openstack.org&q=subject:%22Re\%3A+\[openstack\-dev\]+\[Neutron\][bgpvpn\]+Service+Plugin+vs+Service%09driver%22&o=newest 15:05:32 I proposed to split attachment to extension, but as salv-orlando said, it doesn't seem to be a good idea 15:05:58 we would end up having different API depending on the backend 15:06:05 matrohon: what was your conclusion of the discussion? 15:06:47 I leaning toward implementing the API described in the spec 15:07:03 and start by implementing the network attachment 15:07:27 for every backend, since it is also targeted by ODL 15:08:09 +1, but we will implement the Router attachment in the API and leave it to drivers to reject it as unsupported? 15:08:33 once it works with net attachment, we can start coding the router attachment 15:09:05 but I think that every backend are able to manage router attachments 15:09:18 I think that makes sense. We want to eventually converge on similar functionality across backends, but obviously we can't dictate what the backends currently support. 15:09:31 +1 for ODL 15:09:49 By providing a Neutron API that describes what *should* be supported we provide motivation for the backends to develop that support. 15:10:08 pcarver, +1 15:10:27 the issue is for nuage, which is not compatible with net attachment for the moment 15:10:48 so it seems that nuage won't provide a driver for the first releases of bgpvpn 15:11:09 And we stick to the service driver plugin architecture? 15:11:27 matrohon: or perhaps wishful thinking, but Nuage could provide people to help develop the router attachment part in parallel 15:11:49 pcarver, +100 :) 15:12:17 Then, if they can enhance their backend they'd have the advantage of being the first to support both options 15:12:47 pcaraver : with the ref implementation : bagpipe :) 15:12:57 and ODL probably 15:13:17 ok let's agree on that : 15:14:17 #info : we focus on a implementing the network attachment first, supported by every backends included in tree 15:14:48 #topic : service driver vs service plugin 15:15:07 this was the main point of the ML thread 15:15:30 I discussed with doude who started to implement the contrail backend 15:15:47 we agreed on salv-orlando proposal : 15:16:36 having a standalone plugin for contrail and a generic plugin that loads one driver 15:16:46 for other backends 15:16:54 did I ever made a proposal? 15:17:11 salv-orlando, yes you did ^ 15:17:36 salv-orlando, thanks for this proposal :) it make sense for the bgpvpn project 15:18:13 the generic plugin will provide db persistency before calling the driver 15:18:54 does it make sense for everyone? 15:19:02 Will it also clean up the DB if the call to the driver fails? 15:19:53 janscheurich, this is the tricky part, ML2 had the same issue... 15:20:39 I know. We need to have compatible approaches with ML2 to be able to talk to the same backend from different plugins 15:20:54 janscheurich, AFAIR ML2 proposal was to retry untill the backend works 15:21:14 janscheurich, we have to check what is done in ML2 15:21:35 matrohon: agree! 15:22:04 doude, are you ok, for a standalone contrail plugin 15:22:11 ? 15:22:22 yes, I am 15:22:32 I will check with our ML2/ODL experts 15:22:48 we need to revert the patch I merged to split driver in two categories 15:23:11 #info : contrail will implement its own bgpvpn plugin, while ODL and backend will whare a generic plugin to consistently manage the db layer 15:23:57 #topic : backend impelmentation 15:24:07 #undo 15:24:09 Removing item from minutes: 15:24:13 #topic : backend implementation 15:24:48 any update fot the implementation of the ODL driver 15:24:56 janscheurich, ^ 15:26:29 matrohon: Not yet. We are currently planning the work in the team; ODL driver and ODL Neutron North-bound 15:26:50 janscheurich, thanks for the update 15:26:59 Work will start very soon 15:27:13 doude, any update for the contrail plugin? 15:28:17 matrohon: I'm close to finish it, but it was in standby during the last 3 weeks. I hope to propose a review in a week 15:28:35 doude : great! 15:29:05 nothing new for bagpipe :) 15:29:05 I also start a dicussion with the OpenContrail community to add the bgpvpn_connection resource to Contrail data model 15:29:32 doude : do you have a link to a ML thread? 15:29:46 so the BGPVPN Contrail plugin will be dependent to a recent Contrail version 15:30:20 matrohon: I just discuss that on IRC for the moment but I plan to send an email on the Contrail mailing list 15:30:34 doude : ok 15:30:51 doude : put me in the loop if needed 15:30:57 sure 15:31:02 thanks 15:31:17 #topic : bugs and blueprints 15:32:11 I keep on working on https://blueprints.launchpad.net/bgpvpn/+spec/split-association-api 15:32:31 I'm about to push the db layer 15:34:04 I would also like to resume the discussion of the static routes discussion because we will need it for the network attachment. 15:34:18 *blueprint 15:34:41 who is interested? 15:34:58 this bp ? https://blueprints.launchpad.net/bgpvpn/+spec/static-routes 15:35:20 yes. we can take that off-line also 15:36:06 janscheurich, ok 15:36:28 #topic : open discussion 15:36:40 Please add you comments proposals to the wiki 15:37:07 janscheurich, do you mean etherpad? 15:38:19 sorry, etherpad of course 15:38:20 anyone wants to discuss anything else? 15:39:31 matrohon: no 15:39:47 ok so let's en the meeting 15:39:54 thanks everyone 15:39:58 #endmeeting