15:03:30 #startmeeting bgpvpn 15:03:31 Meeting started Tue Jan 3 15:03:30 2017 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:35 The meeting name has been set to 'bgpvpn' 15:04:02 hi everyone 15:04:29 hi bobmel doude eon`lewo matrohon pcarver timirnich 15:05:12 Hi tmorin 15:05:20 hi doude 15:06:11 nad happy new year by the way :) 15:06:12 and 15:07:06 thx happy new year to you to 15:08:26 thx ! 15:08:29 hi 15:09:18 hi matrohon ! 15:09:31 not sure anyone else will join us now 15:09:39 let's start... 15:09:54 not much happened during the last two weeks 15:09:56 in French ;) 15:10:00 :) 15:10:36 hi, joining late 15:10:52 the key things that happened is (a) that the CI is broken in many places, because of changes beyond our reach 15:10:56 hi pcarver ! 15:11:17 and ... (b) ongoing work in neutron-lib on the API 15:11:18 :) 15:11:52 I have a fix in progress for one of the CI issues ( https://review.openstack.org/#/c/416263/ ) 15:12:15 another one was recently solved (dep version issue on the Routes package) 15:12:49 and there is a last issue still unsolved: http://logs.openstack.org/93/414293/2/check/gate-networking-bgpvpn-dsvm-functional-ubuntu-xenial/0cdbd92/console.html#_2017-01-03_14_33_58_453894 15:13:37 the dulwich python package installation fails, because some C wrapper compilation fails to create a directory under /opt 15:13:46 this happens in the functional test job 15:14:03 tmorin: Would any of this affect devstack locally (i.e. not in OpenStack CI)? I tried to restack a devstack VM yesterday to validate API examples and it failed. 15:14:10 presumably because /opt/stack/... is created by root and then used by the stack user 15:14:21 Since I was technically still on vacation I didn't spend any time investigating why it failed. 15:15:29 pcarver: perhaps the broken dependency on the Routes package could impact a devstack 15:15:43 pcarver: but I don't believe the other issue would 15:16:04 ok, thanks 15:16:14 devstack failing is unfortunately something that routinely happens :-/ 15:17:11 #topic neutron-lib & BGPVPN API 15:17:20 pcarver: do you want to give us an update ? 15:17:50 tmorin: Nothing major. I updated for a little reviewer feedback. 15:18:09 I saw you respond as well. One of the comments was on project ID 15:18:18 yes 15:18:23 I'm unsure about this one 15:18:48 I'm pretty sure that I created the API examples directly through curl commands 15:18:53 need to revive a devstack to check if our API currently provides the project_id or only the tenant_id 15:19:19 So they should be accurate, but I'll double check once I get that VM restacked 15:20:01 I think the API ref is pretty well complete at this point 15:20:06 pcarver: yes 15:20:33 There still seems to be some back and forth on the API definition regarding the sub-resource map 15:20:55 pcarver: on project_id : providing it is certainly what the BGPVPN API /should be/ doing, so perhaps we can document that, and register a bug to track the fact that we don't do that yet 15:20:58 I think bgpvpn is compatible with project_id 15:21:12 My understanding is that there's neutron-lib code around manipulating the resource map but not around manipulating sub-resource map 15:21:18 this has been done directly in the neutron framework 15:21:29 pcarver, +1 15:21:45 perhaps we need to look into whether code we use for manipulating sub-resource maps should be made common to neutron-lib 15:22:30 I'm lost: who is talking about sub-resource map ? who is talking about project_id ? :) 15:22:56 pcarver: what code have you in mind which would manipulate the resource maps ? 15:23:01 sorry, I'm talking about project_id for resources 15:23:16 I didn't check what was happening for subressources 15:23:50 tmorin: I don't know since I haven't looked in to it, but what I gathered from review comments was that there is common (i.e. shared) code for manipulating resource maps 15:23:52 matrohon: ok, do you think the neutron framework would create "magically" for us the 'project_id' attribute in our resources, based on the presence of tenant_id perhaps ? 15:23:57 but not for sub-resource maps 15:24:11 which seems to be the heart of the objection to our use of sub-resource map 15:24:23 tmorin : AFAIR, it does 15:24:28 pcarver: there seems to be unit test code, but is there more ? 15:24:40 I don't know yet. 15:25:00 maybe it's just intent to write more vs already existing 15:25:09 I'll try to figure out more 15:25:49 but if the idea is that resource maps can be manipulated in a common way across extensions then it might make sense to do the same for sub-resource maps 15:27:30 presumably the whole point of putting sub-project API definitions into neutron-lib is to provide some sort of standardized mechanisms to the API of all neutron plus subprojects 15:28:44 I don't really grasp all the implementation details. I initially thought this was just a cut and paste change. 15:29:20 i.e., moving the API definition, I thought I was just copying code from networking-bgpvpn repo to neutron-lib repo and then deleting it from bgpvpn-repo 15:29:43 pcarver: what I don't get is what/where is the code reading these datastructures, apart from neutron-lib unit tests and networking-foo reading API foo 15:30:09 but that alone isn't really a valuable goal, so presumably the motivation behind it from the Neutron team's perspective is more than just cut and paste some code from one repo to another 15:30:14 pcarver: if these are the only two, then the only thing needing (I presume) is extending the tests to read the sub resource maps as well 15:30:40 pcarver: perhaps, but I haven't read anything about such a project yet 15:31:14 tmorin: I'll try to find more details. Perhaps some of it is still ideas in people's heads that haven't been fully fleshed out yet 15:32:11 yep 15:32:40 we'll have to ask neutron core on how we can move on 15:32:45 next topic ? 15:32:58 doude, any update on OSC CLI things ? 15:33:21 work is done 15:33:32 just need to write cli usage documentation 15:33:47 then I'll submit the review 15:34:12 I already submited a review on bgpvpn to revert the OSC patch 15:34:24 https://review.openstack.org/#/c/411205/2 15:34:34 actually failling due to CI issues 15:35:54 ok 15:36:31 let's wait for the python-neutronclient review to land before we removed the OSC extension from our repo 15:36:42 thanks! 15:36:51 yep many thanks doude 15:37:28 I though to set a dependency on python-neutronclient review on the bgpvpn revert patch 15:37:28 next topic ... ? 15:37:41 yes, good idea 15:40:21 #topic Atlanta PTG 15:41:01 the PTG is in 6 weeks 15:41:13 I don't know exactly what will happen there around neutron 15:41:25 I'm surprised to not see anything on the list 15:41:49 i haven't been able to find anything in #openstack-neutron IRC logs either 15:42:08 I'm still planning to go 15:42:21 tmorin, well, it's just big tables with a lot of beers, nothing to be proud of :) 15:42:31 :) 15:43:07 :) 15:43:39 tmorin, do you plan to go to the PTG? 15:43:57 yes 15:44:24 unless it is not confirmed that neutron folks would meet 15:44:31 I presume neutron would meet 15:44:49 that's for sure 15:44:55 but in the absence of anything being said/discussed/announced, I'm a bit unsure... 15:45:28 maybe armax can tell us more about it? 15:45:58 matrohon: the neutron PTG is scheduled as any other major openstack project 15:46:05 if this is what you’re asking 15:46:25 armax : we're looking for more info about the schedule 15:46:48 matrohon: as soon as I get informed on how to build an official one, I’ll disseminate 15:46:56 hi armax :) 15:46:58 armax, ack 15:47:17 matrohon: it’s probably a bit early, but I suspect details will become known soon enough 15:47:24 thanks for the answer, that's all we were needing 15:47:34 we plan to go from tue to fri 15:47:44 actually I think wed to fri 15:47:51 armax: for those having to plan for travel, it may actually be a bit late 15:47:54 as the first two days are for cross projects parties 15:47:58 erm, sessions 15:48:06 armax: mon-tue seems to be for cross project things 15:48:12 tmorin: right 15:48:28 armax: but neutron might have participation in cross projects things as well I guess... 15:48:41 tmorin: yes 15:49:05 good to know. A few days would be easier to justify than a week. I haven't yet written up a travel request and I know my manager is going to ask for details on why I would need to go. 15:49:09 armax: knowing that neutron cross project things would happen only on Tue and not Mon would allow some people to optimize their travel 15:49:20 +1 15:50:09 tmorin: agreed, let me find out more in the next few days 15:50:30 armax: thanks! 15:52:57 do we have other topics to discuss ? 15:55:38 ok... seems like we don't 15:56:01 thanks doude pcarver matrohon armax 15:56:06 #endmeeting