15:03:13 #startmeeting bgpvpn 15:03:14 Meeting started Tue Nov 10 15:03:13 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:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:19 The meeting name has been set to 'bgpvpn' 15:03:39 hi janscheurich, matrohon, pcarver, Prem, timirnich_ 15:03:50 hi tmorin 15:03:55 Hi all 15:04:01 hi tim 15:04:14 Hi all 15:04:16 Hi Jan, how's it going? 15:04:38 tim: not too bad 15:05:15 tmorin: thanks for the fast answer. I will push the code soon 15:05:32 hi enikher 15:05:49 it will have to be pushed to a backport branch, not created yet 15:05:53 will cover that today 15:05:59 #topic announcements 15:06:08 what do we have to announce ? 15:06:19 I have seen a stable/kilo branch already... 15:06:27 is that not the right one? 15:07:19 no, will explain later in a 'backports' topic 15:07:25 ok 15:07:38 we discussed, solved a few minor issues in the last week 15:07:54 ie. some polish before considering a first release 15:08:18 doude has been working on the contrail driver 15:08:28 now mostly finished I would say 15:09:22 we had also a bunch of things to change to follow the rename of the networking-bagpipe project (was networking-bagpipe-l2 before) 15:10:07 odl driver location. Is that clarified? 15:10:20 not really 15:10:32 the decision early oct was to keep it in networking_odl 15:10:58 tim: can you discuss this with Prem et al? 15:11:08 in tokyo the idea of having all drivers in networking-bgpvpn for a first release was looking nice 15:11:21 +1 15:11:31 but we need to confirm, either way, where to put it before a release 15:11:40 I got the info that it was a request by Neutron cores to have all ODL drivers in netrowking-odl 15:11:53 a release saying "there is also an ODL driver, which is " would work as well 15:11:58 Yes. that's ok for long-term 15:12:07 This was the decision of the networking-odl team, we should leave this decision to that team 15:12:24 The point is, if we want a different solution, we'll have to discuss with the cores. 15:12:45 We would need a release of that project on top of bgpvpn 15:13:08 Yes. Do we know their release plans? 15:13:20 as far as I can see it is only one file and the config service_provider or? 15:14:01 I mean it would be rather easy to cpoy the file into the bgpvpn repo... change the config 15:14:21 and when the odl repo has it in place we will delete it from bgpvpn repo again... 15:14:56 enikher, yep, we left the door open to the odl team, to come back to the bgpvpn repo, which would be pretty easy 15:15:35 only as a temporary solution 15:15:39 +1 15:16:08 Tim: Do you meet Prem et al in San Francisco? 15:16:18 the main issue for them, will be to maintain the driver, since we won't handle chenges at the API layer as we can do if their driver were in our tree 15:16:23 the code looked ok when I reviewed, if someone submits the same driver file in networking-bgpvpn, we will review it 15:17:03 matrohon: this is why having it in networking-bgpvpn initially, until we stabililize the plugin/driver interface, looks like a better idea 15:17:24 tmorin : I totally agree 15:17:38 we take the action to re-discuss with the ODL team 15:17:42 tmorin : but it's not our decision 15:18:05 Aim at decision until next week 15:18:12 yes, please re-discuss 15:18:16 the earlier the btter 15:18:19 better 15:18:23 OK 15:18:53 #action : janscheurich to discuss with ODL team to move their driver back to bgpvpn repo 15:19:28 what's next ? 15:19:30 #topic : resources vs subresources 15:19:35 go ahead 15:19:41 matrohon: moving it back? I would go for push it to both repos 15:19:55 #undo 15:20:05 can you undo twice ? 15:20:07 not sure 15:20:27 enikher, you want to maintain two version of the driver? 15:21:04 matrohon: no but at the moment it is nowhere 15:21:17 it is not yet merged to any repo. 15:21:44 anikher : ok 15:21:47 when it is there in an OS release then we could exclude it from bgpvpn repo 15:21:47 #action : janscheurich to discuss with ODL team to initially submit their driver in bgpvpn repo until plugin/driver api stabilizes 15:22:00 +1 15:22:00 what about this alternate formulation ?? 15:22:08 +1 15:22:21 #topic : resources vs subresources 15:22:37 as you know net-assoc are now managed as subresources 15:22:47 of bgpvpns resources 15:23:23 I hardly see benefits of subres over resources 15:23:41 it complexifies URIs 15:24:04 it is less tested, (tmorin fix a related bug in the client) 15:25:14 and now that those subres are about to manage their tenant_id, I don't know why we should keep on having subresource, instead of resource 15:25:25 But it's more logical. An association can only be part of one BGPVPN 15:25:58 yep, this is enforced at the db layer 15:25:58 yes, this is the rationale for having chosen sub-resources 15:26:11 Why do assocs manage their own tenant_id? 15:26:25 matrohon: you mean that even with resources, it can be enforced by the db layer 15:26:48 I wanted to discuss about benefits of subresources with dougwig or blogan, who introduced this concept for lbaas 15:26:54 tmorin +1 15:27:21 janscheurich: the neutron api policy framework requires having a tenant_id for some corner cases, so we added tenant_ids to associations 15:27:50 https://bugs.launchpad.net/bgpvpn/+bug/1512789 15:27:50 Launchpad bug 1512789 in bgpvpn "a tenant cannot list/show/delete its net-assocs resources" [High,In progress] - Assigned to Mathieu Rohon (mathieu-rohon) 15:28:04 janscheurich: we could have added tenant_id in the API layer only, but we also added it in the db layer, to make the code less surprising for people who will read it later 15:28:25 matrohon: but it must be identical to the tenant_id of its parent bgpvpn, or? 15:28:30 yes 15:28:38 the plugin enforces that 15:29:08 we don't have a use-case for having an association tenant_id being different than the tenant_id of the BGPVPN 15:30:23 having subreources leads to this kind of incoherences : https://bugs.launchpad.net/bgpvpn/+bug/1513087 15:30:23 Launchpad bug 1513087 in bgpvpn "get_network_association inconsistency" [Medium,In progress] - Assigned to Thomas Morin (tmmorin-orange) 15:31:08 It's not a big deal, but I want to consider this move before having our first release 15:31:48 I would have a tendency to keep things as is, not seeing a huge gain in simplification (the issue we found were solved in a satisfying way) 15:32:00 but we think it may be interested to hear from lbaas folks 15:32:00 +1 15:32:12 #action : matrohon to evaluate the benefit/drawbacks of moving net-assoc to a dedicated resource 15:32:16 they moved some things from resources to sub-resources 15:32:22 matrohon: +1 15:32:40 next topic ? 15:32:43 tmorin, they also moves things from sub-resources to resources! 15:32:53 I'd like to understand why 15:32:55 yes 15:33:15 branch management? 15:33:22 #topic backports and branches 15:33:36 a few things as a reminder: 15:33:58 we have recently understood that stable/* branch are very special 15:34:16 in these branches, only neutron stable maitainers can merge gerrit changes 15:34:39 this reflects a contract between the Openstack and the outside world about what "stable" mean 15:34:46 only bugfixes 15:35:28 this obviously does not match what we need to do to work toward releases, in particular for backports 15:35:35 this problem is not only for us 15:35:45 see the email today from networking-calico folks 15:36:06 "Understanding stable/branch process for Neutron subprojects" 15:36:40 the current plan is to work on backports in their own branch 15:36:52 The stable/kilo branch should be created after the release or? 15:36:52 but to not name these branch "stable/x" 15:37:20 enikher: not we first need a branch to work on a backport, we don't want to overwrite our current liberty-compatible code 15:37:45 so we asked the creation of a backport/kilo and a backport/juno branch 15:38:03 #link https://bugs.launchpad.net/bgpvpn/+bug/1513870 15:38:03 Launchpad bug 1513870 in bgpvpn " networking-bgpvpn backport branches" [High,Confirmed] 15:38:41 +1 15:39:07 we will see, when we want to do a release of these backports, how we can fit in the proces of "stable/*" deliveries 15:39:10 that will be later 15:39:28 in the meantime there will be a place to work on backports 15:39:52 this should work fine, except one thing: continuous integration 15:40:19 the CI jobs currently expect branch X of a project to be testing against branch X of other Openstack projects 15:40:52 we already have a tweak in place so that networking-bgpvpn is tested both against master and stable/liberty 15:41:28 we will have to add additional tweaks so that backport/kilo be tested against stable/kilo of other openstack projects 15:41:32 same for juno 15:41:47 not enthousiasting, but doable 15:42:15 the discussion in the community is in progress 15:42:21 we'll see how it goes 15:44:42 no comments ? :) 15:44:52 Regarding the scope of the Kilo backport 15:45:21 We think think we would leave the door open to more than just PoCs and trials 15:45:44 So the DB migration at upgrade from Kilo to Liberty may become an issue 15:46:16 janscheurich: ok, this means that the work should be done to allow this migration 15:46:46 yes. I assume it will mean impact on the liberty branch 15:46:55 some neutron projects were shipping their own db-migration tool, and now used the neutron modularized one 15:47:02 so I think this is very doable 15:47:36 enikher will look into this 15:47:45 janscheurich: maybe, maybe not -- if it does, we need to know it soon 15:47:47 good 15:48:10 I hope you can point him to some examples? 15:48:28 I will check the other repos,, 15:48:56 neutron-lbaas and neutron-vpnaas 15:48:58 from memory 15:49:14 at least one of the two 15:50:18 finding the right solution is likely to require some playing 15:51:02 next topic ? 15:51:08 #topic drivers 15:51:15 any update on drivers ? 15:51:54 work is in progress on Nuage side, been in touch with them to help bootstrap the work 15:52:12 sorry I'm confused, that's not driver related, 15:52:22 that's about Router attachement 15:52:58 #topic open discussion 15:53:04 anything else ? 15:53:51 I'm still waiting for company approval for the port_assoc and static_route API enhancements 15:54:17 request have been sent but no feedback so far 15:54:27 :-( 15:54:58 :-( 15:55:39 you mean for submitting a gerrit change for the API additions 15:55:42 hope it can happen quickly 15:55:53 so do I 15:56:25 I can probably start a change with the clarifications we discussed 15:57:38 sure, this will be welcom 15:57:39 e 15:59:37 ok, it seems like we are done 15:59:42 thanks everyone 15:59:47 #endmeeting