15:03:20 #startmeeting bgpvpn 15:03:21 Meeting started Tue Feb 28 15:03:20 2017 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:24 hi everyone! 15:03:25 The meeting name has been set to 'bgpvpn' 15:04:03 let's see who is around today: bobmel ? doude ? eon`? matrohon ? pcarver ? timirnich ? 15:04:10 hi 15:04:11 hi 15:04:46 hi guys 15:05:59 ok 15:06:08 let's see what we can discuss today: 15:06:19 (a) BGPVPN release last week 15:06:40 (b) neutron-lib & BGPVPN 15:06:58 (c) cleanup WIP on bagpipe driver 15:07:12 (d) Pike roadmap 15:07:17 anything else ? 15:07:45 hi 15:07:45 #topic BGPVPN release last week 15:07:57 hi bobmel :) 15:08:18 networking-bgpvpn 6.0.0 was released last week 15:08:33 nothing more to say than what is already in the release notes 15:09:33 one thing that we may have to discuss consider is whether or not we will want a 6.0.1 with the delete precommit hooks added in https://review.openstack.org/#/c/435651/ 15:09:41 I don't know how important this is for ODL 15:10:38 I think it is likely to be important : https://review.openstack.org/#/c/435967/ 15:10:45 any ODL folk around ? 15:10:49 timirnich: ^ ? 15:11:47 ok, we'll see... 15:12:10 but I think we should proactively backport this... 15:12:36 #topic neutron-lib & BGPVPN 15:12:55 pcarver: congrats !! all this has finally landed ! 15:13:00 yay!!! 15:13:05 both the API definition and the API reference :) 15:13:19 the last items are cleanups on networking-bgpvpn side 15:13:40 I returned home to a heavy meeting schedule this week, but I'm going to squeeze in the networking-bgpvpn side changes this week 15:13:58 or at least a rebase that may get some critical reviews 15:14:03 the change to use the definition from neutron-lib is in flight: https://review.openstack.org/#/c/395585/ 15:14:12 pcarver: ok! 15:14:46 and the other thing to do is update networking-bgpvpn to remove the old API doc and replace it with a pointer to https://developer.openstack.org/api-ref/networking/v2/#bgp-mpls-vpn-interconnection 15:14:48 #link https://developer.openstack.org/api-ref/networking/v2/#bgp-mpls-vpn-interconnection 15:15:02 ok, I'll take care of that too 15:15:13 cool ! thanks 15:15:36 tmorin, concerning the odl patch 15:15:41 yep ? 15:15:56 they already tagged an ocata version at n8g-odl 15:16:22 so they don't need a backport for now 15:16:38 to have a ocata version up and running 15:17:07 tmorin: hi (sorry to be late) 15:17:14 hi doude :) 15:17:20 better late than never :) 15:17:24 :) 15:18:01 we've discussed the 6.0.0 n8g-bgpvpn release done last week and neutron-lib work 15:19:03 matrohon: yes, you are right about ODL, 4.0.0 was indeed already branched 15:19:26 matrohon: so indeed there is no need to backport the delete precommit hooks 15:19:53 #topic bagpipe driver cleanups 15:19:59 not much to say here 15:20:35 https://review.openstack.org/425933 is ready, waiting for a corresponding improvement in neutron to land 15:20:44 all this is progressing nicely enough 15:21:22 the other piece, that we may or may not tackle for Pike would be to use OVO push notifications for neutron-agent exchanges of BGPVPN information 15:22:04 #topic misc fixes 15:22:15 before talking about Pike roadmap 15:22:21 a small heads up on two things 15:22:54 one is https://bugs.launchpad.net/bgpvpn/+bug/1668627 -> a tempest refactor is in progress and we will have to adapt some of our code 15:22:54 Launchpad bug 1668627 in networking-bgpvpn "Refactor of Tempest scenario base classes" [Medium,Confirmed] 15:23:05 if anyone wants to have a look 15:23:48 tmorin: I can do that 15:23:58 ah cool 15:24:00 thanks bobmel 15:24:50 the other thing is our py27 newton periodic job that has been failing since 2017-02-08: http://grafana.openstack.org/dashboard/db/networking-bgpvpn-failure-rates 15:25:49 this is probably related to project config change related to db jobs 15:25:53 I haven't investigated 15:26:53 it seems we now have both a -db and a non -db periodic jobs 15:27:25 i'll try to investigate 15:27:40 we'll also need to see if we want ocata periodic jobs 15:27:48 I think it will make sense 15:27:53 next topic ? 15:28:07 #topic Pike roadmap 15:28:31 Ocata was a short cycle, and we had many things related to the stadium 15:28:57 ideally for Pike we could start covering some of the advanced feature that we've been considering for some time 15:29:23 the etherpad where the discussion was esssentially done is https://etherpad.openstack.org/p/bgpvpn_advanced_features 15:29:45 Sorry - I'm late but here now - reading back through 15:29:58 hi jamemcc, you're welcome! 15:30:14 Paul - great you are here. 15:30:37 Ahh - so sorry - thought it was Massively Scalable 15:30:43 hi jamemcc 15:30:47 But if I can help - I'm glad to 15:30:52 well BGPVPN *are* massively scalable right ? :) 15:31:41 some wellknown telcos (not naming them) have BGPVPNs with millions of routes :) 15:31:47 jamemcc, massevely distributed meeting is on Wednesday, am I wrong? 15:32:39 back to Pike discussion 15:32:40 tmorin, the corresponding etherpad for advanced feature of bgpvpn is : https://etherpad.openstack.org/p/bgpvpn_advanced_features 15:32:48 ? 15:32:55 matrohon: yes 15:33:06 huge backlog! 15:33:50 the goal for Pike would be to see: which among these advanced use cases are clear enough to be implemented, and among these which we would prioritize for Pike 15:34:24 @matrohon - yes - thanks I see it on my calander tomorrow now - relief 15:34:49 my summary of what is clear enough to advance faster than the rest is : Port associations, static routes, control of Extended Communities, control of Local Preference 15:35:38 doude: your contribution will be helpful to see how any proposal would map to Contrail 15:36:08 this applies to any SDN controller, but I don't see contributors on Nuage or ODL or other, around today 15:36:59 I've updated the static-routes blueprint to point to an etherpad with a refreshed summary+proposal on static/dynamic routes 15:37:08 #link https://etherpad.openstack.org/p/bgpvpn_port_routes 15:37:19 #link https://blueprints.launchpad.net/bgpvpn/+spec/port-routes 15:37:36 ok I'll look at it and giva you feedback 15:37:46 I've renamed it from static-routes into port-routes to reflect the fact that we need to address both "static" routes and "dynamic" routes 15:37:47 doude: if you see anything that doesn't map to current Contrail functionality let me know. I maintain AT&T's backlog of what enhancements we're looking for in future Contrail releases. 15:38:04 ok 15:38:08 the port association blueprint is here: https://blueprints.launchpad.net/bgpvpn/+spec/port-association 15:38:32 but it hasn't yet its own up-to-date etherpad --> I'll try to take care of that next week 15:39:33 I also need to register new blueprints for Local Pref control and Extended Community control 15:40:47 the other item on the radar for Pike is EVPN improvements: ODL folks need the "vni" and "technique" attributes 15:41:18 we need to refresh the corresponding bugs/blueprint/changes and have the potential contributors in the loop 15:41:29 they aren't attending the weekly meeting yet 15:44:04 pcarver, doude, everyone: one thing I would insist on is that contrarily to what was has been the enforced/perceived approach in the past for Neutron core feature, it seems that the community would be open to the idea that an implementation for the Neutron reference driver would *not* be a prerequisite for adding a new feature to an API -- under the condition that the said API evolution is discussed/agreed on and can in the future 15:45:10 and that an opensource implementation is available (but not necessarily Neutron) 15:45:30 tmorin: your wording is a little complicated. I'm trying to understand exactly what you're saying. 15:46:38 are you saying that you disagee with current Neutron policy? 15:46:46 it means that people working on an opensource SDN controller should not be worried about having to work both on their SDN controller *and* on their implementation to introduce a new feature in the API 15:47:30 And specifically for bgp-vpn, what is the policy? 15:47:31 pcarver: no, I mean that discussing with a few core, it seem that the idea of considering an SDN controller other than neutron as the reference implementation for a new feature, would be acceptable 15:47:41 ok, so you're saying that it's ok to introduce the API before the implementation is ready? 15:48:09 bobmel: neutron's policy would be n8g-bgpvpn policy 15:48:20 ok 15:49:12 it has been discussed during the PTG? 15:49:13 it would have to be confirmed via a real practical case (or a validation of a document describing that), but my understanding is that the possibility is not closed 15:49:25 no, only side conversations 15:49:42 this was a golden rule for openstack in general 15:50:19 pcarver "before the implementation is ready ?": the implementation would have to be ready during the same timescale, but would not necessarily have to be neutron ref driver 15:50:45 pcarver: and the condition that the API would have to be agreed upon and applicable beyond a single backend would hold 15:51:02 and is indeed an important condition 15:51:21 I guess I'm not understanding what your statement was "contrarily" to 15:51:40 matrohon: we have to discuss more, but at some point feature parity between odl and linuxbridge was important (and it is not anymore) 15:52:06 what was the old policy or practice and what's the new, different policy or practice you're proposing? 15:52:13 tmorin, ok I see 15:52:24 pcarver: opening the door to sometimes not requiring an implementation in the ref driver is backwards with what was done at some point 15:52:50 but the diff is that both are running in the openstack CI 15:53:12 ok, so previously the ref driver had to support the full API, but you're saying it would be ok to have parts of the API that are only supported by a controller other than the ref implementation? 15:53:15 if we introduce a API that doesn't match the ref driver, it won't be tested by our CI 15:53:17 matrohon: and it seems that an extra feature of a stadium project would not be treated in the same way as a core neutron functionality would be 15:53:28 matrohon: CI: perhaps 15:53:58 matrohon: ideally it would I guess have to be covered by a third party CI 15:54:32 tmorin: but perhaps, base API tempest tests with a dummy driver would be considered sufficient to validate the code in the n8g-bgpvpn repo 15:54:34 ? 15:55:26 I think ambition should be to implement full API in the reference driver even if it is not strictly required 15:55:32 in this context it would make sense 15:55:37 bobmel: I 100% agree 15:56:45 bobmel: my idea is that we also need to remove what may deter potential contributors working on SDN controllers from spending time on API definition and BGPVPN framework 15:57:04 matrohon: (not sure what you say would make sense) 15:57:46 Afraid I need to drop. See you next week! 15:58:07 all this needs to be discussed/tried/validated, in particular if the requirement would become "an opensource ref implementation" or "a 4-opens opensource ref implementation" or ... 15:58:19 bobmel: np, we're out of time anyways 15:58:44 tmorin, if it fosters SDN dev to contribute to the API, that would be a great 15:58:53 I propose to try to consolidate Pike roadmap during the next two IRC meetings 15:59:00 matrohon: yes! 15:59:21 we need to leave the floor for the next meeting 15:59:26 thanks everyone ! 15:59:31 #endmeeting