16:00:53 <sridhar_ram> #startmeeting tacker
16:00:54 <openstack> Meeting started Tue May 31 16:00:53 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:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:57 <openstack> The meeting name has been set to 'tacker'
16:01:04 <sridhar_ram> #topic Roll Call
16:01:08 <vishwanathj> o/
16:01:11 <sridhar_ram> who is here ?
16:01:11 <tbh> o/
16:01:13 <s3wong> o/
16:01:15 <janki91> o/
16:01:18 <sripriya> o/
16:01:24 <tung_doan> o/
16:01:45 <sridhar_ram> howdy all ! Let's start...
16:01:51 <sridhar_ram> #topic Agenda
16:02:01 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_May_31.2C_2016
16:02:25 <twm2016> o/
16:02:34 <santoshk> Hi
16:02:42 <sridhar_ram> anything else to discuss beyond this ?
16:02:48 <sridhar_ram> twm2016: santoshk: hi
16:02:56 <KanagarajM> hi
16:03:27 <sridhar_ram> BTW, going forward please suggest your agenda items few days before the meeting..
16:03:36 <sridhar_ram> #topic Annoucements
16:03:52 <sridhar_ram> We are at Newton release milestone 1 (m1)
16:03:58 <tung_doan> sridhar_ram: any session for alarm-based monitoring driver today?
16:03:58 <sridhar_ram> #link http://releases.openstack.org/newton/schedule.html
16:04:29 <sridhar_ram> tung_doan: yes, we plan to discuss that .. important to get that going :)
16:04:51 <sridhar_ram> While we don't have a formal spec approval deadline, it is important to wrap up as many specs as possible within next couple of weeks.
16:05:21 <sridhar_ram> next ..
16:05:32 <sridhar_ram> I'd like to welcome Lin Hua Cheng as a core member in tacker-horizon project,
16:05:40 <sridhar_ram> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/096218.html
16:06:09 <vishwanathj> very good addition to the tacker-horizon project....
16:06:13 <sridhar_ram> Lin is a core member in the main horizon project. He has been our go to person for things related to UI dashboard in Tacker.
16:06:13 <sripriya> congrats lhcheng
16:06:26 <vishwanathj> lhcheng congrats
16:06:35 <sridhar_ram> vishwanathj: indeed, thanks for introducing Lin to our team !
16:06:59 <santoshk> lhcheng congrats..
16:07:10 <sridhar_ram> I can imagine interesting UI additions for our upcoming features.. particularly VNFFG !
16:07:11 <natarajk> Congrats lhcheng
16:07:31 <sridhar_ram> moving on ..
16:07:52 <sridhar_ram> #topic Project Review Cadence
16:08:06 <sridhar_ram> couple of mins on this last min topic..
16:08:19 <sridhar_ram> We have received few offline suggestions to improve our review response time in this project.
16:08:27 <sridhar_ram> This is a valid request though the solution needs some collective effort.
16:08:53 <sridhar_ram> I'm open for ideas in this area..
16:09:16 <sridhar_ram> as I see from my side, first, we need more time from the Tacker core team dedicated to reviews.
16:09:17 <vishwanathj> sridhar_ram are there are any metrics that you can share
16:09:25 <sridhar_ram> Second, the order in which patchsets are reviewed and merged.
16:09:31 <sridhar_ram> One tool available in this area is the review report from stackalytics,
16:09:37 <sridhar_ram> #link http://stackalytics.com/report/reviews/tacker-group/open
16:10:03 <sridhar_ram> Keep an eye on the ones that are 'starved' with high response times. My hope is to drive down the average wait times.
16:10:08 <vishwanathj> thanks for the link
16:10:31 <sridhar_ram> Third, perhaps more impactful one, is to increase the core team strength. I'm looking for opportunities to do this as we get more committed team members.
16:10:39 <sridhar_ram> If you are interested in working towards becoming a core team member in an openstack project, please do consider Tacker 8-)
16:11:28 <sridhar_ram> if you've other ideas, please drop a line.. thanks
16:11:33 <sridhar_ram> moving on...
16:11:47 <sridhar_ram> lhcheng: welcome to Tacker core team!
16:12:16 <lhcheng> all, thanks for all the support!
16:12:20 <KanagarajM> i think if core team could spare little more time daily, eventaully review will come to normal rate
16:12:26 <janki91> sridhar_ram: I am interested in contributing
16:12:31 <lhcheng> would try my best to help :)
16:12:32 <KanagarajM> lhcheng, congrats !
16:12:46 <tbh> congrats lhcheng
16:13:06 <janki91> sridhar_ram: I do solve bugs, would like to contribute to a feature though
16:13:38 <vishwanathj> the core team that is small in number has done a great job.....have seen them review and merge over weekends as well
16:13:50 <sridhar_ram> KanagarajM: yes, I'd encourage tacker-core team spend more time reviewing... i'm personally planning to time box some time everyday for reviewing.
16:14:01 <sridhar_ram> vishwanathj: thanks!
16:14:18 <sridhar_ram> lets move on...
16:14:22 <sridhar_ram> #topic Spec progress round up
16:14:44 <sridhar_ram> janki91: sure, absolutely !
16:14:55 <sridhar_ram> #topic Resource Audit Logs
16:15:07 <sridhar_ram> the new kid in the block..
16:15:19 <sridhar_ram> vishwanathj: KanagarajM: can you guys give a quick update ?
16:15:30 <vishwanathj> KanagarajM and I had a very productive discussion last week and this week.....
16:15:57 <vishwanathj> we now have a spec at a stage that is ready for review and feedback
16:16:11 <KanagarajM> yeah, i really flet good dicussion and it helped to fine tune the spec
16:16:15 <sridhar_ram> vishwanathj: cool, link please
16:16:29 <vishwanathj> KanagarajM please feel free to chime in.....https://review.openstack.org/#/c/321370/
16:17:27 <trozet> hi tacker team, joining late
16:17:30 <sridhar_ram> KanagarajM: vishwanathj : great, thanks for getting this going
16:17:45 <sridhar_ram> trozet: np, we are about to get to VNFFG soon..!
16:17:56 <trozet> cool
16:18:09 <sridhar_ram> #topic Networking-SFC driver
16:18:35 <sridhar_ram> VNFFG spec from trozet merged .. https://review.openstack.org/292196
16:18:55 <trozet> thanks everyone reviews and getting it through
16:19:01 <trozet> for reviews*
16:19:08 <vishwanathj> trozet nice work
16:19:09 <sridhar_ram> now, we need to complete the food chain further down.. the networking-sfc driver..
16:19:30 <sridhar_ram> #link https://review.openstack.org/290771
16:19:44 <sridhar_ram> s3wong: can you give an update ?
16:20:08 <sridhar_ram> is Louis is in the channel ?
16:20:50 <sridhar_ram> trozet: did you had a chance to review this spec ?
16:21:12 <trozet> sridhar_ram: not the latest patch set, will do it today
16:21:48 <sridhar_ram> trozet: okay, thanks...!
16:22:01 <sridhar_ram> s3wong: are you here ?
16:22:50 <sridhar_ram> i'll follow up w/ the networking-sfc team offline..
16:22:55 <sridhar_ram> lets move on...
16:23:10 <sridhar_ram> #topic Alarm based monitoring
16:23:30 <sridhar_ram> tung_doan: can you give an update on your spec ?
16:23:59 <sridhar_ram> tung_doan: are things clear from architecture, scope and work items for this spec .. ?
16:24:00 <tung_doan> sridhar_ram: I already update new patchset.. please see https://review.openstack.org/#/c/306562/9/specs/newton/alarm-based-monitoring-driver.rst
16:24:50 <sridhar_ram> okay.. we can spend rest of this meeting to talk about this spec and the related auto-scaling...
16:25:11 <tung_doan> In this spec, the alarm based monitoring should be generic framework
16:26:13 <sridhar_ram> looking at the diagram at L45.. what you think the interface between the different components...
16:26:34 <tung_doan> sridhar: In real implemenntation, I will go with Ceilometer first
16:26:42 <sridhar_ram> VNFM plugin <---> alarm-f/w <--> [Ceilometer, ...]
16:27:12 <sridhar_ram> tung_doan: sounds good...
16:27:55 <sridhar_ram> question to tung_doan and team... does alarm-framework be a separate process taking to main tacker-server using RPCs ?
16:28:09 <sridhar_ram> s/be a/need to be a/
16:28:19 <sripriya> sridhar_ram: that is what i have in mind as well
16:28:23 <sridhar_ram> s/taking/talking/
16:28:44 <sripriya> sridhar_ram: monitor/alarm should be a separate module of its own emitting events
16:28:44 <sridhar_ram> sripriya: I see...
16:29:10 <sridhar_ram> tacker-server is already overloaded with lots of in-process threads
16:29:18 <KanagarajM> i feel its better to split api and plugins over RPC
16:29:19 <sripriya> sridhar_Ram: before all this, we need to extract our monitor monolithic file out of vm dir. and carve a module for this
16:29:31 <KanagarajM> but it might be BIG thing to go !
16:29:45 <sripriya> sridhar_ram: i created a RFE to refactor it
16:29:57 <sridhar_ram> KanagarajM: yes, we need to do that.. but exactly.. it is a BIG thing, perhaps for Ocata
16:30:09 <tung_doan> sridhar_ram: regrading to the intefarce, tacker monitoring driver can use Ceilometer alarm interface and Monaca alarm interface.. Once we go with Ceilomester, monasca is the same
16:30:17 <KanagarajM> sridhar_ram, ok
16:30:24 <sridhar_ram> however, we can be oppurtunistic and introduce some new features with that future decomposition in mind
16:31:26 <KanagarajM> tung_doan, only thing to abstact, while defining the TOSCA model for alarm based monitoring, better to keep it generic
16:31:44 <sridhar_ram> future (Ocata) we could decompose to api , plugin and alarm/mon f/w in separate scalable processes
16:31:54 <KanagarajM> tung_doan, instead of carrying the ceilometer jargan to it. b
16:31:59 <sripriya> yes, +1
16:32:04 <sridhar_ram> +1
16:32:06 <KanagarajM> sridhar_ram, yes, that is good plan
16:32:16 <tung_doan> KanagarajM: agree
16:32:50 <sridhar_ram> near term (Newton) tacker-server (api, pluging) and alarm-mon f/w process ..
16:32:55 <sridhar_ram> is this doable ?
16:33:12 <sripriya> tbh: ^^ VIM could be using this monitoring framework as well
16:33:13 <sridhar_ram> bobh_: ^^
16:34:29 <tbh> sripriya, yes we can leverage to use this framework too
16:35:40 <sridhar_ram> tbh: sripriya: it could be a follow on .. but let's not add too much to tung_doan spec / scope !
16:36:18 <KanagarajM> sridhar_ram, yes, i feel its better to bring in the feature (alarm) then we could latter make into seprate process
16:36:33 <sripriya> sridhar_ram: yes, it need not be dependent, but just to keep in mind of how it could evolve
16:36:50 <sridhar_ram> sripriya: sure
16:37:12 <tbh> sridhar_ram, no at present I am trying to check reachability only. But once we implement monitoring fw, we can leverage  VIM monitoring part, it won't disturb the spec I think
16:37:36 <sridhar_ram> tbh: sure, as a follow on..
16:38:14 <sridhar_ram> tung_doan: I'd like to hear your thoughts .. on separating alarm mon to separate process as part of your spec.
16:38:51 <sridhar_ram> KanagarajM: you think it is better to bring-in this feature into the current monolithic tacker-server first and then break it out as a separate process ?
16:39:37 <KanagarajM> sridhar_ram, yes, bec, IMO, when we bring the RPC in place, it would make it simple to impl
16:40:14 <KanagarajM> sridhar_ram, so in O release, we easily make it. I hope :)
16:40:20 <sridhar_ram> KanagarajM: okay...
16:40:25 <tung_doan> sridhar_ram: agree wuth KanagarajM
16:40:52 <sridhar_ram> sripriya: i know you are looking at refactoring tasks... does this sound reasonable ?
16:41:48 <sripriya> sridhar_ram: i would still hope to remove the actions out of monitor module as a day 0 refactoring just to get things started
16:42:07 <sripriya> sridhar_ram: we need not do a full fledged refactoring of monitor framework this cycle
16:42:17 <sripriya> sridhar_ram: i will do take that ASAP
16:43:11 <sridhar_ram> sripriya: what you mean by "remove actions out of monitor module"
16:43:24 <tung_doan> sridhar_ram: same question
16:43:39 <sripriya> sridhar_ram: i'm referring to log and respawn action logic that are in monitor file
16:44:00 <sripriya> sridhar_ram: given scaling spec is coming in, scale out scale in can be other actions
16:44:21 <sridhar_ram> sripriya: ah, you mean.. move them into say, separate files in our code tree ?
16:44:33 <sripriya> sridhar_ram: it is better to have a separate interface for these actions than integrating them into our monitor fie
16:44:58 <sridhar_ram> sripriya: agree..
16:45:03 <sripriya> sridhar_ram: thats correct, but i'm open to people' thoughts
16:46:04 <sridhar_ram> So, the conclusion i'm hearing, atleast so far, is to bring in the "new features" like alarm-based mon, scaling using existing single process architecture...
16:46:22 <KanagarajM> +1
16:46:40 <sridhar_ram> .. and then have a follow on specs to re-architecture tacker into decomposable / scalable function (api, plugin, mon)
16:46:54 <tung_doan> sridhar_ram: agree
16:47:11 <sridhar_ram> perhaps we can start this re-arch work later half of newton and deliver it in O-release
16:48:05 <sridhar_ram> tung_doan: so, this means getting the correct interfaces between VNFM --> alarm-mon --> Ceilometer is important
16:48:30 <sridhar_ram> please review the latest alarm-mon spec from tung_doan with this discussion in mind..
16:48:36 <tung_doan> sridhar_ram: sure
16:48:43 <sridhar_ram> moving on..
16:48:52 <sridhar_ram> #topic Scaling
16:49:00 <KanagarajM> https://review.openstack.org/318577
16:49:13 <sridhar_ram> KanagarajM: before talking about Scaling...
16:49:37 <sridhar_ram> KanagarajM: ... thank you so much for your contributions beyond Scaling... much appreciated !
16:49:58 <sripriya> a big +1
16:50:09 <KanagarajM> sridhar_ram, thanks, i really like to work in tacker as technology and team :)
16:50:28 <sridhar_ram> KanagarajM: :)
16:50:33 <KanagarajM> sridhar_ram, i am addressing your comments and having some questions asked
16:50:41 <KanagarajM> sripriya, thanks :)
16:51:09 <KanagarajM> like whether to giving caling per vdu or per VNFD?
16:51:46 <KanagarajM> *scaling
16:51:47 <sridhar_ram> KanagarajM: I had similar thoughts on VDU scaling vs VNF scaling...
16:52:42 <sridhar_ram> If a VNF has only one VDU.. then mapping is trivial
16:53:05 <KanagarajM> yeah, but in other cases
16:53:12 <qwebirc81199> Have we talked about containers and microservices yet?
16:53:15 <KanagarajM> sonus, shall we go in phases
16:53:41 <KanagarajM> sridhar_ram, now introduce the scaling at VDU level first
16:53:52 <sridhar_ram> BTW, we need to nail the TOSCA portion of this spec...some scaling policies have "targets: [VDU1, VDU2, ...]
16:53:58 <KanagarajM> and once its in place, then extend it to VNF
16:54:29 <sridhar_ram> qwebirc81199: can you clarify your question please ?
16:54:30 <KanagarajM> sridhar_ram, yeah i tried to go thru the NFV scaling part and it does like this,
16:55:30 <KanagarajM> sridhar_ram and team, your suggestions
16:55:45 * sridhar_ram notes 5 mins left...
16:56:28 <sridhar_ram> KanagarajM: this question is specific to manual scaling, correct ?
16:57:04 <KanagarajM> sridhar_ram, no, in both manual & auto, it would applicable.
16:57:40 <sridhar_ram> okay... i think we can take this back to the gerrit review..
16:58:06 <KanagarajM> sridhar_ram, sure.
16:58:10 <sridhar_ram> Team - please review the scaling spec...
16:58:24 <sridhar_ram> moving on...
16:58:31 <sridhar_ram> #topic Open Discussion
16:58:36 <KanagarajM> ok, i have a topic https://etherpad.openstack.org/p/tacker-db
16:58:50 <KanagarajM> i'm trying to optimze the db schema
16:58:53 * sridhar_ram looking up...
16:59:22 <KanagarajM> as i felt its good to optimze now than latter..
16:59:33 <sridhar_ram> KanagarajM: agree...
16:59:44 <sripriya> KanagarajM: very cool, yes.
17:00:10 <sridhar_ram> times up folks..
17:00:15 <sridhar_ram> thanks all for joining!
17:00:24 <sridhar_ram> #endmeeting