15:12:13 <tmorin> #startmeeting bgpvpn
15:12:14 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:12:18 <openstack> The meeting name has been set to 'bgpvpn'
15:12:21 <pcarver> hi
15:12:45 <tmorin> hi paul
15:12:51 <tmorin> let's see who is around...
15:13:45 <tmorin> hi bobmel, bfernando, doude ... BGPVPN IRC meeting starting now if you are around
15:14:40 <bfernando> yep o/
15:15:02 <doude> Hi
15:17:14 <tmorin> hi guys
15:17:16 <tmorin> let's start
15:17:39 <tmorin> the main thing on the agenda is the bgpvpn-routes-control API extension proposal
15:17:51 <tmorin> #link https://review.openstack.org/#/c/467277/
15:18:18 <tmorin> and if you see other things to discuss, go ahead, of course
15:18:30 <tmorin> on the bgpvpn-routes-control API extension proposal...
15:18:52 <tmorin> last week and recently I've been addressing the various comments being made
15:19:27 <tmorin> 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 <tmorin> e.g. to allow master/fallback routes scenarios
15:20:08 <tmorin> doude, the patchset you had reviewed was not having this addition
15:21:16 <doude> yes I saw that
15:21:32 <doude> I just reviewed the last patch set and lgtm
15:21:36 <doude> I'll +1
15:22:02 <tmorin> ah excellent
15:23:32 <tmorin> 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 <tmorin> each level above being the fallback if the local_pref isn't defined on the level below
15:24:14 <tmorin> but I finally thought this was overkill
15:24:43 <tmorin> and ended up opting for: BGPVPN level as the default, and a per port route local_pref override
15:25:01 <tmorin> doude, pcarver: any opinion on that ?
15:26:18 <pcarver> 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 <doude> I don't see use case to set local_pref on route, network or port association
15:27:58 <tmorin> one implication is that for fixed IPs of a port, we won't have control on the local_pref
15:28:27 <tmorin> the one defined on the BGPVPN will be applicable
15:30:02 <tmorin> ok
15:30:30 <tmorin> I propose to keep thinking about it to see whether there would be scenarios for which that would be limiting
15:31:09 <tmorin> anyways, I plan to keep the proposal open at least one week so other folks have the opportunity to comment
15:31:40 <tmorin> the next question will be the *implementation* of this API proposal
15:32:16 <tmorin> 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 <tmorin> pcarver, doude, bobmel, bfernando...?
15:33:10 <tmorin> [ I will detail the different pieces in the blueprint at https://blueprints.launchpad.net/bgpvpn/+spec/routes-control ]
15:33:46 <pcarver> 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 <doude> what's the pike schedule?
15:34:34 <pcarver> 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 <tmorin> among the different pieces:
15:34:39 <tmorin> - python description of new API : largely done (we can change things)
15:34:39 <tmorin> - support for new API in the service plugin framework:  API extension declaration, driver hooks, python-neutronclient addition, heat, tempest tests
15:34:53 <tmorin> pike feature-freeze is I think sometimes in Auguest
15:34:57 <tmorin> August
15:34:59 <tmorin> let me check
15:35:13 <tmorin> https://releases.openstack.org/pike/schedule.html
15:35:28 <tmorin> no feature freeze is last week of July
15:35:56 <pcarver> 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 <tmorin> most of the work will be directly inspired from the existing code on router and network associations
15:36:25 <doude> 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 <tmorin> the thing that will be different is that the port associations and the router associations will become updatable
15:37:04 <pcarver> 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 <tmorin> 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 <pcarver> 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 <tmorin> pcarver: even resources to the non-driver parts of the framework ?  (API, DB, API client, heat, tempest scenarios)
15:38:52 <tmorin> doude: do you think you could have resources for contributing on the framework additionally to the contrail driver ?
15:39:25 <doude> no I don't
15:39:30 <doude> sorry
15:40:07 <pcarver> 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 <pcarver> 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 <tmorin> pcarver: "prepare for the future" can be an argument, but ok, understood
15:42:13 <pcarver> 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 <tmorin> 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 <pcarver> 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 <pcarver> Currently we're using Contrail APIs directly, without networking-bgpvpn.
15:45:28 <tmorin> pcarver: understood
15:45:49 <pcarver> I'd like us to move towards using networking-bgpvpn, but we haven't yet.
15:46:56 <tmorin> 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> tmorin: but well, I know how hard it is to make a case for dev resources...
15:47:31 <tmorin> pcarver: ^
15:48:40 <tmorin> hi matrohon, hadn't seen you were around :)
15:49:10 <tmorin> do we have other things to discuss today ?
15:52:01 <tmorin> ok let's wrap up then
15:52:05 <tmorin> bye everyone
15:54:47 <pcarver> bye
15:58:38 <doude> bye
16:00:23 <openstack> adrian_otto: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:00:24 <tmorin> #endmeeting