15:04:31 #startmeeting bgpvpn 15:04:32 Meeting started Tue Feb 23 15:04:31 2016 UTC and is due to finish in 60 minutes. The chair is matrohon. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:35 The meeting name has been set to 'bgpvpn' 15:05:04 waitin few minutes to let people join 15:06:20 hi everyone 15:06:32 hello 15:06:39 hi doude, enikher, matrohon, timirnich, pcarver 15:06:44 hi tmorin 15:07:12 what is on the agenda today ? 15:07:48 off the top of my head: heat, tempest in the CI, bagpipe driver agent evolution 15:07:51 not much : any annoucement anyone? 15:08:36 we can mention the ongoing work by michael chapman on APEX packaging 15:09:34 let's talk about heat ? 15:09:44 yep, a rpm from redhat for net-bgpvpn 15:09:48 tmorin 15:09:52 tmorin fine 15:09:59 #topic heat 15:10:12 :-) 15:10:16 the status is that enikher's patch is ready 15:10:22 enikher : I've slightly modified your patch 15:10:26 thank you very much again for this contribution 15:10:41 we'll try to test it ASAP and, very likely, merge it 15:10:55 matrohon, I plan to test it and merge it asap 15:11:25 I think I'll change the doc too to mention that one need the admin right to launch the HOT file mentionned 15:11:35 ok thank you very much. Sorry for not been more respensive the last days 15:12:05 matrohon: yes that is a good idea 15:12:05 enikher, can you confirm my previous statement? 15:12:12 enikher, ok fine 15:12:45 let's move on 15:12:50 matrohon: may be to mention, only setting up the bgpvpn resource need admin rights 15:13:00 matrohon: the assoc do not need that 15:13:07 enikher, agreed 15:13:14 I'll do that 15:13:21 ok thanks very much 15:13:40 I am very buisy with the opnfv release so I don't have time sorry 15:13:53 enikher, np, I'll handle it 15:13:55 but did the change in the config file worked actually? 15:14:15 what was the problem there? 15:14:19 enikher, there was a missig param in the devstack plugin 15:14:56 https://review.openstack.org/#/c/280214/9..10/devstack/plugin.sh 15:15:33 the DEFAULT was needed to specify the section in the heat.conf file 15:15:59 at least that what my config needed 15:16:32 mhhh I think the real problem was config to conf or? 15:16:46 it will always take the default section 15:16:55 but the enviroment var changed 15:17:12 As said I tested on kilo the last time 15:17:15 sorry for that 15:17:28 enikher, actually I don't remember what was the real issue between the two 15:17:55 :-) 15:18:07 #topic CI 15:18:08 but it is working now that is good 15:18:23 we just have to have that in mind when backporting to liberty,kilo,juno 15:19:02 now that we have a heat plugin and a tempest plugin (thanks to enikher :) we will activate them in the gate 15:19:23 it is very good to progress that : +1 15:19:24 I think we wil first modify the experimental jobs 15:19:50 and then move those jobs to the check queue 15:20:09 it they are stable enough 15:20:11 I am not sure how much time I have to work on the jobs, but you will receive some tempest cases from me soon 15:20:24 I have the will to add e2e test cases 15:20:31 lets see how achievable that is 15:20:43 matrohon: +1 15:20:45 enikher, great! it would be very nice! 15:21:08 #link https://review.openstack.org/#/c/258522/ 15:21:25 this is a start already, but I was not able to continue that... 15:22:27 enikher, thanks I'll look at it! 15:22:41 you can continue or remove it and start with a new job 15:22:46 as you like :-0) 15:23:00 enikher, ok I'll see 15:23:28 having a end to end coverage would need multinode devstack tests 15:23:59 two devstack that peers which each others 15:24:28 yes, that is something we cannot do I think 15:25:02 but we can show that bgpvpn is working inside one node in devstack 15:25:12 another option would be to use the looking glass API of bagpipe to check that the route is correctly announced with bgp 15:25:40 mhhh, I would not like to make it backend specific 15:26:01 enikher, how would you show that in a backend agnostic way? 15:26:02 The real e2e test would be done in opnfv deployments 15:26:06 one thing that will still miss to put an e2e test case in the gate is having all bagpipe components deployable in the gate 15:26:36 tmorin, you're talking about ovs 2.4? 15:26:44 in opnfv bagpipe is as well not jet enabled. 15:26:49 that would also be needed 15:26:59 :-) 15:27:00 but I'm thinking about bagpipe-bgp first 15:27:01 networking-bagpipe need bagpipe-bgp 15:27:06 yes a lot of work to be done 15:27:37 tmorin, oh of course! we need bagpipe-bgp in pypi :) 15:27:43 and bagpipe-bgp is still on github and my understanding is that "git clone" in DSVM CI jobs is restricted to openstack repos 15:27:45 ok, sorry for bringing e2e in the picture, I meand just on one or 2 hosts 15:28:00 my plan has been to put bagpipe-bgp inside networking-bagpipe 15:28:04 but not for opnfv :-) 15:28:09 tmorin, +1 15:28:13 there are other good reasons to do this 15:28:30 but it only move the problem, let me explain 15:29:00 bagpipe initially came with its own fork of exabgp (and it still is the case in the master branch) 15:29:16 bagpipe-bgp has an "use_upstream_exabgp" branch also 15:29:37 this is the branch that we now focus on, and it does not have this fork 15:29:51 but it depends on a non-yet-pypi-released version of exabgp 15:29:59 and thus depends on github's repo exabgp 15:30:24 tmorin, are you aware of exabgp's roadmap? 15:30:46 I'm currently trying to find time to see if using git submodules could help workaround the impossibility to clone a non-openstack git repo 15:31:31 matrohon: plans to release what bagpipe-bgp needs were still unclear last time I checked, it seems to depend on the time tmangin can find on a best effort basis 15:31:40 but sometimes he finds the time 15:31:43 I need to ask him again 15:32:04 ok 15:32:41 #topic opnfv 15:33:02 we just talked about opnfv, what are the news from the sdnvpn project? 15:33:20 we are pushing hard to get last fixes into the BE release 15:33:36 bgpvpn with odl is included but guggy at the moment 15:34:01 enikher, I understood that you were planning to use bagpipe? It's not accurate anymore? 15:34:19 "guggy" ? is it something worse than buggy ? :-D 15:34:27 :)) 15:34:35 one sec 15:35:10 tmorin: yes it is more then buggy... 15:35:11 :-D 15:35:23 :) 15:35:27 bagpipe is still on the agenda 15:35:39 but we have to get odl first running 15:35:47 cause there are already issues with that 15:36:02 it would be very nice to show 2 backends 15:36:16 enikher, +1 15:36:32 lets see if that happens at some time :-) 15:36:38 doude, enikher, well contrail is also an option 15:36:59 nobody from contrail is acive on sdnvpn? 15:37:37 I don't know. I think there is as well contrail, but I was not in concat with them. 15:37:53 do you think that would be easier to make happen 15:38:31 enikher, I don't know, doude is the one who can tell I think 15:39:05 doude: are you there? 15:40:03 enikher, I didn't get in touch with him since a while, I think he's very buzzy currently! 15:40:14 :-) 15:40:16 ok 15:40:18 let's move on 15:40:27 #topic bagpipe 15:40:57 this was to talk about ovs agent ongoing modifications 15:41:50 #link : https://review.openstack.org/#/c/281358/ 15:41:56 tmorin, the floor is yours 15:42:41 ok 15:42:55 the neutron-side patch is landing 15:43:03 I'm finishing the bgpvpn/bagpipe patch 15:43:15 things look ok 15:43:42 there are good chances to have it for mitaka? 15:43:45 we should soon be able to run the same openvswitch agent binary with "extensions=bagpipe_bgpvpn" in the agent config 15:43:48 yes 15:43:59 tmorin, great! 15:44:21 #link https://review.openstack.org/#/c/267591/ 15:44:43 the neutron change already has ihrachys's +2 blessing 15:45:07 the corresponding devref has good progress as well 15:46:00 tmorin, you mean the spec file? 15:46:05 yes 15:46:10 #link https://review.openstack.org/#/c/263819/ 15:46:26 spec is written by ihrachys 15:47:02 ok 15:47:22 I wanted to talk a little bit about news from neutron stadium 15:47:32 #topic stadium 15:47:44 this should be fun 15:48:25 good topic 15:48:31 there has been a thread initiated by armax that is saying that the neutron team can't vouch for every stadium project anymore 15:48:48 there is a corresponding proposal in gerrit as well: 15:48:53 a corresponding review is ongoing 15:49:41 tmorin, do you have the link? 15:49:42 #link https://review.openstack.org/275888 15:49:48 yes :) 15:50:25 the change consist in adding a criteria that the team of any stadium project should have a good overlap with the Neutron team 15:50:30 it just merged! 15:50:48 The question seems to be whether it matters at all if a particular project is "part of Neutron" or not 15:51:01 pcarver +1 15:51:09 it's a matter of communication 15:51:19 If it's not "part of Neutron" it can still be part of OpenStack and it can still do whatever functions it does 15:51:35 pcarver: I agree 15:51:55 pcarver, I don't know what is going to happen for bgpvpn yet 15:51:55 but the interface with Neutron will matter as well 15:52:17 the most likely is that networking-bgpvpn won't be in the neutron stadium 15:52:21 but what I am struggling with is does it make sense to have networking APIs provided by projects that are not "part of Neutron" 15:52:40 I don't think we have any contributor that "qualifies" 15:52:48 pcarver: yes... 15:52:55 if we get out from the stadium, do we have to candidate to the big tent 15:52:57 I guess if everyone agrees that NEutron only provides a subset of OpenStack networking APIs then it's fine 15:53:08 practically speaking, I don't have found any drawback yet to this future situation 15:53:40 tmorin, well the big tent might not accpt us 15:53:44 but if people think that only networking APIs that are "part of Neutron" are "official" OpenStack networking APIs then that's a problem 15:54:01 matrohon: the stadium is in the big tent, we don't have to candidate to the big tent, we are aleady in it 15:54:02 pcarver, +1 15:54:06 at least, this is my understanding 15:54:32 tmorin, yes but if you are not part of the stadium anymore wher do you land? 15:54:32 pcarver: that would be a problem, and the future will tell if we have to face such a question or not 15:55:00 matrohon: like any other big tent project I think: standalone project with its own PTL etc. 15:55:46 tmorin, actually it seems TC struggle at accepting more big tent projects 15:55:57 It makes sense to me that BagPipe can be "not part of Neutron", after all, Open vSwitch isn't part of Neutron either. But the BGPVPN API should definitely be an "official" OpenStack API and it seems odd for a networking API to not be part of Neutron 15:56:35 pcarver : totally agree 15:57:05 pcarver: I don't disagree with you, but then should networking-ovn or networking-odl be "part of Neutron" ? 15:57:27 pcarver: the new criteria is not based on technical consideration, but people overlap 15:57:36 tmorin: I think they should not, if other's like Midonet are not 15:58:10 I think the overlap criteria begs the question 15:58:26 pcarver: yes, I haven't looked closely at how team overlap, but OVN under this criteria might possibly be fall in the Neutron stadium 15:58:28 If something is a part of Neutron then the developers are Neutron developers 15:59:03 So for the overlap criteria to apply you have to first define what is and is not Neutron in order to determine which developer count towards determining overlap 15:59:06 pcarver: but, no necessarily "Neutron developers" as in "contributing to the core of Neutron" 15:59:33 tmorin: yes, but that first requires making the cut on what's core and what isn't core 15:59:54 pcarver: maybe all this is not an interesting question to focus on, I'm not particularly worried, we can choose to wait and see what problem arise eventually 15:59:58 Why for example is ML2 VXLAN driver core but MPLS BGPVPN driver "not core"? 16:00:16 history mostly I think 16:00:16 pcarver: the question is possibly hard to cut for new APIs 16:00:56 pcarver: for ML2 this is easy for historical and technical reasons, L2 has always been the core networking need for IaaS 16:01:13 wrapping up now? 16:01:17 ok, we have to move 16:01:20 yes, we have to 16:01:22 thanks everyone 16:01:24 #endmeeting