16:00:34 <sripriya> #startmeeting tacker
16:00:34 <openstack> Meeting started Tue Nov 29 16:00:34 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:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:38 <openstack> The meeting name has been set to 'tacker'
16:00:48 <sripriya> hi tackers
16:00:51 <sripriya> #topic Roll Call
16:00:54 <tbh> o/
16:00:56 <dkushwaha> o/
16:01:00 <tung_doan> o/
16:01:22 <aimeeu> hi
16:02:18 <sridhar_ram> howdy all!
16:02:38 <tung_doan> sridhar_ram: nice to have you back :)
16:02:41 <sripriya> tbh dkushwaha tung_doan aimeeu hello!
16:02:46 <dkushwaha> hi sridhar_ram good to see you here
16:02:53 <tbh> Hi sridhar_ram
16:03:06 <diga> Hi
16:03:09 <sripriya> sridhar_ram: very huge welcome back!
16:03:12 <sridhar_ram> tung_doan: dkushwaha: tbh: thanks!
16:03:18 <dkushwaha> sridhar_ram, how are you now?
16:03:23 <sripriya> sridhar_ram: happy to have you back
16:03:25 <neeldhwaj> Hello
16:03:26 <diga> sridhar_ram: welcome back!
16:03:42 <sridhar_ram> sripriya: thanks for running the tacker ship, looks you didn't miss a beat...!
16:03:46 <sripriya> diga: neeldhwaj hello
16:03:48 <KanagarajM> hi
16:03:52 <sridhar_ram> diga: thanks
16:04:05 <diga> sridhar_ram: welcome!
16:04:09 <sripriya> sridhar_ram: nothing comparable to you :-) you do it best :-)
16:04:11 <diga> sripriya: hi
16:04:16 <sripriya> sridhar_ram: but thank you
16:04:27 <sripriya> and thanks to the team!
16:04:43 <sridhar_ram> ^^ yes.. thanks team!
16:04:56 <KanagarajM> sridhar_ram, hope you are fine now !
16:05:02 <sridhar_ram> still catching up, will hang back for this meeting.. please carry on
16:05:04 <sridhar_ram> KanagarajM: thanks!
16:05:08 <sripriya> alright let us get started
16:05:13 <sripriya> #topic agenda
16:05:26 <sripriya> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Nov_28th.2C_2016
16:05:57 <sripriya> let us quickly go through the meeting time update and dsvm error, later we can discuss on the specs
16:06:12 <sripriya> #topic revisit weekly meeting time
16:07:12 <sripriya> sridhar_ram: i know you had suggestion to change the weekly meeting update i guess even before the barcelona summit to gather all developers across TZs
16:07:43 <sripriya> sridhar_ram: do we need to have a doodle poll for a new weekly meeting time?
16:07:53 <sridhar_ram> sripriya: yes, particularly with the shifting out of daylight saving...
16:08:07 <sridhar_ram> sripriya: we can do a doodle poll,
16:08:29 <sridhar_ram> if we can quickly sample here.. does anyone have major issue if we push this meeting my 1hr?
16:08:39 <sridhar_ram> s/my/by/
16:09:01 <sridhar_ram> 1700 UTC
16:09:12 <sripriya> sridhar_ram: fine with me
16:09:24 <sridhar_ram> how about folks in Asia ?
16:09:29 <tung_doan> sridhar_ram: seems like hard for me :(
16:09:31 <dkushwaha> sripriya, 1 hour prior
16:09:44 <sridhar_ram> tung_doan: ack
16:10:03 <tbh> sridhar_ram, sripriya I am fine with that
16:10:21 <diga> Fine with me too
16:11:02 <sridhar_ram> okay, will send a doodle poll out
16:11:27 <sridhar_ram> for the record, current 1600UTC / 8AM is not possible for me.
16:11:32 <sripriya> sridhar_ram: looks like folks are okay except tung_doan and others in asia pacific TZ
16:12:07 <tung_doan> dkushwaha: how are you, bro? :)
16:12:10 <sridhar_ram> sripriya: anyone else joins from APAC ?
16:12:21 <tung_doan> dkushwaha: how about you, bro? :)
16:12:22 <sridhar_ram> dkushwaha: are you still in Japan?
16:12:30 <sripriya> sridhar_ram: i know gongysh is interested to join the meetings
16:12:51 <dkushwaha> sridhar_ram, tung_doan yes, will be back to India in next week
16:12:51 <sridhar_ram> sripriya: oh yes, we miss him due to the meeting timing
16:12:59 <sripriya> sridhar_ram: and i guess few other folks from NEC
16:13:30 <sridhar_ram> one option is we can go really early in US pacific.. say, 6:30AM
16:13:38 <sridhar_ram> or 6AM
16:13:51 <sripriya> sridhar_ram: :)
16:14:08 <sridhar_ram> will send a doodle poll and we can take it from there..
16:14:19 <sripriya> sridhar_ram: sounds good,
16:14:43 <sripriya> #action create a doodle poll for new weekly meeting time
16:14:58 <sripriya> is this the tag sridhar_ram? :)
16:15:19 <sridhar_ram> yep!
16:15:24 <sripriya> ok cool
16:15:28 <sripriya> moving on
16:15:33 <sripriya> #topic dsvm gate job update
16:16:00 <sripriya> tung_doan: thanks for actively looking into dsvm job error and actively fixing it
16:16:34 <sripriya> tung_doan: it will be good to give the team an update on the dsvm error fix
16:16:57 <tung_doan> sripriya: np.. latest patch was fix networking-sfc plugin
16:17:18 <tung_doan> sripriya: the problem now is back to tacker :(
16:17:36 <tung_doan> sripriya: http://logs.openstack.org/79/382479/18/check/gate-tacker-dsvm-functional-ubuntu-xenial-nv/9e5a8c3/logs/devstacklog.txt.gz
16:17:49 <sripriya> tung_doan: are you referring to OVS_UPDATE variable?
16:18:07 <tung_doan> sripriya: got  the error: http://logs.openstack.org/79/382479/18/check/gate-tacker-dsvm-functional-ubuntu-xenial-nv/9e5a8c3/logs/devstacklog.txt.gz
16:18:31 <tung_doan> sripriya: yes, it made sense now
16:19:09 <sridhar_ram> specifically here .. http://logs.openstack.org/79/382479/18/check/gate-tacker-dsvm-functional-ubuntu-xenial-nv/9e5a8c3/logs/devstacklog.txt.gz#_2016-11-29_12_45_00_796
16:19:15 <sridhar_ram> RegionOne not found
16:19:26 <sripriya> tung_doan: at least we went past the linux kernel version error and now seeing a new error
16:19:34 <sripriya> tung_doan: is this consistent?
16:19:50 <tung_doan> sridhar_ram: right. that's my concern
16:20:20 <tung_doan> srippriya: +1
16:21:03 <sripriya> tung_doan: we will have to look into the logs closely , not sure what is messing the tacker endpoint creations in keystone
16:21:25 <tung_doan> srippriya: agree
16:22:30 <sripriya> tung_doan: a quick look at the logs, i do not see the nfv-orchestration endpoints created
16:22:42 <sripriya> tung_doan: we can debug it further after the meeting
16:23:11 <tung_doan> srippriya: ok
16:23:18 <sripriya> moving on
16:23:22 <sripriya> #topic NSD spec
16:24:06 <sripriya> dkushwaha: i think we are close to merging the NSD spec, there were few comments related to input and output params support for NSD
16:24:21 <dkushwaha> sripriya, yes, currently we have to fix the input handling issues.
16:24:45 <tbh> sripriya, and I have one more qq on the template part
16:25:09 <dkushwaha> sripriya, we are looking for the way to pass vnf into nsd
16:25:15 <sripriya> dkushwaha: okay, i saw sridhar_ram suggesting the nested param template as input file for ns create
16:25:20 <sripriya> tbh: shoot
16:25:59 <sripriya> bobh_: are you around?
16:26:08 <tbh> sripriya, we have to define the VNF1 in the vnfd for example L# 169 in https://review.openstack.org/#/c/334370/8/samples/tosca-templates/nsd/tosca-nsd.yaml
16:26:35 <tbh> sripriya, so that part is the new change in VNFD
16:26:50 <sridhar_ram> folks - i just pushed few comments
16:27:08 * sridhar_ram forgot to click the reply button
16:27:11 <sripriya> tbh: ack, yes
16:27:32 <tbh> sridhar_ram, one of your comment regarding creation of VL
16:27:32 <sripriya> tbh: i know this needs a change in vnfd template too to integrate it into NSD
16:27:50 <sripriya> tbh: do you have the sample VNFD also?
16:28:00 <sripriya> sridhar_ram: will take a look
16:28:07 <tbh> sripriya, yes we need to refer only existing neutron network there
16:28:20 <sridhar_ram> tbh: my question is .. do we support any node types in NSD other than VNF
16:28:25 <tbh> sripriya, http://paste.openstack.org/show/590813/    http://paste.openstack.org/show/590814/
16:29:09 <tbh> sridhar_ram, we can declare VL too
16:29:42 <sridhar_ram> tbh: okay, can be used to refer to existing networks but not create new networks ?
16:30:31 <tbh> sridhar_ram, for new networks, my concern is ... we may define the same network in VNFD also, so I think it will be conflicting
16:30:42 <dkushwaha> sridhar_ram, sripriya, tbh  we need to mention CP also nsd template as for ns end point
16:30:58 <bobh_> sripriya: sorry I'm late
16:31:24 <tbh> dkushwaha, that can we can pass as forwarder as per the spec http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd03/tosca-nfv-v1.0-csd03.html#_Toc447714731
16:31:25 <sridhar_ram> tbh: it is okay to not support creating new networks in NSD for now.. it is useful, but we can take it up in follow ons.
16:31:43 <sridhar_ram> tbh: i was trying to understand the scope of this initial NSD effort
16:32:16 <sripriya> tbh: i do see the substitution_mappings added to vnfd template
16:32:31 <tbh> sripriya, yes
16:32:43 <sripriya> bobh_: no worries, we were just discussing the NSD spec and addressing the comments
16:33:02 <sripriya> tbh: is the new updated syntax which you pushed earlier?
16:33:18 <tbh> sridhar_ram, currently we are defining APIs for NS and support creation of NS with out creating the forwarding path
16:33:54 <sridhar_ram> tbh: again, fair enough.. but it will be good to capture these in the spec..
16:33:55 <tbh> sripriya, this is the new updated syntax, but no major changes except defining new node type in VNFD
16:35:04 <sripriya> tbh: ack
16:35:40 <dkushwaha> sripriya, bobh_ do we needs to handle vnfd output in nsd?
16:35:43 <tbh> sripriya, sridhar_ram sure will update the spec, still looking for the ways to pass input params
16:36:05 <sripriya> dkushwaha: going back to input param support for nsd, are we going with the nested template as an input for nsd?
16:36:21 <sripriya> sridhar_ram: does it make sense to give them as separate input files for nsd?
16:36:22 <bobh_> dkushwaha: If the NSD is deploying a collection of VNFs then it should handle the inputs/outputs of those VNFs as necessary
16:36:55 <sripriya> bobh_: we do not support specifying outputs for VNFD today
16:37:02 <dkushwaha> sripriya, sridhar_ram please check https://review.openstack.org/#/c/334370/8/samples/tosca-templates/nsd/tosca-nsd-param.yaml
16:37:04 <sridhar_ram> sripriya: I'm leaning towards using a "single" NS param input file
16:37:57 <sridhar_ram> dkushwaha: looks good to me, inline with what i proposed in my latest comments
16:37:58 <sripriya> sridhar_ram: okay, it can become a lengthy nested file at some point
16:38:32 <tbh> sridhar_ram, why do we need params specified for VDUs specifically?
16:38:36 <sridhar_ram> sripriya: understood but it is still better compared to other option
16:39:48 <tbh> sridhar_ram, instead we can specify input params per VNF?
16:40:19 <sridhar_ram> tbh: then we need to worry about VNF <--> param file mapping
16:40:43 <sripriya> sridhar_ram: tbh: and also the order...
16:41:07 <sridhar_ram> tbh: .. and there is an extreme case of an NSD with high number of VNFs (like vIMS) where it just becomes painful
16:41:58 <tbh> sridhar_ram, if we pass params per VNF, we can use the existing API for vnf-create (by passing parameters)
16:42:24 <tbh> sripriya, can you give an example of maintaining the order?
16:42:53 <tbh> sripriya, I mean in which cases we have to maintain the order?
16:43:08 <sridhar_ram> tbh: with a single NS param file we can still use existing vnf-create API... just the NS logic should extract the params related to a specific VNF from the single NS param file
16:43:26 <sridhar_ram> tbh: i've an example in my latest comment in PS17
16:43:36 <sridhar_ram> tbh: it is similar to dkushwaha above link
16:43:50 <sripriya> tbh: nsd might have the vnf order in a specific way, but if we are mapping it based on the vnfd name, i'm not sure how we would maintain the order while specifying the template
16:45:22 <sridhar_ram> sripriya: indexing off node name would be the way to go.. ns_param[vnf_node_name] dict
16:46:04 <sridhar_ram> again see https://review.openstack.org/#/c/334370/8/samples/tosca-templates/nsd/tosca-nsd-param.yaml,unified
16:46:09 <bobh_> I don't think the params need to be necessarily VNF-specific - you may have NSD params that map to multiple VNF inputs
16:46:14 <tbh> sridhar_ram, sripriya I was thinking something like this http://paste.openstack.org/show/590855/
16:46:44 <sridhar_ram> tbh: that would work
16:47:14 <sripriya> sridhar_ram: tbh: this is vnfd rightt and not vnf
16:47:45 <sridhar_ram> bobh_: to support that, we need some sort of an inherited scope
16:47:57 <tbh> sripriya, name give while onboarding VNFD
16:48:07 <sripriya> tbh: correct
16:48:36 <sridhar_ram> sripriya: params comes into play only at runtime.. so ns-create --> vnf-create
16:48:40 <bobh_> sridhar_ram: Can't the NSD pass parameters into the VNFs using get_input the same way a VNFD does?
16:49:16 <sripriya> sridhar_ram: yes but we map it based on vnfd names provided in nsd create for vnf creation
16:49:52 <bobh_> sridhar_ram: I'm not sure I understand how this is expected to work - to me it is just a collection of VNF references that use the same TOSCA conventions as the VNFDs
16:50:09 <sridhar_ram> bobh_: my understanding is the NSD processing logic wouldn't look / do VNFD processing.. can someone confirm if this assumption is correct ?
16:51:03 <tbh> sridhar_ram, bobh_ when we run ns-create 1)we validate the nsd
16:51:18 <sripriya> sridhar_ram: at nsd level, it is just parsing and calling the vnf-create api
16:51:41 <sridhar_ram> sripriya: ack, that is my understanding..
16:51:43 <tbh> 2)collect the params from param file
16:51:43 <tbh> 3)call vnf-create with those params
16:51:46 <dkushwaha> sridhar_ram, bobh_ vnfd will be onboarded
16:51:51 <tbh> 4)complete the ns-creation
16:52:04 <sripriya> folks, quick time check, we have 8 mins left
16:52:12 <sridhar_ram> so param substitution for VNFD will happen in the context of of VNF create within VNFM
16:52:36 <tbh> so here we are not giving NSD to heat-translator/heat
16:52:48 <sripriya> i think we should continue on the tacker channel for this specific topic
16:53:14 <sridhar_ram> sripriya: sounds good..
16:53:16 <sripriya> let us quickly go through the pecan framework spec
16:53:27 <sripriya> #topic Pecan framework spec
16:53:30 <sripriya> diga: ping
16:53:38 <diga> sripriya: Hi
16:53:51 <sripriya> diga: did you happen to chat with infra team on creating a new branch?
16:53:59 <diga> sripriya: I am working with infra to create seperate branch for pecan
16:54:05 <diga> yes
16:54:21 <sripriya> diga: also, i do not see the spec describing the design details of the framework and how existing framework is refactored
16:54:31 <diga> sripriya: they have shared some docs, going through those
16:54:44 <diga> sripriya: yes, will update the patch
16:55:03 <sridhar_ram> diga: can you please fwd them, i'm curious about branch creation process
16:55:15 <diga> sridhar_ram: sure
16:55:16 <sripriya> diga: i believe we should first get the spec completely finished and merged  before we start creating a branch
16:55:50 <diga> sripriya: yes
16:56:01 <sripriya> diga: until we get a better clarity of how pecan framework will better fit for Tacker, it hard to progress forward
16:56:12 <diga> sripriya: okay
16:56:18 <sripriya> diga: i request you to please update the proposed solution and design details
16:56:29 <diga> sripriya: ok
16:56:58 <sripriya> diga: i'm thinking we should talk more about the new controllers, extensions, attribute validation and impact on existing plugins
16:57:07 <sripriya> in the spec
16:57:30 <sripriya> sorry here is the spec link https://review.openstack.org/#/c/368511/ for team to review
16:57:31 <sridhar_ram> .. in addition to that, it would help if you can give an illustration of how new API can be added and how to write an handler in the spec
16:57:34 <diga> sripriya: yes, I will cover all these point
16:57:41 <sripriya> sridhar_ram: +1
16:58:00 <sripriya> thanks diga!
16:58:01 <diga> ok
16:58:06 <diga> sripriya: welcome!
16:58:07 <sripriya> #topic open discussion
16:58:26 <sridhar_ram> Folks - here is the doodle poll for the meeting time...
16:58:30 <sridhar_ram> #link http://doodle.com/poll/ee9p34kfhskd2ucc
16:58:47 <sripriya> thanks for the link sridhar_ram
16:59:04 <sridhar_ram> please set to your local TZ and select all the slots you can possibly attend
16:59:18 <sripriya> time is up team
16:59:26 <sripriya> thanks for joining the meeting
16:59:32 <sripriya> #endmeeting tacker