15:01:54 #startmeeting bgpvpn 15:01:55 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:58 hi 15:01:58 The meeting name has been set to 'bgpvpn' 15:02:07 hi 15:02:15 * pc_m lurking 15:02:43 #topic announcement 15:03:15 hi everyone 15:03:18 thanks to pcarver We now have a doc page 15:03:54 +1 this help is very appreciated 15:04:01 I'm going to update the meeting page too. I've been doing some housekeeping. 15:04:18 this is really good, this was lacking 15:04:20 http://eavesdrop.openstack.org/#Networking_BGPVPN_meeting to include link to meeting logs and an agenda wiki page 15:04:47 pcarver : +1 15:05:25 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 Where can I find the doc page? 15:05:50 Well, we don't have to keep an agenda, but I think it would be helpful 15:06:22 janscheurich: it's linked from http://docs.openstack.org/developer 15:06:45 Under networking sub projects you'll see a new link to BGPVPN 15:06:55 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 pcarver: thanks 15:07:28 matrohon: Yes, one of the items in the sub-project creators guide was publishing to PyPI 15:07:46 I'm not completely sure exactly how it works, but I followed the instructions in the manual 15:08:16 I created an entry on PyPI called networking-bgpvpn and added the Jenkins/Zuul config provided in the OpenStack guide 15:08:29 this change did the work : https://review.openstack.org/#/c/225694/ 15:09:44 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 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 pcarver : ok 15:10:30 tmorin: I think you're right. One of the steps was to make openstackci the owner of the PyPI 15:10:48 any other announcement anyone? 15:11:32 on bagpipe driver, yes, but this will wait for the driver-dedicated topic I guess 15:11:38 let's move on 15:11:56 #topic bgpvpn driver status 15:11:59 :) 15:12:14 so let's start with bagpipe 15:13:01 we merged the change that adapts the bagpipe driver to the association API 15:13:06 https://review.openstack.org/#/c/224154/ 15:13:41 yes, so now the bagpipe driver is useable again 15:13:41 tmorin and I tested it 15:13:57 it works fine with a vanilla OVS 2.4 15:14:23 +1 15:14:41 I also updated my script to run the bagpipe driver with tha bgpvpn API and devstack : 15:14:49 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 https://github.com/mathieu-rohon/devstack-conf/tree/master/test_bgpvpn_bagpipe 15:16:12 any update for other drivers? ODL? Contrail? 15:16:20 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 on ODL: we had a few short discussions with vishal last week 15:17:15 short clarifications easily resolved 15:17:16 tmorin : this is moreorless what my scripts are doing :) 15:17:27 matrohon : yes :) 15:17:48 the ODL change is being reviewed, I did not check the status recently 15:18:30 I don't have an update either 15:18:32 note that the ODL change essentially has the API and internals code, but not the quagga glue for the backend 15:18:49 tmorin : do you mean vthapar instead of vishal? 15:19:02 or vthapar is the irc name of vishar? 15:19:59 matrohon: yes 15:20:27 matrohon: yes, same person 15:20:42 doude : any update for the opencontrail driver? 15:21:25 https://review.openstack.org/#/c/202806/ 15:21:37 matrohon: no nothing musch too add. I did not work a lot on it last week 15:22:11 doude : do you think it is testable? what is missing? 15:24:10 matrohon: that review contains a PoC version that use a generic key/value store to store the bgpvpn resource 15:24:25 it works but it's not efficient 15:24:31 doude : ok 15:24:44 I'm working to add the resource into the contrail data model 15:25:26 do you want to do wait for that being done before merging ? 15:26:10 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 we /might/ even want a driver that would support both... 15:27:39 doude : ^ 15:28:23 tmorin, doude : personnaly, I'm not sure we should wait for a bgpvpn object in the contrail API 15:28:48 matrohon, doude: +1 15:28:58 I prefer to wait to implement the bgpvpn resource onto contrail side 15:29:03 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 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 no I prefer to wait 15:29:47 doude: when would the new datamodel appear, in which contrail release ? 15:29:56 no because we will support that PoC version which is very unefficient 15:30:13 tmorin: I'll propose that on master 15:30:33 so the release after the merge 15:30:53 doude: which is ? (roughly ?) 15:31:25 I don't know. Contrail does not have a precise release roadmap 15:31:31 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 doude: ok 15:32:23 we can still deprecate the first version, and mention its caveats and drawback in the README 15:32:47 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 matrohon: +1 yes, exactly 15:33:36 if you want 15:33:52 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 #agreed : we'll have a first release of the contrail driver based on Key/value pair 15:35:38 let's move forward 15:36:02 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 currently the different READMEs are not in the best places 15:36:20 tmorin, janscheurich can you provide us a status of the static route discussion 15:36:33 README-bagpipe.rst is at the root, should probably be under doc 15:36:45 tmorin : +1 15:36:53 Contrail's is in the source in the directory for the driver, should probably be under doc as well 15:37:15 anyone willing to sort this out is welcome 15:37:36 we also need to move the spec definition under the doc directory as well 15:37:53 even if we keep the current gerrit change open as a useful place for discussion 15:39:34 janscheurich, tmorin : static-routes? 15:39:43 matrohon: sure 15:40:26 janscheurich: go ahead if you want 15:40:32 Discussion between tmorin and myself homing in on alternative to add static routes to the port association 15:40:33 #topic static routes 15:41:10 yes, we converge on the idea that it is a clean approach to define a static route 15:41:12 coupling the blueprints for port association and static routes 15:41:58 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 that will require to define Port associations slightly differently to how Network associations currently are defind 15:42:39 appears to be the simplest and most flexible alternative, not overloading any exiting Neutron feature 15:42:46 Network associations do not have their own uuid, and can't have their own attributes 15:43:08 Can you remind me why not? 15:43:09 Port associations will need to have a uuid and be defined as "full" sub-resources of a BGPVPN resource 15:43:52 janscheurich, theres is no network-association object 15:43:53 janscheurish: not created with a POST, but just with action on another resource 15:44:18 janscheurich, only a associate-network verb/action 15:44:35 yes, but there is a dedicated table for network association objects anyhow, or? 15:44:36 so for port-association we would nedd an object? 15:45:13 janscheurich, yep and so it would not be so hard to have a dedicated object, I agree... 15:45:34 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 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 humm, so we need a port-association object, a router association object... 15:46:39 matrohon: yes 15:46:46 we should move to a network association object to be consistent... 15:46:48 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 matrohon: this is also my thinking 15:47:30 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 janscheurich, it's usefull to manage attribute of those association exposed by the API 15:47:49 tmorin, +1 15:48:36 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 Using UPDATE methods? 15:49:03 janscheurich: yes (well PUT, that is) 15:49:11 tmorin: ok 15:49:12 janscheurich, UPDATE methods are already used for those actions 15:49:36 janscheurich: and to do that we need to expose the resource as a sub resource 15:50:17 matrohon: yes, but this is an update of a BGPVPN resource, Neutron internals know nothing about association objects 15:50:38 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 so we will have CRUD operation for associations... 15:52:45 let's think about it for a week, and see if there is no caveat about this wrokflow 15:52:53 the good news is that we can change that without having to change the drivers 15:52:57 matrohon: agreed 15:53:14 tmorin +1 15:53:30 even the db, has it already exist 15:53:36 The change would not impact the drivers? 15:54:00 matrohon: we'll need the association uuids in the db I think 15:54:37 #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 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 janscheurich, not so sure... we will probably have associationupdate/del/add_postcommit methods 15:56:50 matrohon: I was afraid of that.... 15:57:32 let's think about it, we can easily "transparently" map add/del to the current associate/disassociate 15:57:39 janscheurich, I'm not sure it is useful for the netassociation since it doesn't have any attribute so far 15:58:11 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 I'll work on that this week, and hope to ahave a patch up for review before next meeting 15:58:24 nothing unmanageable I think 15:58:31 sounds good! 15:58:34 matrohon: good :) 15:58:48 2 min left 15:58:56 #topic open discussions 15:59:02 anyone? 15:59:07 one thing to mention: OPNFV 15:59:52 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 everyone encouraged to have a look of what happens there 16:00:12 tmorin : great 16:00:14 #link http://meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-09-01-13.59.html 16:00:27 we''re out of time 16:00:32 thanks everyone 16:00:37 I'm trying to keep in sync with Tim here 16:00:37 #endmeeting