18:01:01 #startmeeting gluon 18:01:02 Meeting started Wed Aug 30 18:01:01 2017 UTC and is due to finish in 60 minutes. The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:06 The meeting name has been set to 'gluon' 18:01:44 #topic Roll Call 18:01:51 #info Bin Hu 18:03:37 #topic Admin Update 18:03:56 #info Kamil Renczewski 18:04:12 #info Congratulations on everyone who have worked hard to make Gluon Pike Release 18:04:38 #info Gluon Pike Release is available https://github.com/openstack/gluon/tree/stable/pike 18:04:47 #info Tagged 1.1.0 18:05:33 #info Major features in Gluon Pike Release are: 18:05:46 #info (1) Proton Version Management 18:06:14 #info (2) Authentication and Authorization / RBAC 18:06:56 #info (3) Move many hardcoded constants in configuration proton.conf 18:07:20 #info (4) and bug fixes 18:07:40 #info Thank you everyone 18:07:56 #topic Planning for PoC in OpenStack Summit in Sydney 18:08:06 Hi Kamil, how are you? 18:08:17 Hi Bin, great thanks 18:08:29 glad you joined 18:08:42 Do you have any feedback regarding the PoC? 18:09:04 Not really, Sukhdev is on vacation 18:09:15 I see. 18:09:18 I was hoping that we can discuss some topics here 18:09:46 He will be back in two weeks if I remember vorrectly 18:09:46 I see. Did you get a chance to read the document I shared with you, regarding the scenario? 18:09:56 Yes, I did 18:10:03 Yup, middle of September 18:10:17 Any feedback on th scenario? 18:10:23 I have a question regarding creating L3VPN via Neutron 18:10:35 sure 18:10:38 Do you have any proposal about this? 18:11:11 I assume that normal scenario (with other SDNs) is done via etcd entries 18:11:38 But I am not sure how this could be done on with Neutron-Contrail calls 18:12:23 I am not familiar with how to create L3VPN via Neutron-Contrail calls, while in a proposal in the past, Nachi and Marco said they could. 18:12:45 Currently we have done great work to better integrate with neutron. New project is available here: https://launchpad.net/networking-opencontrail 18:13:05 That's why in the document, I left it open for your team. 18:13:30 I am aware of it. Is it the Mechanism Driver for Open Contrail to work with Neutron? 18:13:43 Previously what we did was to setup BGP peering, but AFAIK neutron don't have any stable API to do this 18:14:16 Yes, it is a new mechanism driver (build on top of the old one) 18:14:23 That's right, BGP peering between Contrail and ONOS, and ODL, VTS, Nuage etc. 18:14:55 Yes, the new Mechanism Driver will replace the old Monolithic Driver, as far as I know 18:15:25 Are you aware of this: https://docs.openstack.org/networking-bgpvpn/latest/ 18:15:29 I assume the new mechanism driver is based on the mechanism driver code that you developed, right? 18:15:45 Right 18:16:17 Yes, I am aware of this BGPVPN. 18:16:44 So the scenario will be: 18:17:33 On Gluon side, we create L3VPN through 1+ SDN-Cs 18:17:54 sai VPN Blue 18:18:26 On Contrail side, you can create / join this VPN Blue 18:18:59 Thus Contrail and other SDN-Cs will be able to share the same L3VPN (VPN Blue) 18:19:48 So we need to know - if it is possible to achieve this in Neutron/Contrail side 18:20:45 Whe it will be possible to test this scenario? 18:21:42 Setting up BGP peering is not a problem for me, but I am not sure if this will be possible via Neutron 18:22:19 We try to present this scenario in a PoC in early November in OpenStack Summit in Sydney 18:23:46 OK, but when do you plan to test it? 18:24:15 We already know the backend BGP peering is working. So this step is to make sure that at API level, the setup can be done via Gluon APIs and Neutron APIs (because Contrail chooses Mechanism Driver route) 18:24:55 If Contrail supports Shim Layer via Gluon, you need to go via Neutron 18:25:15 sorry I meant you don't need to go via Neutron 18:27:09 I think we need to stay with Neutron 18:28:15 That's fine, as long as you can achieve it via appropriate Neutron-Contrail calls 18:29:07 But then on Neutron-Gluon side, does Gluon will think that resource is Gluon and don't pass it to Neutron? 18:29:28 which resource? 18:30:24 I was thinking about step 2 and step 3 from PoC document 18:32:42 Step 2 is to create an VPN object owned by Gluon. The key here is the RT value (1000:1000 in the example), which will be passed by Gluon to SDN-C via etcd 18:34:26 I am not aware of similar API for Neutron 18:35:34 And I missed bgpeering API, but we also need to use bgppeering API to pass local_ip_address and peer_ip_address 18:35:56 so that SDN-C will be able to ping each other, and create the datapath 18:36:47 The step 3/step 4 will just create port which is also managed by Gluon 18:37:43 right 18:37:49 The step 5/6 to bind the port to VPN Blue with IP address in VPN Blue 18:38:42 Yes, that is clear for me 18:38:43 Therefore, in step 7/8 creates VMs with VPN port, meaning the VMs are in VPN Blue network, and they can communicate with each other 18:39:07 in this VPN Blue 18:39:13 #info JinLi 18:40:00 On Neutron side, equivalent thing should be for Neutron to pass the parameters (RT, local ip, peer ip) to Contrail so that Contrail can create the same data path for this VPN Blue 18:40:27 And I understand that all the steps are executed by Gluon and information about them goes to etcd, so there is no way to pass it via Neutron 18:40:46 No information is passed to Neutron 18:41:37 Thus we need the equivalent APIs in Neutron side to pass the same information (RT, loca ip and peer ip) to Contrail. Then Contrail can create data path with VPN Blue 18:41:40 So for Contrail we need additional calls to Neutron to setup VPN Blue 18:41:54 That's right 18:42:23 OK, I will try to look into Neutron 18:43:09 I also ask Sukhdev if he have something in mind about this. 18:43:29 Maybe Nachi too when Sukhdev is on vacation 18:44:06 I'll try with him also 18:44:18 Great, thank you. 18:44:48 The key here is the Neutron API that can pass those parameters 18:45:54 Let me know your input after you talk with Sukhdev/Nachi 18:46:09 OK 18:46:18 Thank you 18:46:56 #topic Planning for Gluon Queens and Beyond 18:48:00 As we discussed above, in order for Gluon to pass information to Neutron, we will consider to implement Gluon as Neutron service plugin 18:48:26 so that Gluon can reuse Neutron's DB, and store necessary information there. 18:49:56 This idea was discussed with Kevin in Boston, and we will discuss with Neutron team meeting in PTG, and look for feedback 18:52:15 #info (1) Refactor Gluon as Neutron Service Plugin - we will discuss it in Neutron PTG, and look for feedback 18:52:33 #info (2) Alignment with etcd3 18:53:11 #info (3) Improvement Shim Layer by removing hardcoded parts, and supports multiple models 18:54:19 #info (4) and bug fixes 18:54:46 Anything else everyone can think of? 18:56:35 How about you, Jin? 18:57:04 If nothing else, we can adjourn the meeting 18:57:22 #info meeting adjourned 18:57:25 #endmeeting