15:21:11 <tmorin1> #startmeeting bgpvpn
15:21:13 <openstack> Meeting started Tue Apr 25 15:21:11 2017 UTC and is due to finish in 60 minutes.  The chair is tmorin1. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:21:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:21:16 <openstack> The meeting name has been set to 'bgpvpn'
15:21:38 <matrohon> hi tmorin1
15:21:49 <tmorin1> hi matrohon
15:21:50 <matrohon> pcarver was around too
15:21:55 <tmorin1> cool
15:22:03 <pcarver> I'm still here
15:22:34 <tmorin1> let's see who else may be: bobmel ? doude ?
15:25:51 <tmorin1> ok let's start anyhow
15:26:07 <tmorin1> what do we have on our agenda:
15:26:24 <tmorin1> a) gate issues (now resolved)
15:26:34 <tmorin1> b) neutron-lib used from API (now merged)
15:26:46 <tmorin1> sorry *for* API
15:27:00 <tmorin1> c) rally tests
15:27:08 <tmorin1> d) API evolution blueprints
15:27:29 <tmorin1> anything else matrohon? pcarver ? (hi!)
15:27:39 <tmorin1> #topic gate issues
15:27:47 <pcarver> not for me.
15:28:00 <matrohon> boston summit?
15:28:09 <tmorin1> #undo
15:28:10 <openstack> Removing item from minutes: #topic gate issues
15:28:15 <tmorin1> good idea!
15:28:26 <tmorin1> e) boston summit
15:29:11 <tmorin1> #topic gate issues
15:29:19 <tmorin1> so we had two distinct gate issues last week
15:29:26 <tmorin1> both due to change in neutron
15:30:10 <tmorin1> the reasons were not so easily identified, but we finally solved them (matrohon pushed changes today)
15:30:37 <tmorin1> now the gate is clean and we merged some pending changes required for other things (that we will talk about now)
15:31:16 <tmorin1> resolution (of both issues) are in: https://review.openstack.org/#/c/459585/
15:31:25 <tmorin1> anything else to add matrohon ?
15:32:16 <matrohon> nothing to add for me tmorin1
15:32:30 <matrohon> everything rocks now
15:32:34 <tmorin1> yep :)
15:32:37 <tmorin1> #topic using the API definition from neutron-lib
15:32:56 <tmorin1> pcarver, your change to use  the API definition from neutron-lib has just merged
15:33:03 <pcarver> yes
15:33:09 <tmorin1> https://review.openstack.org/#/c/395585/
15:33:38 <tmorin1> which means that we now have all the key parts of the changes for stadium implosion done :)
15:33:41 <tmorin1> a good milestone
15:34:15 <tmorin1> we now need to drive API evolution in a consistent way: doing the work in neutron-lib
15:34:26 <tmorin1> this impacts for instance https://review.openstack.org/#/c/332711/  (add VNI to BGPVPN resource)
15:35:11 <tmorin1> I've had email exchanges with deepthi about this, and I think what needs to be done is clear for them
15:35:26 <tmorin1> this was two weeks ago though
15:36:06 <tmorin1> anyhow, thanks pcarver for your perseverance in this neutron-lib work :)
15:36:14 <matrohon> +1000
15:36:31 <tmorin1> #topic rally tests
15:36:37 <pcarver> thanks, I'm glad it finally made it all the way in
15:37:44 <tmorin1> :)
15:37:57 <matrohon> th work is still ongoing for rally :
15:38:00 <tmorin1> matrohon: I think you are more up to date than I am
15:38:04 <tmorin1> yep
15:38:04 <matrohon> https://review.openstack.org/#/c/386418/
15:38:07 <tmorin1> what is missing
15:38:28 <matrohon> rally's team is ready to merge this patch
15:38:55 <matrohon> I think they will first want to understand why the Rally ci fails
15:39:09 <tmorin1> matrohon: yes, I understand that good discussions happened last wekk
15:39:25 <tmorin1> which problematic job is failing ?
15:39:32 <tmorin1> I see only non-voting jobs failing
15:39:57 <matrohon> the third party mirantis rally CI is failing
15:40:00 <tmorin1> but also the mirantis rally CI: is seems voting right ? (I wasn't aware third party CIs were somtimes voting)
15:40:34 <matrohon> I'm in touch with the rally team on their gitter channel
15:40:54 <matrohon> they're not responding right now
15:41:09 <matrohon> but I think the job is done for our side
15:41:21 <tmorin1> ok
15:41:34 <tmorin1> to follow up next week (or before) ...
15:41:44 <matrohon> however
15:41:57 <matrohon> the patch doesn't cover the ntire bp yet
15:42:08 <matrohon> hopefully cedric will continue the effort
15:42:38 <matrohon> a next step could be to run a rally job in the bgpvpn gate
15:43:25 <tmorin1> yes, indeed
15:43:33 <tmorin1> for both comments
15:44:20 <tmorin1> I think we may also want to enrich the test with a test that actually triggers RPC exchanges and processing in the agent
15:44:33 <tmorin1> for the current test, only API oriented, the dummy driver is fine
15:44:40 <matrohon> +1
15:44:59 <tmorin1> we would have to use bagpipe driver in tests triggering "real" work
15:45:02 <tmorin1> ok
15:45:05 <tmorin1> next topic ?
15:45:15 <tmorin1> #topic API evolution blueprints
15:45:34 <tmorin1> I havent checked the etherpads
15:46:12 <pcarver> I've looked, but haven't added or changed anything
15:46:33 <tmorin1> pcarver: ok, still good !
15:46:39 <tmorin1> pcarver: do you have comments/ideas
15:46:49 <tmorin1> #link https://blueprints.launchpad.net/bgpvpn/+spec/port-association
15:47:00 <tmorin1> #link https://blueprints.launchpad.net/bgpvpn/+spec/port-routes
15:47:25 <pcarver> port association would match with the one PoC API that Gluon has done
15:47:36 <tmorin1> I still need to refresh the etherpad for the port-association feature
15:47:46 <tmorin1> pcarver: yes
15:48:13 <pcarver> There are two more use cases that have been used in conjunction with Gluon discussions, Anycast and Hub & Spoke
15:48:14 <tmorin1> this is something simple for bgpvpn, this is really just a new type of associations
15:48:36 <pcarver> I think we can essentially do hub and spoke through a combination of import and export targets
15:49:08 <tmorin1> pcarver: I wanted to talk to you about specifically about these - I'm unclear why they would need anything new in the API
15:50:19 <pcarver> for hub and spoke I think it would just be a question of is it worth having explicit API constructs vs being able to create the effect via import and export targets configured correctly
15:50:29 <tmorin1> pcarver: yes, hub'n'spoke is precisely just that, the thing perhaps is that as it is, to do hub'n'spoke with two BGPVPNs, the user need to ask the admin to create such a pair of BGPVPNs and hasn't an API to do that -- is this what you think would be needed ?
15:50:41 <tmorin1> pcarver: yes, this is the question
15:51:10 <tmorin1> pcarver: it all depends on whether or not you want non-admin users to be able to do that without admin intervention
15:51:22 <pcarver> I'm not exactly sure. I need to find out exactly who would use either of these and run ideas by them
15:51:58 <pcarver> right now the use cases don't have a lot of background detail to them
15:52:12 <pcarver> but do you think anycast can be done with the current API?
15:52:13 <tmorin1> half kidding: if you don't know who these are, then we can conclude we don't need anything   :)
15:53:31 <tmorin1> pcarver: I think you can have net A and net B use the same prefix range (defined in different subnets), then start VM A in net A with static  IP X, and then VM B in net B with static IP X
15:53:41 <pcarver> I know that there was specific hub and spoke functionality added to Contrail but I didn't look at it closely
15:54:00 <tmorin1> and then, if you associate both net A and net B to a common BGP VPN, then you have your anycast setup, right ?
15:54:53 <tmorin1> ah
15:55:00 <pcarver> maybe. I don't really know for sure one way or the other
15:55:02 <tmorin1> would be great to have a pointer
15:56:03 <pcarver> I'll look for info on the Contrail feature. I'll have to dig around, I don't remember exactly where I saw it.
15:56:32 <tmorin1> https://www.juniper.net/techpubs/en_US/contrail3.1/topics/task/configuration/hub-spoke-vnc.html ?
15:58:04 <tmorin1> but what the above describes is not a new API it seems, but just explains how to use import/export to build a hubnspoke
15:58:07 <pcarver> that looks like what I was thinkin g of
15:58:18 <pcarver> I think you're right it's just doing import and export
15:59:43 <tmorin1> pcarver: what about the following: if you find out more, fillin a new blueprint ?
16:00:02 <tmorin1> hey its already time :-(
16:00:05 <tmorin1> hadn't noticed
16:00:12 <tmorin1> we need to leave the floot
16:00:14 <tmorin1> floor
16:00:15 <pcarver> tmorin1: will do, if the current API doesn't cover it
16:00:23 <tmorin1> thanks
16:00:27 <tmorin1> we'll have to talk about boston next week
16:00:36 <openstack> juggler: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:00:44 <tmorin1> pcarver: still worth pursuing the discussion about these two gluon use cases...
16:00:49 <tmorin1> #endmeeting