16:03:13 <sridhar_ram> #startmeeting tacker
16:03:14 <openstack> Meeting started Tue Jun  7 16:03:13 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:03:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:18 <openstack> The meeting name has been set to 'tacker'
16:03:27 <sridhar_ram> #topic Roll Call
16:03:28 <KanagarajM> hi
16:03:31 <bobh> o/
16:03:35 <manikanta_> o/
16:04:00 <sripriya_> o/
16:04:06 <vishwanathj> o/
16:04:07 <santoshk> hi
16:04:10 <tbh> o/
16:04:14 <s3wong> o/
16:04:38 <sridhar_ram> alright, lets start...
16:04:44 <sridhar_ram> #topic Agenda
16:04:51 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_June_7.2C_2016
16:05:10 <sridhar_ram> anything else to discuss beyond this ?
16:05:44 <sridhar_ram> moving on..
16:05:50 <sridhar_ram> #topic Annoucements
16:06:12 <sridhar_ram> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/096774.html
16:06:33 <sridhar_ram> we have new core team member for tacker (main) project..
16:06:39 <sridhar_ram> tbh: welcome to the team!
16:06:43 <sripriya_> tbh: congrats!
16:06:51 <vishwanathj> tbh congrats and well deserved
16:06:52 <manikanta_> Congrats tbh ...Way to go !!
16:06:53 <KanagarajM> congrats tbh !
16:07:02 <santoshk> congrats tbh
16:07:22 <sridhar_ram> tbh: thanks for all your contributions so far... we have many interesting things to accomplish !
16:07:29 <bobh> tbh: congrats and welcome!
16:07:47 <sridhar_ram> next...
16:07:52 <tbh> thanks all
16:07:56 <tbh> sridhar_ram, sure
16:08:15 <sridhar_ram> Tacker now has support for Reno based releasenotes management
16:08:42 <sridhar_ram> Please follow the usage guide at...
16:08:44 <sridhar_ram> #link http://docs.openstack.org/developer/reno/usage.html
16:09:53 <sridhar_ram> ... please use it to capture new features , deprecation notes or any other heads up to our user community
16:10:10 <sridhar_ram> this is a best practice to pick early in our dev
16:10:33 <sridhar_ram> moving on...
16:10:46 <sridhar_ram> #topic Monitoring & Scaling specs
16:11:07 <sripriya_> sridhar_ram: should reno be updated whenever we implement a new feature?
16:11:23 <sridhar_ram> sripriya_: yes
16:11:56 <KanagarajM> sridhar_ram, for scaling, i think, spec is alomst ready
16:12:03 <sripriya_> sridhar_ram: ok
16:12:15 <tung_doan> hi all. sorry i am late
16:12:18 <KanagarajM> sridhar_ram, only two of your comments to be decided
16:12:43 <sridhar_ram> KanagarajM: okay.. i think finalizing the TOSCA parser is important..
16:12:44 <KanagarajM> sridhar_ram, technically I think PATCH should be
16:13:09 <KanagarajM> sridhar_ram, yeah, on TOSCA side, saw a patch on the support for sclaing policy
16:13:33 <KanagarajM> sridhar_ram, should we add that in the spec?
16:14:00 <sridhar_ram> bobh: any thoughts on navigating the tosca-parser dependency for scaling ?
16:14:34 <bobh> sridhar_ram: if the tosca-parser side can be completed soon it can be released in the next t-p point load and pulled in
16:14:46 <bobh> sridhar_ram: is there also a heat-translator dependency?
16:14:48 <sridhar_ram> KanagarajM: bobh: do we have dep on both tosca-parser and heat-translator for our scaling needs ?
16:15:11 <sridhar_ram> bobh: hehe.. had the same question to you :)
16:15:26 <KanagarajM> sridhar_ram, I saw a patch on the heat-translator, and i believe tosca parser alaready support the ppolicy
16:15:54 <bobh> sridhar_ram: I should probably know that I guess.....
16:16:15 <sridhar_ram> KanagarajM: bobh: first order of deps IMO is tosca-parser.. my understanding is heat-translator can be "managed" ?
16:16:16 <bobh> sridhar_ram: I'll try to track down whats in flight on both t-p and h-t
16:16:31 <sridhar_ram> bobh: that would help...!
16:16:37 <bobh> sridhar_ram: that's one word for it :-)
16:16:52 <KanagarajM> bobh, thanks. that would help !
16:17:44 <sridhar_ram> KanagarajM: bobh: an important deviation i see is on the way the monitoring trigger policy is captured...
16:17:45 <KanagarajM> sridhar_ram, how about the specs update for the reference to that heat-translaotr pathc
16:18:51 <sridhar_ram> fyi, please review https://review.openstack.org/#/c/302636/ .. this is still open in heat-translator
16:19:02 <tung_doan> sridhar_ram: i would like to discuss monitoring policy in TOSCA template.
16:19:26 <tung_doan> sridhar_ram:monitoring policy is embedded in Scaling poplicy
16:19:27 <KanagarajM> sridhar_ram, you mean supporting to monitor across vdus.
16:19:45 <sridhar_ram> KanagarajM: sure.. lets update the spec mention that we will leverage tosca-parser & heat-translator as appropriate...
16:20:12 <KanagarajM> sridhar_ram, ok. thats better.
16:20:28 <sridhar_ram> moving to tung_doan monitoring spec...
16:21:06 <sridhar_ram> tung_doan: my understanding is you proposed a separate "tosca.policies.monitoring" node type for mon policy..
16:21:17 <tung_doan> sridhar_ram:right
16:21:20 <sridhar_ram> tung_doan: IMO, this is a very good approach
16:22:05 <sridhar_ram> this mon policy can have 1 or more "targets" VDUs..
16:22:17 <KanagarajM> yeah, that would really helps to monitor across vdus.
16:22:54 <sridhar_ram> we also have a separate "tosca.policies.scaling" node type specifically for scaling policy...
16:23:44 <tung_doan> sridhar_ram: actually it is also related to some actions
16:23:54 <sridhar_ram> for auto-scaling the "tosca.policies.monitoring" should have an action triggering "tosca.policies.scaling"
16:24:01 <sridhar_ram> tung_doan: agree...
16:24:48 <sridhar_ram> tung_doan: KanagarajM: i don't mean to rat hole on this too much... once we have enough clarity we should wrap up the specs and move on to the implementation..
16:24:52 <tung_doan> sridhar_ram: that is my concern
16:24:57 <sridhar_ram> bobh: tung_doan: KanagarajM : what do you think ?
16:26:13 <sridhar_ram> bobh: can you help to make sure the TOSCA semantics gel well across these two specs ?
16:26:39 <KanagarajM> sridhar_ram, yeah, that s good idea. I will push the patch on the spec today for scaling and start the impl by this week
16:26:47 <bobh> sridhar_ram: only concern is I'm on vacation for a week starting tomorrow
16:27:02 <bobh> sridhar_ram: I can try to do a quick review tonight but I'll be offline after that until next Wednesday
16:27:31 <tung_doan> <sridhar_ram>: IMHO, separating them is not difficult work.
16:27:32 <sridhar_ram> bobh: thanks
16:27:59 <KanagarajM> bobh, by then you will have many patches to look at ;)
16:28:47 <sridhar_ram> tung_doan: that's good.. it is better keep them independent in the beginning so that patchsets can keep landing
16:29:03 <bobh> KanagarajM: :-)
16:29:21 <tung_doan> sridhar_ram: sure. I will follow Santosh's spec as well
16:30:10 <sridhar_ram> tung_doan: KanagarajM : how is callbacks (webhooks) from Ceilometer and Heat-Scaling going to be handled ?
16:31:01 <sridhar_ram> will tacker-service expose a webservice to receive these call backs ?
16:31:47 <KanagarajM> sridhar_ram, tung_doan i think that is the way to go .... as ceilometer needs to inform the tacker
16:31:54 <tung_doan> sridhar_ram: yes. it should be defined in TOSCA template.
16:32:51 <tung_doan> sridhar_ram: we need to provide a webservice. it is way to go
16:32:59 <sridhar_ram> tung_doan: this piece is not related to the TOSCA template
16:34:16 <sridhar_ram> tung_doan: it will be good to describe this webservice in your spec... as it is technically an external facing endpoint
16:34:41 <tung_doan> KanagarajM: "ceilometer needs to inform the tacker". What do you mean?
16:34:43 <sridhar_ram> we also need to secure this channel
16:35:10 <tung_doan> KanagarajM: you mean we can use directly Ceilometer?
16:35:23 <tung_doan> sridhar_ram: OK///
16:35:44 <KanagarajM> tung_doan, when ceilometer evaluate the alarm, it needs to invoke the tacker,
16:36:48 <sridhar_ram> the way i parse this .. tosca.policies.monitoring --will translate--> HOT Ceilometer resource with webhook pointing back to tacker callback webservice
16:37:07 <KanagarajM> sridhar_ram, +1
16:37:23 <tung_doan> sridhar_ram: +1
16:37:38 <sridhar_ram> alright, we are the same page :)
16:37:45 <sridhar_ram> KanagarajM: now for scaling..
16:38:06 <sridhar_ram> .. how do you plan to keep Tacker in the loop when a scaling VM is created or deleted ?
16:39:02 <KanagarajM> sridhar_ram, corresponding events will be generated and capture the scaling related details
16:39:13 <sridhar_ram> like i mentioned in the spec, we need to support custom scaling workflows like giving the ip addr of the new scaled out VM to the control plan vm
16:39:33 <sridhar_ram> KanagarajM: again, this will need a tacker webservice to handle the callbacks ?
16:39:59 <sridhar_ram> KanagarajM: is it a webhook like callback or more like a RPC event ?
16:40:16 <KanagarajM> sridhar_ram, webhook is a like a callback. a
16:40:43 <KanagarajM> sridhar_ram, i think once scling is completed, we could pull the new VMs IP from the heat
16:40:44 <sridhar_ram> KanagarajM: cool, i guess then we need to have *one* tacker webservice across these two specs...
16:41:50 <tung_doan> sridhar_ram: once integrating scaling and monitoring.. one tacker webservice is possible
16:41:54 <KanagarajM> sridhar_ram, from heat to make it async , i.e or we could listen for scaling event from heat and then pull the IP of new VM
16:42:09 <sridhar_ram> KanagarajM: tung_doan: I will be great if you both can co-ordinate on this common webservice piece that be leveraged to handle both ceilometer and scaling callbacks
16:42:33 <KanagarajM> sridhar_ram, for scaling , imo, callbacks does not help
16:42:38 <tung_doan> sridhar_ram: it is truly goo d way to gi
16:42:44 <tung_doan> *gi: go
16:42:47 <sridhar_ram> KanagarajM: cool, can you please desc few sentences on this in your spec
16:42:53 <KanagarajM> sridhar_ram, instead, we should depends on the heat spec
16:43:10 <KanagarajM> sridhar_ram, yeah sure.
16:43:22 <sridhar_ram> KanagarajM: what you mean by "depends on heat spec" ?
16:43:54 <KanagarajM> sridhar_ram, sorry typo, heat events
16:44:26 <sridhar_ram> KanagarajM: okay... make sense..
16:45:00 <sridhar_ram> alright, i think we are in the last legs of this specs.. i'd love to see both of these specs wrapped up by this week
16:45:26 <sridhar_ram> team - please do your last call reviews!
16:45:36 <sridhar_ram> moving on...
16:45:48 <sridhar_ram> #topic NSD Scoping
16:45:58 <sridhar_ram> dkushawa: are you here ?
16:47:17 <sridhar_ram> I don't see him here.. lets move this topic to next week
16:47:32 <sridhar_ram> #topic Midcycle Meetup
16:48:06 <johncallaghan> topic: appeco_wg
16:48:23 <sridhar_ram> I'd like to do a quick poll here if the wider team is interested in participating in a Tacker midcycle meetup
16:48:47 <sridhar_ram> ... our team spread across diff TZs..
16:49:08 <sridhar_ram> how many of you would prefer a 2-day virtual midcycle meetup ?
16:49:42 <sripriya_> sridhar_ram: +1
16:50:17 <sridhar_ram> sripriya_: thanks...
16:50:22 <s3wong> sridhar_ram: virtual is good
16:50:34 <bobh> sridhar_ram: +1
16:50:55 <sridhar_ram> bobh: s3wong: thanks!
16:51:03 <sridhar_ram> i'll also send a doodle pool out to the ML to gauge the interest..
16:51:24 <sridhar_ram> moving on...
16:51:31 <sridhar_ram> #topic Open Discussion
16:51:46 <sridhar_ram> any general things to discuss ?
16:52:00 <sridhar_ram> bugs, docs, gate jobs...
16:52:31 <sripriya_> sridhar_ram: i had one update on a rfe i'm working
16:52:41 <sridhar_ram> sripriya_: sure, go ahead
16:52:55 <KanagarajM> sridhar_ram, sripriya_ bobh kindly have a look at events spec https://review.openstack.org/#/c/321370/
16:54:04 <sripriya> sridhar_ram: i'm planning to remove the whole <class name>-<file path-><uuid>-<vdu name> thing for heat stack names
16:54:05 <sridhar_ram> KanagarajM: will do
16:54:55 <bobh> KanagarajM: will do
16:55:12 <sripriya__> sridhar_ram: this will reflect on the vdu name as well
16:55:23 <sridhar_ram> sripriya: is there a way we can preserve <first 6 chars in uuid>-<vdu-name> ?
16:55:46 <sripriya__> sridhar_ram: which uuid ar eyou referrign to?
16:55:53 <sripriya__> *are you referring
16:56:11 <sridhar_ram> the current uuid .. which is the vnf uuid
16:56:33 <sripriya__> sridhar_ram: is that serving any purporse now that we will make vnf names unique?
16:56:34 <sridhar_ram> i'm suggesting something similar to "git log --oneline"
16:58:04 <sripriya__> sridhar_ram: what does that do?
16:58:05 <sridhar_ram> i was thinking removing is class-name and file-path makes perfect sense.. but i do see value in a portion of uuid+vdu-name for debugging purpose
16:58:23 * sridhar_ram 2mins left
16:58:48 <sripriya__> sridhar_ram: the vdu names inside vnf are also unique resource names
16:59:30 <sridhar_ram> looks we are out of time for today..
16:59:41 <sridhar_ram> sripriya__: let's take this offline ?
16:59:45 <sripriya__> sridhar_ram: i will be pushing a gerrit patch soon and we can discuss on that. i just wanted to give a heads up to the broader team on the refactoring of stack and nova namrs
16:59:48 <sripriya__> names*
17:00:01 <sridhar_ram> sripriya__: thanks for the heads up
17:00:11 <sridhar_ram> that's it folks..
17:00:15 <sridhar_ram> bye all
17:00:18 <sridhar_ram> #endmeeting