15:01:21 <tmorin> #startmeeting bgpvpn
15:01:22 <openstack> Meeting started Tue Jun  2 15:01:21 2015 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:26 <openstack> The meeting name has been set to 'bgpvpn'
15:01:33 <vikram> hi
15:01:38 * pc_m in another meeting...lurking here
15:01:43 <svinota> hi guys
15:01:45 <tmorin> #link https://wiki.openstack.org/wiki/Meetings/BGPVPN
15:01:49 <tmorin> hi paul, hi petr
15:01:55 <tmorin> hi vikram
15:02:05 <timirnich> hi folks
15:02:10 <tmorin> hi tim
15:02:24 <tmorin> the link is a proposed agenda
15:04:11 <matrohon> hi
15:04:21 <matrohon> sorry fot the delay :)
15:04:37 <tmorin> not sure who else will come, we can wait 1/2 minute and start I guess
15:04:52 <tmorin> many of those present to discuss this in Vancouver are here already
15:05:29 <tmorin> hi mat, hi ildiko
15:06:25 <pcarver> hi
15:07:10 <tmorin> hi paul
15:07:24 <pc_m> hi
15:07:30 <matrohon> hi pc_m
15:07:58 <pc_m> hi folks. I'm in a conf call, so will try to keep one eye on this too :)
15:08:19 <tmorin> ok, I guess we can start
15:08:26 <tmorin> thanks everyone for being present
15:08:36 <tmorin> there is a propsed agenda at https://wiki.openstack.org/wiki/Meetings/BGPVPN
15:08:51 <tmorin> don't hesitate to suggest additional points
15:08:55 <tmorin> first a status
15:09:11 <tmorin> there is an ongoing discussion on the proposed API
15:09:23 <tmorin> this is at https://review.openstack.org/#/c/177740
15:09:38 <tmorin> there are a few pending things to discuss later today
15:09:59 <tmorin> and there is a discussed to progress on how/when to converge with other proposal in VPNaaS
15:10:16 <tmorin> we'll have this discussion later today during the VPNaaS meeting
15:10:28 <tmorin> (16:00 UTC #openstakc-meeting-3)
15:10:42 <pc_m> tmorin: how, when, and if it makes sense
15:10:51 <tmorin> pc_m: yes
15:11:00 <tmorin> the other thing on which we can update the statusis the networking-bgpvpn project
15:11:07 <tmorin> it currently is a stackforge project
15:11:30 <tmorin> and we made, last week, a request for making it an openstakc project under the neutron big tent
15:11:36 <tmorin> https://review.openstack.org/#/c/186041
15:11:54 <matrohon> #link https://review.openstack.org/#/c/186041
15:12:07 <tmorin> this request is being progressed, and as we understand, simply pending the ultimate validation
15:13:06 <vikram> Great Work:)
15:13:49 <tmorin> if this is validated, as we hope, we will also move the API spec there and abandon the change for Liberty specs discussed in 177740
15:13:50 <pc_m> nice
15:14:13 <tmorin> yes :)
15:14:17 <svinota> tmorin, any relation and/or comments regarding Mohammad's https://review.openstack.org/#/c/152377/ ?
15:14:53 <vikram> I feel it's on the agenda :"discussion to follow on possible convergence with other related proposal: during VPNaaS meeting (16:00 UTC #openstack-meeting-3"
15:15:04 <tmorin> yes, this is the idea
15:15:05 <matrohon> vikram : +1
15:15:17 <tmorin> for now we haven't see a clear convergence in the targets
15:15:33 <john_a_joyce> we shoudl try hard ton converge
15:15:36 <vikram> tmorin: +1
15:15:49 <john_a_joyce> the use cases are very similar
15:16:08 <tmorin> john_a_joyce: well, that does not seem obvious, but as we say --> up for discussion later today
15:16:17 <pc_m> would be good to understand the use cases for each of the two.
15:16:43 <john_a_joyce> tmorin:  at a high level I don't see much a difference
15:16:44 <tmorin> pc_me: we hope to have properly documented the usecase in the spec in 177740, but comments are welcome
15:16:57 <john_a_joyce> sure in the details there are differences
15:17:16 <pc_m> tmorin: I'll check it out more
15:17:17 <tmorin> I think the discussion on this should involve Mohamad and others
15:17:27 * pc_m trying to wrap my head around both of these :)
15:17:27 <tmorin> let's discuss this later today
15:17:37 <john_a_joyce> tmorin: makes sense - lets leave it for now
15:17:39 <tmorin> you tell us how we can help
15:17:40 <tmorin> ok
15:17:50 <vikram> actually, i also want to see both the API together :)
15:18:02 <tmorin> #topic discuss on BGP VPN API,  pending items
15:18:31 <tmorin> (apart from question related to difference/convergence with other proposals)
15:18:42 <tmorin> the spec has been updated to address comments made
15:18:50 <tmorin> there aren't much pending points
15:19:06 <tmorin> we steel need to describe in more detail how we want to use the "type" field
15:19:24 <tmorin> how much in detail we want this field to indicate a particular technology
15:19:42 <tmorin> the example being IP VPN with RFC4364, and IP VPN with E-VPN Prefix routes
15:20:24 <svinota> tmorin, maybe just write in the type field the rfc number?
15:20:41 <svinota> like type = 'rfc4364'
15:21:00 <tmorin> yes, with some adaptation for specs which aren't rfcs yet
15:21:25 <svinota> 'rfcXXXX+extension'
15:21:40 <tmorin> we had talked about "l2:", "l3:" suffixed by some text indicating the technique
15:21:55 <tmorin> anyhow the API spec will have to list the values and document what they correspond too
15:22:09 <tmorin> the format itself is not that important
15:22:09 <svinota> yep
15:23:05 <svinota> then can we just make an initial list of types to submit, and later expand it, if needed?
15:23:21 <svinota> (leaving current types intact, sure)
15:23:42 <tmorin> i think the inital list could be "l3:rfc4364", "l2:evpn", "l3:evpn-type5"
15:23:57 <svinota> ack
15:24:32 <tmorin> and we also need to document the API for listing the types, but this one is quite trivial
15:24:53 <tmorin> we'll return a json list of the type strings e.g. [ "l3:rfc4364", "l2:evpn", "l3:evpn-type5" ]
15:25:34 <vikram> do we really want to name as "l3:rfc4364"
15:25:52 <tmorin> #action tmorin to update spec for type field
15:26:01 <tmorin> maybe not
15:26:17 <svinota> tmorin, just to be clear: list of types, really supported by the running implementation
15:26:18 <vikram> ok ..
15:26:33 <tmorin> ipvpn could be good enough, and the API documentation would say 'this means RFC4364'
15:26:42 <tmorin> "ipvpn" is more use friendly
15:27:03 <tmorin> petr: yes, list of supported types
15:27:08 * svinota thinks that an rfc reference is friendly enough
15:27:22 <tmorin> ;)
15:27:30 <vikram> :)
15:27:39 <tmorin> ok we can keep this open for now
15:28:09 <matrohon> so the API should ask the driver to get supported types
15:28:13 <vikram> can we have separate section for l2 and l3 and then stating sub-types?
15:28:26 <tmorin> matrohon: yes
15:28:32 <tmorin> what do you mean by section ?
15:28:43 <svinota> vikram, section == ?
15:28:49 <tmorin> hi carl
15:29:32 <vikram> i mean one string stating both types and sub-types or two diff arguments for types and su-types separately
15:30:01 <vikram> am I clear?
15:30:04 <tmorin> yes
15:30:11 <tmorin> this is not a bad idea
15:30:18 <svinota> there is a reason to state explicitly arguments, agree
15:30:33 <svinota> not to require any implicit string parsing
15:30:34 <tmorin> one (l2/l3) can be exposed to the tenant, and the other hidden
15:30:36 <vikram> ok
15:31:03 <tmorin> and we can indicate that the second one can be ommitted, up to the driver to use its default
15:31:35 <svinota> not sure, if we should hide anything from tenants, but explicit things are better sometimes.
15:31:49 <svinota> tmorin, just notice, that the list call will take an argument then
15:32:06 <tmorin> yes indeed
15:32:15 <svinota> tmorin, like list('l2') -> ['evpn']
15:32:26 <tmorin> yes
15:32:36 <vikram> svinota: +1
15:32:52 <tmorin> ok lets agree on that and move to the next topic
15:32:58 <svinota> ack
15:33:09 <vikram> ok
15:33:25 <tmorin> there is another pending point on whether we should let the API user specify a VXLAN id when VXLAN is used as an encap
15:33:47 <tmorin> diego was the one suggesting that, I suggest we wait for a meeting where he is present to address this
15:34:09 <tmorin> #topic networking-bgpvpn, work items
15:34:33 <tmorin> so we have a few pieces of work on which we'll need to work
15:34:49 <tmorin> moving the API on the new networking-bgpvpn project is one
15:34:52 <tmorin> an easy one
15:35:04 <tmorin> it goes with the creation of the new repo etc
15:35:25 <vikram> is the neutronclient part done?
15:35:52 <matrohon> vikram : it's included in the bgpvpn upstream code
15:35:57 <vikram> ok
15:36:12 <tmorin> matrohon, ok for handling the new repo creation etc. ?
15:36:13 <matrohon> #action : matrohon to create the new openstack repo
15:36:15 <vikram> matrohon: thanks
15:36:35 <matrohon> neutronclient is extendable now :)
15:37:07 <vikram> :)
15:37:14 <tmorin> yes, installing the networking-bgpvpn package is enough to extend the python-neutronclient so that the new commands can be used
15:37:45 <tmorin> next stuff to do is adapting the code to what we changed in the API since the early proposal
15:37:50 <tmorin> API calls
15:37:53 <tmorin> DB mapping
15:37:56 <tmorin> neutron client
15:38:14 <tmorin> getting supported technique info from the driver
15:38:23 <tmorin> I think these are the four pieces
15:38:40 <vikram> i can help with few of these
15:39:03 <tmorin> for the API, DB and neutron client, the work specificaly relates to: RDs field, supporting multiple networks
15:39:07 <matrohon> vikram : thanks :)
15:39:14 <tmorin> vikram: kewl :)
15:39:43 <vikram> I can take up this:)
15:40:01 <vikram> if unassigned
15:40:08 <tmorin> which piece in partcular ?
15:40:14 <tmorin> anyone else ?
15:40:25 <svinota> I can help, sure
15:40:32 <vikram> neutron client to start with
15:40:51 <matrohon> vikram, svinota : I'll create the corresponding blueprint
15:41:02 <svinota> matrohon, thanks
15:41:12 <vikram> ok
15:41:37 <vikram> do we have any deadlines?
15:41:53 <svinota> tmorin, is it ok if I will take a look onto RD and DB mappings?
15:42:07 <matrohon> svinota : great !
15:42:11 <tmorin> vikram: "strike while the iron is hot" is our deadline ;)
15:42:23 <vikram> hehehehe ;)
15:42:23 <tmorin> svinota: +1, excellent
15:42:37 <svinota> ok
15:42:56 <vikram> actually, i will on a vacation from 10th - 21st June
15:43:14 <vikram> so .. just want to confirm
15:43:38 <matrohon> vikram : ok, np
15:43:56 <vikram> thanks Mathieu
15:44:21 <svinota> tmorin, matrohon, I'm not familiar with the meeting's black magic, could you write down somewhere on the meeting minutes these assignments?
15:44:26 <tmorin> ok, don't hesitate to ping ourselves on #neutron
15:44:47 <tmorin> yes, the bot will track this based on #action stuff we type
15:45:00 <matrohon> #action matrohon to create blueprint and assign them
15:45:11 <tmorin> #action vikram update python-neutronclient code
15:45:14 <svinota> #action : svinota to work on DB mappings and RD
15:45:29 <tmorin> perfect :)
15:45:36 <svinota> huh
15:45:56 <tmorin> (maybe the meetbot likes it better without the colon)
15:46:08 <tmorin> i'm not familiar yet either ;)
15:46:16 <tmorin> next item: unit tests
15:46:52 <pc_m> Question, will there be an issue, if the cli client comes out, and then later a decision is made to blend it into the VPN APIs?
15:46:54 <tmorin> we already have a basic coverage, but I guess it will need to be adapted to the API changes too
15:47:35 <tmorin> pc_m: no magic
15:47:36 <vikram> pc_m: I feel yes
15:47:58 <matrohon> pc_m : it'll depend on the degree of integration we might have with the VPN project
15:48:11 <tmorin> pc_m: if the API are close enough, we should be able to make that compatible, but we aren't there yet
15:48:15 <tmorin> hard to tell now
15:48:45 <pc_m> concern about an API getting published, and then trying to change it.
15:49:05 <vikram> pc_m: Make sense. +1
15:49:34 <tmorin> of course, but the starting point is do not delay progress waiting for (a still hypothetical) convergence
15:50:46 <matrohon> it really depends on the VPNaaS V2 API
15:51:00 <tmorin> only 10 mins left, I'd rather use time to cover other items
15:51:15 <tmorin> unit test: API calls are covered but will need an update
15:51:17 <svinota> pc_m, tmorin , iirc we have API versioning, and I believe that's exactly why it is needed — not to wait for a perfect solution indefinitely
15:51:41 <tmorin> svinota: +1
15:51:56 <tmorin> unit test will also need to cover DB persistency, which they don't do yet
15:52:16 <svinota> tmorin, unit, not functional?
15:52:20 <john_a_joyce> but versioning is for extending the APIs not to try to converge two into one down the road
15:52:30 <pc_m> makes sense, just worried about introducing more pain down the road. Maybe unneccessarily?
15:52:34 <tmorin> I'm ok to take on this part (persistency unit test for db)
15:52:45 <tmorin> svinota: func tests, next item :)
15:52:53 <svinota> ok :)
15:53:13 <tmorin> #action tmorin investigate unit test coverage to db persistency
15:53:31 <tmorin> ok, let's talk about func tests now
15:53:50 <tmorin> i know svinota and mat where interested
15:53:51 <matrohon> Neutron has made significant improvment in this area in kilo
15:54:37 <matrohon> the use of nethelpers and the Fixture lib helps on creating what's neede for func test
15:55:14 <matrohon> I start to investigate on how to use the existing work to perform bagpipe func tests
15:55:37 <tmorin> maybe we can plan an IRC discuss later this week on this, with at leat you petr ?
15:55:46 <tmorin> you and matrohon I mean
15:55:52 <matrohon> i make sens for other drivers too
15:56:19 <matrohon> since it helps to create the corresponding neutron conf file etc....
15:57:12 <svinota> I agree, lets plan a meeting — this time is almost over
15:57:17 <tmorin> yes
15:57:19 <matrohon> ok
15:57:25 <tmorin> let keep other items for a future meeting
15:57:34 <vikram> ok
15:57:39 <tmorin> #topic driver status
15:57:45 <tmorin> any update here ?
15:59:00 <vikram> just we need to work on API convergance fastly to avoid rework
15:59:16 <tmorin> let's discuss dirvers next time
15:59:22 <tmorin> #topic next meetings
15:59:36 <john_a_joyce> vikram: yes - that is probably most important
15:59:41 <tmorin> any opinion on this slot ?
15:59:45 <tmorin> good for everyone ?
15:59:48 <matrohon> everybody's ok with this timeslot?
15:59:52 <vikram> i am fine
15:59:54 <timirnich> works fine for me
16:00:06 <john_a_joyce> fine for me
16:00:16 <tmorin> ok, then I'll register this slot for bgpvpn weekly meeting
16:00:26 <svinota> great.
16:00:33 <tmorin> we'll see down the road if we keep the periodicity
16:00:44 <john_a_joyce> thanks for driving us forward tmorin
16:00:58 <pc_m> I think OK for me.
16:01:01 <vikram> Good job Thomos
16:01:04 <tmorin> not alone though, but thanks
16:01:21 <tmorin> thank you all for your involvment
16:01:33 <tmorin> see you next week
16:01:37 <vikram> byey
16:01:39 <vikram> bye
16:01:42 <tmorin> and in a minute on vpnaas :)
16:01:53 <timirnich> thanks and bye
16:02:05 <vikram> :)
16:02:06 <tmorin> bye
16:02:20 <tmorin> #endmeeting