15:02:00 <matrohon> #startmeeting bgpvpn
15:02:00 <openstack> Meeting started Tue Nov 17 15:02:00 2015 UTC and is due to finish in 60 minutes.  The chair is matrohon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:04 <openstack> The meeting name has been set to 'bgpvpn'
15:02:06 <nikolas> hey
15:02:37 <matrohon> hi nikolas, janscheurich tmorin doude
15:03:19 <tmorin> hello everyone
15:03:24 <openstack> tmorin: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
15:03:31 <openstack> tmorin: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
15:03:45 * tmorin not awake yet
15:03:58 <matrohon> :)
15:04:10 <tmorin> hi timirnich_
15:04:11 <matrohon> I was looking at last meeting action points
15:04:33 <matrohon> let's start with those points
15:04:46 <tmorin> hi enikher
15:04:46 <matrohon> #topic action points
15:05:15 <matrohon> janscheurich, you were supposed to contact the ODL team
15:05:22 <matrohon> you did we saw your mail
15:05:28 <matrohon> any feedbacks?
15:06:30 <matrohon> let's move to my AP
15:06:48 <matrohon> I considered moving from subresources to resources
15:07:52 <matrohon> after discussing with blogen, about the reason why lbaas use subresources
15:08:17 <matrohon> he told me that it was about the cosmetic of the API, and the lifecycle of the resources
15:09:18 <matrohon> he didn't have strong arguments, but it seems we have the same structure, with subresources that have no sense without resources
15:09:51 <matrohon> so 'im in favor of leaving association treated as subresources of bgpvpns, from an API point of view
15:09:59 <janscheurich> +1
15:10:06 * tmorin agrees
15:10:29 <tmorin> janscheurich: any feedback on the ODL driver location discussion?
15:10:31 <janscheurich> Sorry, I have not received feedback from the ODL developers regarding the location of the ODL driver
15:10:43 <matrohon> janscheurich, ok
15:10:51 <janscheurich> Our Indian colleagues were mostly on vacation last week
15:11:02 <janscheurich> WIll follow up this week
15:11:03 <matrohon> I discussed briefly with vthapar last friday
15:11:36 <matrohon> he sent a mail then to consider managing associations as object in ODL
15:12:00 <matrohon> but we didn't discuss about moving to the bgpvpn repo
15:12:40 <tmorin> janscheurich: the question is whether we should delay a first release before a decision is made, or not ?
15:13:20 <matrohon> there's one advantage having it in the odl repo : we don't have to wait for the odl driver to be ready to cut the bgpvpn liberty release :)
15:13:48 <matrohon> however I told vthapar that we will wait for their feedback on the new driver API before cutting
15:14:05 <janscheurich> true, but then we have two releases to deal with for ODL
15:15:36 <matrohon> two releases : kilo and liberty?
15:16:43 <matrohon> ok what's up next?
15:17:12 <janscheurich> networking bgpvpn and networking-odl. And I don't know if an how we can make intermediate networking-odl releases
15:17:34 <matrohon> janscheurich, oh of course
15:18:20 <tmorin> janscheurich: would it make sense to  release a first networking-bgpvpn rc release, without ODL, and a second one later with the ODL driver ?
15:18:32 <matrohon> I think we should discuss that yamahata
15:18:40 <matrohon> I think we should discuss that with yamahata
15:18:51 <janscheurich> tmorin: yes
15:18:57 <janscheurich> matrohon: yes
15:19:29 <matrohon> janscheurich, was he CC of your mail?
15:20:07 <janscheurich> yamahata? no
15:20:26 <janscheurich> I don't have his email...
15:20:43 <matrohon> vthapar told me he was the main dev of networking-odl
15:20:59 <tmorin> isaku.yamahata@gmail.com
15:21:06 <janscheurich> thx
15:22:09 <matrohon> I think doude won't be available all the meeting long
15:22:22 <matrohon> doude can you tell us the status of the contrail driver
15:22:47 <tmorin> #topic contrail driver
15:23:15 <doude> matrohon: sure
15:23:43 <doude> matrohon: I rebased the first PoC version with the master
15:23:54 <doude> with last fixes
15:24:01 <tmorin> I did a review of the last PS
15:24:07 <doude> tmorin made some review I included
15:24:25 <tmorin> there is one last thing that's missing, but AFAICT the driver is ready
15:24:40 <doude> tmorin: yes I'm finishing some tests before answer you reveiw
15:24:43 <tmorin> (check on delete_net_assoc)
15:24:49 <tmorin> doude: ok :)
15:24:51 <doude> tmorin: yes
15:24:56 <doude> I'm on it
15:25:00 <tmorin> :)
15:25:15 <matrohon> pep8 is failing too
15:25:34 <tmorin> next topic ? backports ?
15:25:40 <matrohon> yep
15:25:45 <tmorin> #topic backports
15:25:55 <tmorin> I have *great* news
15:26:13 <tmorin> mestery has just created backport branches in networking-bgpvpn
15:26:19 <tmorin> thanks mestery
15:26:22 <mestery> \o/
15:26:23 <matrohon> champagne
15:26:27 <tmorin> backport/kilo and backport/juno
15:26:37 <enikher> +1
15:26:39 <doude> nice
15:26:42 <matrohon> great
15:26:55 <enikher> ok then ignore the commits I have pushed today
15:26:59 <tmorin> it means the pending backport patches can now be submitted in the right branch (e.g. git review backport/kilo )
15:27:05 <enikher> I will push them again on kilo branch
15:27:16 <matrohon> enikher, +1
15:27:20 <tmorin> enikher: yes, you can "abandon" them
15:27:36 <matrohon> doude, can you push your patch to the juno branch
15:27:43 <doude> I did the job to backport on Juno and I pushed it on a review to store it until the branch is ready
15:27:43 <tmorin> doude: you can possibly cherry-pick enikher changes into backport/juno
15:27:45 <doude> ok
15:28:05 <tmorin> at least some of the changes will be common
15:28:13 <doude> I did not tested it with a driver which use the db layer (ie: bagpipe)
15:28:14 <matrohon> shouldn't we first tag the liberty release
15:28:28 <doude> I'm not sure migration script will work correctly
15:28:38 <matrohon> and backports branches should be based on the commit of the tag
15:28:40 <tmorin> matrohon: we don't need to
15:29:14 <tmorin> backport branches have been created from our current master head, and patches will be applied on these branches only
15:29:22 <tmorin> no impact on liberty targetted work
15:29:25 <matrohon> ho ok
15:29:40 <matrohon> so let's tag this as RC at least :)
15:29:56 <tmorin> doude: enikher has done some work to make kilo/liberty migration work
15:30:09 <tmorin> doude: don't know if it will work for juno
15:30:24 <tmorin> matrohon: yes, rc sounds like a proper name
15:30:39 <doude> tmorin: ok I'll try to cherry-pisk enikher backport before mine
15:31:33 <matrohon> I'm not sure how current client code will be compatible with older branches
15:31:56 <tmorin> matrohon: the thing we need to clarify is how we will work for rc2.. and other liberty releases, in the new stable/liberty branch as currently setup, we won't be able to merge code ourselves, only neutron stable maintainers will be able to
15:32:52 <matrohon> I think we should first propose the change to stable, and then, if accepted backport it to our backport branches
15:33:06 <tmorin> matrohon: the best idea wecame up with is to require people to use a liberty-version of python-neutronclient, even with kilo or juno on the server side
15:33:34 <janscheurich> tmorin: so perhaps we should not use stable branches for the time being
15:33:43 <matrohon> tmorin, make sense, but this client might have incompatibuility with older branches
15:33:58 <janscheurich> until we really have a stable release
15:34:13 <tmorin> janscheurich: yes, I agree, but as I understand the release process currently involves the creation of a stable-something branch
15:34:48 <tmorin> tmorin: I've started to write an email for openstack-dev to explain what problems we have and what answers we need
15:34:59 <janscheurich> OK
15:35:09 <tmorin> tmorin: all/many projects under the neutron stadium have the same issue
15:36:03 <tmorin> e.g.: http://lists.openstack.org/pipermail/openstack-dev/2015-November/078702.html
15:37:40 <tmorin> tmorin: the key point being that, since we want to add features in releases between openstack releases, our stable branches shouldn't be named stable/liberty or stable/mitaka, and we need a different way to express which openstack release a said stable branch is targetting
15:39:08 <matrohon> we shuold us requirement.txt
15:39:14 <enikher> do we realy need to do that. openstack releases are already quite often
15:39:54 <tmorin> enikher: 6 month is not really "often"
15:40:14 <tmorin> it may be frequent enough once networking-bgpvpn is mature
15:40:39 <enikher> espacialy if we have to maintain the old branch
15:41:19 <tmorin> enikher: we don't necessarily want to advertise that, not for all releases
15:42:31 <tmorin> enikher: releasing a new driver, adding router associations, adding static routes, are things we may want to not wait for openstack releases ticks
15:43:46 <enikher> ok
15:44:45 <tmorin> other topics ?
15:45:02 <pcarver_> API documentation
15:45:10 <tmorin> #topic API documentation
15:45:14 <tmorin> go ahead paul :)
15:45:55 <pcarver_> There's an ongoing effort to convert WADL to Swagger, but we didn't do WADL so I don't think it makes sense to start there.
15:46:30 <pcarver_> I'm trying to figure out whether we can go directly to Swagger but I don't quite understand the documentation I've found so far.
15:46:55 <pcarver_> I'm thinking I may continue with what I started, just updating and reformatting the RST to begin with
15:47:12 <pcarver_> but I wanted to share the URL in case anyone else wants to take a look
15:47:25 <pcarver_> http://specs.openstack.org/openstack/docs-specs/specs/liberty/api-site.html
15:47:37 <tmorin> pcarver: even without something like wadl or swagger, any improvement will be useful
15:48:11 <pcarver_> From what I understand, the intent is to generate API documentation directly from the Python code. I just don't see exactly how it works or whether there are requirements for the Python to be written in a particular way.
15:48:57 <pcarver_> It's possible that I'm just misunderstanding what I've read, but I think it's more that the docs team is more focused on the WADL conversion at this point.
15:49:13 <matrohon> I makes sense taht we maintain the API doc, if this is the final goal
15:49:34 <matrohon> in our own repo
15:50:25 <pcarver_> Ok. I'm going to continue with that. Been out of town at OPNFV and OvS meetings, but it's still on my list.
15:51:15 <matrohon> I think the lib mention parses the code to extract comment
15:51:42 <matrohon> and generated swagger output
15:52:08 <matrohon> so nothing should be done for us, except valuable comments on the plugin API :)
15:52:35 <matrohon> pcarver_, Thanks for the link we should follow this effort
15:52:40 <pcarver_> matrohon: I think so. I didn't see specific examples.
15:52:41 <tmorin> +1
15:53:08 <pcarver_> But I think the long term idea is that the API spec would be encoded into the Python source, probably as you say in comments or docstrings
15:53:40 <matrohon> that's what I understand too
15:53:47 <tmorin> pcarver: in the meantime, having something easy to understand for people starting with the project, will be very useful
15:54:02 <pcarver_> I'll keep looking for specific examples but update the RST file in the mean time
15:54:20 <matrohon> we should have a dedicated job to see if the output of the lib is correct
15:55:16 <tmorin> anything else before we're out of time ?
15:56:14 <matrohon> ok, let's close the meeting earlier
15:56:23 <matrohon> thanks everyone
15:56:29 <matrohon> #endmeeting