15:03:30 <tmorin> #startmeeting bgpvpn
15:03:31 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:35 <openstack> The meeting name has been set to 'bgpvpn'
15:04:02 <tmorin> hi everyone
15:04:29 <tmorin> hi bobmel doude eon`lewo matrohon pcarver timirnich
15:05:12 <doude> Hi tmorin
15:05:20 <tmorin> hi doude
15:06:11 <tmorin> nad happy new year by the way :)
15:06:12 <tmorin> and
15:07:06 <doude> thx happy new year to you to
15:08:26 <tmorin> thx !
15:08:29 <matrohon> hi
15:09:18 <tmorin> hi matrohon !
15:09:31 <tmorin> not sure anyone else will join us now
15:09:39 <tmorin> let's start...
15:09:54 <tmorin> not much happened during the last two weeks
15:09:56 <doude> in French ;)
15:10:00 <tmorin> :)
15:10:36 <pcarver> hi, joining late
15:10:52 <tmorin> the key things that happened is (a) that the CI is broken in many places, because of changes beyond our reach
15:10:56 <tmorin> hi pcarver !
15:11:17 <tmorin> and ... (b) ongoing work in neutron-lib on the API
15:11:18 <tmorin> :)
15:11:52 <tmorin> I have a fix in progress for one of the CI issues ( https://review.openstack.org/#/c/416263/ )
15:12:15 <tmorin> another one was recently solved (dep version issue on the Routes package)
15:12:49 <tmorin> 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 <tmorin> the dulwich python package installation fails, because some C wrapper compilation fails to create a directory under /opt
15:13:46 <tmorin> this happens in the functional test job
15:14:03 <pcarver> 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 <tmorin> presumably because /opt/stack/... is created by root and then used by the stack user
15:14:21 <pcarver> Since I was technically still on vacation I didn't spend any time investigating why it failed.
15:15:29 <tmorin> pcarver: perhaps the broken dependency on the Routes package could impact a devstack
15:15:43 <tmorin> pcarver: but I don't believe the other issue would
15:16:04 <pcarver> ok, thanks
15:16:14 <tmorin> devstack failing is unfortunately something that routinely happens :-/
15:17:11 <tmorin> #topic neutron-lib & BGPVPN API
15:17:20 <tmorin> pcarver: do you want to give us an update ?
15:17:50 <pcarver> tmorin: Nothing major. I updated for a little reviewer feedback.
15:18:09 <pcarver> I saw you respond as well. One of the comments was on project ID
15:18:18 <tmorin> yes
15:18:23 <tmorin> I'm unsure about this one
15:18:48 <pcarver> I'm pretty sure that I created the API examples directly through curl commands
15:18:53 <tmorin> need to revive a devstack to check if our API currently provides the project_id or only the tenant_id
15:19:19 <pcarver> So they should be accurate, but I'll double check once I get that VM restacked
15:20:01 <pcarver> I think the API ref is pretty well complete at this point
15:20:06 <tmorin> pcarver: yes
15:20:33 <pcarver> There still seems to be some back and forth on the API definition regarding the sub-resource map
15:20:55 <tmorin> 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 <matrohon> I think bgpvpn is compatible with project_id
15:21:12 <pcarver> My understanding is that there's neutron-lib code around manipulating the resource map but not around manipulating sub-resource map
15:21:18 <matrohon> this has been done directly in the neutron framework
15:21:29 <matrohon> pcarver, +1
15:21:45 <pcarver> 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 <tmorin> I'm lost: who is talking about sub-resource map ? who is talking about project_id ?  :)
15:22:56 <tmorin> pcarver: what code have you in mind which would manipulate the resource maps ?
15:23:01 <matrohon> sorry, I'm talking about project_id for resources
15:23:16 <matrohon> I didn't check what was happening for subressources
15:23:50 <pcarver> 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 <tmorin> 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 <pcarver> but not for sub-resource maps
15:24:11 <pcarver> which seems to be the heart of the objection to our use of sub-resource map
15:24:23 <matrohon> tmorin : AFAIR, it does
15:24:28 <tmorin> pcarver:  there seems to be unit test code, but is there more ?
15:24:40 <pcarver> I don't know yet.
15:25:00 <pcarver> maybe it's just intent to write more vs already existing
15:25:09 <pcarver> I'll try to figure out more
15:25:49 <pcarver> 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 <pcarver> 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 <pcarver> I don't really grasp all the implementation details. I initially thought this was just a cut and paste change.
15:29:20 <pcarver> 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 <tmorin> 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 <pcarver> 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 <tmorin> 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 <tmorin> pcarver: perhaps, but I haven't read anything about such a project yet
15:31:14 <pcarver> 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 <tmorin> yep
15:32:40 <tmorin> we'll have to ask neutron core on how we can move on
15:32:45 <tmorin> next topic ?
15:32:58 <tmorin> doude, any update on OSC CLI things ?
15:33:21 <doude> work is done
15:33:32 <doude> just need to write cli usage documentation
15:33:47 <doude> then I'll submit the review
15:34:12 <doude> I already submited a review on bgpvpn to revert the OSC patch
15:34:24 <doude> https://review.openstack.org/#/c/411205/2
15:34:34 <doude> actually failling due to CI issues
15:35:54 <tmorin> ok
15:36:31 <tmorin> let's wait for the python-neutronclient review to land before we removed the OSC extension from our repo
15:36:42 <tmorin> thanks!
15:36:51 <matrohon> yep many thanks doude
15:37:28 <doude> I though to set a dependency on python-neutronclient review on the bgpvpn revert patch
15:37:28 <tmorin> next topic ... ?
15:37:41 <tmorin> yes, good idea
15:40:21 <tmorin> #topic Atlanta PTG
15:41:01 <tmorin> the PTG is in 6 weeks
15:41:13 <tmorin> I don't know exactly what will happen there around neutron
15:41:25 <tmorin> I'm surprised to not see anything on the list
15:41:49 <tmorin> i haven't been able to find anything in #openstack-neutron IRC logs either
15:42:08 <tmorin> I'm still planning to go
15:42:21 <matrohon> tmorin, well, it's just big tables with a lot of beers, nothing to be proud of :)
15:42:31 <tmorin> :)
15:43:07 <doude> :)
15:43:39 <matrohon> tmorin, do you plan to go to the PTG?
15:43:57 <tmorin> yes
15:44:24 <tmorin> unless it is not confirmed that neutron folks would meet
15:44:31 <tmorin> I presume neutron would meet
15:44:49 <matrohon> that's for sure
15:44:55 <tmorin> but in the absence of anything being said/discussed/announced, I'm a bit unsure...
15:45:28 <matrohon> maybe armax can tell us more about it?
15:45:58 <armax> matrohon: the neutron PTG is scheduled as any other major openstack project
15:46:05 <armax> if this is what you’re asking
15:46:25 <matrohon> armax : we're looking for more info about the schedule
15:46:48 <armax> matrohon: as soon as I get informed on how to build an official one, I’ll disseminate
15:46:56 <tmorin> hi armax :)
15:46:58 <matrohon> armax, ack
15:47:17 <armax> matrohon: it’s probably a bit early, but I suspect details will become known soon enough
15:47:24 <tmorin> thanks for the answer, that's all we were needing
15:47:34 <armax> we plan to go from tue to fri
15:47:44 <armax> actually I think wed to fri
15:47:51 <tmorin> armax: for those having to plan for travel, it may actually be a bit late
15:47:54 <armax> as the first two days are for cross projects parties
15:47:58 <armax> erm, sessions
15:48:06 <tmorin> armax: mon-tue seems to be for cross project things
15:48:12 <armax> tmorin: right
15:48:28 <tmorin> armax: but neutron might have participation in cross projects things as well I guess...
15:48:41 <armax> tmorin: yes
15:49:05 <pcarver> 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 <tmorin> 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 <tmorin> +1
15:50:09 <armax> tmorin: agreed, let me find out more in the next few days
15:50:30 <tmorin> armax: thanks!
15:52:57 <tmorin> do we have other topics to discuss ?
15:55:38 <tmorin> ok... seems like we don't
15:56:01 <tmorin> thanks doude pcarver matrohon armax
15:56:06 <tmorin> #endmeeting