15:03:36 <tmorin> #startmeeting bgpvpn
15:03:37 <openstack> Meeting started Tue Jun  9 15:03:36 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:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:41 <openstack> The meeting name has been set to 'bgpvpn'
15:04:00 <tmorin> hi matrohon, hi svinota
15:04:08 <matrohon> hi
15:04:52 <tmorin> hi pc_m
15:04:59 <tmorin> hi pcarver
15:05:00 <pc_m> tmorin: hi
15:05:13 <matrohon> anybody around for the bgpvpn meeting?
15:05:21 <pc_m> matrohon: yup
15:06:01 <ni694458> matrohon: yes for bgp vpn
15:06:49 <tmorin> hi ni694458, nice nick ;-P
15:08:33 <tmorin> ok, let's start
15:08:53 <tmorin> we did not update the agenda since we had ran out of time last week
15:09:21 <tmorin> the points we did not cover were:   work on Horizon, work on Heat, and a status on drivers
15:09:30 <tmorin> we can also cover additional points as relevant
15:09:43 <matrohon> #link : https://wiki.openstack.org/wiki/Meetings/BGPVPN
15:10:03 <tmorin> #topic work item Horizon
15:10:57 <tmorin> pc_m (I think) had mentioned there would be two distinct parts, one for admin, one for tenant
15:11:19 <pc_m> not me :)
15:11:31 <tmorin> ok, well, this is still true ;)
15:11:40 <tmorin> #undo
15:11:41 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x9566c50>
15:11:52 <tmorin> we need to make a better introduction first ;)
15:12:24 <tmorin> one big piece of news since last week is that networking-bgpvpn was formally approved as an official project under the neutron big tent
15:12:32 <matrohon> #link : https://review.openstack.org/#/c/186041/
15:13:28 <matrohon> the process to move the code to the neutron big test is on its way :
15:13:40 <matrohon> #link : https://review.openstack.org/#/c/188822/
15:14:02 <matrohon> ^ s/test/tent
15:14:25 <tmorin> as soon as the new repo is created, we'll move the spec and the associated discussion there
15:15:23 <matrohon> can we have a status on last meeting action points?
15:15:44 <tmorin> matrohon: well, yes, we should have started with that
15:16:12 <tmorin> #link http://eavesdrop.openstack.org/meetings/bgpvpn/2015/bgpvpn.2015-06-02-15.01.html
15:16:38 <tmorin> "tmorin to     update spec for type field" : I've done it, but not pushed the update yet
15:16:49 <tmorin> "matrohon to     create the new openstack repo"  -> see above, in progress
15:17:00 <tmorin> "matrohon to create blueprint and assign them"...?
15:17:19 <matrohon> I've created 2 bps
15:17:38 <matrohon> one for adding a list of RDs
15:17:45 <matrohon> #link https://blueprints.launchpad.net/bgpvpn/+spec/api-optional-rd-list
15:18:25 <matrohon> another one to be able to add several networks to a bgpvpn connection
15:18:35 <matrohon> #link : https://blueprints.launchpad.net/bgpvpn/+spec/multiple-net-attachment
15:18:42 <matrohon> I din't assigned them
15:19:08 <matrohon> I let people interested in it assign them to theirself
15:19:41 <matrohon> or having an auto assigment asa they'll upstream some ccode
15:19:52 <tmorin> looks good
15:19:54 <dhruvdhody> Regd "vikram update python-neutronclient code "; he is working on it
15:20:16 <tmorin> dhruvdhody: ok, good
15:20:51 <matrohon> dhruvdhody : good! he agreed on waiting for the API to be upstream before pushing the code for the client
15:21:21 <tmorin> but I guess a few things can be updated even before the API change on RDs and multiple networks are implemented
15:21:42 <matrohon> dhruvdhody : but it is worth looking at it to be responsive when the API will be available
15:22:26 <tmorin> yes, starting before the API side is ready will be useful
15:22:31 * svinota begs pardon for being late
15:22:57 <tmorin> svinota: we were just arriving at your action item :)
15:23:03 <tmorin> "svinota to work on DB mappings and RD"
15:23:05 <dhruvdhody> matrohon: definitely, either he or someone from my team would take care if it
15:23:21 <matrohon> dhruvdhody : great
15:24:16 <pc_m> so I take it that the team is past the point of considering whether or not the API should be integrated in with the VPNaaS API?
15:25:12 <tmorin> I guess we're still ready to converge when/if a relevant convergence emerges
15:25:25 <tmorin> but not waiting for that to progress on a solution
15:26:20 <tmorin> svinota: can you give us a view on your progress on "svinota to work on DB mappings and RD"  ?
15:26:30 <matrohon> pc_m :  does it make sense to you?
15:26:56 <svinota> tmorin, takes a bit more time than I expected, but will be submitted these days — hopefully tonight.
15:26:59 <john_a_joyce> in order to converge we would have to compromise a bit and make some changes to this API
15:27:12 <tmorin> svinota: excellent
15:27:14 <pc_m> matrohon: sure. Hopefully we can look at it and see if there is any commonality, so that the users' experience is consistent.
15:27:15 <john_a_joyce> there seems no appetite to to that
15:27:52 <tmorin> john_a_joyce: "this API" being which API ? current BGP VPN API ?
15:27:58 <john_a_joyce> yes
15:28:30 <tmorin> john_a_joyce: well, I'm not even clear what the changes would be
15:29:06 <john_a_joyce> I don't want to derail - but we did have some concrete proposal last week and also in the specific convergence meeting
15:29:27 <tmorin> pc_m: the discussion on the benefit on finding commonality are still worth debating
15:29:41 <pc_m> tmorin: agree.
15:29:41 <john_a_joyce> but it would need a bit of compromise on the part of this team - I feel
15:30:39 <matrohon> john_a_joyce : what compromises?
15:30:59 <john_a_joyce> we should probably not get bogged down on it here since not all the parties maybe on
15:31:04 <tmorin> john_a_joyce: to me, there was not a satisfying conclusion on a specific proposal that would make a user experience really consistent
15:31:16 <tmorin> john_a_joyce: agreed
15:31:41 <pc_m> Do we want to discuss that at the VPNaaS IRC in 30 mins?
15:32:09 <john_a_joyce> tmorin: I don't agree with your user experience comment - but lets take it up in the proper forum
15:32:27 <tmorin> pc_m: ok, let's see if we can make better progress this week
15:32:31 <matrohon> pc_m : If there is a clear conclusion, I'd love to ear it!
15:32:38 <tmorin> let's pursue on action items
15:32:56 <tmorin> next one is "tmorin investigate unit test coverage to db persistency"
15:33:00 <pc_m> #action explore API convergence in VPNaaS meeting
15:33:20 <matrohon> pc_m : If not, I can help to underline the overlaps between the two API
15:33:22 * tmorin did not progress on this action item
15:34:16 <tmorin> I did progress on making the bagpipe driver easier to intergrate in functional tests though
15:35:28 <tmorin> making it able to use a vxlan encap (which is not standard, but will allow to exercise the whole chain without having to deploy in the test VM a specific not-yet-released version of OVS supporting MPLS)
15:36:18 <svinota> oh, that's great
15:36:35 <svinota> really
15:36:49 <tmorin> yes, and not hard to do by the way
15:37:11 <tmorin> was pushed to day on bagpipe-bgp github
15:37:21 <tmorin> we're done with action items
15:37:32 <tmorin> #topic work items
15:37:47 <tmorin> the work items we did not discussed were: Horizon and Heat
15:38:02 <tmorin> clearly lower priority than the rest, but relevant nevertheless
15:38:22 <tmorin> someone (can't remember who) said we should have two separate (admin and tenant) for Horizon
15:38:32 <tmorin> this is true and the spec now keeps track of that
15:38:48 <tmorin> I don't know if someone would volunteer on working on either of these
15:39:31 <tmorin> can be looked at later
15:39:40 <pc_m> Carl did
15:39:51 <pc_m> recommended admin/tenant
15:39:52 * svinota has to leave, will reach tmorin this evening
15:39:57 <tmorin> you mean the comment was by Carl
15:39:57 <tmorin> ok
15:39:59 <tmorin> yes
15:40:11 <tmorin> ok, bye petr
15:40:19 <svinota> bye
15:40:55 <tmorin> Heat: not urgent either, but if anyone is interested, than will be relevant to cover
15:42:04 <tmorin> ok, that will be for later too
15:42:21 <tmorin> another topic raised (by pc_m) was on how we specify RTs
15:42:49 <tmorin> currently, we have route_targets plus import_targets and export_targets
15:42:54 <tmorin> the spec explains why
15:43:30 <tmorin> pc_m you suggest only keeping import_targets and export_targets in the datamodel, but possibly keeping the three in the API
15:43:52 <pc_m> tmorin: Yeah, didn't think we needed to duplicate info in the dbase
15:44:22 <pc_m> The api could accept a route_targets parm and store in both lists.
15:44:29 <pc_m> just a thought.
15:44:52 <tmorin> the issue I would see is that it becomes impossible on a "show" request, to reply the same thing that the user gave when it created the object
15:45:05 <tmorin> since we loose information if we merge before storing in the db
15:45:55 <tmorin> pc_m: I don't understand : the API really needs to offer the ability to provide distinct lists for import and exports
15:46:25 <tmorin> pc_m: and what kind of duplication are you wanting to avoid ?
15:46:44 <pc_m> tmorin: Maybe I misunderstand the fields?
15:47:09 <tmorin> what is critical is preserving the ability to specify two lists
15:47:12 <tmorin> through the API
15:47:25 <pc_m> tmorin: I thought that the user could specify import or export, or could specify route_targets, meaning they are both import and export.
15:47:41 <tmorin> while we could live with two lists exposed via the API, it is useful to have a third one for RTs common to both lists
15:48:04 <tmorin> this is useful in the simpler and most common use case where only one RT is used for both import and export
15:48:35 <tmorin> pc_m: this is correct
15:48:44 <pc_m> tmorin: So, if I add a RT as import, and later add it as export, how will that be handled? Add it to the route_target list and remove from other? or have show that has some in route_target list and some is both import and output list.
15:49:22 <pc_m> some in
15:49:39 <tmorin> ok, maybe I got your point
15:50:08 <tmorin> on a "show" request we would recreate "route_targets" based on RTs common to export and imports
15:50:19 <pc_m> thinking the database can be normalized. The user API could allow for the easier input (whcih makes sense).
15:50:24 <pc_m> right.
15:51:04 <tmorin> ok
15:51:10 <tmorin> seems to make sense
15:51:22 <pc_m> if they later add the other direction, then it could be included in the route_targets output of show.
15:51:51 <tmorin> let's then add to the spec that the datamodel will store only two lists and translate back to the API to show in "route_targets" the RTs that are common
15:52:24 <tmorin> #action tmorin to update specs to indicate that DB will store only import_rts and export_rts
15:52:42 <tmorin> we're close to the end of the meeting
15:52:50 <tmorin> anyone sees anything else ?
15:53:32 <tmorin> yes, one point: there is an ongoing discussion (on the API spec gerrit change) on whether or not we should attach a BGPVPN connection to the router
15:53:55 <tmorin> we will plan this topic for next week, hoping that interested people can be present
15:54:52 <tmorin> I will readd the unclosed action items, so that the last IRC logs will show them too
15:55:04 <tmorin> #action tmorin to investigate unit test coverage to db persistency
15:55:22 <tmorin> #action vikram to  update  python-neutronclient code
15:55:38 <tmorin> #action svinota to     work on DB mappings and RD (mostly done)
15:55:52 <tmorin> #action matrohon to create the new openstack repo
15:56:03 <tmorin> ok, I think we are done
15:56:19 <tmorin> discuss to follow up in VPNaaS
15:56:29 <tmorin> thanks everyone!
15:56:41 <matrohon> tmorin : thanks
15:56:44 <pc_m> tmorin: bye
15:56:53 <dhruvdhody> tmorin: bye
15:57:14 <tmorin> #endmeeting