15:15:59 <tmorin> #startmeeting bgpvpn
15:16:00 <openstack> Meeting started Tue Dec 13 15:15:59 2016 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:16:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:16:03 <openstack> The meeting name has been set to 'bgpvpn'
15:16:14 <pcarver> hi
15:16:18 <tmorin> hi doude, eon`, lewo
15:16:20 <tmorin> hi pcarver
15:16:24 <tmorin> hi matrohon
15:16:27 <tmorin> hi timirnich
15:16:29 <matrohon> hi
15:16:43 <tmorin> sorry for being late
15:16:55 <tmorin> cant get used to winter schedule
15:17:34 <lewo> hi
15:19:28 <tmorin> let's see what we have on our agenda...
15:19:49 <tmorin> * stadium-related work in progress
15:20:10 <tmorin> * discussing where to implement API constraints (matrohon, doude)
15:20:56 <tmorin> * discussing the Atlanta PTG
15:20:59 <tmorin> anything else ?
15:23:25 <pcarver> sounds like a good list
15:24:08 <tmorin> #topic stadium things / API
15:24:20 <tmorin> pcarver: want to give us a status ?
15:25:26 <pcarver> I think the api-ref/definition change is about done, but there's a gate failure on the gate-neutron-lib-api-ref job. When I run tox -e api-ref locally I don't get a failure.
15:25:40 <pcarver> I haven't looked into what the difference is yet.
15:26:30 <pcarver> If there are any more reviewer concerns about the api definition I'll split that part out as a different commit from the api-ref, but at this point I think it's mostly ok from a human review standpoint
15:26:44 <tmorin> pcarver: I'd tend to believe the cause for this failure to be somewhere else
15:27:03 <tmorin> whether in a recent docutils package, or in the api-ref package
15:27:07 <pcarver> I'm supposing from Armando's "on the fence" comment that he's not going to block it over the sub-resource stuff
15:27:31 <tmorin> pcarver: I share this understanding, ; we'll see
15:28:35 <tmorin> pcarver: anyhow, the sub-resource stuff is only a question related to how they are represented in the API definition, not about what the API is seen from the outside (this will not have to change, whatever the decision ends up being done on the representation)
15:30:49 <tmorin> ok, next topic ?
15:31:24 <tmorin> #topic stadium / move openstack client to python-neutronclient
15:32:36 <tmorin> not sure if doude is around...
15:32:41 <tmorin> doude ?
15:33:27 <tmorin> ok, we'll see next meeting if he has an update on this...
15:33:38 <tmorin> #topic where to implement API constraints (matrohon, doude)
15:33:53 <tmorin> matrohon: do you want to explain/give a status ?
15:34:07 <matrohon> yep, I filed a bug recently
15:34:13 <matrohon> let me find it
15:34:49 <tmorin> https://bugs.launchpad.net/bgpvpn/+bug/1648510 ?
15:34:50 <openstack> Launchpad bug 1648510 in networking-bgpvpn "Constraint enforcment might not work for contrail driver" [Undecided,New]
15:34:57 <matrohon> yep
15:35:28 <tmorin> haven't you identified a possible race as well, which you were dicussing with kevinbenton the other day ?
15:35:35 <tmorin> it's not in this bug report right
15:35:36 <matrohon> so doude was asking for removing this constraint since the opencontrail controller was already checking that
15:35:47 <matrohon> that's a pont
15:36:31 <tmorin> yes, this point is ok/easy, I think : we can certainly move this to the Db-specific driver base class
15:36:47 <matrohon> and another is that currently, I'm pretty sure that if concurrent API calls are sent to neutron for bpgpn attachment to router and networks, the constraint might be bypassed
15:37:43 <matrohon> well, I'd rather say concurrent API call for attching a net to a bgpvpn and a subnet of this net to a router
15:37:50 <tmorin> matrohon: yes, since the DB itself has no way (at least no obvious way) to enforce this kind of constraint, we can't have a race-free check
15:38:04 <matrohon> tmorin, +&
15:38:06 <matrohon> tmorin, +1
15:38:45 <matrohon> a possible workaround would be to recheck the constrint periodicly
15:39:12 <matrohon> but I' not keen of this kind of implementation
15:39:15 <tmorin> the thing is that this constraint is not something absolutely necessary
15:39:54 <tmorin> it was added to avoid a possible confusion about what it can possibly mean to have both at the same time
15:40:28 <tmorin> I don't think its worth spending an unreasonable amount of effort on it
15:40:40 <matrohon> back in the days, I heard about possible route leaking?
15:40:53 <tmorin> on the other hand, having the constraint and letting it open to a race, is not nice
15:40:58 <tmorin> route leaking: ?
15:41:24 <matrohon> from one bgpvpn to another, with dual attachments?
15:42:21 <tmorin> my recalling is that the question, in the case where a network was bound to a BGVPN and connected to a Router attached to a same BGPVPN, was that perhaps with some backend it would be left undetermined whether the traffic would "go through" the router or not
15:42:41 <tmorin> a question which does not necessarily makes sense for all backends...
15:43:13 <tmorin> no, I don't see why route leaking would happen, and I don't remember a discussion on that
15:43:20 <tmorin> I may be wrong though
15:43:48 <matrohon> ok, it seems we don't have a strong opinion on having this kind of constraint
15:44:23 <tmorin> I think the thing was mainly discussed with Jan Scheurich
15:44:24 <matrohon> maybe just a warning for an nondeterministic behavior woud be sufficient?
15:44:34 <matrohon> in the doc
15:45:20 <tmorin> yep, or perhaps "behavior may depend on the backend"
15:45:42 <matrohon> makes sense
15:46:20 <matrohon> we can forward the callback to the backend, and it's up to it to stop the attachment
15:51:04 <tmorin> matrohon: well, yes, but enforcing the constraint race-free may or may not be easy for the backend
15:52:27 <matrohon> indeed.. we should use some kind of distributed lock manager for that
15:52:52 <tmorin> matrohon: but for sure, if the backend has an incompatibility, we can decide to delegate him  the responsibility for enforcing the constraint
15:53:21 <tmorin> ok...
15:53:33 <tmorin> #topic Atlanta PTG
15:54:16 <matrohon> tmorin, for bagpipe and backends that use the db, the lock offered by mysql might be enough...
15:54:20 <matrohon> ok let's move on
15:54:43 <tmorin> yes, let's move the discuss to later / #openstack-net-bgpvpn
15:55:06 <tmorin> does anyone have an idea of what is planned around Neutron for the Atltanta PTG in February ?
15:56:37 <tmorin> nothing on the mailing list as far as I can tell
15:56:48 <tmorin> who plans to go ?
15:57:28 <tmorin> I'm very likely to be there, and think it would be a good opportunity to work in depth on net-bgpvpn
15:57:33 <tmorin> in particular on API evolution
15:57:56 <pcarver> I plan to put in a travel request. I don't know what the likelyhood of approval is.
15:58:03 <tmorin> ok
15:58:07 <tmorin> matrohon: any plans yet ?
15:58:34 <matrohon> tmorin, no, not in my schedule for now
16:00:10 <openstack> juggler: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
16:00:32 <adrian_otto> juggler: I'm here, and I can start it
16:00:35 <tmorin> #endmeeting