15:04:44 <tmorin> #startmeeting bgpvpn
15:04:44 <openstack> Meeting started Tue Mar 15 15:04:44 2016 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:48 <openstack> The meeting name has been set to 'bgpvpn'
15:05:15 <tmorin> bgpvpn irc meeting now / hi doude, matrohon, pcarver_, timirnich
15:05:46 <matrohon> hi
15:07:30 <doude> hi
15:08:42 <tmorin> doude: good to see you ! :)
15:08:50 <tmorin> we're not that many, but let's start
15:08:56 <timirnich> hi folks - can I hijack the meeting for a second? We have OPNFV SDN VPN breakout at the hackfest in 2h from now - anyone interested in joining via IRC?
15:08:57 <doude> me to
15:09:34 <timirnich> just drop me a note
15:09:39 <tmorin> timirnich: thanks for the announce - I would have joined, but it is slightly too late for me
15:09:47 <tmorin> which channel ?
15:10:00 <timirnich> it would be #opnfv-sdnvpn
15:10:08 <tmorin> ok
15:10:18 <tmorin> what do we have to discuss
15:11:10 <matrohon> vthapar had a bug earlier tody
15:11:18 <tmorin> off the top of my head I have: bagpipe driver improvements, gate work, heat bug, RD/RT encoding issue
15:11:20 <tmorin> yes
15:11:23 <matrohon> I didn't see any report
15:11:33 <tmorin> no, he did not fill one yet
15:11:38 <tmorin> vthapar: ^^ ?
15:11:54 <vthapar> tmorin, matrohon, yeah.. didn't raise bug yet.
15:12:03 <tmorin> hi vthapar
15:12:17 <tmorin> do you plan to fill one ?
15:12:22 <vthapar> tmorin mentioned he was aware of it, so wasn't sure if there already was a bug or not.
15:12:27 <vthapar> will do
15:12:30 <tmorin> ok, thanks
15:12:55 <tmorin> yes, I was aware as in "once though we should track that but forgot about it the next second"  ;)
15:14:06 <vthapar> :) which reminds me of a similar topic of mine, but will get to it later.
15:14:30 <tmorin> #topic heat bug
15:14:51 <tmorin> there was a simple/dumb bug in one of my changes, which matrohon found
15:14:59 <tmorin> #link https://bugs.launchpad.net/bgpvpn/+bug/1557445
15:15:00 <openstack> Launchpad bug 1557445 in bgpvpn "heat fails creating a net-assoc" [Undecided,In progress] - Assigned to Mathieu Rohon (mathieu-rohon)
15:15:04 <tmorin> the fix is in already
15:15:26 <tmorin> which reminded us that having a better gate would be really nice
15:15:36 <tmorin> bringing us to the next topic:
15:15:39 <tmorin> #topic gate work
15:15:59 <tmorin> I did a few things last week as first step to improve our gate
15:16:26 <tmorin> first: make on gate jobs easily configurable without having to submit a change in the project-config repo
15:17:00 <tmorin> I hope it will be advanced soon
15:17:02 <tmorin> #link https://review.openstack.org/#/c/291103/
15:17:31 <tmorin> the other thing I did is work on networking-bagpipe so that the bgpvpn code in bagpipe-bgp (github) can be installed by the gate devstack jobs
15:17:59 <tmorin> we should have soon everything in place to run the complete bgpvpn+bagpipe combination in the gate
15:18:33 <tmorin> additionally, we will be able easily to enable tempest testing in the gate
15:18:50 <matrohon> great job tmorin
15:18:54 <tmorin> and able to easily add testing of our heat plugin as well, I think
15:19:29 <tmorin> as soon as 291103 is in, improving the jobs will be a matter of pushing a change to networking-bgpvpn
15:19:37 <tmorin> thanks matrohon
15:20:06 <tmorin> I haven't looked how easy it is to test a heat plugin in the gate
15:20:13 <tmorin> any comment ?
15:20:15 <tmorin> next topic ?
15:22:10 <tmorin> #topic bagpipe driver
15:22:38 <tmorin> we merged last week the change which allows to have bgpvpn be loaded as a clean extension to the OVS agent
15:23:15 <tmorin> this is much much better than the hack we had before (standalone agent, inheriting from OVSNeutronAgent code, copy-pasting main() code, etc.)
15:23:39 <tmorin> and it solves a "lost flows on restart" that we had
15:23:48 <tmorin> comments ?
15:24:49 <matrohon> I had some issues with this change
15:25:28 <matrohon> it seems to constantly cloning the bagpipe-bgp project
15:25:43 <matrohon> even if we made some changes in bagpipe-bgp
15:26:13 <matrohon> I mean when we run stack.sh
15:26:54 <tmorin> you're not talking about the "ovs l2 agent" change right ?
15:26:58 <tmorin> but previous topic ?
15:27:10 <matrohon> oh sorry, yep :)
15:28:04 <tmorin> it is very much possible that even with RECLONE=yes, the git submodule sync/update overwrite the changes made
15:28:15 <tmorin> sorry, even with RECLONE=no
15:28:25 <tmorin> the logic can I guess be improved to avoid that
15:29:08 <tmorin> that would have to be done around here: https://github.com/openstack/networking-bagpipe/blob/master/devstack/override-defaults#L5
15:29:36 <matrohon> another issue is that the bagpipe-bgp devstack plugin doesn't get some global parameters such as $HOST_IP, when specified in local.conf
15:29:58 <matrohon> hence : https://github.com/Orange-OpenSource/bagpipe-bgp/pull/5#issuecomment-196712533
15:31:40 <matrohon> apart from those little issue, it's much cleaner than having to specify 3 plugins in local.conf
15:32:22 <tmorin> ok, let's see how we can improve that
15:32:32 <tmorin> I've commented on your github pull request
15:32:46 <tmorin> next topic ?
15:33:02 <tmorin> vthapar: didn't you had something you wanted to discuss ?
15:33:22 <vthapar> tmorin, yep.
15:33:33 <tmorin> ODL related ?
15:33:40 <vthapar> yes,
15:33:45 * tmorin trying to find what to set the topic to :)
15:33:52 <tmorin> #topic ODL driver
15:33:56 <tmorin> go ahead :)
15:34:20 <vthapar> remember last time when we were workin gon ODL driver, we had a point on having option for *_precommit so drivers can reject unsupported use cases before they get commited to db?
15:35:03 <vthapar> there are certain bgpvpn use cases that aren't supported in ODL yet and there is still no mechanism for ODL to talk back to openstack yet [in plans for newton].
15:35:30 <vthapar> so, it would be good to have ceratin validations in precommit so driver can reject instead of throwing error in post_commit which requires DB revert
15:35:42 <matrohon> vthapar, what use case you don't support?
15:36:25 <vthapar> I don't have list on me right now, but multiple RDs is one I remember off top of my head...
15:36:38 <vthapar> limit on no. of networks that can be associated with a bgpvpn etc.
15:36:38 <tmorin> I guess no driver supports E-VPN yet for instance
15:36:55 <vthapar> yeah that too.
15:37:18 <vthapar> we have checks in ODL code, but that today results in de-sync between what is on openstack side vs ODL.
15:37:25 <matrohon> if no driver support a feature, we can remove it from the API
15:37:36 <matrohon> vthapar, ok
15:37:52 <tmorin> hey, let's not forget about plans to implement E-VPN !   :)
15:38:47 <vthapar> we have plans for E-VPN in ODL though, most likely in next release.
15:38:55 <matrohon> vthapar, so you want to move checks done in odl to the bgpvpn driver
15:39:16 <tmorin> there is a relevant to have whether we prefer to avoid issues related to discrepencies between backends, or support all possible discrepencies and add pre-commit to manage them as nicely as possible
15:39:50 <vthapar> yes, till ODL Driver folks in networking-odl figure out how to manage this... even then, not doing a revert will be preferred.
15:41:07 <matrohon> vthapar, you might still need to be able to revert if ODL NB API gets called by any other consumer than bgpvpn
15:41:10 <tmorin> there is one case where I think pre-commit would make sense: drivers not supporting the control of the RD -- in the discussion a few months back, we concluded this was acceptable (for a driver not to support it), but we don't yet have something clean for pre-commit
15:42:03 <tmorin> not supporting all VPN types is also something that all driver may not support at the same time
15:42:08 <vthapar> matrohon, agree. revert is unavoidable in some cases but scenarios where we know backend will not support should be handled in precommit.
15:42:18 <tmorin> having clean pre-commit would be nice for this as well
15:43:00 <matrohon> vthapar, do you think you can manage those checks without having to call ODL NB API?
15:43:20 <tmorin> doude: do you plan to implement VPN type l2 (E-VPN) in the contrail driver ?
15:43:47 <matrohon> because, as in ML2, pre_commit calls are done suring a sql session, so calling external components is prohibited
15:43:55 <vthapar> matrohon, yes. RD as list, l2 as type etc are some simple ones that can be handled in driver itself. same for associating multiple networks to bgpvpn.
15:44:11 <vthapar> any checks that need ODL will be kept in postcommit.
15:44:36 <matrohon> vthapar, I think we can agree then
15:45:00 <vthapar> matrohon, cool :)
15:45:04 <matrohon> vthapar, do you need it for mitaka?
15:45:29 <vthapar> matrohon, answer to such questions is always 'would prefer to' :)
15:45:58 <tmorin> vthapar: can you fill a request-for-enhancement bug for that as well ?
15:46:14 <vthapar> tmorin, will do.
15:46:15 <matrohon> vthapar, next answer is "do you have time to code it"? :)
15:46:24 <matrohon> s/answer/question
15:46:30 <tmorin> yes, this is what I was going to ask as well
15:46:46 <tmorin> we can certainly help review/polish to that it lands for mitaka
15:46:48 <vthapar> matrohon, I can find time, it is my openstack/python skills I doubt.
15:47:05 <vthapar> hopefully I can pull some of my pythn expert colleagues for it.
15:47:49 <vthapar> is there any deadline by when I need to get it ready?
15:47:49 <matrohon> vthapar, let's start with a RFE bug
15:48:24 <matrohon> vthapar, well I'm not sure we have a clear roadmap :)
15:48:25 <vthapar> bug should request for precommit support in plugin? or make it specific to ODL Driver?
15:48:46 <matrohon> vthapar, in plugin, so that any driver can use it
15:48:52 <vthapar> matrohon, anything from core-neutron side timelines that impacts us?
15:49:15 <matrohon> vthapar, we are a release-independant project for now
15:49:42 <vthapar> matrohon, oh yeah, had forgotten about that:)
15:49:56 <matrohon> vthapar, but of course we'd to release ASAP, not too long after mitaka
15:50:11 <tmorin> the only thing is that this time, the idea is to branch a stable/mitaka and release at a time close to neutron
15:50:16 <vthapar> matrohon, that is why I asked for some tentative date by when to get this ready
15:50:41 <tmorin> to avoid the problematic window where we're out of sync, which is a mess to manage for test jobs
15:51:00 <matrohon> tmorin, vthapar : pre_commit stuff migt not be so hard to implement I feel like we can target it for the mitaka release
15:51:08 <matrohon> tmorin +1
15:51:09 <tmorin> +1
15:51:47 <vthapar> cool :) this week am caught up in upcoming ODL SR1 activities, will probaby start sometime next week.
15:51:57 * vthapar goes off to lure a colleague
15:52:21 <matrohon> vthapar, great!
15:52:32 <tmorin> cool
15:52:44 <tmorin> one thing to look at is where to implement it
15:52:59 <vthapar> matrohon, tmorin, btw, how do I raise an RFE? same as raising a bug, right?
15:53:17 <tmorin> the service plugin does not do db persistency, so having it call "pre_commit" does not sound clean -- maybe it's just a name issue
15:53:20 <matrohon> vthapar, you just have to add the rfe tag to you byug
15:53:29 <vthapar> martohon, thanks.
15:53:39 <tmorin> we could also implement it in the DB driver superclass, common to all drivers using Neutron db
15:53:58 <tmorin> in that case, pre_commit will no apply to for instance contrail
15:54:03 <tmorin> but I think this is ok
15:54:24 <matrohon> yep pre_commit will never work with contril
15:54:31 <tmorin> but it's not needed either
15:54:56 <tmorin> they can already to the appropriate check before calling contrail (no persistency made before check is done)
15:55:05 <tmorin> the contrail code actually already does this
15:56:32 <tmorin> so the plan would I think be (a) add pre_commit methods to the db driver interface, and (b) have create_foo in the db driver call pre_commit before doing db calls
15:56:53 <tmorin> and we also need the same for update_foo calls
15:58:03 <tmorin> the code to add will be in BGPVPNDriverDBMixin
15:58:50 * tmorin talking alone ?
15:58:59 <tmorin> we're nearly out of time
15:59:11 <tmorin> matrohon, vthapar: ^^ anything else ?
15:59:25 <matrohon> nop
15:59:33 <vthapar> I've raised the bugs and done.
15:59:52 <vthapar> https://bugs.launchpad.net/bgpvpn/+bug/1557608
15:59:52 <openstack> Launchpad bug 1557608 in bgpvpn "plugin should support/provide *precommit methods for drivers" [Undecided,New]
16:00:39 <vthapar> https://bugs.launchpad.net/bgpvpn/+bug/1557588
16:00:39 <openstack> Launchpad bug 1557588 in bgpvpn "using ip-addr:asn format for router_distinguisher throws Invalid input error" [Medium,Confirmed]
16:01:02 <tmorin> vthapar: many thanks !
16:01:08 <tmorin> we have to leave the floor
16:01:10 <tmorin> thanks guys
16:01:15 <tmorin> #endmeeting