16:01:06 <sridhar_ram> #startmeeting tacker
16:01:07 <openstack> Meeting started Tue Jul 12 16:01:06 2016 UTC and is due to finish in 60 minutes.  The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:10 <openstack> The meeting name has been set to 'tacker'
16:01:18 <sridhar_ram> #topic Roll Call
16:01:20 <manikanta_tadi> o/
16:01:22 <janki> o/
16:01:24 <s3wong> o/
16:01:37 <sripriya> o/
16:01:37 <tbh> o/
16:01:39 <vishwanathj> o/
16:01:58 <sridhar_ram> Howdy folks !
16:02:14 <xuhaiwei_> hi, I am new to Tacker, this is my first team meeting
16:02:33 <tung_doan> Hi all
16:02:36 <sridhar_ram> Here is a shout out to silent observers .. if they are interested in introducing themselves. !
16:02:44 <sridhar_ram> xuhaiwei_: welcome to the project!
16:02:46 <vishwanathj> xuhaiwei_ Welcome
16:02:57 <xuhaiwei_> thanks, guys
16:03:09 <sridhar_ram> lets start..
16:03:14 <sridhar_ram> #topic Agenda
16:03:31 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker
16:03:44 <sridhar_ram> anything else beyond the ones listed ?
16:04:33 <sridhar_ram> I've one last minute item related to Team mascot
16:04:52 <sridhar_ram> #topic Announcements
16:05:20 <sridhar_ram> #info Lin Hua Cheng has stepped down tacker-horizon core team
16:05:57 <vishwanathj> oh
16:05:57 <sridhar_ram> Lin's work has moved away from OpenStack and he has stepped down both as horizon core and in tacker-horizon project
16:06:18 <sridhar_ram> I'd like to thank Lin for his help so far in the project..
16:06:25 <sripriya> +1
16:06:28 <vishwanathj> +1
16:06:32 <manikanta_tadi> +1
16:06:35 <tbh> +1
16:06:49 <sridhar_ram> He has introduced Tacker project to Horizon PTL for further tacker - horizon collaboration
16:06:50 <KanagarajM_> really appreciate Lin, thanks !
16:07:28 <sridhar_ram> A shout out for Tacker is planned in Horizon project's upcoming mid-cycle
16:07:51 <sridhar_ram> next...
16:08:18 <sridhar_ram> Summit talk deadline is tomorrow..
16:08:37 <sridhar_ram> Please use #Tacker to tag all the talks related to this project..
16:09:00 <sridhar_ram> It was initially missing and i had the Summit team add it for us
16:09:14 <sridhar_ram> anything else to announce from anyone here ?
16:09:39 <sridhar_ram> moving on..
16:09:52 <sridhar_ram> #topic Alarm based monitoring
16:10:01 <sridhar_ram> tung_doan: please take over..
16:10:13 <tung_doan> sridhar, thanks
16:10:22 <tung_doan> Currently, I started to code. My first focus is on implementing new abstract driver, alarm-listener and modifying monitoring framework
16:10:35 <tung_doan> I will finish soon and hope you guys review later.
16:11:21 <sridhar_ram> tung_doan: cool, some code / prototyping helps to shape the spec better
16:11:38 <tung_doan> sridhar_ram: yeah.. i try to do it...
16:11:57 <tung_doan> sridhar_ram: As Sridhar mentioned in the last meeting, in case scaling is triggered by alarm-based monitoring driver, I agree that it has an overlap with scaling spec
16:12:24 <tung_doan> sridhar_ram: So in the view of alarm spec, can I support KanagarajM to implement scaling usecase?
16:13:20 <sridhar_ram> KanagarajM_: do you need tung_doan to pitch in for scaling ?
16:13:26 <tung_doan> KanagarajM: last week, I reviewed scaling code and realized that Heat driver should add alarm monitoring policy. I would like to update this...
16:13:44 <tung_doan> KanagarajM: , please help me to review.. if possible
16:14:05 <KanagarajM_> sridhar_ram, I am fine if tung_doan really want to impl
16:14:23 <KanagarajM_> tung_doan, sure. I will review. thanks for looking at it.
16:14:31 <tung_doan> KanagarajM: thanks.. I will update ASAP
16:14:54 <sridhar_ram> tung_doan: it is unclear to me which part of scaling you are interested.. my understanding is scaling is fully taken care in KanagarajM_ spec and code..
16:15:39 <sridhar_ram> tung_doan: alarm-mon spec will stop at invoke *any* specified action.. one of the action could be scaling
16:16:11 <sridhar_ram> tung_doan: so, the only thing i anticipate is an integration work after both yours and KanagarajM_ work lands
16:16:30 <tung_doan> sridhar_ram:  right.. I mean that auto-scaling will need to have monitoiring policy if we want to do it automatically
16:16:52 <tung_doan> sridhar_ram:  not about alarm-based monitoring driver.. it is different
16:16:52 <KanagarajM_> sridhar_ram, yes. one change needed from scaling is, setup the metadata to support auto-scaling
16:17:13 <sridhar_ram> tung_doan: yes, but scaling feature is designed in a way it doesn't matter who triggers it.. manual vs alarm-mon
16:17:17 <KanagarajM_> tung_doan, sridhar_ram i will do it once scaling impl lands
16:17:43 <sridhar_ram> KanagarajM_: okay...
16:18:20 <sridhar_ram> KanagarajM_: tung_doan: sure, you guys can definitely collaborate to get that delta taken care..
16:18:31 <sridhar_ram> tung_doan: KanagarajM_: thanks for the explanation..
16:18:43 <KanagarajM_> sridhar_ram, sure.
16:18:54 <tung_doan> sridhar_ram:  thanks for reviewing my spec :)
16:19:00 <sridhar_ram> another general sticking point is .. "vnf-update" to change the threshold
16:19:10 <sridhar_ram> this is something new for Tacker..
16:19:33 <sridhar_ram> not sure, if we have thought about all the implications it brings in
16:19:38 <tung_doan> sridhar_ram:  i think that's something we should support
16:20:15 <sridhar_ram> tung_doan: why ? can't we expect the VNF operator to feed to correct threshold values during instantiation ?
16:20:27 <sridhar_ram> *feed he
16:20:36 <sridhar_ram> **feed the
16:20:52 <KanagarajM_> sridhar_ram, if we want to change any thing mentioned int VNFD after provisioning, we may need to peacefully handle VNFD first before updatign the actual VNF
16:21:05 <tung_doan> sridhar_ram:  actually, ceilometer already support this for alarm
16:21:51 <sridhar_ram> KanagarajM_: we can't "touch" VNFD after it is uploaded.. FWIW, it could in a git repo
16:22:04 <KanagarajM_> sridhar_ram, yes.
16:22:24 <KanagarajM_> sridhar_ram, i just insisted on it :)
16:22:27 <sridhar_ram> NFV catalog evolution is a whole different topic :)
16:22:40 <KanagarajM_> sridhar_ram, got it :)
16:23:17 <sridhar_ram> back to updating alarm thresholds in the middle of a VNF life-cycle .. i'm trying to judge whether it is MUST-HAVE or a nice-to-have
16:23:29 <sridhar_ram> what is the team's take ?
16:24:01 <KanagarajM_> tung_doan, is therosold not captured in the VNFD ?
16:24:02 <vishwanathj> Have you see any requests for that feature lately?
16:24:32 <tung_doan> sridhar_ram:  yes.
16:25:04 <sripriya> sridhar_ram: it is nice-to-have, we can then just parameterize the template for the thresholds and then update it on the VNF
16:25:36 <vishwanathj> sripriya good point
16:26:03 <sridhar_ram> sripriya: agree, but our parameterization story stops at initiation .. and it doesn't come into picture after a VNF goes ACTIVE
16:26:35 <sridhar_ram> that is my I see this as a new precedence.. in fact, not even related to alarm-mon..
16:26:56 <sridhar_ram> it has other implications.. to change VNF properties after it is instantiated..
16:26:58 <sripriya> sridhar_ram: yes, right now we only update the config and this will be something new to be handled as part of vnf-update
16:27:19 <sripriya> sridhar_ram: agree it is a separate RFE and need not be mixed with alarm-mon feature
16:27:48 <sridhar_ram> exactly, that is why i don't want this to come in as part of alarm-mon, instead consciously bring it in as a tacker capability
16:28:47 <sridhar_ram> tung_doan: our vnf-update flow is currently restricted to invoking mgmt-driver
16:28:52 <sripriya> sridhar_ram: yeah
16:29:10 <tung_doan> sridhar_ram:  it's fine for me.
16:29:12 <sridhar_ram> tung_doan: I'd recommend we take the "vnf-update" portion of your spec in a follow on
16:29:51 <sridhar_ram> tung_doan: other than this, i'm good to go w/ the spec..
16:29:53 <sripriya> tung_doan: you could capture it in future enhancements nice-to-have in your spec
16:30:14 <tung_doan> sridhar_ram:  sripriya: thanks
16:30:19 <sridhar_ram> tung_doan: captured few editorial comments as well
16:30:25 <sridhar_ram> tung_doan: overall looks good !
16:30:37 <tung_doan> sridhar_ram: ok.. will do
16:30:43 <sridhar_ram> anything else on alarm-mon ?
16:31:09 <sridhar_ram> #topic NSD support
16:31:36 <sridhar_ram> dkushwaha: tbh: are you here ?
16:32:19 <manikanta_tadi> sridhar_ram: I think you have missed VNFC Support in the agenda ?
16:32:44 <tbh> hi sridhar_ram , I couldn't have much updates from NSD side this week, dharmendra updated the spec regarding the ReST APi
16:33:04 <sridhar_ram> manikanta_tadi: will get to VNFC after NSD
16:33:20 <manikanta_tadi> sridhar_ram: Ok
16:33:32 <sridhar_ram> tbh: thanks, np
16:33:43 <sridhar_ram> team: here is the spec to review .. https://review.openstack.org/#/c/304667/4/specs/newton/nsd-support.rst
16:34:02 <sridhar_ram> we can continue the discussion in the gerrit
16:34:10 <sridhar_ram> moving on..
16:34:17 <sridhar_ram> #topic VNFC support
16:34:24 <sridhar_ram> tbh: manikanta_tadi: please take over
16:34:51 <manikanta_tadi> sridhar_ram, I am working with tbh to bring the spec to better shape.
16:35:06 <tbh> sridhar_ram, we have created the spec for VNFC support https://review.openstack.org/#/c/339798/
16:36:01 <manikanta_tadi> i have one doubt in mind, Why should not we have VNFC as seperate resource in the Tacker ...rather as parameter in the TOSCA templates ?
16:36:14 <KanagarajM> sorry team, my internet became too bad today !
16:36:35 <sridhar_ram> KanagarajM: noticed that, it is like weather
16:36:59 <KanagarajM> sridhar_ram, :)
16:37:26 <KanagarajM> sridhar_ram, not sure if i missed to answer .
16:37:36 <sridhar_ram> manikanta_tadi: it about modeling, logically VNFC maps to the runtime s/w within a Virtual Machine (VDU)
16:38:06 <sridhar_ram> so, VNFC is a sub-component of VNF
16:38:24 <sridhar_ram> we don't have a tacker resource that is granular than VNF today..
16:39:04 <manikanta_tadi> sridhar_ram: Ok
16:39:22 <tbh> sridhar_ram, manikanta_tadi  raised that point because we want to make use of VNFC for updating of s/w too
16:39:30 <sridhar_ram> VNFC is something a VNFD author need to decide when "designing" a VNF.. it is not the "Operator" job to decide which VNFC should go where
16:40:23 <sridhar_ram> tbh: yes, we need to support "vnf-upgrade" operation in the near future
16:40:55 <manikanta_tadi> sridhar_ram: But then i am not sure how a vnf upgrade needs to be handled
16:40:57 <sridhar_ram> tbh: we can still refer to the VNFC within the VNFD for the upgrade / update operation...
16:41:09 <tbh> sridhar_ram, if it binds to VNF, how can we try to use vnf-upgrade?
16:41:14 <KanagarajM> sridhar_ram, tbh, i was assuming that VNF mostly go with golden image concept instead
16:41:35 <sridhar_ram> manikanta_tadi: that could be similar to how we do "vnf-scaling <policy-name>"
16:41:43 <sridhar_ram> KanagarajM: Exactly
16:42:32 <KanagarajM> sridhar_ram, so do we need to support software installation on top of running VNF ?
16:42:50 <sridhar_ram> the spec need to clearly mention the motivation behind this ask.. operators want security hardened, golden base image (like CentOS) and populate installation s/w on top of it
16:43:11 <sridhar_ram> KanagarajM: yes, that is the crux of the VNFC support..
16:43:34 <manikanta_tadi> KanagarajM, sridhar_ram : We should some one wants to build the images , I think its good to have the loose coupling between the software component and underlying image?
16:43:49 <sridhar_ram> instead of sneaking in s/w installation into cloud-init.. VNFC will explicit "model" the s/w installed on golden base image
16:44:07 <sridhar_ram> manikanta_tadi: yes, +1 for loose coupling
16:44:09 <KanagarajM> sridhar_ram, +1
16:44:17 <sripriya> i had the same concern, so this spec deals with installing VNF application on a running VNF instance with prebuilt image than having the application also tightly integrated with the VNF instance
16:44:30 <sripriya> +1
16:45:05 <sridhar_ram> sripriya: sorry, what is the concern here ?
16:46:53 <sridhar_ram> IMO, the main design knot to crack is the mechanism by which tacker will install, uninstall s/w on the VM it spawned
16:47:21 <sridhar_ram> KanagarajM: i'm assuming Heat's SoftwareComponent would've solved this problem for cloud-init enabled VMs ?
16:47:34 <manikanta_tadi> sridhar_ram: I thought Operator will  be the VNFD Author , is it not true
16:47:58 <KanagarajM> sridhar_ram, yes
16:48:16 <sridhar_ram> well, the person who pushes the button on "vnf-create" is probably the not the same person who wrote the VNFD template
16:49:02 <tbh> sridhar_ram, I am here not totally depending on the SoftwareComponent of heat
16:50:43 <sridhar_ram> Here is my key take away for the VNFC effort (a) we need TOSCA modeling for the s/w running in "blank" VMs - this is not possible today and we need this support (b) once specified in the VNFD model, tacker server need to get the bits into those blank VMs spawnd and invoke the install sequence .. that is the scope of this effort .. Make sense ? Did i miss
16:50:43 <sridhar_ram> anything ?
16:51:40 <KanagarajM_> sridhar_ram, why blank VM ?
16:52:14 <manikanta_tadi> sridhar_ram :  I think,we should consider adding vnf component upgrade in this spec ?
16:52:16 <sridhar_ram> tbh: take a look at heat SoftwareComponent.. it is works for the above funtionalty we shd make use of it - to save effort + tosca-parser / heat-translator also has SoftwarreComponent support (AFAIK)
16:52:20 <tbh> sridhar_ram, for invoking, can we provide multiple options to the user?
16:52:31 <sridhar_ram> manikanta_tadi: no, differ to the next follow-on
16:53:29 <sridhar_ram> KanagarajM_: by blank VM i meant VM with just the base OS
16:53:37 <tbh> sridhar_ram, in the spec we mentioned about using SSH instead of SoftwareComponent
16:53:56 <sridhar_ram> tbh: you can definitely list diff options in the spec..
16:54:02 <sridhar_ram> tbh: .. we can discuss it
16:54:05 <sripriya> sridhar_ram: tbh: i thought the spec mentioned about limited capability  of Sofware Component
16:54:05 <vishwanathj> Is SoftwareComponent support available for a VM that is already up and running?
16:55:30 <tbh> sripriya, yes I am not sure, does all types of VDUs can support cloud-init itself which SoftwareComponent is using I guess
16:56:18 <tbh> vishwanathj, am not sure it will support
16:56:28 <sridhar_ram> tbh: ssh might be an option.. i'd suggest you to make some reasonable assumptions.. like the base VMs need to be cloud-init enabled..
16:56:42 <sripriya> tbh: it can only depend on the image itself if it has cloud-init capability, i dont think we should be based off that dependency
16:57:18 <sridhar_ram> sripriya: is it unreasonable in this day & age to insist cloud-init ?
16:57:31 <sripriya> sridhar_ram: does openwrt support this?
16:57:46 <sridhar_ram> ssh has many downsides as well, the primary being credential storage
16:58:18 <sridhar_ram> openwrt is different story.. here we are talking about an horizontal capability
16:58:35 <sridhar_ram> Folks .. we are out of time for today
16:58:47 <sridhar_ram> let's continue this next week..
16:58:58 <sripriya> sridhar_ram: ack
16:59:05 <sridhar_ram> tbh: please capture different install options in the spec..
16:59:17 <tbh> sridhar_ram, thanks for the inputs
16:59:23 <sridhar_ram> tbh: we can zoom in on 1 or more based on further discussion
16:59:32 <sridhar_ram> good discussion
16:59:40 <sridhar_ram> #topic Open Discussion
16:59:51 <sridhar_ram> sorry no time this week :)
16:59:56 <sridhar_ram> bye everyone...
17:00:00 <s3wong> bye
17:00:02 <sridhar_ram> #endmeeting