15:03:20 <tmorin> #startmeeting bgpvpn
15:03:21 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:24 <tmorin> hi everyone!
15:03:25 <openstack> The meeting name has been set to 'bgpvpn'
15:04:03 <tmorin> let's see who is around today: bobmel ? doude ? eon`? matrohon ? pcarver ? timirnich ?
15:04:10 <pcarver> hi
15:04:11 <matrohon> hi
15:04:46 <tmorin> hi guys
15:05:59 <tmorin> ok
15:06:08 <tmorin> let's see what we can discuss today:
15:06:19 <tmorin> (a) BGPVPN release last week
15:06:40 <tmorin> (b) neutron-lib & BGPVPN
15:06:58 <tmorin> (c) cleanup WIP on bagpipe driver
15:07:12 <tmorin> (d) Pike roadmap
15:07:17 <tmorin> anything else ?
15:07:45 <bobmel> hi
15:07:45 <tmorin> #topic BGPVPN release last week
15:07:57 <tmorin> hi bobmel :)
15:08:18 <tmorin> networking-bgpvpn 6.0.0 was released last week
15:08:33 <tmorin> nothing more to say than what is already in the release notes
15:09:33 <tmorin> 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 <tmorin> I don't know how important this is for ODL
15:10:38 <tmorin> I think it is likely to be important : https://review.openstack.org/#/c/435967/
15:10:45 <tmorin> any ODL folk around ?
15:10:49 <tmorin> timirnich: ^ ?
15:11:47 <tmorin> ok, we'll see...
15:12:10 <tmorin> but I think we should proactively backport this...
15:12:36 <tmorin> #topic neutron-lib & BGPVPN
15:12:55 <tmorin> pcarver: congrats !! all this has finally landed !
15:13:00 <pcarver> yay!!!
15:13:05 <tmorin> both the API definition and the API reference   :)
15:13:19 <tmorin> the last items are cleanups on networking-bgpvpn side
15:13:40 <pcarver> 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 <pcarver> or at least a rebase that may get some critical reviews
15:14:03 <tmorin> the change to use the definition from neutron-lib is in flight:  https://review.openstack.org/#/c/395585/
15:14:12 <tmorin> pcarver: ok!
15:14:46 <tmorin> 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 <tmorin> #link https://developer.openstack.org/api-ref/networking/v2/#bgp-mpls-vpn-interconnection
15:15:02 <pcarver> ok, I'll take care of that too
15:15:13 <tmorin> cool ! thanks
15:15:36 <matrohon> tmorin, concerning the odl patch
15:15:41 <tmorin> yep ?
15:15:56 <matrohon> they already tagged an ocata version at n8g-odl
15:16:22 <matrohon> so they don't need a backport for now
15:16:38 <matrohon> to have a ocata version up and running
15:17:07 <doude> tmorin: hi (sorry to be late)
15:17:14 <tmorin> hi doude :)
15:17:20 <tmorin> better late than never :)
15:17:24 <doude> :)
15:18:01 <tmorin> we've discussed the 6.0.0 n8g-bgpvpn release done last week and neutron-lib work
15:19:03 <tmorin> matrohon: yes, you are right about ODL,  4.0.0 was indeed already branched
15:19:26 <tmorin> matrohon: so indeed there is no need to backport the delete precommit hooks
15:19:53 <tmorin> #topic bagpipe driver cleanups
15:19:59 <tmorin> not much to say here
15:20:35 <tmorin> https://review.openstack.org/425933 is ready, waiting for a corresponding improvement in neutron to land
15:20:44 <tmorin> all this is progressing nicely enough
15:21:22 <tmorin> 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 <tmorin> #topic misc fixes
15:22:15 <tmorin> before talking about Pike roadmap
15:22:21 <tmorin> a small heads up on two things
15:22:54 <tmorin> 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 <openstack> Launchpad bug 1668627 in networking-bgpvpn "Refactor of Tempest scenario base classes" [Medium,Confirmed]
15:23:05 <tmorin> if anyone wants to have a look
15:23:48 <bobmel> tmorin: I can do that
15:23:58 <tmorin> ah cool
15:24:00 <tmorin> thanks bobmel
15:24:50 <tmorin> 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 <tmorin> this is probably related to project config change related to db jobs
15:25:53 <tmorin> I haven't investigated
15:26:53 <tmorin> it seems we now have both a -db and a non -db periodic jobs
15:27:25 <tmorin> i'll try to investigate
15:27:40 <tmorin> we'll also need to see if we want ocata periodic jobs
15:27:48 <tmorin> I think it will make sense
15:27:53 <tmorin> next topic ?
15:28:07 <tmorin> #topic Pike roadmap
15:28:31 <tmorin> Ocata was a short cycle, and we had many things related to the stadium
15:28:57 <tmorin> ideally for Pike we could start covering some of the advanced feature that we've been considering for some time
15:29:23 <tmorin> the etherpad where the discussion was esssentially done is https://etherpad.openstack.org/p/bgpvpn_advanced_features
15:29:45 <jamemcc> Sorry - I'm late but here now - reading back through
15:29:58 <tmorin> hi jamemcc, you're welcome!
15:30:14 <jamemcc> Paul - great you are here.
15:30:37 <jamemcc> Ahh - so sorry - thought it was Massively Scalable
15:30:43 <matrohon> hi jamemcc
15:30:47 <jamemcc> But if I can help - I'm glad to
15:30:52 <tmorin> well BGPVPN *are* massively scalable right ? :)
15:31:41 <tmorin> some wellknown telcos  (not naming them)  have BGPVPNs with millions of routes :)
15:31:47 <matrohon> jamemcc, massevely distributed meeting is on Wednesday, am I wrong?
15:32:39 <tmorin> back to Pike discussion
15:32:40 <matrohon> tmorin, the corresponding etherpad for advanced feature of bgpvpn is : https://etherpad.openstack.org/p/bgpvpn_advanced_features
15:32:48 <matrohon> ?
15:32:55 <tmorin> matrohon: yes
15:33:06 <matrohon> huge backlog!
15:33:50 <tmorin> 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 <jamemcc> @matrohon - yes - thanks I see it on my calander tomorrow now - relief
15:34:49 <tmorin> 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 <tmorin> doude: your contribution will be helpful to see how any proposal would map to Contrail
15:36:08 <tmorin> this applies to any SDN controller, but I don't see contributors on Nuage or ODL or other, around today
15:36:59 <tmorin> I've updated the static-routes blueprint to point to an etherpad with a refreshed summary+proposal on static/dynamic routes
15:37:08 <tmorin> #link https://etherpad.openstack.org/p/bgpvpn_port_routes
15:37:19 <tmorin> #link https://blueprints.launchpad.net/bgpvpn/+spec/port-routes
15:37:36 <doude> ok I'll look at it and giva you feedback
15:37:46 <tmorin> 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 <pcarver> 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 <doude> ok
15:38:08 <tmorin> the port association blueprint is here: https://blueprints.launchpad.net/bgpvpn/+spec/port-association
15:38:32 <tmorin> but it hasn't yet its own up-to-date etherpad --> I'll try to take care of that next week
15:39:33 <tmorin> I also need to register new blueprints for  Local Pref control and Extended Community control
15:40:47 <tmorin> the other item on the radar for Pike is EVPN improvements: ODL folks need the "vni" and "technique" attributes
15:41:18 <tmorin> we need to refresh the corresponding bugs/blueprint/changes and have the potential contributors in the loop
15:41:29 <tmorin> they aren't attending the weekly meeting yet
15:44:04 <tmorin> 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 <tmorin> and that an opensource implementation is available (but not necessarily Neutron)
15:45:30 <pcarver> tmorin: your wording is a little complicated. I'm trying to understand exactly what you're saying.
15:46:38 <pcarver> are you saying that you disagee with current Neutron policy?
15:46:46 <tmorin> 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 <bobmel> And specifically for bgp-vpn, what is the policy?
15:47:31 <tmorin> 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 <pcarver> ok, so you're saying that it's ok to introduce the API before the implementation is ready?
15:48:09 <tmorin> bobmel: neutron's policy would be n8g-bgpvpn policy
15:48:20 <bobmel> ok
15:49:12 <matrohon> it has been discussed during the PTG?
15:49:13 <tmorin> 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 <tmorin> no, only side conversations
15:49:42 <matrohon> this was a golden rule for openstack in general
15:50:19 <tmorin> 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 <tmorin> pcarver: and the condition that the API would have to be agreed upon and applicable beyond a single backend would hold
15:51:02 <tmorin> and is indeed an important condition
15:51:21 <pcarver> I guess I'm not understanding what your statement was "contrarily" to
15:51:40 <tmorin> 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 <pcarver> what was the old policy or practice and what's the new, different policy or practice you're proposing?
15:52:13 <matrohon> tmorin, ok I see
15:52:24 <tmorin> 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 <matrohon> but the diff is that both are running in the openstack CI
15:53:12 <pcarver> 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 <matrohon> if we introduce a API that doesn't match the ref driver, it won't be tested by our CI
15:53:17 <tmorin> 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 <tmorin> matrohon: CI: perhaps
15:53:58 <tmorin> matrohon: ideally it would I guess have to be covered by a third party CI
15:54:32 <tmorin> 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 <tmorin> ?
15:55:26 <bobmel> I think ambition should be to implement full API in the reference driver even if it is not strictly required
15:55:32 <matrohon> in this context it would make sense
15:55:37 <tmorin> bobmel: I 100% agree
15:56:45 <tmorin> 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 <tmorin> matrohon: (not sure what you say would make sense)
15:57:46 <bobmel> Afraid I need to drop. See you next week!
15:58:07 <tmorin> 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 <tmorin> bobmel: np, we're out of time anyways
15:58:44 <matrohon> tmorin, if it fosters SDN dev to contribute to the API, that would be a great
15:58:53 <tmorin> I propose to try to consolidate Pike roadmap during the next two IRC meetings
15:59:00 <tmorin> matrohon: yes!
15:59:21 <tmorin> we need to leave the floor for the next meeting
15:59:26 <tmorin> thanks everyone !
15:59:31 <tmorin> #endmeeting