05:30:13 <sridhar_ram> #startmeeting tacker
05:30:14 <openstack> Meeting started Wed Dec 14 05:30: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.
05:30:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:30:17 <openstack> The meeting name has been set to 'tacker'
05:30:26 <sridhar_ram> #topic Roll Call
05:30:35 <janki> o/
05:30:35 <sridhar_ram> who is here for tacker meeting?
05:30:41 <dkushwaha> o/
05:30:51 <sripriya> o/
05:31:06 <ruijie> o/
05:31:18 <tung_> o/
05:31:38 <elynn__> o/
05:31:49 <s3wong> o/
05:32:03 <haiwei_> 0/
05:32:03 <sridhar_ram> howdy all !!
05:32:11 <sridhar_ram> welcome to the new timeslot!
05:32:15 <sridhar_ram> let's start..
05:32:21 <sridhar_ram> #topic Agenda
05:32:32 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Dec_14th.2C_2016
05:32:42 <sridhar_ram> #topic Announcments
05:32:56 <sridhar_ram> #info  https://releases.openstack.org/ocata/schedule.html
05:33:10 <sridhar_ram> 5 weeks until Ocata Feature Freeze
05:33:43 <sridhar_ram> .. please get in your client and API changes as soon as possible
05:34:04 <sridhar_ram> nothing else announce
05:34:26 <sridhar_ram> #topic Spec-less blueprints rundown
05:35:03 <sridhar_ram> We now allow some simple enhancements to be submitted *without* a need to write a details spec
05:35:27 <sridhar_ram> I still like to run them in the weekly meeting at regular intervals to bring it to team's attention.
05:36:06 <sridhar_ram> Please voice your thoughts as I run them down, particularly if you think some of them more information or we should not approve
05:36:37 <sridhar_ram> #link https://blueprints.launchpad.net/tacker/+spec/deprecate-legacy-template-dsl
05:37:19 <dkushwaha> sridhar_ram, Thanks for assigning me, as i am already working on it
05:37:25 <sridhar_ram> pretty straight forward, the VNF template we introduced in May 2015 will now be completely removed
05:37:51 <sridhar_ram> dkushwaha: thanks and glad to see the patcshets are already in :)
05:38:03 <sridhar_ram> any questions on this BP ?
05:38:31 <dkushwaha> sridhar_ram, no
05:38:41 <sridhar_ram> next..
05:38:43 <sridhar_ram> #link https://blueprints.launchpad.net/tacker/+spec/switch-to-keystoneauth
05:38:52 <sridhar_ram> this already got merged, so moving on
05:39:05 <sridhar_ram> #link https://blueprints.launchpad.net/tacker/+spec/vnffgd-param-support
05:39:20 <sridhar_ram> This is an important BP
05:39:30 <sridhar_ram> .. it brings in parameter support for VNF Forwarding Graph
05:40:15 <sridhar_ram> The idea is these BPs don't have any controversial design plots to debate..
05:40:30 <sridhar_ram> next..
05:40:33 <sridhar_ram> #link https://blueprints.launchpad.net/tacker/+spec/hot-template-support
05:40:46 <sridhar_ram> I'd like to get team's opinion on this...
05:41:29 <sridhar_ram> This BP proposes to use Tacker for hosting HOT templates in its catalog
05:41:44 <sridhar_ram> Thoughts?
05:42:24 <haiwei_> I am not sure why this feature is needed?
05:42:38 <dkushwaha> +1
05:42:46 <sridhar_ram> The motivation behind this is, some operators have a mix of TOSCA templates and HOT templates in this ops and now they can use a single service (Tacker) to instantiate both
05:43:02 <sridhar_ram> s/this ops/their ops/
05:43:57 <sripriya> is this separate from the feature implementing direct vnfd template?
05:43:58 <sridhar_ram> I do see some challenges in our API response, particular for fields like mgmt_ip in vnf-create response
05:44:22 <sridhar_ram> sripriya: yes, they are unrelated to each other
05:44:56 <sridhar_ram> dkushwaha: thanks for the resp
05:45:00 <sripriya> is this feature supposed to support monitoring and mgmt driver support?
05:45:24 <janki> sridhar_ram, mgmt_driver info too is derived from tosca template
05:45:38 <sridhar_ram> sripriya: it won't support any TOSCA features.. it is a pure passthru' to Heat Client
05:45:56 <sripriya> sridhar_ram: then wouldnt the customer directly use heat?
05:46:03 <tung_> sripriya: for alarm monitor, it help alot
05:46:07 <haiwei_> then how to configure monitoring and mgmt driver?
05:47:01 <sridhar_ram> haiwei_: entities beyond and above tacker need to have any monitoring and mgmt of the VMs spawned using HOT template
05:47:19 <sridhar_ram> however, we atleast need to export the ip addresses of the VMs
05:47:33 <sridhar_ram> again, I'm wondering if we are opening a can of worm with this BP
05:47:34 <haiwei_> sridhar_ram, that mean user needs to prepare for two templates?
05:48:22 <sripriya> sridhar_ram: i understand the need for aggregating a catalog with both tosca and heat templates
05:48:48 <sridhar_ram> sripriya: the main diff I see with this vs directly calling Heat client is .. you can upload your HOT template in the catalog and instantiate many stacks using that.
05:48:49 <sripriya> sridhar_ram: probably worth visiting this once we come up with a separate catalog module
05:49:19 <sridhar_ram> sripriya: that could work too..
05:49:36 <sridhar_ram> how many of you think this needs more thought, perhaps we should write a proper spec ?
05:49:59 <janki> sridhar_ram, +1 to spec
05:50:02 <sripriya> sridhar_ram:+1
05:50:12 <haiwei_> +1 for spec
05:50:18 <tung_> sridhar_ram: +1 for this spec
05:50:28 <sridhar_ram> alright, spec it is :)
05:50:39 <sridhar_ram> haiwei_: why do you think we need two templates ?
05:51:17 <dkushwaha> haiwei_,  IMO ueser should not prepare for both, but can have choice for both.
05:51:18 <janki> sripriya, what do you mean by separate catalog module?
05:51:29 <haiwei_> sridhar_ram: I misunderstood it I think
05:51:41 <sridhar_ram> haiwei_: no worries
05:51:54 <sripriya> janki; right now we have catalog integrated in to vnfm and have separate resources for each of vnfd, vnffgd and nsd
05:52:19 <sripriya> janki: we will need to refactor that to come up with a generic catalog module handling multiple catalog types
05:52:57 <janki> sripriya, are you saying to separate vnfd and vnf logic from a single file?
05:53:07 * sridhar_ram notes to write a BP in launchpad for that
05:53:20 <sripriya> janki: yeah
05:53:30 <sripriya> janki: we can put it that way
05:54:09 <janki> sripriya, sridhar_ram that is really nice. I would like to take it up if noone is taking
05:54:16 <sridhar_ram> I'll write a BP, it is more a refactoring activity and it is a reasonable one
05:55:03 <sridhar_ram> #action sridhar_ram to write a BP request in launchpad for common template catalog across vnfm and nfvo
05:55:17 <janki> sridhar_ram, please assign it to me if there is no owner
05:55:24 <sridhar_ram> janki: sure, will do! thanks
05:55:36 <janki> sridhar_ram, thanks
05:55:41 <sridhar_ram> moving to the next topic..
05:55:53 <sridhar_ram> #topic Refactor openstack driver
05:56:02 <sridhar_ram> #link https://review.openstack.org/405276
05:56:21 * sridhar_ram is wondering if Kanagaraj is here
05:57:01 <sripriya> haiwei_: thanks for taking this up!
05:57:02 <sridhar_ram> haiwei_: I see test_vnf_tosca_scale func test is still failing, any clue?
05:57:21 <haiwei_> sridhar_ram, I am still investigating it
05:57:41 <sridhar_ram> haiwei_: okay, np...
05:57:45 <haiwei_> sridhar_ram, will keep on it later
05:58:12 <sridhar_ram> I really happy we have a decent collection of func test to do these surgical refactoring .. god bless dsvm gate :)
05:59:16 <sridhar_ram> as I left in the comment, we need a follow on to consolidate the vnfm openstack driver with nfvo one at https://github.com/openstack/tacker/blob/master/tacker/nfvo/drivers/vim/openstack_driver.py
05:59:22 <sridhar_ram> sripriya: what do you think?
05:59:53 <sripriya> sridhar_ram: i need to take a look into the patch, will try to review it soon
06:00:14 <sripriya> sridhar_ram: but i agree with you on the consolidation part
06:00:35 <sridhar_ram> sripriya: okay, thanks
06:00:36 <sripriya> sridhar_ram: in to VIM module
06:01:38 <sridhar_ram> sripriya: it is mostly code shifting, correct? wondering if this can be absorbed in Ocata
06:02:06 <sripriya> sridhar_ram: i think yes
06:02:11 <sridhar_ram> okay
06:02:21 <sridhar_ram> haiwei_: anything else on this topic?
06:02:26 <haiwei_> no
06:02:31 <sridhar_ram> moving on
06:02:40 <sridhar_ram> #topic Tacker-Senlin integration spec
06:02:53 <sridhar_ram> #link https://review.openstack.org/#/c/352943/
06:03:22 <sridhar_ram> xuan0802_: haiwei_: is this something you can finish in Ocata ?
06:03:43 <haiwei_> sridhar_ram, I think we can :)
06:04:16 <haiwei_> sridhar_ram: we can get help from the guys in Senlin team
06:04:23 <sridhar_ram> okay
06:04:42 <sridhar_ram> the main concern i have is dependency of Senlin service for Tacker...
06:05:18 <haiwei_> sridhar_ram: yes, I understand, but it should be no problem imo
06:05:54 <haiwei_> sridhar_ram: Senlin has good team, and keep getting the project better and better
06:06:06 <sridhar_ram> I haven't tracked Senlin recently.. glad to hear that
06:06:32 <sridhar_ram> does Senlin do regular cycle release ?
06:06:44 <haiwei_> sridhar_ram: In fact you can ask any questions related to senlin in IRC channel
06:07:11 <haiwei_> sridhar_ram: of course, Senlin will release regularly
06:07:30 <sridhar_ram> haiwei_: thanks
06:07:37 <elynn__> @sridhar_ram mitaka is 1.0.0 and newton is 2.0.0
06:08:22 <sridhar_ram> elynn__: thanks!
06:08:40 <elynn__> And senlin follows the milestones of openstack community.
06:08:55 <sridhar_ram> elynn__: cool
06:08:58 <sridhar_ram> haiwei_: are there any plans beyond auto-scaling for Tacker+Senlin ?
06:09:24 <haiwei_> sridhar_ram: yes, besides auto-scaling, senlin also has policies for HA
06:10:08 <haiwei_> I think it is the next step is inviting senlin's HA policy to Tacker
06:10:56 <sridhar_ram> okay, the reason for my question is .. we are putting tacker users and devs into some level of pain by introducing Senlin to support a feature that already exists.. want to make sure we have plans to introduce enhanced tacker features using senlin integration
06:11:05 <haiwei_> This is a big topic, so I didn't write the details in the Senlin integration spec
06:11:41 <sridhar_ram> haiwei_: totally agree, we have now is the right approach..
06:12:01 <sridhar_ram> now, when can be bring in HA support using senlin ?
06:12:04 <sridhar_ram> Pike ?
06:12:17 <sridhar_ram> s/can be/can we/
06:12:36 <haiwei_> srihar_ram: I am not sure introducing Senlin is a pain, maybe it can be the only auto-scaling solution in Tacker someday
06:13:25 <sridhar_ram> haiwei_: i'm sure senlin is a high quality service to depend on...
06:13:26 <haiwei_> sridhar_ram: HA support in Senlin has some problems on lbaas, because lbaas is deprecated, and there is a bug there
06:13:55 <sridhar_ram> haiwei_: I see, perhaps we can plan that for Pike release
06:14:16 <haiwei_> sridhar_ram: yes
06:14:19 <Qiming> the bug is only relevant if you want a LBaaS based node failure detection, we are bugging the Octavia team
06:15:33 <sridhar_ram> my understanding is Tacker will not have a library dependency on Senlin, rather it will have indirect dependency through Heat / HOT Senlin node types ?
06:15:47 <sridhar_ram> is this understanding correct?
06:16:10 <Qiming> sridhar_ram, I'd suggest Tacker to depend on openstacksdk, :)
06:16:36 <Qiming> Senlin is not depending on any service clients or libraries other than openstacksdk
06:16:42 <sridhar_ram> Qiming: we can always do that, but my question still remains
06:17:07 <haiwei_> sridhar_ram: I am afraid Tacker needs to depend on Senlin library
06:17:18 <Qiming> service level, you will have that dependency
06:17:29 <sridhar_ram> so, it is Tacker --> Senlin --> Heat ?
06:17:58 <haiwei_> sridhar_ram: it is Tacker -> Heat -> Senlin -> Heat
06:18:02 <Qiming> it depends on how you will use senlin features
06:18:20 <sridhar_ram> haiwei_: ouch, that's a recursion ;-)
06:18:31 <Qiming> if you would rather to stick to Heat templates
06:18:41 <Qiming> the dependency would be Tacker -> Heat -> Senlin
06:19:11 <Qiming> if you do want more knobs on managing your resource pool, you can interact with Senlin directly
06:19:26 <sridhar_ram> Qiming: haiwei_: can we see if we can stick to Tacker -> Heat -> Senlin ..
06:19:32 <Qiming> behind the scene, Senlin can invoke either Heat or Nova directly to get the job done
06:20:03 <Qiming> as a first step POC, that is a reasonable, viable approach
06:20:12 <sridhar_ram> Qiming: good
06:20:19 <sridhar_ram> haiwei_: what do you think?
06:21:03 <haiwei_> sridhar_ram: According to my spec, the process should be Tacker-> Heat -> Senlin, after senlin is deployed, the auto scaling is controlled by Senlin
06:22:03 <sridhar_ram> haiwei_: okay, we are good then.. again with this approach there shouldn't be any requirements.txt dep to senlinclient
06:22:09 <haiwei_> sridhar_ram: If you want to make it Tacker -> Senlin directly, there will be big changes in Tacker
06:22:22 <sripriya> haiwei: is it possible to manually scale using senlin?
06:22:40 <sripriya> haiwei_: ^
06:22:40 <haiwei_> sripriya: of course
06:23:02 <sridhar_ram> sripriya: good catch..
06:23:09 <Qiming> #link http://developer.openstack.org/api-ref/clustering/
06:23:27 <sridhar_ram> haiwei_: please clarify the manual scaling support in your spec...
06:23:29 <haiwei_> sridhar_ram: if you want to make it manually scalable, you need to use Senlinclient
06:23:46 <sridhar_ram> haiwei_: ouch
06:24:03 <Qiming> ... or you should skip senlinclient completely
06:24:21 <sridhar_ram> haiwei_: we can't get away with a stack-update like we are currently doing for ASG based solution ?
06:24:22 <elynn__> Or use senlin receiver to scale a cluster.
06:24:29 * sridhar_ram notes 5mins left
06:24:32 <Qiming> the goal of maitaining senlinclient, beyond Pike cycle, would be only for OSC plugins
06:24:34 <haiwei_> sridhar_ram: there is no way to make a service working if you have no client , right?
06:24:49 <Qiming> we will recommend using openstacksdk directly
06:25:28 <Qiming> Heat is not talking to senlin via senlinclient, correct? elynn__ ?
06:25:51 <elynn__> Heat is talking with senlin via senlinclient
06:25:52 <sridhar_ram> Qiming: i'm interchangably using senlinclient and openstacksdk client.. i was trying to avoid code level API dependency and get away with just HOT template based senlin dependency
06:25:57 <elynn__> not openstacksdk yet.
06:26:21 <elynn__> https://github.com/openstack/heat/blob/master/requirements.txt#L50
06:26:36 <sridhar_ram> Folks - we got to wrap this discussion up, we are almost out of time
06:27:17 <sridhar_ram> haiwei_: if you can zoom in on two aspects (a) manual scale support and (b) avoid direct API dependency
06:27:30 <sridhar_ram> we can take the discussion to gerrit
06:27:42 <sridhar_ram> sounds good ?
06:27:49 <haiwei_> sridhar_ram: I will update the spec
06:28:00 <sridhar_ram> haiwei_: thanks
06:28:14 <sridhar_ram> thanks senlin team for bringing this in.. and this lively discussion
06:28:25 <haiwei_> nope
06:28:32 <Qiming> glad to help
06:28:33 <sridhar_ram> if needed we can take it up again in next week's call
06:28:47 <sridhar_ram> hope we can wrap up in gerrit itself
06:29:03 <sridhar_ram> #topic Open Discussion
06:29:12 <sridhar_ram> hope this time works for most of you
06:29:20 <sridhar_ram> i still don't see gongysh
06:29:33 <gongysh> sridhar_ram, it seems I am not used to it yet.
06:29:45 <sridhar_ram> gongysh: ah,you are lurking ..!
06:29:50 <sripriya> sridhar_ram: good to buzz interested folks at the start of the meeting
06:29:51 <s3wong> sridhar_ram: it was actually the same old time we had with yamahata :-)
06:29:55 <sridhar_ram> gongysh: we will fix that
06:30:06 <sripriya> sridhar_ram: folsk can add their irc handles in tacker wiki meeting page
06:30:07 <sridhar_ram> alright.. times up..!
06:30:11 <sripriya> folsk*
06:30:19 <sripriya> folks
06:30:27 <sridhar_ram> i see some new irc handles.. welcome to tacker
06:30:33 <sridhar_ram> #endmeeting