17:00:10 <cathy__> #startmeeting service_chaining 17:00:10 <openstack> Meeting started Thu Jan 7 17:00:10 2016 UTC and is due to finish in 60 minutes. The chair is cathy__. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:14 <openstack> The meeting name has been set to 'service_chaining' 17:00:30 <pcarver> hi 17:00:34 <cathy__> pcarver: hi 17:01:58 <igordcard_> hi 17:02:43 <johnsom> o/ 17:02:46 <LouisF> hi 17:03:16 <cathy__> igordcard_: johnsom LouisF Hi 17:03:21 <cathy__> let's start 17:03:28 <cathy__> I have 3 topics in mind 1. OVS driver patch, OVS agent patch, updated FC API patch, 2. the Networking-sfc bug page, 3. 1. Make “source Neutron port” a mandatory field in the Flow classifier API. 17:03:33 <cathy__> s3wong: hi 17:03:41 <cathy__> any other topic you would like to discuss 17:03:52 <s3wong> hello 17:04:26 <cathy__> #topic OVS driver patch, OVS agent patch, updated FC API patch 17:05:24 <cathy__> These are the patches that need to be merged so that we can get ready for code release. Can we get the review completed by mid next week? 17:06:35 <georgewang> hi 17:06:52 <cathy__> The OVS driver patch and OVS agent patch have been open for review for a long time, probably over 3 months 17:07:03 <LouisF> cathy__: those patches have been out for review for some time 17:07:19 <pcarver> I've started looking through them. I'll get through the rest of it soon. 17:07:26 <cathy__> LouisF: yes, for quite a long time. 17:07:30 <cathy__> pcarver: thanks! 17:08:20 <cathy__> s3wong: I remember you have posted some comments before and those comments should have been addressed. Could you go through the latest patches again? 17:08:32 <cathy__> georgewang: hi 17:10:27 <georgewang> we will go through all comments and try to resolve them ASAP 17:10:55 <cathy__> It seems s3wong got disconnected. 17:11:09 <cathy__> georgewang: thanks! 17:11:25 <georgewang> BTW, if the issue is small like code style and formatting, should we left them fixed after these patches? 17:11:26 <s3wong> cathy__: I am here :-) 17:11:30 <cathy__> s3wong: I remember you have posted some comments before and those comments should have been addressed. Could you go through the latest patches again? 17:11:41 <georgewang> to make things move faster 17:11:45 <s3wong> cathy__: OK 17:12:10 <cathy__> s3wong: let's shoot for getting these patches review completed by mid next week. OK with you? 17:12:20 <s3wong> cathy__: sure 17:12:26 <cathy__> s3wong: Thanks! 17:13:09 <cathy__> georgewang: yes if the issue is minor like style and formatting, we can fix them later after the main patches are merged. 17:13:31 <cathy__> georgewang: to make things move faster as you said:-) 17:14:02 <cathy__> #topic the Networking-sfc bug page 17:14:19 <cathy__> here is the bug page link https://launchpad.net/networking-sfc 17:14:47 <cathy__> Sukhdev: hi, welcome to join the service_chaining meeting ! 17:15:40 * Sukhdev just lurking around 17:15:52 <cathy__> igordcard_: I see that you opened some bugs. I think those should be fixed. Could you check them again and update the bug status? 17:17:08 <igordcard_> cathy__: haven't had trouble again, so I'll close them 17:17:19 <cathy__> igordcard_: great. Thanks! 17:17:37 <LouisF> cathy__: those 2 buds are related to packaging for rpm and debian 17:17:42 <LouisF> bugs 17:17:59 <cathy__> The other 2 bugs are opened by Ramanjaneya Reddy Palleti. He does not seem to call in the meeting today. 17:18:24 <pcarver> I wonder how much work is needed for packaging and how much happens automatically by leveraging existing infrastructure 17:18:24 <cathy__> LouisF: yes. I think there are patches for these two bugs, right? 17:19:15 <pcarver> Theoretically, when we're ready for a release it should leverage existing automation to publish packages to PyPI 17:19:42 <cathy__> pcarver: yes, I think so too 17:20:12 <cathy__> pcarver: let me talk with Ramanjaneya Reddy Palleti offline on this. 17:20:58 <cathy__> #topic service chaining feature release process 17:21:42 <LouisF> cathy__: yes i believe there are 17:22:13 <cathy__> We have completed all the UT and also over 60 end-to-end SFC test cases including the test cases for cross-subnet SFC. We have also fixed most bugs found. We will fix the few left by end of this week. 17:23:26 <cathy__> After that and after the remaining 3 patches are merged, I will start working with Neutron team on releasing this feature in the M cycle time frame. Sounds Ok to everyone? 17:23:50 <pcarver> cathy__: sounds good 17:24:01 <johnsom> Sounds great 17:24:01 <cathy__> of course, during this process, we will continue testing and fixing bugs. 17:25:04 <prithiv> it would be better to add the instructions and steps to deploy the chain 17:25:16 <igordcard_> cathy__ pcarver LouisF can you provide sample working CLI calls to deploy a basic chain? 17:25:20 <prithiv> could be helpful for someone looking at it for the first time 17:25:22 <cathy__> #agreed We have completed all the UT and also over 60 end-to-end SFC test cases including the test cases for cross-subnet SFC.After that and after the remaining 3 patches are merged, Cathy will start working with Neutron team on releasing this feature in the M cycle time frame 17:25:48 <LouisF> igordcard_: yes will do that 17:25:52 <cathy__> igordcard_: prithiv yes, will do 17:26:11 <pcarver> igordcard_: That's already in the devref, although maybe needs a little tweaking 17:26:15 <prithiv> thanks cathy. 17:26:32 <igordcard_> thank you 17:26:45 <LouisF> to release to mitaka need to add release request patch to release repo 17:27:29 <pcarver> it may not be linked obviously enough. I'll take a look at the docs and see if it needs to be linked to more obviously 17:27:39 <LouisF> https://github.com/openstack/releases/ 17:28:57 <cathy__> LouisF: I am thinking about following the neutron sub project release guide page. I will take a look at this link too. thanks 17:29:10 <cathy__> #topic Make “source Neutron port” a mandatory field in the Flow classifier API. 17:29:29 <LouisF> see https://github.com/openstack/releases/blob/master/doc/source/instructions.rst 17:30:22 <cathy__> We found an issue in a specific cross-subnet SFC testing scenario (other cross-subnet scenarios work fine, just this specific scenario). 17:30:54 <prithiv> could you give a brief detail about the scenario 17:31:01 <cathy__> LouisF: would you like to describe the scenario and root cause? 17:31:54 <cathy__> let me describe it here. 17:32:53 <cathy__> When a SFC spans across multiple subnets, a vRouter comes into the picture. For example, suppose the chain is as follows: source VM in subnet 1 àSF1 in subnet 1àdestination VM in subnet 2. If the vRouter, which connects subnet1 with subnet 2, runs on the same compute node as the source VM, then the OVS on the source VM compute node needs to distinguish the traffic that comes from the source VM from the traffic that come 17:33:11 <LouisF> the issue is related to the case where the final destination is in a different subnet from the last SF 17:33:13 <cathy__> different. If the traffic comes from the source VM, the next hop is SF1, and if the traffic comes from the vRouter, the next hop is destination VM. One way to distinguish this is through the source port of the traffic since their source port will be different. 17:33:51 <pcarver> igordcard_: this is what I was thinking of http://docs.openstack.org/developer/networking-sfc/system_design%20and_workflow.html#port-chain-creation-workflow let me know if that's what you're looking for regarding CLI for setting up a chain. 17:35:28 <cathy__> let me take a look at the link 17:36:07 <igordcard_> pcarver: yes, would that work today? 17:36:32 <pcarver> igordcard_: I think so, but I've been having unrelated lab issues that I've needed to take care of. 17:37:30 <igordcard_> and by the way, let me ask a question: ingress and egress ports are named from the perspective of one SF right? I.e. ingress port is the port through which traffic gets into the SF, and egress is the one through each it gets out of the SF, correct? 17:37:53 <igordcard_> through which* 17:37:56 <cathy__> igordcard_: that should work. This issue is very specific to cross-subnet SFC in which the vRouter and the SRC VM are located on the same compute node and also the vRouter's next hop is destination VM. 17:38:05 <LouisF> igordcard_: correct 17:39:05 <igordcard_> thanks 17:39:17 <LouisF> the issue will not occur on production networks where the router is located on a network node separate from the computer nodes 17:39:17 <cathy__> if the vRouter and the source VM are not located on the same node, then it works fine. 17:39:28 <cathy__> LouisF: yes 17:41:07 <cathy__> So to fix this problem, we can make the source neutron port a mandatory field in the API. Since once the OVS knows the source port of the source VM, then it can distinguish the traffic coming out of the source VM from the traffic coming out of the vRouter and can resolve this issue 17:41:39 <Swami> LouisF: that may not be always true, since in the case of dvr the routers will be running in compute node. 17:42:19 <LouisF> swami yes, is dvd is enabled that will be an issue 17:42:23 <LouisF> if 17:43:01 <Swami> LouisF: then we need to resolve this issue with dvr as well 17:43:23 <cathy__> Swami: Once we make the source neutron port a mandatory field in the API, this issue will be resolved 17:43:45 <LouisF> cathy__: right 17:43:46 <igordcard_> So with this change it won't be possible to match on traffic coming from any place? 17:43:56 <Swami> cathy__: what it takes to make the neutron port a mandatory filed. 17:44:08 <cathy__> Swami: since the OVS can distinguish the traffic coming from the source and the traffic coming from the vRouter due to they have different source port 17:44:13 <Swami> s/filed/field 17:44:27 <cathy__> Swami: just add a check in the API, simple 17:44:55 <Swami> cathy__: ok, just wanted to make sure that it is interoperable with dvr and nothing is let loose. 17:44:59 <cathy__> Swami: actually there have been suggestions before to make the source neutron port a mandatory field to enhance scalability. 17:45:10 <cathy__> Swami: yes, it is 17:45:20 <Swami> cathy__: thanks 17:45:34 <cathy__> so one stone killing two birds:-) 17:46:45 <LouisF> igordcard_: when you mean any place is that from any vm in the tenant network? 17:46:57 <cathy__> If no disagreement, then we will update the FC API updated patch to add this check and also update the OVS Agent patch accordingly to use this source port to distinguish the traffic 17:47:00 <igordcard_> LouisF: for example, yes 17:48:36 <LouisF> in that case the VMs are known and their ports can be added using a FC update to a port chain 17:48:57 <cathy__> if you have any comment or have a better suggestion of fixing this issue, please post your comments in the patches after the meeting. 17:50:01 <igordcard_> okay 17:52:01 <LouisF> cathy__: i think this a workable solution for this release, if is becomes an issue it can revisited later as we get more experience with the different use cases 17:52:48 <cathy__> BTW, our FC API allows multiple IP addresses and multiple ports in the flow classification criteria, but our codes currently only select one IP from the set, which is a bug. The patch https://review.openstack.org/#/c/263003/ is mainly to correct this. 17:53:02 <cathy__> LouisF: agree. 17:53:32 <cathy__> Any other topic you would like to discuss? 17:54:07 <LouisF> please review the OVS driver and agent patches 17:54:31 <cathy__> yes, let's try to get the review completed by mid next week. 17:55:02 <cathy__> here are the links to the 3 patches 17:55:13 <cathy__> https://review.openstack.org/#/c/227285/ https://review.openstack.org/#/c/233758/ https://review.openstack.org/#/c/263003/ 17:55:36 <cathy__> OK, if no more topic, let's end the meeting here. 17:56:04 <cathy__> Thanks everyone! let's continue our discussion next Thursday. 17:56:05 <LouisF> igordcard_: prithiv if there is anything unclear or missing from http://docs.openstack.org/developer/networking-sfc/system_design%20and_workflow.html#port-chain-creation-workflow please let us know 17:56:07 <cathy__> by now 17:56:38 <georgewang> bye 17:56:43 <pcarver> bye 17:56:51 <prithiv> thanks Louis 17:57:02 <prithiv> I will let you know 17:57:10 <cathy__> #endmeeting