15:02:07 <tmorin> #startmeeting bgpvpn
15:02:07 <openstack> Meeting started Tue Mar 22 15:02:07 2016 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:10 <openstack> The meeting name has been set to 'bgpvpn'
15:02:10 <tmorin> hi everyone
15:02:12 <matrohon> hi
15:02:18 <vthapar> hello
15:02:32 <tmorin> hi doude, matrohon, pcarver, timirnich, vthapar
15:02:49 <timirnich> Hi tmoring, hi all
15:03:04 <tmorin> here is what I have in mind for the agenda:
15:03:12 <tmorin> discuss gate job progress
15:03:21 <tmorin> discuss tempest test progress
15:03:33 <tmorin> discuss mitaka release
15:03:36 <pcarver> hi
15:03:58 <tmorin> discuss precommit hooks for drivers
15:05:48 <vthapar> I need to step away for couple minutes, brb.
15:06:19 <tmorin> #topic mitaka release
15:07:05 <tmorin> we've looked at what is the right thing to do for mitaka release
15:07:21 <tmorin> we don't want to run into the same issues we had for liberty
15:08:01 <tmorin> issues that were due to the fact that there was a long time window where our master branch was intended to be run against neutron stable/liberty branch
15:08:44 <tmorin> which brings me to the conclusion: we tend to think we should branch-out and release a mitaka branch very closely after neutron forks for mitaka
15:09:09 <tmorin> for your information, neutron has already forked a stable/mitaka branch and neutron's master is already targetting newton
15:09:37 <tmorin> so the plan is to close very early our mitaka branch
15:10:06 <tmorin> many things that we have in mind but we haven't started will have to wait for openstack neutron
15:10:20 <tmorin> opinions?
15:10:32 <tmorin> doude, pcarver, timirnich, vthapar ^^^ ?
15:10:45 <tmorin> matrohon: agree with my summary ?
15:10:51 <timirnich> I think that is a very reasonable approach
15:10:54 <matrohon> tmorin : totally!
15:11:10 <vthapar> +1
15:11:26 <matrohon> the only thing that we'd like to merge for mitaka is the precommit feature
15:11:34 <matrohon> asked by ODL
15:11:37 <pcarver> it sounds ok, but I honestly don't really have a good understanding of the issues
15:12:25 <matrohon> but this highly depends on the ability of ODL folks to patch their driver accodingly, and fatsly
15:12:45 <tmorin> one implication is the following::
15:12:53 <vthapar> matrohon, what date are we targeting?
15:13:04 <tmorin> there is no process for doing intermediate releases introducing siginficant feature
15:13:28 <tmorin> except if we abuse the "stable/*" expectations
15:13:50 <tmorin> so the implication is that significant new features would posssibly only be available with Openstack Newton
15:14:12 <timirnich> question for clarification: is your assumption that current master basically contains what we intend to release for Mitaka?
15:14:33 <tmorin> except if the world around us buys the idea that noone yet has "stable"-grade expectation against our stable/* branches
15:15:12 <tmorin> timirnich: yes, roughly, except the precommit change currently merged but which we may extend to associations
15:15:49 <matrohon> vthapar, as tmorin said, neutron already forked it stable branch, so ASAP !
15:15:50 <tmorin> we might create a backport/liberty branch additionally to stable/liberty in which we could backport the work on new feature done in our master-newton branch
15:16:14 <tmorin> vthapar: yes, ASAP,   I'd say first week of April
15:16:36 <timirnich> ok thanks. Let me add one facet: OPNFV SDN VPN will deliver scenario fixes into Brahmaputra.3.0 since we missed the first stable release by a few days
15:16:42 <matrohon> vthapar, does it sound reasonnable to you ?
15:17:34 <vthapar> tmorin, matrohon, good enough. I'm targeting to finish by next Tuesday. we have a long weekend in India this week else would've done it by this weekend.
15:17:37 <timirnich> On the other hand (thinking aloud) we are consuming stable/liberty AFAIK
15:17:44 <timirnich> so should not make a difference
15:18:10 <tmorin> timirnich: no, indeed, for B* that does not change anything
15:18:30 <tmorin> timirnich: but it will might make a difference for Colorado
15:18:43 <matrohon> vthapar, fine let's target next tuesday for our mitaka release
15:18:46 <tmorin> tmorin: everyone: Colorado is codename for next OPNFV release
15:19:10 <timirnich> tmorin: yes. I expect Colorado to be based on Mitaka at least for some installers
15:19:28 <timirnich> So we need a stable Mitaka branch early on.
15:19:45 <timirnich> does not need to be release though
15:19:48 <tmorin> matrohon: there is one bagpipe driver bug that I'd like to fix, but since it's a bug, the mitaka release does not have to wait for it, it can be backported to mitaka branch slightly after
15:19:58 <matrohon> actually, as tmorin explained, there is no big deal, until neutron folks introduce some changes in neutron, that makes our gate failing :(
15:22:18 <tmorin> timirnich: the implication then is that new things (e.g. static routes, Horizon UI, ...) will not be in Mitaka and thus not in Colorado
15:22:36 <tmorin> I think it's good
15:23:13 <tmorin> much better than saying "lets wait for feature X, Y Z" and pay the high price of working on delayed branches
15:23:41 <timirnich> Is there a wiki page showing the expected delta between stable/liberty and stable/mitaka based on the assumption of branching soon?
15:23:54 <tmorin> for net-bgpvpn ?
15:24:01 <tmorin> no wiki page
15:24:22 <timirnich> Would be good if I had such reference to point to from Colorado planning perspective
15:29:16 <matrohon> let's move on?
15:31:04 <matrohon> tmorin seems offline
15:31:36 <matrohon> #topic : gate changes
15:31:59 <matrohon> we slightly modified our gate strategy
15:32:36 <matrohon> now, we can control the behavior of our gate jobs through rc files in the bgpvpn repo
15:32:50 <matrohon> https://review.openstack.org/#/c/291103/
15:33:43 <matrohon> I just tried to enable tempest test with bgpvpn, but it's failing
15:33:49 <matrohon> https://review.openstack.org/#/c/295849/
15:33:59 <matrohon> I need to investigate
15:35:15 <matrohon> we will now be able to modify those jobs without having to modify project-config repo
15:36:01 <matrohon> pcarver, timirnich, vthapar : I am alone on the meeting?
15:36:26 <pcarver> matrohon: sorry, I'm in two meetings simultaneously
15:36:30 <timirnich> nope sorry two meetings in parallel :-)
15:36:41 <vthapar> matrohon, am around, multitasking.
15:37:02 <matrohon> pcarver, timirnich : ok, I just noticed that tmorin was out, but I was wondering if the issue was on my side
15:37:13 <matrohon> vthapar, np
15:37:25 <tmorin> I'm back
15:37:26 <tmorin> sorry
15:38:21 <tmorin> so we think these gate changes will allow us to improve our jobs much faster now
15:38:36 <tmorin> without depending on infra folks to review all our changes
15:39:03 <tmorin> next topic ?
15:39:54 <tmorin> #topic tempest tests
15:39:58 <tmorin> not much to day
15:39:59 <tmorin> say
15:40:12 <tmorin> there were two updates by enikher
15:40:26 <tmorin> one to update how we import tempest
15:40:31 <tmorin> and an additional tempest test
15:40:58 <tmorin> once our gate job will be more interesting, we'll have a strong motivation to enrigh the tempest tests
15:41:00 <tmorin> comments ?
15:41:21 <timirnich> Niko said he'll occasionally add more tests whenever he gets bored with other stuff ;-)
15:41:33 <matrohon> I'd love to have a scenario test
15:42:07 <timirnich> matrohon can u elaborate a bit pls?
15:42:51 <matrohon> timirnich, a test that create a bgpvpn, attach a net and delete the bgpvpn would be a good start
15:43:29 <matrohon> timirnich, we should be able to run this test on every driver
15:43:53 <tmorin> enikher was saying it shouldn't be hard to have a test to verify connectivity between two VMs on different nets, via a BGPVPN
15:44:04 <timirnich> ok understand. Reason why I was asking is that I'd like to get some sync with Temptest and OPNFV Yardstick test scopes in place
15:44:09 <tmorin> matrohon: this assume we can instantiate every SDN controller in the gate
15:44:34 <matrohon> those test could be run outside the gate
15:44:35 <tmorin> matrohon: maybe not so easy for contrail, don't know about ODL
15:45:26 <timirnich> probably not trivial for ODL either
15:45:41 <tmorin> matrohon: yes, these tempest test will also typically be run in an OPNFV context, additionally to what Yardstick will do
15:46:00 <tmorin> timirnich: yes, the question of what to do in Yardstick is interesting
15:46:05 <matrohon> timirnich, it would make sense t colaborate with what going on at OPNFV to have relevant tests directly inside the bgpvpn repo
15:46:28 <tmorin> timirnich: for the things that we would like to run in Openstack gate, we'll certainly prefer tempest
15:46:45 <tmorin> timirnich: we need to find the other things for which Yardstick will make more sense
15:46:54 <timirnich> yes let's engineer test scope so that we get most bang for buck. COmplicated setups are easier in OPNFV
15:47:10 <tmorin> timirnich: maybe the test involving  performance questions
15:47:39 <tmorin> timirnich: or test involving a router stack to be instantiated in a VM
15:47:57 <timirnich> tmorin yes that definitely but using the OPNFV deployment tools to set up more complicated SUT configs is another thing to consider
15:48:20 <timirnich> since we'd be reinventing the wheel if we do those in Tempest
15:48:31 <timirnich> unless it's low hanging fruit
15:49:08 <tmorin> timirnich: yes, tempest's will focus on (a) driver-independent tests and (b) test that involve a driver which is easily run in the gate (today, bagpipe only)
15:49:46 <timirnich> would be good if we had a way to test the driver without the actual backend - is that possible?
15:50:02 <tmorin> timirnich: for these two kind of setups, there isn't much to do in the direction of "more complicated SUT configs"
15:50:15 <timirnich> like in ODL case checking the REST calls that get pushed down to ODL NBI
15:50:16 <tmorin> timirnich: good question
15:50:50 <tmorin> timirnich: ODL driver could I guess be designed to say act like if there was a real ODL behind it, and say "yes sir" to everything
15:51:10 <tmorin> tmorin: but we wouldn't test anything interesting that what the dummy driver tests, I think
15:51:40 <tmorin> timirnich: yes, checking the calls might make sense
15:51:45 <timirnich> I was more thinking of checking if the driver translates the calls correctly to what is expected on the controller northbound
15:51:51 <tmorin> timirnich: but the unit tests pretty much already do that
15:51:54 <tmorin> timirnich: yes
15:52:10 <timirnich> ok if we have that in unit tests we're fine
15:53:02 <tmorin> timirnich: this is not undoable, you would have to run a small rest server in the API, mocking the basic stuff and checking the rest calls from the driver
15:53:07 <tmorin> yes
15:53:21 <tmorin> next topic ?
15:53:26 <timirnich> ok
15:53:29 <tmorin> #topic precommit hooks
15:53:41 <tmorin> we've just merged the precommit hooks for bgpvpn create/update
15:54:01 <tmorin> next steps:  support same hooks for association create/update
15:54:14 <tmorin> and then use these hooks in drivers
15:54:22 <tmorin> ODL is the first asking for that
15:54:51 <tmorin> but the bagpipe driver will also use it (for RDs, and type l2 BGPVPNs)
15:54:56 <tmorin> vthapar: anything to add ?
15:55:14 <tmorin> vthapar, you explained that you needed the precommit hooks for associations as well
15:55:16 <vthapar> tmorin, precommits for associations.
15:55:26 <matrohon> I'll add it asap
15:55:27 <tmorin> to prevent multiple associations for a network or router
15:55:30 <vthapar> tmorin, yes
15:55:37 <tmorin> that makes sense
15:56:18 <vthapar> I've started working on driver changes for update/create. will push for review once resolve some dev setup issues.
15:56:29 <matrohon> vthapar, great
15:56:34 <tmorin> +1
15:58:36 <tmorin> anything else to discuss ?
15:58:48 <tmorin> #topic open (very short) discussion
15:58:53 <tmorin> we only have 2 mins left
16:00:18 <tmorin> ok, looks like we're done
16:00:22 <tmorin> thanks everyone
16:00:25 <matrohon> thanks
16:00:33 <tmorin> that was a very useful meeting
16:00:59 <tmorin> by everyone
16:01:02 <tmorin> #endmeeting