17:00:30 <cathy_> #startmeeting service_chaining 17:00:31 <openstack> Meeting started Thu Aug 18 17:00:30 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:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:34 <openstack> The meeting name has been set to 'service_chaining' 17:01:17 <cathy_> hi everyone 17:01:26 <mohankumar> hi cathy_ 17:01:36 <georgewang> hi 17:01:50 <bcafarel> hi 17:02:27 <LouisF> hi 17:03:03 <cathy_> mohankumar: is vikram going to join? 17:03:09 <yamahata> hello 17:03:23 <mohankumar> cathy_ , no 17:03:37 <cathy_> ok, let's start 17:03:42 <fsunaval> hi all 17:04:16 <cathy_> #topic networking-sfc release 17:04:18 <LouisF> fsunaval: hi 17:04:55 <cathy_> Based on request from the community, we will have a new release. 17:06:49 <mohankumar> cathy_ , mitaka or newton branch ? 17:07:26 <pcarver> hi 17:07:31 <cathy_> Currently our code development is based on master branch. So any change on master branch will impact our code. Since we are going to have mikata based release. Anyone has any suggestion how we can base our code on stable/mitaka branch for preparing for the release? 17:07:46 <cathy_> fsunaval: pcarver hi 17:08:17 <cathy_> mohankumar: mitaka, then after Neutron pulled the Newton stable branch, we will release Newton 17:08:29 <mohankumar> okay cathy_ 17:09:51 <cathy_> yamahata: pcarver mohankumar georgewang Any suggestion ? 17:10:31 <cathy_> hi csun 17:10:41 <pcarver> cathy_: sorry, not my area of expertise 17:10:42 <georgewang> I think we should decide what change should be in mitaka release 17:11:01 <csun> Hi cahty_ 17:11:03 <cathy_> georgewang: yes. that is our second topic 17:11:14 <georgewang> after that we should make sure the code compatible with mitaka release 17:11:54 <cathy_> georgewang: is there an automatic way for enforcing that, such as through our gate testing? 17:12:45 <cathy_> georgewang: I am a little concerned whether our current networking-sfc code is a mixed code for Mitaka and Master 17:13:00 <cathy_> yamahata: how did ODL repo do this? 17:13:11 <georgewang> I think most code compatible with mitaka 17:13:36 <georgewang> after we decide the code to cut the release, 17:13:50 <georgewang> we should do manual tests to make sure it works in mitaka 17:14:04 <cathy_> hi s3wong 17:14:07 <s3wong> hello 17:14:21 <s3wong> cathy_: you are back! :-) 17:14:29 <cathy_> s3wong: yes:-) 17:15:24 <Vikram> Hi 17:15:40 <cathy_> OK, we need to do manual tests combined with automatic tests to ensure that our code is 100% compatible with Mitaka. 17:15:43 <Vikram> Sorry to be late 17:15:44 <cathy_> hi Vikram 17:16:26 <cathy_> Vikram: s3wong we are discussing how to ensure our code base is compatible with stable/mitaka code base since we are going to have a mitaka release. 17:16:39 <Vikram> Ok 17:16:52 <s3wong> cathy_: sure 17:17:25 <cathy_> Vikram: s3wong currently our code is based on master branch, any automatic way we can ensure our code to be compatible with stable/mitaka branch? 17:18:32 <Vikram> AFAIK, Separte Jerkin jobs run for master and stable branches 17:19:02 <Vikram> First we need to freeze the code for mitaka 17:19:41 <Vikram> I mean we got to create a stable Mitaka branch 17:20:03 <Vikram> For this Ihar need to help us out 17:20:11 <cathy_> Vikram: do you mean that we create a networking-sfc branch from the stable/mitaka branch? 17:21:06 <georgewang> I think that branch should be created by neutron release team, I mean gerrit branch 17:21:24 <cathy_> Vikram: My understanding is that the branch creation happens after we request for release, right? 17:21:29 <Vikram> cathy_, in the existing networking-sfc repo we need to create a separate branch called stable/mitaka 17:22:14 <LouisF> cathy_: currently the git has a liberty branch https://github.com/openstack/networking-sfc/tree/stable/liberty 17:22:22 <cathy_> Vikram: I understand that part. But my understanding is that this branch will be created after we request a release, right? 17:22:53 <Vikram> Yes 17:23:21 <Vikram> For that we got to provide the master branch last commit we want to release 17:23:22 <cathy_> After we request the release, then the stable/mitaka branch will be created and networking-sfc package will be released. 17:23:53 <georgewang> yes 17:24:00 <cathy_> But what I want is to make sure before we request the release, our code is compatible with OpenStack stable/Mitaka 17:25:10 <georgewang> that should be done by manual tests 17:25:13 <Vikram> What I suggest is we can test locally and make sure our code is compatible with mitaka 17:25:34 <Vikram> Code base 17:25:47 <cathy_> Vikram: OK, so we still need to go through the manual test 17:25:53 <Vikram> Yup 17:26:05 <cathy_> Vikram: yes, that is what we have been doing. 17:26:15 <Vikram> Ok 17:26:50 <Vikram> Do we have changes specific to Newton now? 17:27:13 <georgewang> not yet 17:27:17 <cathy_> OK, let's discuss the freeze commit, then we do one more round of local tests, and then let's not approve any more patches to be merged before the stable/mikata branch is pulled. 17:27:35 <Vikram> Aggreed 17:27:37 <mohankumar> cathy_ +1 17:27:57 <fsunaval_> ... 17:28:31 <Vikram> I suggest we can tag our patch sets accordingly 17:28:53 <Vikram> So that reviewer knows what is required for mitaka 17:29:17 <Vikram> Till the stable branch is not pulled 17:29:25 <cathy_> #agreed after the freeze commit for mitaka release, the team will do one more round of end-to-end tests for all test cases, and then let's not approve any more patches to be merged before we request the release and the stable/mikata branch is pulled. 17:30:32 <cathy_> Now let's go to the next topic: the freeze commit as well as other commits we would like to be included in the mitaka release 17:31:18 <cathy_> #topic the freeze patch for networking-sfc mitaka release 17:31:48 <cathy_> Here is the link to our current patches under review 17:31:53 <cathy_> #link https://review.openstack.org/#/q/networking-sfc+status:new 17:32:41 <cathy_> I think we need to get the following patches included in the mitaka release 17:32:58 <cathy_> let me know if you have different thought 17:33:01 <cathy_> #link https://review.openstack.org/#/c/355324/ 17:33:03 <Vikram> cathy_, I would suggest to mark the patch as WIP if we don't want them to land in mitaka 17:34:07 <cathy_> Vikram: +1 17:34:30 <cathy_> #link https://review.openstack.org/#/c/308274/ 17:35:23 <mohankumar> it may be correct link : https://review.openstack.org/#/q/project:openstack/networking-sfc+status:open 17:35:31 <LouisF> cathy_: that one needs ovs support 17:36:28 <Vikram> Yes I was also looking for that 17:36:55 <cathy_> how about this? I will mark all patches that do not need to be in as WIP off line. If anyone has different opinions, we can exchange via emails. I will send out an email to everyone working on networking-sfc listing all the patches that need to be in. 17:37:08 <LouisF> +1 17:37:14 <Vikram> +100 17:37:29 <cathy_> And let's review them as soon as possible. 17:37:30 <s3wong> +1 17:37:47 <Vikram> I have one question 17:37:58 <cathy_> Vikram: sure 17:38:06 <Vikram> I can find so many new features coming up.. 17:38:25 <Vikram> Do we have spec or design for those? 17:38:47 <Vikram> New CLI's are getting proposed as well 17:39:07 <cathy_> #action Cathy will mark all patches that do not need to be in the mitaka release as WIP offline. If anyone has different opinions, we can exchange via emails. 17:39:44 <cathy_> #action Cathy will send out an email to everyone working on networking-sfc listing all the patches that need to be in and everyone review them as soon as possible. 17:39:49 <LouisF> Vikram: which items do you feel need a spec? 17:40:20 <LouisF> Vikram: or that a spec is missing? 17:40:41 <Vikram> LouisF: I can find new few new CLI's coming the way 17:41:09 <cathy_> Vikram: I think we can update the spec to include them 17:41:12 <Vikram> And not able to digest the usecase or real scenario where they will be useful 17:41:16 <cathy_> the API/CLI spec 17:41:55 <Vikram> More, recently I found we have added port chain group parameter for ppg cmd 17:42:11 <Vikram> Which sounds little odd 17:42:37 <cathy_> Vikram: I think you mean port pair group param? 17:42:46 <Vikram> What is my concern here is whether we have already discussed about the new cli parameter or Api 17:42:51 <Vikram> Yes 17:43:27 <cathy_> You are talking about weight command 17:43:39 <cathy_> sorry I take it back 17:43:46 <Vikram> Let me check 17:44:13 <Vikram> I cannot find now.. Sorry 17:44:29 <Vikram> I remember reviewing in the morning 17:44:38 <cathy_> Let's discuss this via email when we have time to find them. 17:44:39 <Vikram> No problem cathy_ 17:44:55 <Vikram> Ok 17:45:33 <LouisF> Vikram: are you refering to https://review.openstack.org/#/c/355324/ 17:45:58 <Vikram> Thanks LouisF 17:46:37 <Vikram> I just felt the proposed cmd arg is not good 17:47:08 <cathy_> Vikram: maybe you can suggest a better arg? 17:47:30 <Vikram> I will try cathy_ 17:47:55 <cathy_> I think we need this addition since some attributes apply to all functional like SFs in a group. 17:48:05 <Vikram> May be I might be wrong but that was my feeling 17:48:25 <LouisF> you mean port-pair-group-parameters in https://review.openstack.org/#/c/355324/4/networking_sfc/cli/port_pair_group.py 17:48:37 <cathy_> Anyway I think some good explanation/clarification in the commit message will help 17:49:02 <Vikram> LOUISF, exactly 17:49:31 <LouisF> Vikram: can you suggest an alternative syntax 17:49:39 <Vikram> To me port-pair-group looks redundant as we are already inside the cmd 17:50:18 <Vikram> I cannot think now. 17:50:22 <LouisF> Vikram: i think it was done for consistency with the PC and PP parameter names 17:50:28 <Vikram> Will try.. 17:50:37 <Vikram> Ohhh 17:50:53 <Vikram> I didn't looked at other cmds 17:51:02 <Vikram> I will recheck 17:51:11 <LouisF> Vikram: ok thanks 17:51:21 <cathy_> Vikram: ok, we can finalize the cmd via the patch review. 17:51:33 <Vikram> LouisF: Thanks for the explanation 17:51:38 <cathy_> we do not have much time left. Any other topic you have in mind 17:51:50 <Vikram> Ok cathy_ 17:52:03 <LouisF> s3wong: how is the tacker/sfc driver work? 17:52:26 <cathy_> #topic tacker/sfc driver status 17:53:03 <cathy_> s3wong: how is the work going with Tacker on VNF Manager functionality? 17:53:12 <s3wong> LouisF: not much progress --- given that tacker python client will release first, sridhar_ram asked me to first focus on reviewing trozet's VNFFG patchset 17:54:04 <s3wong> cathy_, LouisF: so we will finalize the APIs / TOSCA template format of initial phase 1 release of VNFFG on Tacker 17:55:07 <cathy_> s3wong: what functions can the VNF Manager manages now? Are there generic APIs for people to automatically create and configure a type of SF via the VNF Manager? 17:55:20 <s3wong> cathy_, LouisF: in terms of code change, the one I know of is to make networking_sfc_driver into a mixIn with OpenStack driver, as the driver needs to be aware of which VIM it is running 17:56:11 <s3wong> cathy_: lifecycle management of VNF is the most basic functionality of Tacker 17:56:14 <LouisF> s3wong: what is the patch number? 17:57:03 <s3wong> LouisF: same two: https://review.openstack.org/#/c/347563/ and https://review.openstack.org/#/c/347568/ 17:57:10 <LouisF> s3wong: thanks 17:57:53 <s3wong> LouisF: will try to update sometime this week. May be able to do some integration test with trozet's VNFFG plugin, don't know yet 17:58:10 <cathy_> s3wong: so you mean there are already generic APIs for people to automatically create and configure a type of SF via the VNF Manager 17:58:56 <s3wong> cathy_: yes --- type of service is the basic VNFM schema 17:59:21 <LouisF> s3wong: i will look for updates and review 17:59:28 <cathy_> s3wong: could you send me a link to that? 17:59:36 <s3wong> LouisF: thanks --- you are on the reviewers list :-) 17:59:47 <LouisF> s3wong: yes 17:59:56 <trozet> cathy_: what are you looking for? this? https://review.openstack.org/#/c/344522/ 18:00:12 <mohankumar> bye 18:00:18 <cathy_> trozet: VNF manager 18:00:31 <cathy_> Ok, I will contact you later via email. 18:00:35 <cathy_> We are running out of time. 18:00:40 <cathy_> bye for now 18:00:46 <LouisF> trozet: thx 18:00:47 <s3wong> cathy_: one example can be found here: https://github.com/openstack/tacker/blob/master/samples/tosca-templates/vnfd/tosca-config-openwrt-with-firewall.yaml 18:00:56 <fsunaval_> bye 18:01:00 <LouisF> bye 18:01:02 <bcafarel> bye 18:01:10 <cathy_> #endmeeting