16:00:33 <sridhar_ram> #startmeeting tacker
16:00:34 <openstack> Meeting started Tue Jun 14 16:00:33 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:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:37 <openstack> The meeting name has been set to 'tacker'
16:00:43 <sridhar_ram> #topic Roll Call
16:00:55 <vishwanathj> o/
16:01:02 <sripriya_> o/
16:01:11 <s3wong> o/
16:01:30 <santoshk> o/
16:01:43 <sridhar_ram> howdy all ! let's give a min before we start...
16:02:30 <tung_doan> Hi all
16:02:33 <sridhar_ram> i know bobh and tbh are out today
16:02:37 <sridhar_ram> tung_doan: hi there!
16:02:42 <sridhar_ram> KanagarajM: are you here ?
16:02:50 <KanagarajM> sridhar_ram: hi
16:03:03 <sridhar_ram> okay, lets start...
16:03:07 <sridhar_ram> #topic Agenda
16:03:14 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_June_14.2C_2016
16:03:31 <sridhar_ram> anything else to discuss ? we might have some time for open topics
16:04:04 <sridhar_ram> alright...
16:04:11 <sridhar_ram> #topic Annoucements
16:04:36 <sridhar_ram> We have a bug fix release 0.3.1 out for Mitaka ...
16:04:44 <sridhar_ram> tacker 0.3.1 (mitaka) bug fix release
16:04:50 <sridhar_ram> #link http://lists.openstack.org/pipermail/openstack-announce/2016-June/001213.html
16:04:56 <sridhar_ram> tacker-horizon 0.3.1 (mitaka) bug fix release
16:05:00 <sridhar_ram> http://lists.openstack.org/pipermail/openstack-announce/2016-June/001216.html
16:05:06 <sridhar_ram> python-tackerclient 0.3.1 (mitaka) bug fix release
16:05:10 <sridhar_ram> http://lists.openstack.org/pipermail/openstack-announce/2016-June/001223.html
16:05:33 <sridhar_ram> Thanks for all those cherrypicks...
16:06:14 <sridhar_ram> Also, I'd like to thank the reviewers as we have picked up our review response / merge rate!
16:06:41 <sridhar_ram> Heads up, i'm out whole next week for OPNFV Summit @ Berlin..
16:06:57 <sridhar_ram> I'll cancel next week's mtg unless someone else wants to host it
16:07:35 <sridhar_ram> moving on..
16:07:47 <sridhar_ram> #topic Monitoring & Scaling specs
16:08:08 <KanagarajM> https://review.openstack.org/#/c/318577/7/specs/newton/manual-and-auto-scaling.rst
16:08:28 <sridhar_ram> KanagarajM: tung_doan: do you
16:08:32 * sridhar_ram oops
16:08:54 <sridhar_ram> KanagarajM: tung_doan: do you've any specific subtopics / design issues in these specs to discuss now ?
16:08:59 <tung_doan> sridhar_ram: also, my spec is updated: https://review.openstack.org/#/c/306562/12/specs/newton/alarm-based-monitoring-driver.rst
16:09:02 <KanagarajM> sridhar_ram: I have got some comments from sripriya and answered them ... and today i tried to define the schema for the new types
16:09:24 <KanagarajM> sridhar_ram: yeah, so would like to get feedback on https://review.openstack.org/#/c/329528/1/tacker/vm/tosca/lib/tacker_defs.yaml
16:09:49 <tung_doan> sridhar_ram: yes, some things related to alarm-url in monitoring driver
16:10:01 <sridhar_ram> unfortunately we are missing both bobh & tbh who can advise on tosca lib
16:10:04 <KanagarajM> sridhar_ram: trying to introduce a scalegroup after refering a tosca simple profile
16:10:23 <tung_doan> sridhar_ram: please have a look at L114
16:10:40 * sridhar_ram is looking
16:10:42 <sripriya> KanagarajM: sridhar_ram: i would like to know if it is beneficial to show scaling stats all the way to the user or are they supposed to get that from heat?
16:11:31 <sridhar_ram> KanagarajM: hang on, lets take one at a time :)
16:11:56 <KanagarajM> sridhar_ram: yeah, sure, will wait on scaling :)
16:12:26 <sridhar_ram> for TOSCA changes for both monitoring and scaling, tacker_defs.yaml is the right approach as this is not really coming from TOSCA NFV profile
16:12:40 <sridhar_ram> basing it off TOSCA Simple Profile is the right approach
16:13:12 <sridhar_ram> fyi... TOSCA Simple Profile is here http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html
16:13:50 <sridhar_ram> tung_doan: do this make sense? we shd insert Monitoring node type in tacker_defs.yaml
16:13:52 <sripriya> KanagarajM: why don't we push this new type to tosca parser project?
16:14:20 <sridhar_ram> KanagarajM: oh, sure we could.. that is the preferred approach
16:14:30 <tung_doan> sridhar_ram: sure.
16:15:03 <KanagarajM> sridhar_ram: ok. thanks i will update the spec with the new def in place,
16:15:10 <sridhar_ram> if we are blocked due to some reason in tosca-parser project, we can temporarily host it in tacker_defs.yaml
16:15:46 <sridhar_ram> tung_doan: you had a question on alarm-url in monitoring driver ?
16:16:01 <KanagarajM> sridhar_ram: sure. I will try to catch sahdev
16:16:05 <tung_doan> sridhar_ram: right... let take a lookpleae :)
16:16:20 <sridhar_ram> tung_doan: link please ?
16:16:31 <tung_doan> sridhar_ram: https://review.openstack.org/#/c/306562/12/specs/newton/alarm-based-monitoring-driver.rst
16:16:39 <tung_doan> Line 114
16:16:49 <KanagarajM> sripriya: I think, we could retrieve from heat when ever user make a request, or do you want to store in the deviceattributes table about the current state of scaling?
16:17:26 <sridhar_ram> tung_doan: i have doubts exactly in the same spot as well..
16:17:30 <sripriya> KanagarajM: probably we could take this up once we finish monitoring discussion?
16:18:21 <KanagarajM> sripriya: Ah, sure. thats right :)
16:18:24 <tung_doan> sridhar_ram: does it make sense, sridhar?
16:18:39 <sridhar_ram> KanagarajM: tung_doan: referring to monitoring policy id and scaling id in the API URI doesn't make sense
16:19:18 <sridhar_ram> these id, as far as I understand, refers to the policy name in the TOSCA template ?
16:19:28 <KanagarajM> sridhar_ram: its an name of the policies
16:19:32 <KanagarajM> sridhar_ram: yeah right
16:19:52 <sridhar_ram> so the URL will look like ...
16:19:56 <tung_doan> sridhar_ram: but srihar.. monitoirng policy can some actions
16:20:18 <sridhar_ram> "v1.0/vnfs/df2323-234234df2-23c23f32-3r4r234/vdu1_cpu_usage_monitoring_policy/<action-id>
16:20:31 <KanagarajM> RESTful API does allows to have action names it in
16:20:40 <tung_doan> sridhar_ram: sounds good
16:20:52 <KanagarajM> sridhar_ram: yes, its should be fine IMO
16:21:11 <KanagarajM> instead of action-id, it could be action-name
16:21:24 <sridhar_ram> okay, this means we need to decompose tosca template node names into addressable attributes
16:21:26 <KanagarajM> so that it would confuse by terms
16:21:28 <sripriya> KanagarajM: again that is unique only tot he VNF
16:21:28 <sridhar_ram> doable
16:21:52 <sripriya> KanagarajM: i could have another VNF with same policy name and the url will only defer on the uuid
16:22:05 <KanagarajM> sripriya: yes,
16:22:41 <tung_doan> KanagarajM: i already mentioned "action_name" in my spec
16:22:58 <KanagarajM> tung_doan: sure.
16:23:03 <sridhar_ram> tung_doan: KanagarajM: we need a pick one name!
16:23:30 <tung_doan> sridhar_ram: that's why I come today :)
16:23:46 <sridhar_ram> tung_doan: cool, worth it :)
16:23:56 <sridhar_ram> tung_doan: another question..
16:24:17 <tung_doan> KanagarajM: could I mentioned to metadata in my spec
16:24:33 <tung_doan> KanagarajM: in case if auto-scaling
16:24:35 <sridhar_ram> tung_doan: are we going to run a oslo_service/wsgi endpoint to take these webhook callback ?
16:25:05 <KanagarajM> sridhar_ram: yes, i believe so
16:25:10 <sridhar_ram> tung_doan: does it going a separate threads to process these callbacks ?
16:25:32 <sripriya> sridhar_ram: +1
16:25:37 <sridhar_ram> okay, then we need this part to be scalable (in the sense, to set num_thread/ workers)
16:25:44 <tung_doan> sridhar_ram: right
16:26:04 <KanagarajM> sridhar_ram: similar concept of heat :)
16:26:23 <sridhar_ram> KanagarajM: sure, now how secure this can be ... ?
16:26:57 <sridhar_ram> what if some malicious code can call this webhook ? is there a randon webhook identifier for each invocation ?
16:27:01 <KanagarajM> sridhar_ram: its right question, heat earlier gives by means of EC2 signing and i think now keystone deprecating it
16:27:37 <KanagarajM> sridhar_ram: so, we need to with tacker RBAC and in case of signaling we should see how to make ceilometer to invoke tacker with required credentails in place
16:28:25 <sridhar_ram> KanagarajM: i thought other projects generate a specific only time identifier (per webhook)
16:28:50 <KanagarajM> sridhar_ram: time identifier ?
16:28:53 <sridhar_ram> .. and as long as the original call is https we would have some level of protection
16:29:04 <sridhar_ram> oops, i meant one-time identifier
16:29:48 <KanagarajM> sridhar_ram: no, its getting used always in case of EC2 signed url in auto-scaling
16:30:02 <sridhar_ram> we can take this offline, but we need some solution to secure the calls coming through this channel (webhook)
16:30:15 <KanagarajM> sridhar_ram: yes,
16:30:16 <sridhar_ram> KanagarajM: i see
16:30:33 <sridhar_ram> tung_doan: just to wrap up monitoring....
16:30:35 <KanagarajM> tung_doan: if possible, could you please check with ceilometer
16:30:49 <tung_doan> sridhar_ram: Kanagaraj: OK
16:31:23 <sridhar_ram> tung_doan: can you please describe your design for the oslo_service/wsgi endpoint, multi-thread handler for the webhook callback and how you are planning to have this scale ?
16:31:41 <sridhar_ram> tung_doan: .. in meant, in your next patchset
16:32:14 <tung_doan> sridhar_ram: Ok.. I will think about them...
16:32:27 <sridhar_ram> IMO, with that and a some kind of handle on the callback security, we should wrap this spec and land it
16:32:49 <sridhar_ram> let's move onto scaling...
16:33:09 <sridhar_ram> KanagarajM: sorry, you got interrupted.. please continue
16:33:39 <KanagarajM> sridhar_ram: for scaling, i belive we could go with  https://review.openstack.org/#/c/329528/1/tacker/vm/tosca/lib/tacker_defs.yaml
16:33:42 <tung_doan> sridhar_ram: anw, please review my spec.. thanks
16:34:02 <sridhar_ram> tung_doan: will do, thanks again for join at this late hour
16:34:06 <sridhar_ram> *joining
16:34:43 <KanagarajM> sridhar_ram: and i will place it in tacker and contiune the dev
16:35:14 <KanagarajM> sridhar_ram: in parallel, i would check with sahdev on how to take it tosca-parser + heat-translator
16:35:25 <KanagarajM> sridhar_ram: is that fine?
16:36:17 <sridhar_ram> KanagarajM: fine, we still need to follow up https://review.openstack.org/#/c/302636/ ?
16:36:51 <KanagarajM> sridhar_ram: yes, sure
16:37:46 <sridhar_ram> KanagarajM: for the call back handler ..
16:38:01 <sridhar_ram> KanagarajM: .. you need to coordinate w/ tung_doan, correct?
16:38:28 <KanagarajM> sridhar_ram: for call back, i have asked tung_doan to check with ceilometer
16:38:38 <KanagarajM> and follow up on it.
16:38:43 <sridhar_ram> okay.. thanks
16:38:47 <sridhar_ram> one last..
16:39:13 <sridhar_ram> have you figured out the dependency between your two work items ? who is going to go first ?
16:39:54 <sridhar_ram> again, you can decide offline.. but it will be good to have a plan..
16:40:00 <KanagarajM> sridhar_ram: it should go in parallel, and for the auto-scaling from the alarm-monitor can go last
16:40:04 <sridhar_ram> .. so that you don't trip each other :)
16:40:23 <KanagarajM> sridhar_ram: 1. scaling and/or monitoring 2. auto-scaling from monitor driver
16:40:38 <sridhar_ram> KanagarajM: sounds good :)
16:40:48 <sridhar_ram> tung_doan: KanagarajM: thanks!
16:40:56 <tung_doan> sridhar_ram: np :)
16:41:02 <KanagarajM> sridhar_ram: so i don't see any dependency for manual scaling
16:41:24 <sridhar_ram> okay.. i've a clarification on that, but will take it offline..
16:41:30 <sripriya> KanagarajM: sridhar_ram: should we capture scalign stats in tacker?
16:41:36 <sripriya> *scaling
16:41:40 <KanagarajM> sripriya: you had some questions, and i answered, kindly let me know your feed back
16:41:56 <sridhar_ram> KanagarajM: what you mean by scaling stats ?
16:41:57 <sripriya> KanagarajM: sure, will respond to that
16:42:29 <sripriya> sridhar_ram: no. of vdus currently scaled and related metrics?
16:42:33 <KanagarajM> sridhar_ram: sripriya has mentioned that its better toc apture the current state like number of VDUS
16:43:01 <sripriya> sridhar_ram: with scaling coming in, we may start off with 2 instances per vdu and then scale out to 3 based on policies
16:43:27 <sridhar_ram> that will be usefull
16:43:29 <sripriya> sridhar_ram: the only way to see this is going through heat
16:43:43 <sridhar_ram> apart from the event-logging on every scale event
16:44:12 <sripriya> sridhar_ram: yes...
16:44:38 <sridhar_ram> KanagarajM: we got to probe heat to get that stat ? again, depends on the effort .. we can always do this in a follow on
16:45:05 <KanagarajM> sridhar_ram: yeah, thats better plan.
16:45:26 <sripriya> KanagarajM: sounds good
16:45:34 <sridhar_ram> KanagarajM: i'd suggest we split it into a follow on RFE if that is going to be long poll
16:45:49 <KanagarajM> sridhar_ram: yeah sure.
16:46:12 <KanagarajM> sridhar_ram: it would be great if you could help to merge the spec before your OPNFV summit trip :)
16:46:37 <KanagarajM> sridhar_ram: i could use that week to impl
16:46:39 <sridhar_ram> yes, we should shoot for that.. :)
16:47:01 <KanagarajM> sripriya: i would seek your help too :)
16:47:07 <KanagarajM> sridhar_ram: yeah sure :)
16:47:17 <sripriya> KanagarajM: sure
16:47:21 <sridhar_ram> tung_doan: KanagarajM: lets sync up to catchup in the #tacker channel and/or ML to keep this moving.. so that we don't wait for this weekly meeting
16:47:39 <sridhar_ram> moving to the next topic...
16:47:52 <tung_doan> sridhar_ram: agree
16:47:53 <KanagarajM> sridhar_ram: sure.
16:48:02 <sridhar_ram> #topic Midcycle Meetup - Virtual vs F2F
16:48:32 <sridhar_ram> based on the doodle pool .. http://doodle.com/poll/2p62zzgevg6h5xkn
16:49:10 <sridhar_ram> .. we unanimously prefer a virtual midcycle meetup
16:49:36 <sridhar_ram> i propose we do a two-day Virtual Meetup with two different timeslots..
16:50:03 <sridhar_ram> .. one Asia friendly and another w/ US / Europe
16:50:11 <sridhar_ram> thoughts ?
16:51:15 <sripriya> +1
16:51:20 <sridhar_ram> anyways, i will create another doodle poll to finalize the timeslots
16:51:28 <manikanta_tadi> +1
16:51:31 <s3wong> +1
16:51:55 <KanagarajM> sridhar_ram: nice
16:52:14 <sridhar_ram> i was start an etherpad as well.. and we should start collecting ideas for topics to discuss
16:52:43 <sridhar_ram> Here it is https://etherpad.openstack.org/p/tacker-newton-midcycle
16:53:22 <sridhar_ram> zeih offered an EU location.. i wish we can go there for tacker midcycle one day :)
16:53:33 <sridhar_ram> moving on...
16:53:51 <sridhar_ram> #topic Bugs, RFE and Open Discussion
16:54:09 <sridhar_ram> I know we have many bugs and RFEs in flight...
16:54:36 <sridhar_ram> in fact, lots of small but significant things are coming in as RFEs..
16:54:53 <sridhar_ram> i'd like to thankg gongysh for all those oslo refactoring!
16:55:10 <sridhar_ram> anyone have a specific bug or RFE to discuss ?
16:55:35 <KanagarajM> sridhar_ram: i am trying to set the retry count to 3 in heat driver
16:55:51 <KanagarajM> sridhar_ram: as 60 is big in number https://review.openstack.org/329527
16:55:56 <sridhar_ram> KanagarajM: stack retry
16:55:58 <sridhar_ram> ?
16:56:09 <KanagarajM> sridhar_ram: sripriya  yes
16:57:01 <KanagarajM> sridhar_ram: yes it was 60 earlier
16:57:25 <sridhar_ram> KanagarajM: well, what to say.. we don't give up trying that easily ;-)
16:57:36 <KanagarajM> sridhar_ram: :)
16:57:59 <sridhar_ram> alright.. please keep the bug fixes, RFEs coming..
16:58:00 <sripriya> KanagarajM: 300 was the time out keeping vms in mind which take nearly 2 -3 minutes to bring up an instance
16:58:03 <KanagarajM> sridhar_ram: in heat also we try for 3 as default for resource
16:58:24 <sridhar_ram> KanagarajM: sounds good & make sense!
16:58:37 <sripriya> KanagarajM: tacker was false setting VNF to ERROR state even though the actual instance did come up after like 2 minutes on VMs with starved specs
16:59:09 <sridhar_ram> KanagarajM: yeah, thats bad
16:59:23 <sridhar_ram> we are out of time..
16:59:33 <sridhar_ram> thanks everyone who joined..
16:59:42 <sridhar_ram> again, no meeting next week..
16:59:52 <sridhar_ram> will meet the week after next...
17:00:00 <sridhar_ram> thanks everyone!
17:00:05 <s3wong> have fun in Berlin!
17:00:09 <s3wong> bye
17:00:14 <vishwanathj> bye
17:00:15 <KanagarajM> sridhar_ram: will come to tacker
17:00:15 <sridhar_ram> s3wong: thanks!
17:00:18 <sridhar_ram> #endmeeting