15:03:13 <tmorin> #startmeeting bgpvpn
15:03:14 <openstack> Meeting started Tue Nov 10 15:03:13 2015 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:19 <openstack> The meeting name has been set to 'bgpvpn'
15:03:39 <tmorin> hi janscheurich, matrohon, pcarver, Prem, timirnich_
15:03:50 <janscheurich> hi tmorin
15:03:55 <timirnich_> Hi all
15:04:01 <janscheurich> hi tim
15:04:14 <enikher> Hi all
15:04:16 <timirnich_> Hi Jan, how's it going?
15:04:38 <janscheurich> tim: not too bad
15:05:15 <enikher> tmorin: thanks for the fast answer. I will push the code soon
15:05:32 <tmorin> hi enikher
15:05:49 <tmorin> it will have to be pushed to a backport branch, not created yet
15:05:53 <tmorin> will cover that today
15:05:59 <tmorin> #topic announcements
15:06:08 <tmorin> what do we have to announce ?
15:06:19 <enikher> I have seen a stable/kilo branch already...
15:06:27 <enikher> is that not the right one?
15:07:19 <tmorin> no, will explain later in a 'backports' topic
15:07:25 <enikher> ok
15:07:38 <tmorin> we discussed, solved a few minor issues in the last week
15:07:54 <tmorin> ie. some polish before considering a first release
15:08:18 <tmorin> doude has been working on the contrail driver
15:08:28 <tmorin> now mostly finished I would say
15:09:22 <tmorin> we had also a bunch of things to change to follow the rename of the networking-bagpipe project (was networking-bagpipe-l2 before)
15:10:07 <janscheurich> odl driver location. Is that clarified?
15:10:20 <tmorin> not really
15:10:32 <tmorin> the decision early oct was to keep it in networking_odl
15:10:58 <janscheurich> tim: can you discuss this with Prem et al?
15:11:08 <tmorin> in tokyo the idea of having all drivers in networking-bgpvpn for a first release was looking nice
15:11:21 <janscheurich> +1
15:11:31 <tmorin> but we need to confirm, either way, where to put it before a release
15:11:40 <timirnich_> I got the info that it was a request by Neutron cores to have all ODL drivers in netrowking-odl
15:11:53 <tmorin> a release saying "there is also an ODL driver, which is <here>" would work as well
15:11:58 <janscheurich> Yes. that's ok for long-term
15:12:07 <matrohon> This was the decision of the networking-odl team, we should leave this decision to that team
15:12:24 <timirnich_> The point is, if we want a different solution, we'll have to discuss with the cores.
15:12:45 <janscheurich> We would need a release of that project on top of bgpvpn
15:13:08 <timirnich_> Yes. Do we know their release plans?
15:13:20 <enikher> as far as I can see it is only one file and the config service_provider or?
15:14:01 <enikher> I mean it would be rather easy to cpoy the file into the bgpvpn repo... change the config
15:14:21 <enikher> and when the odl repo has it in place we will delete it from bgpvpn repo again...
15:14:56 <matrohon> enikher, yep, we left the door open to the odl team, to come back to the bgpvpn repo, which would be pretty easy
15:15:35 <janscheurich> only as a temporary solution
15:15:39 <tmorin> +1
15:16:08 <janscheurich> Tim: Do you meet Prem et al in San Francisco?
15:16:18 <matrohon> the main issue for them, will be to maintain the driver, since we won't handle chenges at the API layer as we can do if their driver were in our tree
15:16:23 <tmorin> the code looked ok when I reviewed, if someone submits the same driver file in networking-bgpvpn, we will review it
15:17:03 <tmorin> matrohon: this is why having it in networking-bgpvpn initially, until we stabililize the plugin/driver interface, looks like a better idea
15:17:24 <matrohon> tmorin : I totally agree
15:17:38 <janscheurich> we take the action to re-discuss with the ODL team
15:17:42 <matrohon> tmorin : but it's not our decision
15:18:05 <janscheurich> Aim at decision until next week
15:18:12 <tmorin> yes, please re-discuss
15:18:16 <tmorin> the earlier the btter
15:18:19 <tmorin> better
15:18:23 <janscheurich> OK
15:18:53 <matrohon> #action : janscheurich to discuss with ODL team to move their driver back to bgpvpn repo
15:19:28 <tmorin> what's next ?
15:19:30 <matrohon> #topic : resources vs subresources
15:19:35 <tmorin> go ahead
15:19:41 <enikher> matrohon: moving it back? I would go for push it to both repos
15:19:55 <matrohon> #undo
15:20:05 <tmorin> can you undo twice ?
15:20:07 <tmorin> not sure
15:20:27 <matrohon> enikher, you want to maintain two version of the driver?
15:21:04 <enikher> matrohon: no but at the moment it is nowhere
15:21:17 <enikher> it is not yet merged to any repo.
15:21:44 <matrohon> anikher : ok
15:21:47 <enikher> when it is there in an OS release then we could exclude it from bgpvpn repo
15:21:47 <tmorin> #action : janscheurich to discuss with ODL team to initially submit their driver in bgpvpn repo until plugin/driver api stabilizes
15:22:00 <enikher> +1
15:22:00 <tmorin> what about this alternate formulation ??
15:22:08 <janscheurich> +1
15:22:21 <matrohon> #topic : resources vs subresources
15:22:37 <matrohon> as you know net-assoc are now managed as subresources
15:22:47 <matrohon> of bgpvpns resources
15:23:23 <matrohon> I hardly see benefits of subres over resources
15:23:41 <matrohon> it complexifies URIs
15:24:04 <matrohon> it is less tested, (tmorin fix a related bug in the client)
15:25:14 <matrohon> and now that those subres are about to manage their tenant_id, I don't know why we should keep on having subresource, instead of resource
15:25:25 <janscheurich> But it's more logical. An association can only be part of one BGPVPN
15:25:58 <matrohon> yep, this is enforced at the db layer
15:25:58 <tmorin> yes, this is the rationale for having chosen sub-resources
15:26:11 <janscheurich> Why do assocs manage their own tenant_id?
15:26:25 <tmorin> matrohon: you mean that even with resources, it can be enforced by the db layer
15:26:48 <matrohon> I wanted to discuss about benefits of subresources with dougwig or blogan, who introduced this concept for lbaas
15:26:54 <matrohon> tmorin +1
15:27:21 <tmorin> janscheurich: the neutron api policy framework requires having a tenant_id for some corner cases, so we added tenant_ids to associations
15:27:50 <matrohon> https://bugs.launchpad.net/bgpvpn/+bug/1512789
15:27:50 <openstack> Launchpad bug 1512789 in bgpvpn "a tenant cannot list/show/delete its net-assocs resources" [High,In progress] - Assigned to Mathieu Rohon (mathieu-rohon)
15:28:04 <tmorin> janscheurich: we could have added tenant_id in the API layer only, but we also added it in the db layer, to make the code less surprising for people who will read it later
15:28:25 <janscheurich> matrohon: but it must be identical to the tenant_id of its parent bgpvpn, or?
15:28:30 <tmorin> yes
15:28:38 <tmorin> the plugin enforces that
15:29:08 <tmorin> we don't have a use-case for having an association tenant_id being different than the tenant_id of the BGPVPN
15:30:23 <matrohon> having subreources leads to this kind of incoherences : https://bugs.launchpad.net/bgpvpn/+bug/1513087
15:30:23 <openstack> Launchpad bug 1513087 in bgpvpn "get_network_association inconsistency" [Medium,In progress] - Assigned to Thomas Morin (tmmorin-orange)
15:31:08 <matrohon> It's not a big deal, but I want to consider this move before having our first release
15:31:48 <tmorin> I would have a tendency to keep things as is, not seeing a huge gain in simplification (the issue we found were solved in a satisfying way)
15:32:00 <tmorin> but we think it may be interested to hear from lbaas folks
15:32:00 <janscheurich> +1
15:32:12 <matrohon> #action : matrohon to evaluate the benefit/drawbacks of moving net-assoc to a dedicated resource
15:32:16 <tmorin> they moved some things from resources to sub-resources
15:32:22 <tmorin> matrohon: +1
15:32:40 <tmorin> next topic ?
15:32:43 <matrohon> tmorin, they also moves things from sub-resources to resources!
15:32:53 <matrohon> I'd like to understand why
15:32:55 <tmorin> yes
15:33:15 <matrohon> branch management?
15:33:22 <tmorin> #topic backports and branches
15:33:36 <tmorin> a few things as a reminder:
15:33:58 <tmorin> we have recently understood that stable/* branch are very special
15:34:16 <tmorin> in these branches, only neutron stable maitainers can merge gerrit changes
15:34:39 <tmorin> this reflects a contract between the Openstack and the outside world about what "stable" mean
15:34:46 <tmorin> only bugfixes
15:35:28 <tmorin> this obviously does not match what we need to do to work toward releases, in particular for backports
15:35:35 <tmorin> this problem is not only for us
15:35:45 <tmorin> see the email today from networking-calico folks
15:36:06 <tmorin> "Understanding stable/branch	process for Neutron subprojects"
15:36:40 <tmorin> the current plan is to work on backports in their own branch
15:36:52 <enikher> The stable/kilo branch should be created after the release or?
15:36:52 <tmorin> but to not name these branch "stable/x"
15:37:20 <tmorin> enikher: not we first need a branch to work on a backport, we don't want to overwrite our current liberty-compatible code
15:37:45 <tmorin> so we asked the creation of a backport/kilo and a backport/juno branch
15:38:03 <tmorin> #link https://bugs.launchpad.net/bgpvpn/+bug/1513870
15:38:03 <openstack> Launchpad bug 1513870 in bgpvpn " networking-bgpvpn backport branches" [High,Confirmed]
15:38:41 <enikher> +1
15:39:07 <tmorin> we will see, when we want to do a release of these backports,  how we can fit in the proces of "stable/*" deliveries
15:39:10 <tmorin> that will be later
15:39:28 <tmorin> in the meantime there will be a place to work on backports
15:39:52 <tmorin> this should work fine, except one thing: continuous integration
15:40:19 <tmorin> the CI jobs currently expect branch X of a project to be testing against branch X of other Openstack projects
15:40:52 <tmorin> we already have a tweak in place so that networking-bgpvpn is tested both against master and stable/liberty
15:41:28 <tmorin> we will have to add additional tweaks so that backport/kilo be tested against stable/kilo of other openstack projects
15:41:32 <tmorin> same for juno
15:41:47 <tmorin> not enthousiasting, but doable
15:42:15 <tmorin> the discussion in the community is in progress
15:42:21 <tmorin> we'll see how it goes
15:44:42 <tmorin> no comments ?  :)
15:44:52 <janscheurich> Regarding the scope of  the Kilo backport
15:45:21 <janscheurich> We think think we would leave the door open to more than just PoCs and trials
15:45:44 <janscheurich> So the DB migration at upgrade from Kilo to Liberty may become an issue
15:46:16 <tmorin> janscheurich: ok, this means that the work should be done to allow this migration
15:46:46 <janscheurich> yes. I assume it will mean impact on the liberty branch
15:46:55 <tmorin> some neutron projects were shipping their own db-migration tool, and now used the neutron modularized one
15:47:02 <tmorin> so I think this is very doable
15:47:36 <janscheurich> enikher will look into this
15:47:45 <tmorin> janscheurich: maybe, maybe not -- if it does, we need to know it soon
15:47:47 <tmorin> good
15:48:10 <janscheurich> I hope you can point him to some examples?
15:48:28 <enikher> I will check the other repos,,
15:48:56 <tmorin> neutron-lbaas and neutron-vpnaas
15:48:58 <tmorin> from memory
15:49:14 <tmorin> at least one of the two
15:50:18 <tmorin> finding the right solution is likely to require some playing
15:51:02 <tmorin> next topic ?
15:51:08 <tmorin> #topic drivers
15:51:15 <tmorin> any update on drivers ?
15:51:54 <tmorin> work is in progress on Nuage side, been in touch with them to help bootstrap the work
15:52:12 <tmorin> sorry I'm confused, that's not driver related,
15:52:22 <tmorin> that's about Router attachement
15:52:58 <tmorin> #topic open discussion
15:53:04 <tmorin> anything else ?
15:53:51 <janscheurich> I'm still waiting for company approval for the port_assoc and static_route API enhancements
15:54:17 <janscheurich> request have been sent but no feedback so far
15:54:27 <janscheurich> :-(
15:54:58 <tmorin> :-(
15:55:39 <tmorin> you mean for submitting a gerrit change for the API additions
15:55:42 <tmorin> hope it can happen quickly
15:55:53 <janscheurich> so do I
15:56:25 <janscheurich> I can probably start a change with the clarifications we discussed
15:57:38 <tmorin> sure, this will be welcom
15:57:39 <tmorin> e
15:59:37 <tmorin> ok, it seems like we are done
15:59:42 <tmorin> thanks everyone
15:59:47 <tmorin> #endmeeting