15:05:40 <matrohon> #startmeeting bgpvpn
15:05:41 <openstack> Meeting started Tue Sep  8 15:05:40 2015 UTC and is due to finish in 60 minutes.  The chair is matrohon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:05:44 <openstack> The meeting name has been set to 'bgpvpn'
15:06:12 <tmorin> hi everyone
15:06:14 <matrohon> #topic announcement
15:06:33 <matrohon> no big announce for me, anyone?
15:06:49 <tmorin> nothing big
15:07:13 <janscheurich> tmorin and I have revived the technical discussion around static routes
15:07:28 <tmorin> yes
15:07:44 <tmorin> we'll pursue the discussion and update the etherpad
15:07:53 <janscheurich> I would like to invite all interested parties to subscribe to the blueprint and watch the wiki
15:07:54 <matrohon> janscheurich, great, I didn't take the time to read those discussions carefully
15:08:09 <tmorin> hopefully we could provide the conclusion we reached during another IRC meeting
15:08:11 <janscheurich> *etherpad
15:08:15 <tmorin> +1
15:08:49 <matrohon> ok let's move on
15:08:55 <tmorin> we can also give an update on gerrit changes in progress, but I don't know if this is an announcement :)
15:09:05 <matrohon> #topic bugs and bps
15:09:25 <matrohon> tmorin, this is the dedicated topic
15:09:27 <matrohon> :)
15:09:35 <tmorin> :)
15:09:59 <tmorin> the new association API implementation by Mathieu is mostly ready
15:10:15 <matrohon> blueprint : https://blueprints.launchpad.net/bgpvpn/+spec/split-association-api
15:10:21 <tmorin> I'm working on the neutronclient change in //, and hope to finish it soon
15:10:34 <matrohon> review : https://review.openstack.org/#/c/207371/
15:11:14 <matrohon> this is quite hard to review, since it is a big change : I merge the db patch with the API patch
15:11:45 <matrohon> but it reflects what is in the psec
15:11:54 <matrohon> s/psec/spec
15:12:02 <tmorin> neutronclient change: #link https://review.openstack.org/#/c/219688
15:13:56 <matrohon> ok this is the main work in progress currently, hope it can get merged soon
15:14:09 <janscheurich> +1
15:14:19 <tmorin> I've also contributed a change to avoid requiring an ML2 mech driver for the bagpipe driver
15:14:31 <tmorin> to use neutron registry callbacks instead
15:14:41 <matrohon> #topic : drivers
15:14:56 <tmorin> and I plan to implement an ovs agent extension to also have the agent cleaner, as suggested by Mathieu
15:15:15 <tmorin> ah yes, sorry, that belongs to a driver topic
15:15:22 <matrohon> np
15:15:24 <matrohon> :)
15:16:36 <matrohon> so bagpipe : as tmorin mentioned, thanks to latest neutron improvments, bagpipe should integrate neutron smoothly with liberty
15:16:48 <matrohon> https://blueprints.launchpad.net/bgpvpn/+spec/bagpipe-use-neutron-registry
15:17:08 <matrohon> https://bugs.launchpad.net/bgpvpn/+bug/1492021
15:17:09 <openstack> Launchpad bug 1492021 in bgpvpn "bagpipe : do not overload the ovs agent" [High,New]
15:17:35 <matrohon> those two links provide the way we should refactor the bagpipe driver
15:18:36 <matrohon> doude is not around so I don't think we can speak about the contrail driver
15:18:52 <matrohon> janscheurich, any update from the ODL team?
15:19:03 <tmorin> indeed, and there was no update on doude'd contrail driver last week
15:19:14 <janscheurich> No news from my side :-( I haven't been able to talk to them last week
15:19:36 <matrohon> ok, np
15:19:57 <matrohon> #topic : tokyo summit
15:20:24 <matrohon> pcarver : is there any update from the neutron team and the schedule of the design session?
15:20:45 <pcarver> I haven't seen the scheduling Etherpad come out yet
15:21:53 <matrohon> pcarver, ok thanks
15:22:39 <tmorin> #topic API
15:22:50 <tmorin> we have a pending question raised by doude
15:22:55 <tmorin> last comment at #link https://review.openstack.org/#/c/177740/
15:23:27 <tmorin> we'll have a 'networks' attribute in API replies
15:23:46 <tmorin> for a BGPVPN
15:24:02 <tmorin> but currently we don't have a 'networks' attribute in the API resource specification
15:24:29 <tmorin> the reason is that this is a /particular/ attribute, because it is derived from the associate/disassociate actions
15:24:43 <tmorin> question is should we or shouldn't we keep it in the API spec
15:24:53 <tmorin> kind of a philosophical question in fact
15:25:10 <tmorin> totally *not* impacting what we end up implementing
15:25:58 <tmorin> if we keep it in the API resource, that breaks (but only a little bit) the idea of a BGPVPN object independent to how it is associated to Networks/Routers or soon Ports
15:26:06 <janscheurich> if we add it to the API, we need to mark it as read-only, or?
15:26:16 <tmorin> yes, that would be what I'd do
15:27:05 <janscheurich> I would vote for including it if it is returned in GET
15:27:13 <matrohon> a a read-only attr, this wouldn't change the code, only the spec!
15:27:51 <matrohon> we should add routers too
15:28:05 <janscheurich> +1
15:28:14 <janscheurich> and later for ports
15:28:22 <tmorin> ok, let's do that
15:28:41 <tmorin> the last pieces of work on the API spec is this update, and adding diagrams
15:29:13 <tmorin> any #help would be appreciated if someone has the time to do nice diagrams and know the tools
15:29:58 <tmorin> next topic ?
15:30:16 <matrohon> tmorin, none :)
15:30:23 <tmorin> #topic work items to fully implement the new API
15:30:31 <tmorin> short topic :)
15:30:41 <tmorin> there are a few new things in the new API
15:30:51 <tmorin> not all of them are of high importance
15:31:16 <tmorin> but if people feel they are important, contributions will be welcome
15:31:31 <tmorin> implementing support for RDs in the bagpipe driver
15:31:43 <tmorin> implementing support for specifying VNID
15:31:53 <tmorin> implementing router association
15:32:04 <tmorin> implementing admin_status
15:32:17 <tmorin> possibly other things that I do not have in mind
15:32:24 <tmorin> #topic testing
15:32:30 <tmorin> just a short announce
15:32:56 <tmorin> we've started to see with matrohon what kind of things we can add to improve ou unit and functional test coverage
15:33:19 <tmorin> possibly we'll have things to propose or announce next week
15:33:37 <tmorin> and now I don't have a next topic to propose :)
15:34:15 <matrohon> I started to improve the UT framework in 207371
15:34:51 <matrohon> #topic open discussion
15:35:31 <matrohon> nobody?
15:35:39 <janscheurich> Stupid question
15:35:47 <janscheurich> from my side :-)
15:35:53 <matrohon> go ahead we love them
15:36:19 <tmorin> +1 for the unit test improvements!
15:36:35 <janscheurich> Will the patches you have made (excluding the bagpipe driver) work on Kilo baseline or only on Neutron master?
15:37:08 <matrohon> it's not a stupid question!
15:37:43 <janscheurich> Is there a simple answer?
15:37:59 <tmorin> Liberty only
15:38:02 <tmorin> is the answer
15:38:10 <tmorin> we don't have a Kilo branch
15:38:39 <janscheurich> But Liberty is not released yet. Is there a Liberty branch already?
15:38:53 <matrohon> I already though about it, and the only thing I see in the neutron side that is incompatible with previous releases is the way the service plugin is loaded
15:39:00 <matrohon> this change https://review.openstack.org/#/c/208527/
15:39:04 <tmorin> many things could be backported to Kilo, lost of small things, so a significant work
15:39:07 <matrohon> reflect the move from neutron
15:39:20 <janscheurich> Didn't want to suggest backporting!
15:39:52 <janscheurich> Just curious how to build a working prototype
15:39:59 <matrohon> tmorin : not sure it would be so significant, the API/DB layer from neutron dind't move a lot since kilo
15:40:19 <tmorin> no, but many small things need an update, that's tedious work
15:40:35 <janscheurich> What would be the appropriate OpenStack/Neutron baseline to check out?
15:40:54 <matrohon> liberty is the tagerted baseline
15:40:55 <tmorin> jan: there is no liberty branch,   the liberty branch is the master until mitaka forks if I understand correctly
15:41:19 <janscheurich> So you are working/testing against master?
15:41:31 <tmorin> yes
15:41:32 <matrohon> and we plan to announce the compatibility with liberty, which makes sense
15:41:39 <janscheurich> +1
15:41:41 <matrohon> yes
15:42:18 <tmorin> on my dev platform, I sometimes pin nova, keystone or such components to their Kilo release, to workaround bugs
15:42:31 <tmorin> but we definitly follow neutron master
15:42:43 <janscheurich> ok. thanks!
15:43:12 <matrohon> any other question?
15:43:35 <janscheurich> nope
15:43:46 <matrohon> ok, let's end the meeting
15:43:49 <matrohon> thanks all
15:43:54 <janscheurich> thanks!
15:43:57 <matrohon> #endmeeting