15:07:20 <tmorin> #startmeeting bgpvpn
15:07:20 <openstack> Meeting started Tue Jan 31 15:07:20 2017 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:07:24 <openstack> The meeting name has been set to 'bgpvpn'
15:07:24 <tmorin> hi everyone
15:07:30 <pcarver> hi
15:07:33 <bobmel> hi
15:07:39 <tmorin> hi pcarver, hi bobmel
15:07:47 <tmorin> hi doude (around ?)
15:08:00 <doude> Hi tmorin
15:08:29 <tmorin> not sure who else is around today...
15:09:24 <tmorin> let's see what we can put on the agenda
15:09:39 <tmorin> a) OSC integration (doude)
15:09:54 <tmorin> b) API doc and definition in neutron-lib (pcarver)
15:10:25 <tmorin> c) allow to filter per-network in the API (doude)
15:11:10 <tmorin> d) bagpipe driver cleanups (tmorin)
15:11:36 <tmorin> anything else ?
15:12:13 <doude> waht about API constraint validation?
15:12:54 <doude> the topic was opened by Mathieu but I'm not sure if we have some work in progress
15:13:22 * doude looking at meeting logs
15:13:49 <tmorin> doude: no we haven't anything in progress
15:14:01 <tmorin> e) API constraint validation
15:14:08 <tmorin> #topic OSC integration
15:14:19 <tmorin> doude, want to give a status ?
15:15:35 <doude> actually two +1 on the review, one from you tmorin
15:15:55 <tmorin> yes, I guess we simply need core reviewers time
15:16:29 <doude> yes I take care of all reviews last week
15:16:34 <doude> waiting now
15:16:44 <tmorin> ihrachys ? kevinbenton ? would you have time for https://review.openstack.org/#/c/416321/  (stadium implosion, BGPVPN OSC client merge into python-neutronclient)
15:19:00 <tmorin> amotoki: ^^ ?
15:19:06 <tmorin> well, we'll see...
15:19:08 <tmorin> next topic ?
15:19:30 <amotoki> tmorin: ack
15:19:51 <tmorin> amotoki: thanks :) !
15:20:05 <tmorin> #topic API doc and definition in neutron-lib
15:20:10 <tmorin> pcarver: want to give an update ?
15:20:17 <pcarver> I'm still chipping away at both the ref and the def
15:20:36 <pcarver> Am I the only one who has constant problems with Devstack?
15:21:16 <pcarver> It seems that every time I turn around stack.sh is bombing out again and I spend more time figuring out why it won't stack than I do working on the thing I wanted to work on.
15:21:21 <tmorin> pcarver: well, devstack is sometimes cumbersome, but I don't have too much trouble with it these days, or gotten used to its quirks
15:21:46 <tmorin> feel feel to ping me, I may be able to help
15:22:09 <pcarver> Anyway, there were a bunch of review comments questioning which http return codes are valid
15:22:40 <pcarver> I haven't been able to get Devstack working to try to see which ones I can generate and which I can't.
15:22:55 <pcarver> So I addressed all other review comments, but not the ones about HTTP status codes.
15:23:06 <pcarver> That's for the API reference.
15:23:30 <pcarver> For the API definition I'm working on writing a test case for the RT/RD validator per boden's comment
15:23:35 <tmorin> pcarver: another approach would be looking at the exceptions that the networking-bgpvpn code raises, and see to which HTTP code they map
15:23:58 <pcarver> tmorin: If you can point me in the right direction I will. I don't know where to look.
15:24:13 <tmorin> pcarver: I've see that the test_resource_map and  test_subresource_map  tests are failing (http://logs.openstack.org/82/413182/9/check/gate-neutron-lib-python27-ubuntu-xenial/4757845/testr_results.html.gz )
15:24:44 <pcarver> I think that's probably due to all the rebasing. They were passing at one point.
15:25:20 <pcarver> I'll dig through and figure out what the cause is.
15:25:37 <tmorin> there are two different things
15:26:15 <tmorin> one is that the generic unit test (test_resource_map) is trying to understand type:route_target_list but failing
15:26:49 <tmorin> because it's registered in bgpvpn module, not in the generic list
15:27:34 <tmorin> so whether we find a workaround for this validator to be known, or we'll have to define the validator in the generic list, like you were doing in a previous PS
15:27:59 <tmorin> I didn't look at the other issue ('router_id' not in ('admin_state_up', 'id', 'description', 'name', 'network_id', ...)
15:28:02 <tmorin> but it is distinct
15:28:42 <pcarver> yes, for the second one I need to figure out where the list is being built. router_id IS in the tuple extension_attributes defined in test_bgpvpn.py
15:28:59 <tmorin> i'll have a look after the meeting
15:29:02 <pcarver> but maybe the test needs it somewhere else
15:29:17 <tmorin> maybe
15:29:35 <pcarver> and I know it was passing at one point, but there have been multiple rebases since then
15:29:53 <pcarver> and I don't know git very well, the rebases have been dicey
15:30:07 <tmorin> for the unit test asked by boden, I guess we need to translate the unit tests for RT/RD that are currently in networking_bgpvpn, into tests for this validator
15:30:26 <pcarver> I've had to abort and retry a few of the rebases multiple times before it would go through
15:30:42 <pcarver> so maybe something changed out from under me
15:31:10 <tmorin> the test we have on RT/RD are currently in networking_bgpvpn.tests.unit.extensions.test_bgpvpn.BgpvpnExtensionTestCase._test_valid_field
15:31:32 <tmorin> they are not unit tests for the validator though, but "overall tests" for all parameters
15:31:34 <pcarver> oh, that should help. I was starting to write one from scratch. I'll take a look.
15:32:20 <pcarver> I'm looking at the validators in https://github.com/openstack/neutron-lib/blob/master/neutron_lib/tests/unit/api/test_validators.py and trying to write something similar in test_bgpvpn.py
15:32:21 <tmorin> writing a unit test should be as simple as: taking the values, feeding them into the validator, checking that it complain or not
15:32:55 <tmorin> pcarver: sounds good
15:33:27 <pcarver> the test itself isn't what I need to figure out, it's how the test is called in the whole neutron-lib framework
15:34:25 <pcarver> I'm assuming I can write functions of the form 'def test_something(self):' inside of the class 'class BgpvpnDefinitionTestCase(base.DefinitionBaseTestCase):' in test_bgpvpn.py
15:34:48 <tmorin> yes, exactly
15:35:06 <tmorin> then the unit tests framework will autodiscover it
15:35:13 <tmorin> you don't need anything else
15:35:36 <pcarver> but I'm not sure if I call validators.add_validator from there or if that's only for "standard" validators
15:36:11 <pcarver> If we keep the rtrd one as a private method in the bgpvpn API def, I'm not sure if that affects how to call it
15:37:28 <tmorin> you can import the bgpvpn module from the test module, and then directly call the validator function
15:38:04 <pcarver> that's what I figured. It's already imported
15:38:28 <pcarver> I just wasn't sure if the add_validators part is important
15:38:47 <tmorin> I don't think it should
15:38:56 <tmorin> try the lazy/simple way first :)
15:39:03 <pcarver> ok
15:39:27 <tmorin> anything to discuss on the API documentation change ?
15:39:33 <tmorin> apart from HTTP codes ?
15:39:52 <pcarver> hmm, looking at the last patch set I pushed for the API def it looks like the rebase went wrong
15:40:05 <pcarver> the validator is completely gone and I didn't delete it
15:40:26 <tmorin> hmm
15:40:47 <tmorin> the good thing is that its not a more complex issue to solve :)
15:41:22 <pcarver> I'll have to roll it back and try again. Git was giving me all sorts of merge conflict messages and suggestions for commands to run. I guess I ran the wrong ones.
15:41:55 <tmorin> pcarver: yes, this kind of thing can be messy, anyone gets one wrong sometimes :)
15:42:03 <tmorin> next topic maybe ?
15:42:09 <pcarver> sure
15:42:18 <tmorin> #topic allow to filter per-network in the API
15:42:32 <tmorin> this is about https://review.openstack.org/#/c/426309/
15:42:38 <tmorin> proposed by doude
15:42:50 <tmorin> doude: I agree this is useful
15:43:22 <tmorin> I was wondering whether we should do something more flexible (like what exists for tags)
15:43:23 <doude> yes I see your comments and I'm not sure to undertand it
15:43:29 <tmorin> but I feel this would be overkill
15:43:34 <doude> yes
15:43:49 <tmorin> I need to review the code
15:43:54 <doude> actually API permits to provide a list of value for filter key
15:44:02 <tmorin> if you can add a "implements blueprint api-find-bgpvpn-for-net" that would be nice
15:44:10 <tmorin> we had tracked this limitations for a loong time
15:44:46 <doude> I mean in interface driver, the filter method param dict can contain a list of value to filter
15:45:39 <doude> I did not check how that could be implemented for db based drivers but the patch I proposed do the job for non db based drivers (=contrail)
15:45:58 <tmorin> yes, but how that applies to an attribute that is also a list could be different things:  it could be "all the values in the filter should be in the attribute" or "at least one of the values ..."  etc.
15:47:52 <doude> yes my proposed patch is limited to "all the values in the filter should be in the attribute"
15:48:51 <tmorin> doude: we need to have something that is consistant with the syntax used for tags= ... filter
15:49:13 <doude> why?
15:50:40 <tmorin> well, just to have consistant APIs across neutron modules for filtering on list attribute
15:51:52 <tmorin> I've just read http://docs.openstack.org/mitaka/networking-guide/ops-resource-tags.html again
15:51:59 <tmorin> both definitions are consistant
15:52:43 <tmorin> if we want later to have a "at least one of the network should be associated ..." then we'll introduce network-any= filter
15:52:47 <tmorin> this is ok
15:52:52 <doude> but tag is a specific neutron extension
15:52:55 <doude> ok
15:53:32 <tmorin> I don't know if there are other places which provide filters for list attributes
15:54:23 <tmorin> we should provide API unit test and support for this filter for db-based drivers
15:54:34 <tmorin> doude, would you be ok to look at this also ?
15:56:05 <doude> for db-based driver?
15:57:46 <tmorin> anything you can help on :)
15:58:10 <tmorin> but I guess the db-based driver support will make it easy to implement an API test
15:58:30 <doude> I'll try and if I'm lost you'll be the first person who know it ;)
15:58:37 <tmorin> ok :)
15:58:41 <tmorin> we're out of time
15:58:48 <tmorin> #topic bagpipe driver cleanup
15:58:57 <tmorin> this was about https://review.openstack.org/#/c/425933/
15:59:05 <tmorin> but there isn't much to say
15:59:12 <tmorin> it depends on a neutron change
15:59:25 <tmorin> #topic API constraint validation
15:59:36 <tmorin> -> I guess it will be for next week :-(
15:59:47 <tmorin> #topic wrap up
15:59:47 <doude> ok
15:59:57 <tmorin> feel free to discuss in the bug
16:00:17 <tmorin> I think the key issue is that the solution on how to solve that is not easy at all :-(
16:00:23 <tmorin> bye everyone
16:00:36 <tmorin> rendez-vous next week :)
16:00:40 <tmorin> #endmeeting