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