16:00:13 <sripriya> #startmeeting tacker
16:00:14 <openstack> Meeting started Tue Oct 11 16:00:13 2016 UTC and is due to finish in 60 minutes.  The chair is sripriya. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:17 <openstack> The meeting name has been set to 'tacker'
16:00:34 <sripriya> hello everyone
16:00:36 <sripriya> #topic Roll Call
16:00:42 <tbh> o/
16:00:43 <manikanta_tadi> Hi all
16:00:52 <tung_doan> o/
16:00:58 <vishwanathj> o/
16:01:27 <neel> o/
16:01:37 <mike_m> o/
16:01:50 <sripriya> tbh manikanta_tadi tung_doan vishwanathj neel mike_m hello
16:01:56 <sripriya> lets get started
16:02:11 <sripriya> #chair tbh
16:02:11 <openstack> Current chairs: sripriya tbh
16:02:19 <sripriya> #topic Agenda
16:02:34 <sripriya> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Oct_11th.2C_2016
16:03:06 <sripriya> we will be discussing on the 2 blueprints VNFC and NSD, also touch upon few topics for the design summit
16:03:14 <sripriya> #topic Announcements
16:03:42 <sripriya> as you all know, tacker newton stable release branch is cut. hence any critical patches, important bug fixes applicable for existing features in stable/newton need to be cherry picked from master as and when the patches are merged. thanks for your cooperation.
16:03:56 <dkushwaha> o/
16:04:00 <sripriya> next...
16:04:04 <sripriya> team: ocata development cycle will be a short one per the new format, and is targeted for release in the week of Feb 20-24
16:04:22 <sripriya> #link https://releases.openstack.org/ocata/schedule.html
16:04:46 <sripriya> last but not the least :-)
16:04:55 <sripriya> countdown to summit: 2 more weeks to go, hope you are all set for the conference and have your travel logistics planned out.
16:05:33 <sripriya> did anyone have other announcements to make?
16:06:08 <manikanta_tadi> Can you explain a bit abt PTG
16:06:46 <sripriya> manikanta_tadi: thats the 1st topic today, i did not put that in the meeting agenda
16:06:55 <sripriya> #topic PTG presence
16:06:59 <manikanta_tadi> sripriya: Ok thanks
16:07:12 <sripriya> the 1st PTG (Project Team Gathering) is happening at Atlanta, Feb 20-24 2017.
16:07:27 <sripriya> please read through the below link
16:07:28 <sripriya> #link https://www.openstack.org/ptg/
16:07:40 <sripriya> as a team, we are asked to decide if we plan to attend this event and have our presence at PTG.
16:07:55 <sripriya> also, sent out a mail on ML
16:07:57 <sripriya> #link http://lists.openstack.org/pipermail/openstack-dev/2016-October/105309.html
16:08:24 <manikanta_tadi> Is it possible to attend PTG remotely ?
16:08:43 <sripriya> what this means is going forward after the barcelona summit, design summit will not happen in parallel to the conference at the same venue
16:09:15 <sripriya> no, it is a inperson gathering
16:09:19 <sripriya> manikanta_tadi: ^
16:09:28 <sripriya> just like the regular design summit
16:09:36 <manikanta_tadi> sripriya : ok
16:10:09 <sripriya> only difference is it happens way early before the actual conference and marks the beginning of a new dev cycle
16:11:24 <sripriya> existing format has conferences and dev summit aligned together, now, the release happens 3 months before the conference itself
16:11:44 <sripriya> any questions on the PTG?
16:12:22 <sripriya> below are couple of choices to help make the decisions as a team
16:12:32 <sripriya> 1. conduct virtual design summit (similar to Tacker midcycle format) around PTG timeframe. use the conference (in May) as informal midcyle gathering for those who will be attending.
16:12:51 <sripriya> 2. conduct official design summit at PTG Atlanta, and there will be no work sessions at the conference.
16:13:36 <sripriya> I believe 1. can work for us given most of our contributors are spread out geographically and that it may be tough for all remote folks to attend in person.
16:13:56 <manikanta_tadi> sripriya : As tacker team is working from geographically different location, IMO option 1 will give chance to most of members
16:14:03 <sripriya> thoughts?
16:14:08 <sripriya> manikanta_tadi: ack
16:14:39 <vishwanathj> +1 on option 1
16:14:53 <tbh> sripriya, first option sounds more reasonable for me
16:14:57 <mike_m> also agree with option 1
16:16:22 <dkushwaha> +1 for 1
16:17:26 <sripriya> thanks team for the response, looks we are all favoring  option 1. will provide our decision to OSF . please feel free to let us know on the ML if you have any other thoughts.
16:17:58 <sripriya> moving next to blueprints
16:18:11 <sripriya> #topic VNFC blueprint review
16:18:33 <sripriya> tbh: manikanta_tadi can you please provide an update on the spec?
16:19:01 <tbh> sripriya, we got few comments from you and gongysh
16:19:21 <tbh> #link https://review.openstack.org/#/c/339798
16:19:40 <manikanta_tadi> sripriya : I think we need to discuss on ssh driver more hre
16:19:57 <sripriya> tbh: i believe the decision now left for us to choose the right approach for implementing the VNFC, will it be heat or ssh driver
16:20:31 <tbh> sripriya, agree
16:20:53 <manikanta_tadi> sripriya: We have Heat Software deployment solution clear and based on our discussion in spec, SSH driver has some limitations too
16:21:07 <sripriya> manikanta_tadi: yeah, we need to weigh in on both options
16:22:00 <sripriya> manikanta_tadi: tbh: the main drawbacks with ssh driver is : how do we notify the user on the outcome of the script?
16:22:00 <tbh> sripriya, in the scaling case, I feel the time consumes by the both drivers will be same
16:22:52 <tbh> sripriya, yup, even in the s/w deployment scenario, we have support to get the output of the script in the heat
16:23:28 <sripriya> tbh: in case of ssh, tacker needs to maintain the vdu scale list and ensure vnfc is applied on the scaled out vdus
16:23:28 <tbh> sripriya, but it is not implemented yet in heat-translator. And why can't we get the output of VNFC in ssh case
16:23:52 <manikanta_tadi> sripriya : I believe .. we will have to rely on VNF state for outcome of script in ssh driver ?
16:24:40 <sripriya> tbh: suppose the user is interested in getting the outcome of certain installation steps within the script,  how do we implement that?
16:25:39 <sripriya> manikanta_tadi: ^, i'm specifically referring to the outcome /status of the steps itself
16:26:21 <tbh> sripriya, okay, but we can get the whole output of script
16:27:01 <sripriya> tbh: regarding heat-translator support, i suppose they have support for softwaredeployment config itself right?
16:27:36 <tbh> sripriya, yes in scaling scenario, ssh driver has to make sure VNFC is deployed
16:28:06 <tbh> sripriya, I didn't get your previous statement
16:28:53 <sripriya> tbh: you mentioned about heat translator not having support yet for 'output' parameter in deployment config, did i understand it right?
16:29:44 <tbh> sripriya, yes, got it
16:30:11 <tbh> sripriya, I haven't seen 'output' support for s/w config
16:30:14 <sripriya> tbh: i'm trying to understand what are the capabilities already supported by heat -translator and what needs to be handled in tacker if we take the heat driver approach?
16:30:23 <sripriya> tbh: okay
16:31:25 <tbh> sripriya, 1)support multi VDU for VNFC 2)Support output parameter (if it is not already there)
16:31:50 <tbh> sripriya, I think it is good to have these features in heat-translator and tosca-parser itself, instead of implementing in Tacker
16:32:16 <sripriya> tbh: manikanta_tadi: if we look into VIMS beyond, AWS also has something similar for auto installing applications
16:32:21 <sripriya> tbh: agree
16:32:51 <sripriya> tbh: manikanta_tadi another question on the upgrade
16:33:07 <tbh> sripriya, so I believe we can have minimal changes  in Tacker if we prefer heat driver
16:33:38 <sripriya> tbh: manikanta_tadi: when we refer to upgrade VNFC in tacker, is this the software upgrade of VNFC?
16:33:41 <sripriya> tbh: ack
16:33:54 <manikanta_tadi> sripriya : yes it is software upgrade
16:33:55 <tbh> sripriya, yes
16:34:25 <sripriya> tbh: and will this be implemented as a stack-update ?
16:35:05 <tbh> sripriya, yes it will be stack-update
16:35:23 <tbh> sripriya, one more thing regarding VNFC specification ...
16:35:38 <sripriya> tbh: well, this means stack gets deleted and recreated with the new software/config
16:36:24 <tbh> as per sridhar_ram, VNFC is not in ETSI docs yet, so we can't give reference link in  the BP spec
16:36:49 <tbh> sripriya, no, we change the create node value in HOT and invoke stack-update
16:37:17 <tbh> sripriya, heat will identify only the diff and update it, it won't disturb other deployed resources
16:37:37 <sripriya> tbh: got it,  how did we decide upon the new node types for VNFC originally?
16:37:49 <sripriya> tbh: i see
16:38:45 <tbh> sripriya, the basic assumption we consider is one VNFC per VDU
16:39:11 <tbh> sripriya, while upgrading we will map script to VNFC name or VDU name
16:39:37 <tbh> so will update only that those portions and invoke stack-update
16:39:49 <sripriya> tbh: i was referring to the node type VNFC and its properties 'interface', 'input' etc
16:40:05 <mike_m> tbh: yes that is what ETSI is using, VNFC == VDU, also note that VNFC is no longer in the version 2 of the ETSI NFV spec.
16:41:19 <sripriya> tbh: okay, let us continue to take this discussion on the gerrit as we have other pending topics in the agenda
16:41:31 <tbh> sripriya, I think in VNFC node properties, the variable is input and create value
16:41:48 <sripriya> tbh: i think taking the heat driver approach will help us implement this feature a lot easier
16:42:10 <tbh> mike_m, I see, and VNFC we mean s/w component hosted by VDU
16:42:17 <tbh> sripriya, totally agree
16:42:40 <sripriya> tbh: please respin the patch based on these suggestions and we will take it forward
16:42:47 <tbh> sripriya, sure
16:42:54 <mike_m> tbh: it seems so, although the ETSI version 2 model is confusing now
16:42:54 <sripriya> moving on to next blueprint, NSD
16:43:16 <sripriya> #topic NSD mistral integration
16:43:16 <tbh> mike_m, exactly :)
16:43:43 <sripriya> dkushwaha: can you please give an update on the NSD spec?
16:44:04 <dkushwaha> sripriya, I got the comments from you and will update the spec.
16:44:28 <dkushwaha> sripriya, Our current main concern is to finalize the design approach, i.e. 1: using tacker itself 2: using mistral workflow
16:45:08 <dkushwaha> sripriya, thoughts from the team required on that
16:45:21 <sripriya> dkushwaha: bringing in mistral helps in handling complex workflows specified in NSD
16:46:07 <sripriya> dkushwaha: especially when we start integrating VNFFG in NSD
16:47:09 <sripriya> team, dkushwaha is looking for suggestions on integrating mistral in Tacker and the general approach using Tacker itself
16:47:43 <tbh> sripriya, dkushwaha just for confirmation, mistral workflows for handling VNFD and VNF operations right?
16:48:30 <sripriya> tbh: and more such as handle VNFFG as well in future iterations
16:48:40 <dkushwaha> tbh, right, nsd use mistral for vnfd/vnf operations
16:48:59 <tbh> sripriya, dkushwaha got it
16:49:29 <tbh> sripriya, dkushwaha and I assume we are not supporting VNFD in the NSD?
16:50:02 <sripriya> tbh: dkushwaha it will be beneficial to use mistral when we have a dependency workflow such as certain VNF should only be created after some initial steps are completed
16:50:19 <sripriya> tbh: i think we support
16:50:28 <sripriya> dkushwaha: please correct
16:50:43 <tbh> sripriya, I am looking into using substitution_mappings for linking VNFD in NSD, so want to know do we support VNFD in the NSD itself
16:50:55 <dkushwaha> tbh, what is mean by supporting vnfd?
16:51:30 <tbh> dkushwaha, only one NSD, all VDU details are mentioned in the same template
16:52:14 <dkushwaha> tbh, initially we will support already created vnfds
16:52:48 <dkushwaha> tbh, in that case vnds will be be in different template
16:52:52 <tbh> dkushwaha, by mentioning VNFD  ID/
16:53:21 <sripriya> tbh: dkushwaha: sorry to interrupt, can we please carry forward this discussion on to the gerrit spec review or on the tacker channel
16:53:43 <tbh> sripriya, yeah sure
16:53:52 <sripriya> we have couple more items to touch open before we wrap up the meeting in exactly 7 mins :-)
16:54:08 <sripriya> #topic Ocata design summit grooming
16:54:15 <sripriya> #link https://etherpad.openstack.org/p/tacker-ocata-summit
16:54:53 <sripriya> the 2 topics for fishbowl are containerized VNFs and multi VIM suppotr
16:55:46 <sripriya> tbh: i would request you to prepare few slides on the containerized VNFs to initiate the discussions
16:56:19 <tbh> sripriya, ok
16:56:38 <sripriya> tbh: i think it will good to understand some usecases and challenges and how we plan to integrate using existing projects such as magnum, etc and come up with the 1st iteration
16:56:51 <sripriya> tbh: thanks
16:57:22 <sripriya> mike_m: i guess you expressed interest in multi VIM topic and em interface
16:57:44 <mike_m> sripriya: yes I did.
16:58:18 <sripriya> mike_m: it will be great to have some points added in etherpad to highlight some of the areas we want to discuss or get feeedback from the users
16:58:39 <mike_m> sripriya: yes I will add points to etherpad
16:58:44 <sripriya> it will help us all better prepare for the sessions
16:58:50 <sripriya> mike_m: thanks
16:59:17 <sripriya> we can discuss more on the design summit in the next meeting
16:59:24 <sripriya> #Open Discussion
16:59:35 <sripriya> please continue to utilize the current ramp up time to groom the ocata specs and help land them soon. it will be easier to quick start the development/review of these features early in the cycle.
17:00:06 <sripriya> thats all for today
17:00:14 <sripriya> thanks for joining the meeting folks!
17:00:18 <vishwanathj> thanks
17:00:22 <sripriya> #endmeeting