16:00:45 <sridhar_ram> #startmeeting tacker
16:00:45 <dkushwaha_> o/
16:00:46 <openstack> Meeting started Tue May 17 16:00:45 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:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:50 <openstack> The meeting name has been set to 'tacker'
16:00:56 <sridhar_ram> #topic Roll Call
16:01:01 <vishwanathj> o/
16:01:01 <twm2016> o/
16:01:03 <trozet> o/
16:01:03 <sripriya> o/
16:01:05 <dkushwaha_> o/
16:01:06 <tbh> o/
16:01:09 <tung_doan> o/
16:01:15 <janki91> o/
16:01:29 <manikanta_tadi> o/
16:01:29 <sridhar_ram> Howdy folks !
16:01:41 <sridhar_ram> KanagarajM: brucet: are you here ?
16:02:03 <sridhar_ram> lets start...
16:02:12 <sridhar_ram> #topic Agenda
16:02:16 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_May_17.2C_2016
16:02:52 <sridhar_ram> main topic is alarm based monitoring & scaling...
16:03:04 <tung_doan> sridhar_ram: thanks
16:03:13 <sridhar_ram> we can take the rest if we wrap up early on this subject..
16:03:34 <sridhar_ram> #topic Alarm based VDU Monitoring & Scaling
16:03:45 <sridhar_ram> bobh: are you here ?
16:03:55 <KanagarajM> sridhar_ram, hi
16:03:59 <bobh> o/
16:04:09 <sridhar_ram> KanagarajM: bobh: hi !
16:04:37 <sridhar_ram> First order of business to clarify the user stories for this features ..
16:04:57 <sridhar_ram> bobh: can you please help to set the parameters of the end goal here ?
16:05:18 <bobh> sridhar_ram: I think there is a long-term goal and multiple short-term goals to get there
16:05:35 <bobh> sridhar_ram: the long-term goal is to be able to use ceilometer alarms to trigger auto-scaling of VDUs
16:05:55 <bobh> sridhar_ram: I think the components of that need to be (a) a ceilometer monitoring plugin
16:06:19 <bobh> sridhar_ram: (b) a way to take advantage of auto-scaling support in heat
16:06:38 <bobh> sridhar_ram: and another important issue is how to model all of this in TOSCA
16:07:00 <s3wong> hello
16:07:16 <sridhar_ram> bobh: +1 on bring TOSCA template to articulate these features..
16:07:22 <sridhar_ram> bobh: thanks...
16:07:55 <sridhar_ram> I was thinking even one level abstract..w/o bringing Ceilometer and Heat-Scaling...
16:08:19 <sridhar_ram> .. as we are designing TOSCA templates for these features...
16:09:29 <sridhar_ram> fyi, see this http://paste.openstack.org/show/497374/
16:10:43 <sridhar_ram> I like the idea of splitting this work into two specs.. (a) alarm based monitoring and (b) VDU scaling - both auto using (a) and manual
16:10:43 <bobh> sridhar_ram: the scaling policy might need to be bundled into a monitoring_policy with action:scale
16:10:54 <bobh> sridhar_ram: +1
16:11:18 <sridhar_ram> tung_doan: KanagarajM: brucet_: can you please chime on splitting the spec ?
16:11:33 <KanagarajM> sure
16:12:05 <tung_doan> sridhar_ram: Hi sridhar, can I mention to manual/autoscaling in my spec as some actions?
16:12:09 <KanagarajM> unless we want to give control to user for what ever reason, to trigger the scaling,
16:12:18 <brucet_> Splitting manual and auto???
16:12:20 <brucet_> Bad idea
16:12:21 <KanagarajM> scaling could be part of moniotring policy
16:12:33 <sridhar_ram> bobh: sure, we can discuss abt which is the correct place for scaling policy.. I was thinking we could allow manual scaling even WITHOUT monitoring
16:12:47 <bobh> sridhar_ram: agree
16:13:08 <bobh> sridhar_ram: the scaling mechanism should be independent of manual/automatic
16:13:12 <sridhar_ram> tung_doan: No, I would leave any scaling related things out of your spec.. as there is too much for one spec level content
16:13:13 <KanagarajM> if that is the case, then scaling_policy could be outside and moniroing could refer it
16:13:51 <sridhar_ram> brucet_: no, splitting alarm-based monitoring and any scaling related policy + actions
16:14:13 <brucet_> How is that differentbthan what eists now?
16:14:18 <KanagarajM> sridhar_ram, i would like to keep considering both while design the both the features though both could be splitted into two
16:14:23 <sridhar_ram> that way we have clear separation of end goal here and also developer ownership
16:14:38 <sridhar_ram> KanagarajM: +2, absolutely...
16:15:12 <sridhar_ram> the design should be cohorent across these two specs.. they need to leverage each other..
16:15:41 <KanagarajM> yes, perfect !
16:16:01 <sridhar_ram> brucet_: today we have mushed these two non-trivial functions into one spec... it is getting hard to see a clear picture
16:16:33 <bobh> sridhar_ram: +2
16:16:54 <KanagarajM> we could carry out the both the spec simultanesous, after agreeing up on the dependecy among them, like meta-data settings,
16:17:06 <brucet_> Triggers and actions need to be part of one overall architecture
16:17:15 <brucet_> I can't say what that means in terms of specs
16:17:37 <sridhar_ram> KanagarajM: sure.. scaling spec can test manual scaling until alarm based spec is ready
16:17:57 <brucet_> Monitoring creates triggers / events
16:18:05 <KanagarajM> sridhar_ram, sure.
16:18:09 <brucet_> Scaling is an example of an action based on that event
16:18:48 <sridhar_ram> brucet_: as you see in the http://paste.openstack.org/show/497374/ the first spec - alarm based monitoring driver should focus on VDU monitoring and triggering existing actions (respawn, log)
16:18:56 <sridhar_ram> tung_doan: what do you think ?
16:19:05 <brucet_> That one approach / architecture that cn be used
16:19:10 <brucet_> There are others
16:19:11 <KanagarajM> brucet_, yes, in alarm-monitor-driver, scale_in/out could be different actions, in addition to the exsting actions
16:19:23 <sridhar_ram> KanagarajM: =1
16:19:25 <sridhar_ram> +1
16:19:43 <tung_doan> sridhar_ram: I still think it is possible to mention to scaling as a policy in monitoring driver
16:19:50 <KanagarajM> when scale_xxx, scaling policy needs to given as params
16:20:12 <tung_doan> sridhar_ram: monitoring diver can support multiple policies
16:20:13 <brucet_> I think we need one overall architecture for Tacker based events and actions
16:20:23 <KanagarajM> this will hold good with existing approach
16:21:00 <brucet_> A heat based event / action implementation should be part of that architecture
16:21:30 <brucet_> A Tcker monitoring driver based event / action implementation should be another part
16:21:30 <sridhar_ram> tung_doan: from implementation point of view, my understanding is you'll have a lot to cover for alarm / ceilometer based monitoring
16:21:37 <brucet_> Then the two mechanisms can interact
16:21:51 <KanagarajM> brucet_, yes, and as we decided to split the scaling and monirotring, triggering in heat needs to be via resource-signal command
16:22:07 <brucet_> Not necessarily
16:22:09 <KanagarajM> instead of heat webhook
16:22:24 <brucet_> Ah....
16:22:30 <brucet_> Both are valid
16:22:46 <KanagarajM> the reason is, tacker creates the scaling stack, monitoring stack, so tacker could directly siganl it
16:23:04 <KanagarajM> no need to depends on the webhook url.
16:23:09 <tung_doan> sridhar_ram: what actions can be mentioned in my spec, sridhar?
16:23:36 <brucet_> Heat webhook is a valid option for signaling events. So is triggers within a Heat stack itself
16:24:13 <sridhar_ram> tung_doan: for now "log" action makes most sense...
16:24:16 <tung_doan> some actions i can see are log, repspawn, scaling....
16:24:17 <KanagarajM> brucet_, while tacker can directly signal the scaling stack, its better option
16:24:30 <brucet_> Both are valid options
16:24:38 <KanagarajM> rather than using webhook
16:24:45 <brucet_> IMHO, we should not create an architecture that precludes either
16:24:57 <KanagarajM> brucet_, both are valid approach, but i prefer the siganling over resource-signal
16:25:20 <sridhar_ram> tung_doan: this suggestion is purely a divide and conquer.. once you are done w/ alarm based monitoring, you can continue to participate in the scaling related work items...
16:25:33 <KanagarajM> as tacker is the owner of those stacks, its perfect option to resource-signal
16:25:34 <brucet_> If we agree that both approaches are valid, then we don't need to debate which is "better"
16:26:06 <tung_doan> sridhar_ram: Ok... but it still can support scaling if possible, right?
16:26:35 <brucet_> sridhar_ram: I suggest we focus on overall architecture first. Then break up the specs
16:26:37 <sridhar_ram> tung_doan: No, lets leave the scaling to the 2nd spec...
16:27:10 <KanagarajM> brucet_, while desiging, its better to go with the right option, i believe.
16:27:38 <KanagarajM> brucet_, sure. for spliting, i guess, the last patch set could be direclty splited into two
16:28:04 <KanagarajM> one for scaling and another for alarm-monitor
16:28:34 <sridhar_ram> Folks - I'm trying to put - on the fly - an etherpad to use TOSCA as the way to describe the scope for these two specs...
16:28:38 <sridhar_ram> https://etherpad.openstack.org/p/tacker-alarm-scaling-template
16:28:42 <brucet_> My main point here is that I think we need an overall arch for Monitoring / Events and Actions (scaleup, scaledown, etc)
16:31:16 <sridhar_ram> As you see in the etherpad.. alarm mon spec should focus on TOSCA related to alaram based monitors
16:31:47 <sridhar_ram> translating that to heat ceilometer .. and based on the callback invoke the Action
16:32:29 <KanagarajM> sridhar_ram, yes, by adding scale specific param
16:32:37 <sridhar_ram> tung_doan: skipping scaling in this first iteration will help to keep the focus and get this piece correctly
16:33:08 <tung_doan> sridhar_ram: Ok...
16:33:33 <sridhar_ram> bobh: what do you think on a split like this ?
16:34:10 <bobh> sridhar_ram: looks good to me
16:35:03 <KanagarajM> sridhar_ram, i feel that we could take them simultaneuosly
16:35:16 <bobh> sridhar_ram: the monitors should be independent of the actions, yet be able to invoke whatever actions are provided by the interface
16:35:18 <KanagarajM> as the depenecies are spoted out already
16:35:41 <KanagarajM> bobh, yes, that is the way i felt
16:35:51 <sridhar_ram> bobh: +1
16:36:09 <sridhar_ram> KanagarajM: we sure can start the spec in parallel..
16:36:37 <sridhar_ram> KanagarajM: however, for scaling it will be good to go "behind" alarm-based monitor
16:36:54 <sridhar_ram> KanagarajM: all this doesn't stop any of us from coding away ;-)
16:37:15 <KanagarajM> sridhar_ram, i guess, we wanted to to give it for manual trigger from user
16:37:46 <sridhar_ram> KanagarajM: yes, that would be testable earlier w/o alarm-based monitor
16:38:00 <KanagarajM> sridhar_ram, yes.
16:38:01 <sridhar_ram> KanagarajM: we can split the patchsets coming out of scaling into two
16:38:10 <sridhar_ram> (a) manual scaling - no dependency
16:38:28 <sridhar_ram> (b) alarm based mon trigger - has dependency on alarm work items
16:38:50 <sridhar_ram> tung_doan: any concerns ?
16:39:04 <KanagarajM> sridhar_ram, let us choos the appraoch on how to create the alarm via heat or direclty?
16:39:50 <brucet_> sridhar_ram: Will there be a time to discuss the alternative arch slides I put together??
16:39:51 <tung_doan> sridhar_ram: (b) look good to me
16:40:01 <sripriya> KanagarajM: i had the same question, interested to know if tacker needs to talk to ceilometer directly or we just invoke heat to create resources
16:40:26 <tung_doan> brucet_: yes, I hope
16:40:38 <KanagarajM> via heat gives one advantage , tomorrow if we want to auto-scale direclty via heat without tacker comes in while scaling
16:41:13 <KanagarajM> sripriya, yes. its better to decide the option :)
16:41:15 <sridhar_ram> brucet_: the current approach does involve ceilometer and heat
16:41:23 <brucet_> OK. I'll go now
16:42:14 <sripriya> KanagarajM: i believe tacker would still need to control some of ceilometer alarms to trigger non heat actions as well
16:42:40 <sridhar_ram> KanagarajM: tung_doan: It will be nice to get some clarity there for sure... direct ceilometer vs heat ceilometer resources
16:42:44 <sridhar_ram> what are the pros & cons ?
16:43:00 <KanagarajM> sripriya, we are taking complete control on the triggering part in tacker, but it would help tomorrow to enable auto-scaling if we opt
16:43:30 <KanagarajM> sridhar_ram, in the last patch-set i have mentioned the options
16:43:39 <KanagarajM> sridhar_ram, these*
16:44:19 <KanagarajM> once we decide the option, then alarm-monitor is clear now i believe
16:44:36 <sridhar_ram> tung_doan: do you've any preference on direct ceilometer vs heat based ceilometer ?
16:45:11 <vishwanathj> would there be any impact to end users/operators depending on the approach?
16:45:21 <tung_doan> sridhar_ram:  I think direct ceilometer is suitable
16:45:47 <tung_doan> sridhar_ram:  we can setup many policies..
16:45:51 <KanagarajM> And noe more, https://review.openstack.org/#/c/306562/5/specs/newton/alarm-based-monitoring-driver.rst line 154 is mandatory, on either via heat or ceilometer
16:46:32 <KanagarajM> one*
16:47:00 <sridhar_ram> tung_doan: you mean, more that one alarm per VDU and different actions for each of them ?
16:47:05 <sridhar_ram> *more than
16:47:08 <sripriya> KanagaraM: for auto scaling action it makes perfect sense to leave it as a heat resource, i'm thinking if an user wants to use ceilometer based alarms to perform custom actions without heat dependency
16:47:16 <tung_doan> sridhar_ram:  right, sridhar
16:47:33 <KanagarajM> tung_doan, all these options are vailable in heat ceilometer resource type as well
16:47:34 <sridhar_ram> tung_doan: that's interesting.. I like it (as an operator :)
16:48:09 <sridhar_ram> okay.. here is what I propose...
16:48:16 <tung_doan> sridhar_ram:  yeah, it is more flexible
16:48:30 <KanagarajM> sridhar_ram, another reason, i would think of is, most of the orchestration, if we levarage from heat, it will reduce the depenecy of the more services (ceiloemeter) in the tacker
16:48:59 <sridhar_ram> lets use the  https://review.openstack.org/#/c/306562 for alarm based monitoring.. I'm assuming tung_doan you are going to be the lead author / developer
16:49:05 <sripriya> tung_doan: sridhar_ram: we will need to monitor network resources given that we have SFC coming in, neutron ports can be monitored for existance
16:49:17 <KanagarajM> otherwiseguy, both tacker and heat would does the same and it will be of redunt things across
16:50:08 <sridhar_ram> KanagarajM: can you start a new BP and spec for tacker scaling with a scope for both auto & manual ?
16:50:39 <tung_doan> sripriya: right.. that is what I want to do with alarm based monitoring driver
16:50:40 <KanagarajM> sridhar_ram, sure, i will strip of scaling things from current spec
16:50:59 <KanagarajM> sridhar_ram, and submit a new spec on it
16:51:12 <sridhar_ram> sripriya: agree, I really feel we are scratching the surface on various feature combinations here .. this area is surely a multi cycle evolution
16:51:17 <sridhar_ram> we are just getting started :)
16:51:49 <KanagarajM> sridhar_ram, yes, but its always better to leavarge things from existing things instead re-invest the wheels :)
16:51:55 <tung_doan> sridhar_ram: the quesiton is you have any concern with alarm-based monitoring driver in yor spec?
16:51:56 <sridhar_ram> KanagarajM: I'd also like to discuss Senlin within that scope for the auto-scaling spec.. but that is for another day
16:52:11 <tung_doan> KanagarajM: the quesiton is you have any concern with alarm-based monitoring driver in yor spec?
16:52:56 <sridhar_ram> tung_doan: no, in fact you should bring back your contents from the earlier revision and make it focused on alarm
16:53:06 <KanagarajM> tung_doan, yes, how the alarm wil be created
16:54:11 <sridhar_ram> tung_doan: It will be nice to document both the options in your spec and select one as the way forward...
16:54:35 * sridhar_ram notes about 5 mins left
16:54:51 <KanagarajM> sridhar_ram, tung_doan if we decied to go directly use ceilometer, my only concern is, we are adding depency on ceilometer in taker while it can be done via heat. (reduce mainatance & givens more option for auto-scaling in futyre)
16:55:26 <KanagarajM> sridhar_ram, sure. let us take forward from specs. i felt its good discussion
16:55:33 <sridhar_ram> KanagarajM: I've similar concerns but I'd like to hear any functional advantage that tung_doan pointed out.. we can take this up in tung_doan's spec
16:55:48 <KanagarajM> sridhar_ram, sure.
16:56:27 <sridhar_ram> tung_doan: again, are you fine w/ this approach to focus your spec on alarm based monitoring ?
16:56:51 <tung_doan> sridhar_ram: np. I will try
16:57:01 <sridhar_ram> great.. !
16:57:29 <KanagarajM> tung_doan, kindly don't mind, i have update the last patch set to set the ground for the todays meeting
16:57:30 <tung_doan> I will update my spec ASAP
16:57:51 <sridhar_ram> I wish brucet was here to desc his alternative approach ... how different from what we have penciled in there
16:58:02 <KanagarajM> tung_doan, which helped.
16:58:43 <sridhar_ram> tung_doan: thanks sooooo much for staying late.. close to 2am there
16:58:56 <sridhar_ram> KanagarajM: same for you too .. late there as well
16:59:01 <tung_doan> sridhar_ram: np. :)
16:59:02 <KanagarajM> tung_doan, great !!!
16:59:10 <sridhar_ram> lets wrap for today..
16:59:15 <KanagarajM> sridhar_ram, yeah, but nope :)
16:59:29 <sridhar_ram> #topic Open Discussion
16:59:40 <sridhar_ram> bye everyone!
16:59:47 <KanagarajM> bye
16:59:51 <sripriya> thanks all
16:59:57 <sridhar_ram> #endmeeting