15:05:12 #startmeeting bgpvpn 15:05:13 Meeting started Tue Nov 29 15:05:12 2016 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:05:16 The meeting name has been set to 'bgpvpn' 15:05:24 hello 15:05:31 hi 15:05:38 hi bobmel, doude, eon`, lewo, pcarver, timirnich, matrohon ! :) 15:05:39 hi :) 15:05:46 hi 15:06:32 hi 15:07:38 so, what do we have on our agenda today ?... 15:08:01 stadium compliance I guess 15:08:08 yes, that's one item 15:08:18 another item is the scenario test you are working on bobmel 15:08:39 yes 15:08:48 matrohon: anything else you see ? 15:09:37 doude wanted to discuss a patch we introduce in newton 15:09:54 ha yes 15:10:08 the one to prevent attachment of network already attached to routers 15:10:31 ok, let's add this to our agenda as well 15:10:37 let's start ? 15:10:44 #topic neutron stadium compliance 15:10:59 the scorecard is frozen until pike cycle 15:11:16 so what matters is the summary in the WIP change for overall stadium health 15:11:27 https://review.openstack.org/#/c/389397/ 15:11:40 we are doing ok 15:11:44 html render: http://docs-draft.openstack.org/97/389397/12/check/gate-neutron-specs-docs-ubuntu-xenial/23199f8//doc/build/html/specs/stadium/ocata.html 15:12:16 the items we are still missing are: 15:12:29 scenario test --> this is in progress and the next item on our agenda 15:13:13 cli osc binding -> we now need to submit the client binding in python-neutronclient 15:13:31 doude, would you be fine pursuing your work on osc by doing that ? 15:14:10 and last thing is API ref documentation, the work is well in progress (https://review.openstack.org/#/c/390196/ by pcarver) 15:14:37 tmorin: yes I can 15:14:46 great ! 15:15:09 I saw that there were a some review comments. I'll update the commit soon. I took a bit of vacation over the US holiday. 15:15:18 all this needs to be done, but it seems we will stay in the stadium 15:15:56 https://review.openstack.org/#/c/389397/ has a "*" besides project that will have to re-apply for pike, and bgpvpn is not in the list 15:16:16 good! 15:16:52 yes :) 15:17:29 great! 15:17:33 part of the work to stay in the stadium in the next months will consist in following, and even better, contributing to things moving from neutron to neutron-lib 15:17:37 tmorin: one topic we may still have to address is the API definition, particularly the sub-resource map 15:17:56 we've had breakage last week, and we hope next things will happen more smoothly 15:18:20 pcarver: what is the exact issue with the sub-resource map ? 15:18:35 You might want to take a look at https://review.openstack.org/#/c/394244 It doesn't affect us directly, but I think the idea is to acheive consistency 15:18:43 pcarver: is it the network_association_id being misrepresented as a body parameter instead of a path parameter ? 15:19:37 No, I'm looking at https://review.openstack.org/#/c/394244/18/neutron_lib/api/definitions/trunk.py in particular 15:20:00 The constants RESOURCE_NAME and COLLECTION_NAME vs TRUNK and TRUNKS 15:20:33 In bgpvpn.py I've got a bunch more constants 15:20:48 pcarver: it just means that your WIP would have to do something similar, right ? 15:20:51 I'm not sure whether to replace BGPVPN with RESOURCE_NAME and BGPVPNS with COLLECTION_NAME 15:21:15 If I do, then what do I do with the other constants, just leave them? 15:21:47 there is SUB_PORTS = 'sub_ports' in trunk.py, so it might be ok 15:21:50 for everyone to follow, pcarver is talking about https://review.openstack.org/#/c/395585/ 15:22:19 and https://review.openstack.org/#/c/390196/ 15:22:47 but I need to give it some more thought to make sure I fully understand where the standard for API definitions is going so that we're consistent with other extensions 15:23:48 There are also some test cases added in 394244 that I think are expected to apply to all API definitions, so I'll need to make sure that we pass those 15:24:21 pcarver: I don't see yet what would have to change in https://review.openstack.org/#/c/395585 if the constants in https://review.openstack.org/#/c/390196/9/neutron_lib/api/definitions/bgpvpn.py are modified to follow what is done in https://review.openstack.org/#/c/394244/18/neutron_lib/api/definitions/trunk.py 15:25:46 it may be minor 15:26:06 pcarver: yes, from an helicopter view, I don't see anything problematic 15:26:09 one thing may be the use of an accessor for RESOURCE_ATTRIBUTE_MAP 15:26:34 yes, but this is easy, right ? 15:26:35 I agree, no major problems. Just minor tweaking to ensure consistency. 15:26:39 yep 15:27:10 But I don't have an example to follow for SUB_RESOURCE_ATTRIBUTE_MAP so I'm not sure if we're consistent or not 15:28:35 and if we're the first using SUB_RESOURCE_ATTRIBUTE_MAP I may need tests as in https://review.openstack.org/#/c/394244/18/neutron_lib/tests/unit/api/test_attributes.py 15:29:14 lbass was using sub resources 15:29:35 pcarver: if an accessor method is used for resource_attribute_map, then it will make sense to define an accessor for the sub_resource_map as well 15:29:46 I was looking at their code while coding sub_resources 15:29:57 I don't know if lbaas already submitted an API definition in neutron-lib 15:30:10 perhaps ask what approach to take on the dev list 15:30:18 I haven't seen one for LBaaS yet 15:30:38 or in the next neutron drivers irc 15:30:54 bobmel: I can go ahead and ask 15:32:42 asking will not hurt, and in parallel, pcarver, you can add an accessor for the resource map and an accessor for the sub resource map 15:34:07 tmorin: I added the accessor for RESOURCE_ATTRIBUTE_MAP but haven't pushed a new patch set. I'll add one for SUB_RESOURCE_ATTRIBUTE_MAP and address all the other review comments then push it all at once 15:34:23 pcarver: +1 15:34:43 pcarver: I added a few other comments today btw 15:34:47 next item ? 15:35:36 #topic tempest scenario test 15:35:52 bobmel: do you want to give us an update ? 15:36:01 sure 15:36:36 https://review.openstack.org/#/c/396967 15:36:53 I’ve tried to do the scenario test without the use of fip (and router) for VM access (i.e., the pinging to verify connectivity) 15:36:53 Basically, create a neutron port for the host and wire it up. 15:37:06 It works on my server but not in gate-tempest-dsvm-networking-bgpvpn-bagpipe-ubuntu-xenial. 15:37:13 I have not figured out why. 15:37:31 Since this has taken some time my thinking now is perhaps that I should just do as your original suggestion and use fip. 15:38:09 bobmel: I haven't found either what prevents the tempest host from accessing the VM 15:38:54 bobmel: the issue is that your special port/route setup is cleaned up, so we can't use worlddump to see how the devstack host tries to route toward the VM (http://logs.openstack.org/67/396967/17/check/gate-tempest-dsvm-networking-bgpvpn-bagpipe-ubuntu-xenial/ec5ebd7/logs/worlddump-2016-11-29-151751.txt.gz) 15:39:11 bobmel: perhaps you could try with the cleanup commands commented out 15:39:26 bobmel: and if we don't succeed, fallback to the approach based on floating IPs 15:39:34 So if I do the FIP approach, do I need to have a separate network that the router and one of the VMs connect to? 15:39:45 bobmel: no 15:40:33 bobmel: since newton release, it now should work to have a network associated to a BGPVPN and the network having a router interface 15:40:57 tmorin: it's not a setup that I've played with though 15:41:38 Ok, do I need to create the router port separately and tell neutron to attach the router into that or is it enough to just attach by subnet? 15:42:52 bobmel: both attach by port and attach by subnet should work 15:43:02 Ok 15:43:25 bagpipe dirver is listening to the ADD_ROUTER_INTERFACE event, that matrohon fixed so that it's triggered in both cases 15:44:08 So what I'll do is to update the patch so it uses a FIP. 15:45:13 I'll also continue to look into why the "devstack plugged into neutron network" approach does not work. I'm interested to understand why. 15:46:03 Any other suggestions/feedback? 15:47:13 nope 15:47:45 to understand why your current approach does not work in the gate, I think we need to know, after your special setup, how would the devstack host route to 10.100.x.y 15:48:00 adding some "ip route" loggin would be a way 15:48:20 skipping the cleanup so that worlddump exposes this information, would be another way 15:48:21 You may see several revisions from me as my local runs do not seem to be identical to the ones in gate-tempest-dsvm-networking-bgpvpn-bagpipe-ubuntu-xenial 15:48:30 that's fine ! :) 15:48:37 next topic ? 15:49:00 #topic discuss about preventing attachment of network already attached to routers 15:49:11 doude, what do you wanted to discuss ? 15:49:15 Well, the devstack host gets an interface on 10.100.x.y with the setup I do so it is directly connected 15:49:31 I'm not sure bgpvpn service driver should take care of association constraints. 15:49:42 I'm not sure bgpvpn service driver should take care of association constraints. 15:49:46 But let's move on (these are details). 15:49:46 oops 15:49:53 I think that should be the responsability to SDN controller. 15:50:32 Perhaps not for all cases, that check could/should stay in service driver for drivers which use the neutron DB as that constraints could also be a db constraints but for db less drivers, the service driver must not check it. 15:51:05 That prevents to double checked it, one time on the service driver side and another one on the SDN controller 15:52:39 doude: but for something that is an API consistency question, it would be surprising, in the case of a no-DB driver, to not have any check on neutron side, wouldn't it ? 15:53:08 no, for exemple, for the neutron core driver if you don't use the neutron db, neutron does not ceck if network's subnet overlaps 15:53:23 s/ceck/check 15:53:40 or if subnet attached to a router overlaps 15:53:48 doude: I don't have a strong feeling on this question to be honest 15:54:55 I don't have much concern to check it from service driver but I think it's useless because in anycase the check must also be done on the controller side 15:55:05 These assoc contraints, are they driver dependent? Or are there some constraints that are common and some are not? 15:55:24 and checks like https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/plugin.py#L91 is costly 15:57:13 I think that constraints can be different between driver. Perhaps, a controller can be more precise and check if rt of a bgpvpn does not averlaps with other and permit router association with a network event if they have bgpvpn associated 15:57:29 s/event/even/ 15:57:36 bobmel: this check we are discussing is not driver specific, but there may exists other backend specific constraints 15:58:04 tmorin, doude: thanks for the clarification 15:58:16 but the bgpvpn api spec clearly forbidden it for the moment http://docs.openstack.org/developer/networking-bgpvpn/api.html#association-constraints 15:58:20 actually we implemented it in the plugin because of our spec, that specifies this behavior 15:58:28 doude +1 15:58:54 so moving it under the resp of the will lead us to an update of the spec 16:00:15 in the contrail case, the controller must also make that check as it also exposes that bgpvpn resource on its api and could be use by another third party than networking-bgpvpn 16:00:43 matrohon: +1 probably we need to discuss that spec constraints 16:00:47 doude : same for other sdn controller probably 16:00:52 yes 16:00:58 we have to wrap up 16:01:11 my conclusion to this: I'm open to revisiting where we enforce this constraint 16:01:21 same for me 16:01:26 ok! 16:01:29 thanks everyone! 16:01:34 ok 16:01:36 #endmeeting