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