15:05:12 <tmorin> #startmeeting bgpvpn
15:05:13 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:05:16 <openstack> The meeting name has been set to 'bgpvpn'
15:05:24 <pcarver> hello
15:05:31 <bobmel> hi
15:05:38 <tmorin> hi bobmel, doude, eon`, lewo, pcarver, timirnich, matrohon ! :)
15:05:39 <tmorin> hi :)
15:05:46 <doude> hi
15:06:32 <matrohon> hi
15:07:38 <tmorin> so, what do we have on our agenda today ?...
15:08:01 <bobmel> stadium compliance I guess
15:08:08 <tmorin> yes, that's one item
15:08:18 <tmorin> another item is the scenario test you are working on bobmel
15:08:39 <bobmel> yes
15:08:48 <tmorin> matrohon: anything else you see ?
15:09:37 <matrohon> doude wanted to discuss a patch we introduce in newton
15:09:54 <doude> ha yes
15:10:08 <matrohon> the one to prevent attachment of network already attached to routers
15:10:31 <tmorin> ok, let's add this to our agenda as well
15:10:37 <tmorin> let's start ?
15:10:44 <tmorin> #topic neutron stadium compliance
15:10:59 <tmorin> the scorecard is frozen until pike cycle
15:11:16 <tmorin> so what matters is the summary in the WIP change for overall stadium health
15:11:27 <tmorin> https://review.openstack.org/#/c/389397/
15:11:40 <tmorin> we are doing ok
15:11:44 <tmorin> 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 <tmorin> the items we are still missing are:
15:12:29 <tmorin> scenario test --> this is in progress and the next item on our agenda
15:13:13 <tmorin> cli osc binding -> we now need to submit the client binding in python-neutronclient
15:13:31 <tmorin> doude, would you be fine pursuing your work on osc by doing that ?
15:14:10 <tmorin> and last thing is API ref documentation, the work is well in progress (https://review.openstack.org/#/c/390196/ by pcarver)
15:14:37 <doude> tmorin: yes I can
15:14:46 <tmorin> great !
15:15:09 <pcarver> 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 <tmorin> all this needs to be done, but it seems we will stay in the stadium
15:15:56 <tmorin> 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 <bobmel> good!
15:16:52 <tmorin> yes :)
15:17:29 <doude> great!
15:17:33 <tmorin> 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 <pcarver> tmorin: one topic we may still have to address is the API definition, particularly the sub-resource map
15:17:56 <tmorin> we've had breakage last week, and we hope next things will happen more smoothly
15:18:20 <tmorin> pcarver: what is the exact issue with the sub-resource map ?
15:18:35 <pcarver> 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 <tmorin> pcarver: is it the network_association_id being misrepresented as a body parameter instead of a path parameter ?
15:19:37 <pcarver> No, I'm looking at https://review.openstack.org/#/c/394244/18/neutron_lib/api/definitions/trunk.py in particular
15:20:00 <pcarver> The constants RESOURCE_NAME and COLLECTION_NAME vs TRUNK and TRUNKS
15:20:33 <pcarver> In bgpvpn.py I've got a bunch more constants
15:20:48 <tmorin> pcarver: it just means that your WIP would have to do something similar, right ?
15:20:51 <pcarver> I'm not sure whether to replace BGPVPN with RESOURCE_NAME and BGPVPNS with COLLECTION_NAME
15:21:15 <pcarver> If I do, then what do I do with the other constants, just leave them?
15:21:47 <pcarver> there is SUB_PORTS = 'sub_ports' in trunk.py, so it might be ok
15:21:50 <tmorin> for everyone to follow, pcarver is talking about https://review.openstack.org/#/c/395585/
15:22:19 <tmorin> and https://review.openstack.org/#/c/390196/
15:22:47 <pcarver> 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 <pcarver> 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 <tmorin> 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 <pcarver> it may be minor
15:26:06 <tmorin> pcarver: yes, from an helicopter view, I don't see anything problematic
15:26:09 <pcarver> one thing may be the use of an accessor for RESOURCE_ATTRIBUTE_MAP
15:26:34 <tmorin> yes, but this is easy, right ?
15:26:35 <pcarver> I agree, no major problems. Just minor tweaking to ensure consistency.
15:26:39 <tmorin> yep
15:27:10 <pcarver> 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 <pcarver> 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 <matrohon> lbass was using sub resources
15:29:35 <tmorin> 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 <matrohon> I was looking at their code while coding sub_resources
15:29:57 <tmorin> I don't know if lbaas already submitted an API definition in neutron-lib
15:30:10 <bobmel> perhaps ask what approach to take on the dev list
15:30:18 <pcarver> I haven't seen one for LBaaS yet
15:30:38 <bobmel> or in the next neutron drivers irc
15:30:54 <pcarver> bobmel: I can go ahead and ask
15:32:42 <tmorin> 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 <pcarver> 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 <tmorin> pcarver: +1
15:34:43 <tmorin> pcarver: I added a few other comments today btw
15:34:47 <tmorin> next item ?
15:35:36 <tmorin> #topic tempest scenario test
15:35:52 <tmorin> bobmel: do you want to give us an update ?
15:36:01 <bobmel> sure
15:36:36 <bobmel> https://review.openstack.org/#/c/396967
15:36:53 <bobmel> 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 <bobmel> Basically, create a neutron port for the host and wire it up.
15:37:06 <bobmel> It works on my server but not in gate-tempest-dsvm-networking-bgpvpn-bagpipe-ubuntu-xenial.
15:37:13 <bobmel> I have not figured out why.
15:37:31 <bobmel> 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 <tmorin> bobmel: I haven't found either what prevents the tempest host from accessing the VM
15:38:54 <tmorin> 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 <tmorin> bobmel: perhaps you could try with the cleanup commands commented out
15:39:26 <tmorin> bobmel: and if we don't succeed, fallback to the approach based on floating IPs
15:39:34 <bobmel> 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 <tmorin> bobmel: no
15:40:33 <tmorin> 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> tmorin: it's not a setup that I've played with though
15:41:38 <bobmel> 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 <tmorin> bobmel: both attach by port and attach by subnet should work
15:43:02 <bobmel> Ok
15:43:25 <tmorin> bagpipe dirver is listening to the ADD_ROUTER_INTERFACE event, that matrohon fixed so that it's triggered in both cases
15:44:08 <bobmel> So what I'll do is to update the patch so it uses a FIP.
15:45:13 <bobmel> 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 <bobmel> Any other suggestions/feedback?
15:47:13 <tmorin> nope
15:47:45 <tmorin> 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 <tmorin> adding some "ip route" loggin would be a way
15:48:20 <tmorin> skipping the cleanup so that worlddump exposes this information, would be another way
15:48:21 <bobmel> 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 <tmorin> that's fine !  :)
15:48:37 <tmorin> next topic ?
15:49:00 <tmorin> #topic discuss about preventing attachment of network already attached to routers
15:49:11 <tmorin> doude, what do you wanted to discuss ?
15:49:15 <bobmel> 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 <doude> I'm not sure bgpvpn service driver should take care of association constraints.
15:49:42 <doude> I'm not sure bgpvpn service driver should take care of association constraints.
15:49:46 <bobmel> But let's move on (these are details).
15:49:46 <doude> oops
15:49:53 <doude> I think that should be the responsability to SDN controller.
15:50:32 <doude> 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 <doude> That prevents to double checked it, one time on the service driver side and another one on the SDN controller
15:52:39 <tmorin> 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 <doude> 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 <doude> s/ceck/check
15:53:40 <doude> or if subnet attached to a router overlaps
15:53:48 <tmorin> doude: I don't have a strong feeling on this question to be honest
15:54:55 <doude> 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 <bobmel> These assoc contraints, are they driver dependent? Or are there some constraints that are common and some are not?
15:55:24 <doude> and checks like https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/plugin.py#L91 is costly
15:57:13 <doude> 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 <doude> s/event/even/
15:57:36 <tmorin> bobmel: this check we are discussing is not driver specific, but there may exists other backend specific constraints
15:58:04 <bobmel> tmorin, doude: thanks for the clarification
15:58:16 <doude> 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 <matrohon> actually we implemented it in the plugin because of our spec, that specifies this behavior
15:58:28 <matrohon> doude +1
15:58:54 <matrohon> so moving it under the resp of the will lead us to an update of the spec
16:00:15 <doude> 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 <doude> matrohon: +1 probably we need to discuss that spec constraints
16:00:47 <matrohon> doude : same for other sdn controller probably
16:00:52 <doude> yes
16:00:58 <tmorin> we have to wrap up
16:01:11 <tmorin> my conclusion to this: I'm open to revisiting where we enforce this constraint
16:01:21 <matrohon> same for me
16:01:26 <tmorin> ok!
16:01:29 <tmorin> thanks everyone!
16:01:34 <doude> ok
16:01:36 <tmorin> #endmeeting