15:03:56 <tmorin> #startmeeting bgpvpn
15:03:57 <openstack> Meeting started Tue Jul  7 15:03:56 2015 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:00 <openstack> The meeting name has been set to 'bgpvpn'
15:04:02 <tmorin> hi everyone
15:04:13 <tmorin> hi pcarver
15:04:17 <tmorin> hi pc_m
15:04:24 <pc_m> hi
15:04:32 <tmorin> hi doude
15:04:41 <doude> tmorin: hi
15:05:27 <tmorin> hi carl_baldwin
15:05:43 <carl_baldwin> tmorin: hi
15:05:46 <vikram> hi
15:05:54 <tmorin> hi Vikram
15:06:22 <vikram> hi tmorin
15:06:33 <tmorin> matrohon is offline, we won't wait for him
15:06:44 <tmorin> I guess we can start
15:06:56 <tmorin> #topic API
15:07:32 <tmorin> the discussion on the fundamental points of the API is finished
15:07:40 <tmorin> we are now looking at the details
15:08:04 <tmorin> matrohon has been looking at how to implement what we had written, in the Neutron framework for API resources
15:08:15 <vikram> great
15:08:49 <tmorin> this will certainly leads to some changes, because it seems that what we had specified does not integrate easily with the framework as-is
15:09:14 <tmorin> there are more details in the gerrit thread, and in an IRC logs between matrohon and blogan
15:09:39 <tmorin> I guess it makes sens anyway to align the spec with what is feasible/idiomatic rather than the reverse way round
15:10:29 <tmorin> matrohon won't work on that until last week of July, don't expect updates on the API before
15:10:35 <tmorin> any comments ?
15:10:54 <tmorin> there are two points that have been briefly discussed in the past on the API
15:11:33 <tmorin> one is the addition of an admin status on a BGPVPN, that would allow to bring all associations down without having to delete them
15:11:47 <tmorin> can be useful for the admin and gives visibility to the tenant
15:11:54 <tmorin> maybe also useful for the tenant
15:12:40 <tmorin> all opinions welcome on the usefulness of such a knob, in particular for tenants
15:13:23 <tmorin> #action people to give feedback on usefullness of an admin_status propert
15:13:46 <pcarver> I think an admin status wouldn't be a bad idea, but I'm not sure how important it is
15:14:27 <tmorin> yes, I agree that it would belong to the "nice to have" category, but not high priority
15:14:50 <pcarver> What might be more important from an operator standpoint is some sort of tenant visible indicator of operational status
15:15:00 <tmorin> and I would think it can be easily added later
15:15:27 <tmorin> pcarver: yes, but I've no idea how easily that can map with backends
15:15:28 <pcarver> i.e., if from a BGP perspective a VPN isn't available, does the tenant have any way to determine that
15:15:52 <pcarver> tmorin: me neither
15:16:02 <tmorin> it's hard to define a network-wide notion of operational status
15:16:25 <tmorin> it's also hard for Neutron, or even for a backend, to know what is reachable outside
15:16:27 <pcarver> but it's worth thinking about as we move along because lack of it is likely to generate trouble tickets
15:17:02 <tmorin> pcarver: agree to keep that in mind
15:17:15 <pcarver> tmorin: for Neutron I agree, but introducing BGP it seems like there may be some visibility to what the WAN is advertising
15:18:32 <tmorin> pcarver: yes, but not necessarily easy to distinguish between normal situation and anomalies
15:18:52 <pcarver> tmorin: I agree
15:18:54 <tmorin> pcarver: the customer does not necessarily know how much prefixes need to be seen by the DC
15:19:24 <pcarver> tmorin: I was mostly thinking in terms of using an incorrect RT
15:20:11 <tmorin> pcarver: I don't know what useful definition of incorrect neutron (or the backend) might have
15:20:26 <tmorin> pcarver: I don't know what useful definition of "incorrect" neutron (or the backend) might have
15:21:15 <tmorin> pcarver: this is the thing that we understand better how to cover with more deployment experience
15:21:21 <pcarver> tmorin: in any case, I'm not saying it's required for this spec. I'm just trying to anticipate operations issues
15:21:43 <tmorin> pcarver: makes sense, let's agree to keep the topic in mind for later
15:22:31 <tmorin> the other possible API addition proposed, by diego, was the addition of a VNID, for l2 BGPVPNs, that would allow to use E-VPN/VXLAN and use a globally-assigned VNID
15:22:32 <pcarver> tmorin: agreed
15:23:12 <tmorin> adding a vnid property is something we can consider
15:23:51 <tmorin> this makes sense essentially for l2, which seems less priority than l3 for our Liberty timeframe
15:24:04 <tmorin> feedback is welcome on this topic
15:25:11 <tmorin> #action people to feedback on the idea of adding a VNID property to allow E-VPN/VXLAN with a globally-assigned VNID
15:25:21 <tmorin> #topic tests
15:26:12 <tmorin> we had basic changes (to README.rst) fail jenkins job
15:26:27 <tmorin> that was because our code was not working anymore with recent Neutron
15:26:40 <tmorin> this was easily fixed
15:26:59 <tmorin> but that raises the question of how we could detect and proactively fix this kind of issues
15:27:14 <tmorin> and keep more easily in sync with Neutron changes
15:27:47 <tmorin> my feeling is that we should work on having non-voting jobs on Neutron repo
15:28:18 <tmorin> but, not being yet familiar with all this, I'd love to have suggestions
15:28:31 <tmorin> maybe carl_baldwin or pc_m would know ?
15:29:02 <pc_m> tmorin: Was away.. reading...
15:29:09 <tmorin> pc_m: thanks
15:29:28 <carl_baldwin> tmorin: pc_m has the right experience to answer this question, I think.
15:29:47 <pc_m> We are seeing tons of VPN breakages due to neutron.
15:30:23 <pc_m> Currently, I'm working on adding VPN functional tests for all neutron commits. dougwig is doing UTs for all service repos.
15:31:11 <pc_m> I'm modifying VPN tox.ini to support such work, and then will make the job experimental for neutron commits. That's about the only way to help reduce breakages.
15:32:09 <pc_m> You may be able to do something similar.
15:32:23 <tmorin> dougwig is doing UTs for all service repos: which service repos ? (is networking-bgpvpn one of them ?)
15:32:38 <tmorin> pc_m: yes, it seems sound
15:32:57 <pc_m> Long term, once Neutron is a libray, has a well defined API and tests to verify, then this will be less an issue.
15:33:09 <tmorin> yes
15:33:18 <pc_m> dougwig is adding FW, LB, VPN repo UTs, AFAIK.
15:33:25 <tmorin> ok
15:34:06 <tmorin> the issue we had is related to the way we insert constants into Neutron for the bgpvpn API endpoint
15:34:43 <tmorin> do you know if they have plans to sort out how external repository can interact with API or constants namespaces managed by Neutron ?
15:35:35 <pc_m> tmorin: I don't know. May be a good thing to bring up.
15:35:42 <tmorin> pc_m: agreed
15:36:34 <tmorin> pc_m: the way we do now is fine, if it's stable enough,  and... until there is a collision where two projects try to use the same name
15:36:41 <tmorin> hopefully the later is unlikely
15:37:07 * pc_m fingers crossed :)
15:37:12 <tmorin> ;)
15:37:22 <tmorin> #topic database sync
15:37:58 <tmorin> I discussed with matrohon the case where a Neutron network is deleted
15:38:37 <tmorin> the bgpvpn service plugin has to be notified, and clean-up in the corresponding associations possibly axisting in one or more BGPVPN
15:38:57 <tmorin> we plan to use the Neutron registry callbacks mechanism
15:39:12 <tmorin> but this depends on a work in progress
15:39:51 <tmorin> the topic of how we can use this is tracked in blueprint https://blueprints.launchpad.net/bgpvpn/+spec/bagpipe-use-neutron-registry
15:39:53 <tmorin> #link https://blueprints.launchpad.net/bgpvpn/+spec/bagpipe-use-neutron-registry
15:40:52 <tmorin> a related question is how we keep the db clean, assuming there may be cases where a network is modified offline in Neutron (eg. manual db modification)
15:41:19 <tmorin> this is an issue to address at some point since we can't have a foreign key on Nutron network
15:41:24 <tmorin> Neutron
15:41:28 <tmorin> networks
15:42:05 <tmorin> #topic bagpipe driver
15:42:45 <tmorin> currently the driver relies on a specific ml2 driver to be notified of ports coming up, being updated, or coming down
15:42:58 <tmorin> we plan to modify this to also use the Neutron registry callback framework
15:43:42 <tmorin> this is also tracked in the same blueprint
15:43:53 <tmorin> I need to split it into two blueprints
15:44:03 <tmorin> one is framework, the other is bagpipe driver specific
15:44:13 <tmorin> #topic Contrail driver
15:44:32 <tmorin> doude has created a blueprint and started working on it
15:44:50 <tmorin> #link https://blueprints.launchpad.net/bgpvpn/+spec/opencontrail-bgpvpn-driver
15:44:54 <tmorin> thanks doude !
15:45:27 <doude> work stills need to be done :)
15:45:37 <tmorin> ;)
15:45:42 <doude> I met an issue and I opened a bug https://bugs.launchpad.net/bgpvpn/+bug/1472203
15:45:42 <openstack> Launchpad bug 1472203 in bgpvpn "BGPVPN inherits from the db model" [Undecided,New] - Assigned to Édouard Thuleau (ethuleau)
15:45:53 <doude> I started to work on it
15:46:20 <tmorin> yes, doude also noticed a misfit between the service plugin as currently implemented (alway persis bgpvpn info) and what is right for the contrail backend (don't persist in Neutron, the Contrail backend will persist the info)
15:46:27 <tmorin> yes
15:46:46 <doude> exactly
15:46:58 <tmorin> feel free to read the details
15:47:33 <tmorin> the plan is to split the framework/driver differently so that we can have drivers without persistency in Neutron
15:48:41 <tmorin> as far as I'm concerned, I haven't more to bring up today
15:48:47 <tmorin> any question, comments ?
15:49:18 <tmorin> one thing: I won't be here next week, same for matrohon
15:49:43 <tmorin> anyone feel free to meet, but somebody else will have to startmeeting and chair
15:50:36 <tmorin> ok, we're done for today
15:50:39 <tmorin> thanks everyone
15:50:45 <tmorin> #endmeeting