15:02:28 <matrohon> #startmeeting bgpvpn
15:02:29 <openstack> Meeting started Tue Oct  6 15:02:28 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:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:32 <openstack> The meeting name has been set to 'bgpvpn'
15:02:50 <matrohon> I did an agenda!
15:03:00 <Prem> hi matrohon
15:03:00 <tmorin> hi timirnich_
15:03:18 <matrohon> https://wiki.openstack.org/wiki/Meetings/BGPVPN#Agenda
15:03:56 <matrohon> #topic announcement
15:04:16 <matrohon> the ODL driver is up for review!
15:04:28 <matrohon> #link  https://review.openstack.org/#/c/231321/
15:04:34 <matrohon> congrant and thanks vthapar
15:04:40 <tmorin> +1
15:04:43 <Prem> +1
15:05:16 <vthapar> I got another patchset that addresses flake errors, but will hold on to it for now.
15:05:46 <matrohon> any other announcement anyone?
15:05:58 <Prem> I will include Sam Hague and Flavio from ODL to get their inputs on the patch
15:06:08 <matrohon> Prem : +1
15:06:18 <tmorin> vthapar: what is your feeling with regards to moving the driver to networking_bgpvpn ?
15:07:14 <vthapar> tmorin: personally I am okay with either, but need to make decision as a community. networking-odl is primarily a collection of drivers for other plugins, so that seemed to be obvious choice to me
15:07:33 <vthapar> l2gateway is another project coming up which will have similar decision to make.
15:07:58 <vthapar> Prem: I'll add Ryan and Yamahata
15:08:27 <vthapar> tomorin: so should be same consistent decision across projects.
15:09:06 <tmorin> vthapar: yes, this is true -- for networking-bgpvpn, at least for the first steps of the projects, we think that it would be easier in networking-bgpvpn, because of some refactoring we plan to do
15:09:28 <matrohon> vthapar : make sense, but it will be hard for us to maintain your driver with regards to any change we make in the bgpvpn framework
15:09:45 <matrohon> tmorin, +1
15:09:46 <Prem> tmorin: also, if I am correct -this is one of the way of working agreed between openstack and odl about hosting the drivers  in networking-odl.  Will check with Kyle on this
15:09:48 <tmorin> vthapar: maybe this is a good enough argument to justify making a particular case for the bgpvpn driver, at least until we have a fully stable driver API
15:10:40 <tmorin> vthapar: the other thing to consider, potentially, is that your driver seems to have few/none real dependency on code in networking-odl
15:10:45 <vthapar> matrohorn: yeah, all other plugins are relatively mature.
15:11:37 <vthapar> tmorin: not yet, but there is some work being done on resync issues... you can take a look at ml2 driver to get an idea. as of today am just using client api to make rest calls.
15:11:46 <matrohon> vthapar : it's a choice taht your team has to make, you're aware of the drawbaks
15:12:05 <tmorin> vthapar: splitting bgpvpn code across repos is doable though, it will simply involve more coordination work on changes, and more work to have CI work properly
15:12:15 <tmorin> matrohon: +1
15:12:31 <matrohon> ok let's move on
15:12:45 <matrohon> #topic subresources
15:13:16 <matrohon> I started coding association as subresources
15:13:49 <matrohon> I didn't uploaded any patch yet, but it should come soon
15:14:27 <matrohon> I commented the spec on the change that will be done from an API POV
15:14:45 <matrohon> https://review.openstack.org/#/c/177740/
15:14:56 <matrohon> please review
15:15:51 <matrohon> I think we should also impact driver interfaces
15:16:23 <tmorin> I had a look at the API change: I'm giving a +1, I think this looks good
15:16:51 <matrohon> drivers will have create/get/delete_network_postcommit
15:17:00 <tmorin> matrohon: maybe we can discuss if we need to change the driver API or not
15:17:13 <matrohon> instead of associate/disassociate_postcommit
15:17:22 <matrohon> tmorin : +1
15:17:53 <matrohon> for the net association, update are needless, since there is no attribute to update
15:18:33 <tmorin> matrohon: the update operation may be added later when/if we want one or more attributes for network associations
15:18:48 <matrohon> tmorin : +1
15:20:08 <matrohon> maybe it will be easier to have this discussion under gerrit, once the patch will be under review :)
15:20:08 <tmorin> matrohoh: did you checks that the current 'networks' attribute in a bgpvpn resource will still exist ?  or we will have to use a GET request on network associations ?
15:20:20 <tmorin> matrohon: yes, +1
15:20:38 <matrohon> I keep the checks for the moment
15:21:13 <matrohon> since the network id is in the json datas, neutron can't check it alone
15:22:03 <matrohon> vthapar, doude : I'll add you to the reviewer of this patch, since you'll have to adapt your driver to the new interface
15:22:43 <vthapar> matrohon: thanks, that would be really helpful.
15:22:59 <tmorin> matrohon: yes, these drivers will need the full association resources with their uuids, which will necessary imply a modified API
15:23:19 <matrohon> vthapar, If you have any thoughs or requirement on the bgpvpn framework, don't hesitate to ping us
15:24:10 <matrohon> #topic ODL driver
15:24:18 <matrohon> we already talk about it
15:25:03 <matrohon> #info : the ODL team has to decide if the driver will live in the bgpvn repo or in the odl repo
15:25:24 <matrohon> #link https://review.openstack.org/#/c/231321/
15:25:45 <matrohon> #topic : Mitaka summit
15:26:10 <matrohon> vthapar : will you attend the next summit?
15:26:35 <vthapar> matrohon: don't think so.
15:26:49 <matrohon> vthapar, ok
15:27:32 <matrohon> Prem, will you?
15:28:00 <Prem> matrohon: I am not attending
15:28:16 <matrohon> Prem : ok
15:28:31 <matrohon> pcarver doesn't seem around
15:28:48 <matrohon> he use to follow how neutron schedule design sessions
15:29:15 <matrohon> the bgpvpn topic is still on the table : https://etherpad.openstack.org/p/neutron-mitaka-designsummit
15:29:38 <matrohon> but design sessions doesn't seem to be organized already
15:30:28 <matrohon> #topic drivers status
15:30:45 <matrohon> we already talked about ODL
15:31:06 <matrohon> doude doesn't seem available to talk about contrail
15:32:27 <matrohon> concerning bagpipe tmorin talked about what bagpipe agent needs to easily integrate the current neutron L2 agent
15:32:31 <matrohon> on the ML
15:32:57 <tmorin> yes, the discussion is in progress
15:33:33 <tmorin> the next step, I guess, is to describe an interface that the OVS agent would implement to let an extension access to some of the agents methods
15:33:59 <matrohon> tmorin do you have the link of the rfe's bug, in neutron
15:34:00 <tmorin> tmorin: the question is whether or not such an interface could be made OVS/linuxbridge agnostic
15:34:06 * matrohon seeking
15:34:37 <tmorin> #link hi armax, dougwig, mestery, I'm adding a job to kickstart devstack CI for networking-bgpvpn, the infra change is waiting for a review of a Neutron liaison
15:34:41 <tmorin> sorry
15:34:44 <tmorin> wrong copy-paste
15:34:45 <tmorin> :)
15:34:51 <tmorin> #link https://bugs.launchpad.net/neutron/+bug/1499637
15:34:52 <openstack> Launchpad bug 1499637 in neutron "An L2 agent extension can't access agent methods" [Undecided,Confirmed]
15:35:30 <matrohon> tmorin, thanks
15:36:00 <matrohon> #topic gate job
15:36:13 <matrohon> tmorin is working on jobs for the gate
15:36:28 <tmorin> yes, the bogus copy paste above is related
15:36:30 <matrohon> #info : tmorin is working on jobs for the gate
15:36:48 <matrohon> #link : https://review.openstack.org/#/c/230358/
15:36:55 <tmorin> we're starting with a gate experimental jobs to deploy networking-bgpvpn in a devstack, with the dummy driver
15:37:14 <tmorin> we'll follow with a job deploying bagpipe driver
15:37:36 <matrohon> tmorin : it will run in neutron or in bgpvpn?
15:37:41 <tmorin> and then with a job deploying bagpipe driver *and* running Neutron-related tempest tests
15:37:43 <matrohon> for the devstackk deployment
15:37:44 <tmorin> bgpvpn for now
15:37:53 <matrohon> tmorin : ok
15:38:06 <tmorin> having these jobs run in Neutron gate is something we have to work on as well
15:38:33 <matrohon> tmorin : once it will be stable, neutron should run it in its check queue
15:38:43 <matrohon> tmorin, +1
15:39:18 <tmorin> yes, and that should be also in networking-bagpipe-l2 queue
15:39:28 <matrohon> yep
15:39:44 <matrohon> #topic : Open discussion
15:40:09 <matrohon> if anybody wants to speak I leave the floor
15:40:55 <Prem> matrohon: tmorin: we plan to support vrouter data model for Be release
15:41:18 <tmorin> Prem: are you referring to bgpvpn-router associations ?
15:41:22 <matrohon> Prem : you mean the router attachment?
15:41:29 <Prem> yes
15:41:38 <matrohon> Prem : ok good to know
15:41:57 <Prem> I wanted to keep you posted on the same
15:42:06 <tmorin> any #help on implementing router associations in networking-bgp will be appreciated
15:42:09 <matrohon> #info : ODL team plans to support the router attachment in B release
15:42:14 <tmorin> #help on implementing router associations in networking-bgp will be appreciated
15:42:28 <Prem> matrohon: tmorin: Thanks
15:44:23 <matrohon> Ok I think we can close the meeting
15:44:24 <vthapar> tmorin, matrohon: on where to keep bgpvpn odl driver, will you take it up with Kyle/Armando? good to get Ryan's opinion too, he is th PTL for ODL NEutron
15:45:20 <Prem> +1, as mentioned earlier; we would need their support to move the driver code
15:45:59 <tmorin> vthapar: we can try to reach out to them
15:46:00 <matrohon> mestery, armax ping
15:46:13 <matrohon> maybe there are around
15:46:17 <mestery> matrohon: Hola
15:46:24 <mestery> Regarding bgpvpn odl driver? :)
15:46:26 <matrohon> they woke up early today
15:46:31 <matrohon> mestery : yep
15:46:41 <mestery> :)
15:46:51 <matrohon> vthapar, pushed it in networking-odl
15:46:55 <matrohon> repo
15:47:02 <mestery> matrohon: Does it make sense to keep it in networking-odl? That would be my first thought.
15:47:42 <matrohon> mestery : it will be easier for us to help maintaining it if it were in networking-bgpvpn
15:48:18 <mestery> matrohon: I'd be fine it was kept in networking-bgpvpn to be honest.
15:48:22 <mestery> To me, that's just fine.
15:48:30 <mestery> Does it depend on networking-odl?
15:48:36 <mestery> That's easy to do either way
15:48:37 <matrohon> bat apparently, this is a genral issue, that occurs also for the networkling-l2gw too
15:49:04 <matrohon> it seems to have a tiny dependency with net-odl
15:49:18 <matrohon> https://review.openstack.org/#/c/231321/
15:49:22 <matrohon> mestery : ^
15:49:26 * mestery looks
15:50:11 <mestery> matrohon: Seems simple enough
15:50:29 <mestery> matrohon: It may in fact make sense to add that into networking-odl after all, but I'm fine either way to be honest
15:51:24 <matrohon> vthapar, mestery, armax : As I said earlier this decision has to be made by the networking-odl team, wether you want to split your drivers or not
15:51:59 <mestery> matrohon: Yes, agreed. Perhaps an email is required to sync with folks?
15:52:38 <matrohon> vthapar, can you manage a sync email with people involved?
15:52:46 <armax> matrohon: it’s up to the bgp/odl teams to figure out
15:52:55 <vthapar> matrohon: will do.
15:53:23 <armax> I would think an ODL driver is part of the ODL repo
15:53:26 <matrohon> armax : the same issue seems to exist for the l2gw driver
15:53:43 <armax> imo drivers should be closer to the technology they use
15:54:06 <armax> it seems like that’s the path we set ourselves on
15:54:20 <matrohon> armax : I'm fine with that, but be aware taht it will be harder for us to help you maintain you driver
15:54:25 <armax> true
15:54:30 <armax> that’s a compromise
15:54:55 <armax> the only solution would be to have again a gigantic monolitic codebase :)
15:55:20 <matrohon> vthapar, mestery, armax : ok, we have an agreement so? no need a sync email
15:55:59 <armax> matrohon: maybe you have a provisional agreement?
15:56:43 <vthapar> matrohon: am okay. I believe this pain point of frequent updates will go once api is stable enough.
15:57:21 <matrohon> vthapar, +1, I hope
15:57:33 <matrohon> vthapar, at least this is our goal :)
15:57:57 <matrohon> let's leave the odl driver in odl repo
15:58:29 <matrohon> if you revert your decission, you can still submit a patch review with your driver in the bgpvpn repo
15:59:09 <matrohon> #agreed : The ODL driver will live in the networking-odl repo for the moment
15:59:16 <vthapar> sure, in case odl folks are not too keen on hosting till bgpvpn is stable enough I'll come with patch in networking-bgpvpn too
15:59:22 <matrohon> thanks all for attending the meeting
15:59:33 <matrohon> vthapar, +1
15:59:42 <matrohon> Bye
15:59:48 <matrohon> #endmeeting