17:00:59 #startmeeting tacker 17:00:59 Meeting started Tue Dec 1 17:00:59 2015 UTC and is due to finish in 60 minutes. The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:02 The meeting name has been set to 'tacker' 17:01:11 #topic Roll Call 17:01:15 o/ 17:01:16 o/ 17:01:18 who is here for tacker ? 17:01:19 o/ 17:01:53 vishwanathj: bobh: sripriya: hi there! 17:02:08 sridhar_ram: good morning 17:02:21 good morning everyone 17:02:24 hello tackers 17:02:32 Hello all.. 17:02:43 lets starts in a min... 17:02:44 hello 17:03:49 #topic Agenda 17:03:55 #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Nov_30.2C_2015 17:04:15 #chair bobh sripriya 17:04:16 Current chairs: bobh sridhar_ram sripriya 17:04:25 #topic Announcment 17:05:04 A quick reminder on Mitaka Schedule.. 17:05:08 #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule 17:05:32 We are close to end of mitaka-1 dev cycle 17:06:22 as we have seen in other projects.. it is good to pack / pace up during the front end of a release cycle 17:06:43 so lets pick up some pace in reviewing the blueprints targeted for Mitaka ... 17:08:03 Lets see if we can land / merge the blueprints before the Dec holidays... approx Dec 2oth 17:08:09 *20th 17:08:42 I'd also like to remind we are still shooting for what is mentioned in the mitaka priorities... 17:08:45 #link https://etherpad.openstack.org/p/tacker-mitaka-priorities 17:09:24 We got to prioritize things aimed for Mitaka among various other things we could work on.. 17:09:27 any questions ? 17:10:02 lets move on... 17:10:09 Is there any development planned for monitoring feature? 17:10:19 sridhar_ram: 20th should be hopefully fine to land our blueprints 17:10:51 brucet: no, beyond what is done in Liberty - loadable health monitoring framework 17:11:04 sripriya: I sure believe we can...! 17:11:37 #topic Mitaka Blueprint Updates 17:11:53 #topic TOSCA parser integration 17:12:10 bobh: can you give a quick update ? 17:12:31 The tosca-parser blueprint was approved last week, so I need to get that code finished and landed 17:12:59 I have to write the heat-translator and tacker blueprints and get those going 17:13:37 I think the hard part will be the heat-translator work, but I need to look into that code more 17:14:09 bobh: sounds good.. 17:14:47 bobh: in fact, I'm curious how all this going to line up tacker --> tosca-parser --> heat-translator --> heat ... 17:15:00 bobh: looking forward to read your BPs ! 17:15:21 more like tosca-parser->heat-translator->tacker for the BP and code implementation path 17:15:35 bobh: I see 17:15:57 bobh: quick note... I actively participate in OASIS tosca-nfv adhoc group... 17:16:10 is there a link to the bp? 17:16:29 Same questin from me 17:16:32 bobh: I can help to clarify some of the normative type references 17:17:06 sridhar_ram: great - that will be a big help 17:17:15 tosca-parser BP is here: #link https://blueprints.launchpad.net/tosca-parser/+spec/tosca-nfv-support 17:17:23 bobh: thanks 17:17:29 heat-translator and tacker BPs are coming soon. 17:18:13 I was looking for link to heat-translator spec 17:18:21 Not yet 17:18:53 Is there a spec for the Heat translator for Yaml profile? 17:19:04 bobh: my biggest stick point is .. how we are going to co-exist with tosca-nfv profile and tacker related extensions 17:19:13 sorry, late --- didn't expect traffic to be this bad during holiday season 17:19:23 bobh: the later will be the way of life in the near term.. 17:19:24 sridhar_ram: that's a good question 17:19:47 bobh: if you can propose some solutions in the BPs .. that will be great 17:20:00 sridhar_ram: I'll see what I can come up with 17:20:25 bobh: great.. no need to go deep here in this mtg now, we can take it up once the BPs show up 17:20:31 bobh: thanks for the update! 17:20:39 bobh: anything else on tosca-parser ? 17:20:56 sridhar_ram: not at this point 17:21:06 #topic Tacker-SFC 17:21:29 trozet: s3wong: LouisF: hi sfc folks! 17:21:37 hi sridhar_ram 17:21:51 did I miss any tacker-sfc subgroup members ? ;-) 17:22:05 sridhar_ram: hi 17:22:29 sridhar_ram: cathy is at another meeting 17:22:40 LouisF: okay.. 17:22:48 Here is the BP #link https://review.openstack.org/#/c/228007/ 17:23:13 trozet: s3wong: I see some good comments in the spec and in the OPNFC-SFC mailer 17:23:33 I think it is time to start wrapping up the BP work... 17:23:55 yes 17:24:25 trozet: can you give us the major outstanding items to discuss and decide ? 17:25:00 sridhar_ram: i think the main thing that has been discussed some already is using abstract types 17:25:09 when defining the chain inpu 17:25:11 input* 17:25:39 sridhar_ram: I think you mentioned we want to keep the scope narrow and not automatically spin up VNFs if missing 17:25:58 trozet: yes, absolutely... 17:26:05 but I'm thinking we should allow for a user to specify abstract types as the chain definition (assuming those types already exist as VNF instances) 17:26:20 trozet: IMO, that's a reasonable thing to incorporate.. 17:26:45 trozet: that would mean we need to expand the tacker sfc-create API ? 17:27:38 sridhar_ram: i was just thinking an extra param like --use-vnfds, to indicate when --chain is specified it is abstract types 17:28:08 Is there anything specified for VNF groups and load balancing preferences 17:28:09 sridhar_ram, trozet: the thing about this is we would need to cross check the abstract service type with VNFd 17:28:30 it should be dynamically generated instead of coding the types into Tacker 17:28:40 s3wong: right, thats what my plan was have tacker SFC query the VNFM 17:29:03 s3wong: well it is dynamically generated by the type you declare in your VNFD right? cant that be any string? 17:30:27 s3wong: why do we need to care to categories VNFD type ? 17:30:40 s3wong: .. just trying to understand here, btw.. 17:31:07 trozet: that's what I am thinking. It should just be an arbitrary string 17:31:08 s3wong: why does Tacker get into the business of categorizing a VNF is nat vs dpi vs lb ? 17:31:43 s3wong: .. that's going to be a long list .. vepc, vims, .etc .. perhaps I'm missing something here 17:31:51 ^vIMS 17:32:01 sridhar_ram: I've always wondered that too 17:32:05 sridhar_ram: we need to support the string as input for CLI, and for Horizon, a list of strings user can choose as chain nodes 17:32:38 sridhar_ram: at time of deployment, we need to validate / verify the input can be supported by things that are already onboard 17:33:24 s3wong: I see.. purely as a cross-validation across vnfm realm and the SFC world ? 17:34:07 sridhar_ram: yep. We are orchestration layer, so we need to validate / verify what we pass on to drivers 17:34:12 sridhar_ram: in the VNFD service_type: firewall is defined 17:34:31 sridhar_ram: so tacker SFC would go check to see if there are any instances with that type if it was specified in a chain create cmd 17:34:42 s3wong: in short, you don't trust the operators would pick the correct VNFD in the chain sequence ? ;-) 17:34:42 s3wong: is the intent to specify vnfd service types to be included in the chain? 17:35:47 sridhar_ram: wouldn't we all wish we can :-) but we are talking about two places where inputs need to match, and human would be the one inputting them 17:36:35 LouisF: yes. The ODL SFC folks are asking Tacker to orchestrate the chain (a template, if you will) by only specifying an abstract service type (a string) 17:36:41 s3wong, sridhar_ram: I think it would be too simplistic to just validate a chain based on a "service type" 17:36:53 s3wong: it is not just that.. we are asking the VNF vendors to correctly categorize their VNFs ..otherwise they wouldn't be accepted in the chain.. 17:37:00 LouisF: rather than specifying the actual VNF instance, like trozet has implemented 17:37:22 s3wong: where will these majic strings come from ? don't tell me this will be iin ietf RFC ..! 17:37:25 s3wong: agree on that idea 17:37:42 ulas: agree 17:39:25 sridhar_ram: that's right. I remember during our demo / prototyping phase, we allow specification of 'firewall' function out of OpenWRT (which can do other things like 'nat' and so on). My guess is we have asked vendors to specify functions. Though trozet mentioned that on ODL, the 'service type' needs to be unique, i.e. cisco-firewall or something) 17:40:32 I think the question isnt should we validate the abstract type (i think thats an obvious yes), but is it OK to add support for specifying those abstract types in the chain as part of this spec 17:40:42 u_kozat: one thing Danny Zhou asked for is that during the deployment phase, IF there isn't any deployed VNF that match a particular abstract service type, Tacker should deploy it 17:41:06 trozet: A resounding .. OK for my side.. 17:41:35 u_kozat: so --- in a way, to define a chain using abstract type, Tacker can only have abstract type to work against... 17:41:39 trozet: just to be clear, I think there is a general consensus to have tacker create an abstract service chain type 17:42:09 s3wong: no, we can't do automatic VNF deployments based on SFC chain creation... 17:42:34 s3wong: that got to wait for a follow on BP .. we need to factor in NSD support to do that properly 17:42:39 sridhar_ram: even if such VNFd is already onboard? 17:42:47 s3wong: yet 17:42:49 *yes 17:43:32 s3wong: as sridhar_ram explained to me automatic spin up of VNF for a chain should be handled by a different NSD plugin to Tacker and not in the SFC orchestrator 17:44:09 trozet: well, that's OK. But it is an expected functionality in the future (I would imagine) 17:44:28 trozet: It seems to me a useful feature to spin up automatically based on a chain request 17:44:30 s3wong: if there is cycles and extra developers we can consider taking that up in the 2nd half of Mitaka 17:44:45 u_kozat: its very useful indeed 17:44:59 sridhar_ram: not suggesting that at all :-) (unless people want to volunteer) 17:45:15 ulas: s3wong: trozet: totally agree.. but we can't expand the current BPs scope too wide.. 17:45:28 yup 17:45:46 sridhar_ram, trozet: it is just that I view that having dynamic deployment based on chain definition is a perfect marriage and use case for integrating high-level SFC definition and a VNFM 17:45:51 remember - openstack digests better in small iterations.. 17:46:19 sridhar_ram: trozet: I agree. But we should put a placeholder or make a note somewhere. 17:46:35 s3wong: I don't what two different ways of doing that.. one the NSD way and another in the context of SFC chain creation 17:46:58 s3wong: we need to somehow gel those two together.. that's why I suggest to take it up in a follow on 17:47:10 u_kozat: I dont mind adding the logic to ask VNFM to spin up the instance if it is missing as a placeholder, im not sure if sridhar_ram would like to set that precedent though 17:47:12 sridhar_ram: SFC can consume NSD plugin 17:47:27 ulas: agree, trozet: please capture that in the BP 17:47:53 sridhar_ram: ok I'll make a note in the spec that it will be handled by a future NSD plugin 17:48:03 trozet: placeholder only in the BP and NOT in code, please 17:48:32 sridhar_ram: I don't want that neither. That said, I do think it is an essential functionality that needs to be taken by Tacker 17:48:33 sridhar_ram: yup got it 17:49:23 ulas: if you look at ETSI MANO.. NSD is the starting point where SFC and VNFM workflows branch out 17:49:23 I have to leave now. 17:50:00 anyways, lets consider the current iteration as part 1 of a series of tacker-sfc work... 17:50:04 sridhar_ram: I will check it out 17:51:03 if there is enough interest and volunteers we can take up NSD / automatic VNF spawn work in a separate BP.. volunteers welcome! 17:51:34 just to conclude.. we have an agreement to do abstract-service chain .. 17:51:59 sridhar_ram: as part of M cycle, right? (the abstract service chain support) 17:52:16 s3wong: yes 17:53:02 validation using service type "strings" is still a TBD in my opinion... trozet: s3wong: is that clear in your mind how you'll achieve that ? 17:53:23 * sridhar_ram 7 mins left in clock 17:53:53 sridhar_ram: that is something we need to look into 17:53:55 sridhar_ram: i mean its pretty clear right, in tacker sfc i just query VNFM for the instance, make sure it exists, then figure out its service_type 17:54:27 trozet: okay, lets keep it simple if possible for this iteration.. 17:54:40 trozet: you will be updating the spec for abstract service types ? 17:54:42 sridhar_ram: err sorry thats a little backwards in order of operations, but its the same idea 17:54:47 sridhar_ram: assuming we require everything needs to be onboard and spawned before we can define a chain, then the service type info should be in DB 17:54:57 s3wong: exactly 17:55:03 sridhar_ram: yeah i will add that to the spec 17:55:48 s3wong: but the abstract service chain can be defined even before spawning VNFs, correct ? 17:56:14 for eg : tacker sfc-chain-create --type abstract nat, firewall, dp 17:56:21 sridhar_ram: that's why I said (in the response to Danny Zhou) that we can ONLY validate when a chain is to be deployed 17:56:22 sridhar_ram: abstract service type is specified for the chain, then vnfm is queried for instance? 17:57:04 tacker sfc-chain-apply -sfc-chain-type uuid-of-abstract-sfc-type ? 17:57:43 LouisF: vnfm will know the vnf instance type.. 17:57:54 sridhar_ram: yes 17:58:05 folks - we are almost out of time... 17:58:27 lets continue this nice discussion in Tim's spec in the gerrit 17:58:29 sridhar_ram: never expected SFC to be a 10 minutes topic :-) 17:58:45 please help to wrap up the spec ... ! 17:59:01 we will fine tune in future iterations ... 17:59:08 trozet: are you going to update the spec soon? 17:59:10 .. as we learn more on sfc usage patterns 17:59:50 s3wong: yes i will do it tmrw 17:59:55 please also review other BPs for tacker mitaka! 18:00:05 multi-vim and auto-resource creation.. 18:00:15 alright.. it was a good discussion 18:00:21 thanks everyone! 18:00:27 bye 18:00:31 Thanks! bye 18:00:39 #endmeeting