15:12:13 #startmeeting bgpvpn 15:12:14 Meeting started Tue Jun 13 15:12:13 2017 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:12:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:12:18 The meeting name has been set to 'bgpvpn' 15:12:21 hi 15:12:45 hi paul 15:12:51 let's see who is around... 15:13:45 hi bobmel, bfernando, doude ... BGPVPN IRC meeting starting now if you are around 15:14:40 yep o/ 15:15:02 Hi 15:17:14 hi guys 15:17:16 let's start 15:17:39 the main thing on the agenda is the bgpvpn-routes-control API extension proposal 15:17:51 #link https://review.openstack.org/#/c/467277/ 15:18:18 and if you see other things to discuss, go ahead, of course 15:18:30 on the bgpvpn-routes-control API extension proposal... 15:18:52 last week and recently I've been addressing the various comments being made 15:19:27 and I also added elements to allow the control of local_pref, which is an important ingredient in scenarios where you want to advertise static routes 15:19:47 e.g. to allow master/fallback routes scenarios 15:20:08 doude, the patchset you had reviewed was not having this addition 15:21:16 yes I saw that 15:21:32 I just reviewed the last patch set and lgtm 15:21:36 I'll +1 15:22:02 ah excellent 15:23:32 I had been considering also allowing local_pref at the router_association, network_association, and port_associations levels (additional to bgpvpn level, and port association route level) 15:24:06 each level above being the fallback if the local_pref isn't defined on the level below 15:24:14 but I finally thought this was overkill 15:24:43 and ended up opting for: BGPVPN level as the default, and a per port route local_pref override 15:25:01 doude, pcarver: any opinion on that ? 15:26:18 tmorin: I don't have any specific use cases to go on one way or the other, but setting it at the BGPVPN level and allowing a per port override sounds reasonable. 15:26:51 I don't see use case to set local_pref on route, network or port association 15:27:58 one implication is that for fixed IPs of a port, we won't have control on the local_pref 15:28:27 the one defined on the BGPVPN will be applicable 15:30:02 ok 15:30:30 I propose to keep thinking about it to see whether there would be scenarios for which that would be limiting 15:31:09 anyways, I plan to keep the proposal open at least one week so other folks have the opportunity to comment 15:31:40 the next question will be the *implementation* of this API proposal 15:32:16 I would like to have an idea among you of whom would have time in the pike cycle to implement parts of what is needed for this API 15:32:30 pcarver, doude, bobmel, bfernando...? 15:33:10 [ I will detail the different pieces in the blueprint at https://blueprints.launchpad.net/bgpvpn/+spec/routes-control ] 15:33:46 tmorin: It will really depend on what happens with the Contrail community, and I'm not sure that's going to fully manifest in the pike cycle. 15:34:31 what's the pike schedule? 15:34:34 A new networking-opencontrail project has been created with the intent of holding drivers for the various networking-* APIs plus ML2, router, etc 15:34:39 among the different pieces: 15:34:39 - python description of new API : largely done (we can change things) 15:34:39 - support for new API in the service plugin framework: API extension declaration, driver hooks, python-neutronclient addition, heat, tempest tests 15:34:53 pike feature-freeze is I think sometimes in Auguest 15:34:57 August 15:34:59 let me check 15:35:13 https://releases.openstack.org/pike/schedule.html 15:35:28 no feature freeze is last week of July 15:35:56 And if we can move towards that model for Contrail then I can advocate internally for getting resources to work on it, but we have to see it as viable first. 15:36:09 most of the work will be directly inspired from the existing code on router and network associations 15:36:25 I'm working on a FWaaS support for Contrail. Then I could work on that. As the BGPVPN driver is already done for Contrail, the control route does not seems to be huge amount of work 15:36:31 the thing that will be different is that the port associations and the router associations will become updatable 15:37:04 We aren't using the BaGPipe (or ODL for that matter) implementations, so it's difficult to argue for assigning development resources. 15:37:29 it's nice if driver work happens in parallel (I plan to do the bagpipe pieces, but I'm unsure yet if I'll be able to land everything for pike) 15:37:54 The existing Contrail driver is a good start, but we need to find a path to actually put it into production in order to justify putting developers on it. 15:38:03 pcarver: even resources to the non-driver parts of the framework ? (API, DB, API client, heat, tempest scenarios) 15:38:52 doude: do you think you could have resources for contributing on the framework additionally to the contrail driver ? 15:39:25 no I don't 15:39:30 sorry 15:40:07 tmorin: I can ask, but I don't have a strong case. We're not using any part of the framework currently. Getting a viable path to deploying it with Contrail would help justify developing all parts, but right now we aren't deploying it, so it's just a forward looking possibility. 15:41:18 I'm hoping with the so-called "reboot" of the Contrail community and the creation of the networking-opencontrail project we can create a path towards deploying networking-bgpvpn and the other networking-* projects in a driver model with Contrail as the backend. 15:41:35 pcarver: "prepare for the future" can be an argument, but ok, understood 15:42:13 tmorin: yes, it's the argument I've been using for my own involvement, but my time is spread thin and it's hard to justify additional people. 15:43:17 pcarver: if the key thing for you is having the opencontrail driver in openstack, there is no technical obstacle in actually having the driver in networking-bgpvpn (like bagpipe, contrail driver v1 or odl driver v1) 15:45:14 tmorin: correct, no technical obstacle. But we still need to actually deploy it that way in order to justify putting more developers on enhancing. 15:45:27 Currently we're using Contrail APIs directly, without networking-bgpvpn. 15:45:28 pcarver: understood 15:45:49 I'd like us to move towards using networking-bgpvpn, but we haven't yet. 15:46:56 tmorin: still sounds a bit like chicken'n'egg, since you are less likely to use an SDN-controller agnostic API if less resources are put on it to develop the features you need 15:47:24 tmorin: but well, I know how hard it is to make a case for dev resources... 15:47:31 pcarver: ^ 15:48:40 hi matrohon, hadn't seen you were around :) 15:49:10 do we have other things to discuss today ? 15:52:01 ok let's wrap up then 15:52:05 bye everyone 15:54:47 bye 15:58:38 bye 16:00:23 adrian_otto: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 16:00:24 #endmeeting