15:01:54 <matrohon> #startmeeting bgpvpn
15:01:55 <openstack> Meeting started Tue Sep 22 15:01:54 2015 UTC and is due to finish in 60 minutes.  The chair is matrohon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:58 <doude> hi
15:01:58 <openstack> The meeting name has been set to 'bgpvpn'
15:02:07 <janscheurich> hi
15:02:15 * pc_m lurking
15:02:43 <matrohon> #topic announcement
15:03:15 <tmorin> hi everyone
15:03:18 <matrohon> thanks to pcarver We now have a doc page
15:03:54 <tmorin> +1 this help is very appreciated
15:04:01 <pcarver> I'm going to update the meeting page too. I've been doing some housekeeping.
15:04:18 <tmorin> this is really good, this was lacking
15:04:20 <pcarver> http://eavesdrop.openstack.org/#Networking_BGPVPN_meeting to include link to meeting logs and an agenda wiki page
15:04:47 <matrohon> pcarver : +1
15:05:25 <tmorin> yes, I guess we shouldn't put the agenda on the wiki, unless we regularly update it the IRC minutes are more useful
15:05:43 <janscheurich> Where can I find the doc page?
15:05:50 <pcarver> Well, we don't have to keep an agenda, but I think it would be helpful
15:06:22 <pcarver> janscheurich: it's linked from http://docs.openstack.org/developer
15:06:45 <pcarver> Under networking sub projects you'll see a new link to BGPVPN
15:06:55 <matrohon> pcarver : did your change https://review.openstack.org/#/c/226083/ affected the pypi package? your mentioned something about package managment in your mail
15:07:02 <janscheurich> pcarver: thanks
15:07:28 <pcarver> matrohon: Yes, one of the items in the sub-project creators guide was publishing to PyPI
15:07:46 <pcarver> I'm not completely sure exactly how it works, but I followed the instructions in the manual
15:08:16 <pcarver> I created an entry on PyPI called networking-bgpvpn and added the Jenkins/Zuul config provided in the OpenStack guide
15:08:29 <matrohon> this change did the work : https://review.openstack.org/#/c/225694/
15:09:44 <tmorin> is it documented somewhere, but I think I read that we may need Neutron main project core devs to "push the button" for us to do release
15:09:51 <pcarver> This: http://docs.openstack.org/infra/manual/creators.html#pypi and this http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases
15:10:24 <matrohon> pcarver : ok
15:10:30 <pcarver> tmorin: I think you're right. One of the steps was to make openstackci the owner of the PyPI
15:10:48 <matrohon> any other announcement anyone?
15:11:32 <tmorin> on bagpipe driver, yes, but this will wait for the driver-dedicated topic I guess
15:11:38 <matrohon> let's move on
15:11:56 <matrohon> #topic bgpvpn driver status
15:11:59 <matrohon> :)
15:12:14 <matrohon> so let's start with bagpipe
15:13:01 <matrohon> we merged the change that adapts the bagpipe driver to the association API
15:13:06 <matrohon> https://review.openstack.org/#/c/224154/
15:13:41 <tmorin> yes, so now  the bagpipe driver is useable again
15:13:41 <matrohon> tmorin and I tested it
15:13:57 <tmorin> it works fine with a vanilla OVS 2.4
15:14:23 <janscheurich> +1
15:14:41 <matrohon> I also updated my script to run the bagpipe driver with tha bgpvpn API and devstack :
15:14:49 <tmorin> anyone wanting to play with it can try and eventually ask for help if the info in the README s is not enough
15:15:05 <matrohon> https://github.com/mathieu-rohon/devstack-conf/tree/master/test_bgpvpn_bagpipe
15:16:12 <matrohon> any update for other drivers? ODL? Contrail?
15:16:20 <tmorin> an easy and light test consist in building two networks, with one VM on each, each network being associated to a distinct BGPVPN, and these BGPVPNs defined with the same RTs ; then you can ping between the two VMs and see MPLS packets on the wire
15:17:05 <tmorin> on ODL: we had a few short discussions with vishal last week
15:17:15 <tmorin> short clarifications easily resolved
15:17:16 <matrohon> tmorin : this is moreorless what my scripts are doing :)
15:17:27 <tmorin> matrohon :  yes :)
15:17:48 <tmorin> the ODL change is being reviewed, I did not check the status recently
15:18:30 <janscheurich> I don't have an update either
15:18:32 <tmorin> note that the ODL change essentially has the API and internals code, but not the quagga glue for the backend
15:18:49 <matrohon> tmorin : do you mean vthapar instead of vishal?
15:19:02 <matrohon> or vthapar is the irc name of vishar?
15:19:59 <janscheurich> matrohon: yes
15:20:27 <tmorin> matrohon: yes, same person
15:20:42 <matrohon> doude : any update for the opencontrail driver?
15:21:25 <matrohon> https://review.openstack.org/#/c/202806/
15:21:37 <doude> matrohon: no nothing musch too add. I did not work a lot on it last week
15:22:11 <matrohon> doude : do you think it is testable? what is missing?
15:24:10 <doude> matrohon: that review contains a PoC version that use a generic key/value store to store the bgpvpn resource
15:24:25 <doude> it works but it's not efficient
15:24:31 <matrohon> doude : ok
15:24:44 <doude> I'm working to add the resource into the contrail data model
15:25:26 <tmorin> do you want to do wait for that being done before merging ?
15:26:10 <tmorin> or do we want something that will work even with version of contrail not supporting the datamodel extension mirroring the BGPVPN and BGPVPN associations ?
15:26:32 <tmorin> we /might/ even want a driver that would support both...
15:27:39 <matrohon> doude : ^
15:28:23 <matrohon> tmorin, doude : personnaly, I'm not sure we should wait for a bgpvpn object in the contrail API
15:28:48 <tmorin> matrohon, doude: +1
15:28:58 <doude> I prefer to wait to implement the bgpvpn resource onto contrail side
15:29:03 <matrohon> tmorin, doude : I would go for a first release of bgpvpn with a OC driver that manages bgpvpns with key/value pair
15:29:29 <tmorin> doude: I think it would be nice to merge that and later extend the driver to use the specific datamodel extension if supported by the contrail API
15:29:31 <doude> no I prefer to wait
15:29:47 <tmorin> doude: when would the new datamodel appear, in which contrail release ?
15:29:56 <doude> no because we will support that PoC version which is very unefficient
15:30:13 <doude> tmorin: I'll propose that on master
15:30:33 <doude> so the release after the merge
15:30:53 <tmorin> doude: which is ? (roughly ?)
15:31:25 <doude> I don't know. Contrail does not have a precise release roadmap
15:31:31 <tmorin> tmorin: it's true that supporting both transparently is complex (unless you migrate data from the k/v store to the new model, you have to read in both, which is not nice at all)
15:31:38 <tmorin> doude: ok
15:32:23 <matrohon> we can still deprecate the first version, and mention its caveats and drawback in the README
15:32:47 <tmorin> doude: while I would rule out doing and supporting a driver that would be able to do both, I think we may publish an experimental driver using the K/v store, explicitly marked as soon-to-be-obsoleted
15:32:57 <tmorin> matrohon: +1 yes, exactly
15:33:36 <doude> if you want
15:33:52 <tmorin> making it explict that it won't be supported and that no means will be provided to migrate to the new mechanism
15:35:30 <matrohon> #agreed : we'll have a first release of the contrail driver based on Key/value pair
15:35:38 <matrohon> let's move forward
15:36:02 <tmorin> by the way, it would be nice to augment the doc with a brief status of each driver and proper pointers to the doc of each driver
15:36:17 <tmorin> currently the different READMEs are not in the best places
15:36:20 <matrohon> tmorin, janscheurich can you provide us a status of the static route discussion
15:36:33 <tmorin> README-bagpipe.rst is at the root, should probably be under doc
15:36:45 <matrohon> tmorin : +1
15:36:53 <tmorin> Contrail's is in the source in the directory for the driver, should probably be under doc as well
15:37:15 <tmorin> anyone willing to sort this out is welcome
15:37:36 <tmorin> we also need to move the spec definition under the doc directory as well
15:37:53 <tmorin> even if we keep the current gerrit change open as a useful place for discussion
15:39:34 <matrohon> janscheurich, tmorin : static-routes?
15:39:43 <janscheurich> matrohon: sure
15:40:26 <tmorin> janscheurich: go ahead if you want
15:40:32 <janscheurich> Discussion between tmorin and myself homing in on alternative to add static routes to the port association
15:40:33 <matrohon> #topic static routes
15:41:10 <tmorin> yes, we converge on the idea that it is a clean approach to define a static route
15:41:12 <janscheurich> coupling the blueprints for port association and static routes
15:41:58 <tmorin> a static route for prefix a.b.c.d/f in BGPVPN Z with Port X as the nexthop, would be defined as an attribute of an association of Port X with BGPVPN Z
15:42:24 <tmorin> that will require to define Port associations slightly differently to how Network associations currently are defind
15:42:39 <janscheurich> appears to be the simplest and most flexible alternative, not overloading any exiting Neutron feature
15:42:46 <tmorin> Network associations do not have their own uuid, and can't have their own attributes
15:43:08 <janscheurich> Can you remind me why not?
15:43:09 <tmorin> Port associations will need to have a uuid and be defined as "full" sub-resources of a BGPVPN resource
15:43:52 <matrohon> janscheurich, theres is no network-association object
15:43:53 <tmorin> janscheurish: not created with a POST, but just with action on another resource
15:44:18 <matrohon> janscheurich, only a associate-network verb/action
15:44:35 <janscheurich> yes, but there is a dedicated table for network association objects anyhow, or?
15:44:36 <matrohon> so for port-association we would nedd an object?
15:45:13 <matrohon> janscheurich, yep and so it would not be so hard to have a dedicated object, I agree...
15:45:34 <tmorin> we also discussed and converged on the idea that for Router association, we should have a flag to say that extra_routes of the Router should be advertized in the BGPVPN, and that this would be better done as an attribute of the Router association
15:46:11 <tmorin> leading us to think that we should change the spec and make a Router association a sub resource of a BGPVPN (POST, its own uuid, etc.)
15:46:29 <matrohon> humm, so we need a port-association object, a router association object...
15:46:39 <tmorin> matrohon: yes
15:46:46 <matrohon> we should move to a network association object to be consistent...
15:46:48 <janscheurich> if we can avoid to have a dedicated object for port/router association, I would be in favor of that. I still don't fully understand why its necessary
15:46:57 <tmorin> matrohon: this is also my thinking
15:47:30 <tmorin> matrohon: we are early enough to do this change, will be much harder later when/if we discover we want an attribute on a Network association
15:47:33 <matrohon> janscheurich, it's usefull to manage attribute of those association exposed by the API
15:47:49 <matrohon> tmorin, +1
15:48:36 <tmorin> janscheurich: this is strongly related to the tool available inside Neutron to model API objects,  we can't "cleanly"  update attributes of an object which does not have its own uuid
15:48:37 <janscheurich> Using UPDATE methods?
15:49:03 <tmorin> janscheurich: yes (well PUT, that is)
15:49:11 <janscheurich> tmorin: ok
15:49:12 <matrohon> janscheurich, UPDATE methods are already used for those actions
15:49:36 <tmorin> janscheurich: and to do that we need to expose the resource as a sub resource
15:50:17 <tmorin> matrohon: yes, but this is an update of a BGPVPN resource, Neutron internals know nothing about association objects
15:50:38 <matrohon> having sub-resource is much more flexible. As we can see, we easily find some use cases were attributes for associations are useful
15:52:11 <matrohon> so we will have CRUD operation for associations...
15:52:45 <matrohon> let's think about it for a week, and see if there is no caveat about this wrokflow
15:52:53 <tmorin> the good news is that we can change that without having to change the drivers
15:52:57 <tmorin> matrohon: agreed
15:53:14 <matrohon> tmorin +1
15:53:30 <matrohon> even the db, has it already exist
15:53:36 <janscheurich> The change would not impact the drivers?
15:54:00 <tmorin> matrohon: we'll need the association uuids in the db I think
15:54:37 <tmorin> #agreed: make all association sub-resources of a BGPVPN resource with their own UUID (sleep on it for a week then act)
15:54:39 <matrohon> janscheurich, not so much, we will propably just update the netassociate_postcommit with the bgpvpn entire object in place of its id
15:56:23 <matrohon> janscheurich, not so sure... we will probably have associationupdate/del/add_postcommit methods
15:56:50 <janscheurich> matrohon: I was afraid of that....
15:57:32 <tmorin> let's think about it, we can easily "transparently" map add/del to the current associate/disassociate
15:57:39 <matrohon> janscheurich, I'm not sure it is useful for the netassociation since it doesn't have any attribute so far
15:58:11 <tmorin> update is different, but until we have an actual driver implementing an association that has an attribute that can be updated, we don't have any migration to support
15:58:20 <matrohon> I'll work on that this week, and hope to ahave a patch up for review before next meeting
15:58:24 <tmorin> nothing unmanageable I think
15:58:31 <janscheurich> sounds good!
15:58:34 <tmorin> matrohon: good :)
15:58:48 <matrohon> 2 min left
15:58:56 <matrohon> #topic open discussions
15:59:02 <matrohon> anyone?
15:59:07 <tmorin> one thing to mention: OPNFV
15:59:52 <tmorin> Tim (and others) have kicked off an SDNVPN project inside OPNFV, that can be seen as the OPNFV counterpart of what we do here
16:00:05 <tmorin> everyone encouraged to have a look of what happens there
16:00:12 <matrohon> tmorin : great
16:00:14 <tmorin> #link http://meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-09-01-13.59.html
16:00:27 <matrohon> we''re out of time
16:00:32 <matrohon> thanks everyone
16:00:37 <janscheurich> I'm trying to keep in sync with Tim here
16:00:37 <matrohon> #endmeeting