16:03:39 #startmeeting tacker 16:03:39 Meeting started Thu Aug 6 16:03:39 2015 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:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:43 The meeting name has been set to 'tacker' 16:03:58 #topic Announcements 16:04:10 Agenda #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Aug_6.2C_2015 16:04:47 Quick, yet another reminder on Tacker Midcycle... 16:04:57 scheduled for Aug 20 - 21st #link https://wiki.openstack.org/wiki/Tacker/LibertyMidcycle 16:04:57 16:05:17 Please RSVP / update the etherpad 16:06:02 Another quick update on our top-level wiki ...#link https://wiki.openstack.org/wiki/Tacker 16:06:13 it now has the updated Mission & Scope !! 16:06:34 sridhar_ram: nice! 16:06:40 both the text and the overview diagram now has the new scope! 16:06:47 sripriya: thanks 16:07:40 If anyone here as further question on the new clarified mission of this project .. please bring it up 16:08:24 Quick point on the OpenStack release timeline 16:08:28 #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 16:08:36 we are in Liberty-3 16:09:03 approx 3 weeks remaining in L3 16:09:33 Sorry got disconnected and joined back 16:09:41 we need to plan a Tacker Liberty release soon 16:10:29 Given couple of specs - health-mon & MANO API - are in flight we need to extend a bit beyond L3 for Tacker 16:10:49 sridhar_ram: so we will have liberty branch along with master after the feature freeze 16:10:57 Exactly .. 16:11:22 we can perhaps go until mid-Sept to pull the release/liberty branch 16:11:50 so please plan your commits and PSs accordingly if you want to make it to Liberty 16:12:00 sridhar_ram: that would be helpful 16:12:41 lets move on.. 16:13:01 #topic MANO API 16:13:14 sripriya: any quick updates? 16:13:20 sridhar_ram: sure 16:13:35 sridhar_ram: thanks for providing your comments 16:13:44 sripriya: sure 16:14:16 after looking into some of the attributes in bit more detail, it appears we can do away with some attributes 16:14:37 like mgmt_driver, service_context, service_type 16:15:13 these attributes will however need to be part of the request dict_ and we need to ensure that 16:15:25 in case the yaml file will not contain these attributes 16:16:03 so basically, the tacker db is expecting them on the outer request dict body 16:16:12 else it will error out 16:16:14 sripriya: totally agree on service_context and service_type, can be done away w/ 16:16:35 sripriya: I see, I was about to ask any DB impact .. which we should avoid for this round 16:16:48 and code to handle service_context is present, we are not using it thought 16:16:51 though* 16:17:15 yes, we need to have them in request body 16:17:38 but we can populate it after reading vnfd 16:17:51 on the mgmt_driver attr: the question to the wider team is VNF needs one mgmt_driver for the whole VNF including for all of its VDUs (= VMs) 16:17:55 or should it be per VDU 16:17:56 we need not specify it as part of the API 16:18:33 sripriya: sounds good (for your db related resp) 16:19:41 sridhar_ram: as far as i understand, it can be per VNF and not per VDU 16:20:29 sripriya: then the scenario I would like to understand .. if VNF is a multi-VM VNF 16:20:37 just to confirm all VDUs are spawned from the same vnf image 16:20:49 sridhar_ram:? 16:20:50 can one mgmt_driver be the same 16:21:10 sripriya - if we keep it per vnf it would be difficult to performs operations since VM spec can be different and pupose as well 16:21:27 per VDU 16:21:40 well, we may have the case where one VDU does Firewall and other vRouter.. 16:21:43 sripriya: no, that may not be the case .. each VDU might be different VM image.. image .. control-pl VM vs DP plane 16:22:06 Agree +1 16:22:06 sridhar_ram: ok 16:22:18 but this example I gave it a bad one .. ;-) 16:22:47 but there are some VNFs like vEPC which are complex and the have different subsystems in VMs 16:23:01 and they need different ways to configure 16:23:08 and they will have diff. configs 16:23:25 sridhar_ram: right 16:23:30 hello 16:23:35 diff configs is fine .. we can handle in our config.yaml structure 16:23:51 each VDU can have different snippets of config.. 16:24:24 the question is whether we can have *one* mgmt_driver for a whole multi-VM VNF 16:24:33 s3wong: hi 16:25:02 Rajkumar_: that's a valuable input...looks you would vote for per VDU mgmt_driver ? 16:25:13 sridhar_ram: can you elaborate 'different ways to configure'? 16:25:58 sripriya: sure.. 16:25:58 yes. Sridhar. 16:26:57 or on the whole we can have management driver per VNF whicn in turn takes care of VDU config as well 16:27:45 imagine a complex multi-VM VNF (like vEPC or others).. where (I'm cooking up here) pcsf-VDU need configuration using RESTapi, another control-pl VDU needs some config using NETCONF/YANG and another VM might need something adhoc CLI-over-SSH 16:28:14 one more thought - We can have management driver per connection protocol. for e.g. Netconf for YANG 16:28:16 sridhar_ram: i see... 16:28:16 this is where mgmt_driver per VDU will help 16:28:43 CLI commands for Telnet/SSH and Rest API's for HTTP 16:28:44 looks like we need mgmt_driver per vdu to handle these complicated scenarios 16:29:20 then do we need a 'plugin' instead of 'drivers' ? 16:29:21 We have devices which supports CLI and few Netconf and few HTTP 16:29:55 in this way we can generalize the management driver as well 16:30:16 yes whichever is simpler and convenient 16:30:16 Rajkumar_: sure, that came up few times as well 16:30:59 there are some that can be generalized like NetConf 16:31:14 but we can't for RESTapi which is inherently VNF / VDU specific 16:31:39 one example - for arista device we use HTTP to do config 16:31:43 we also plan for a generic SSH-replay driver .. that can be handy too 16:32:17 Rajkumar_: sure, but you would need to write specific arista mgmt_driver code to sent those rest/http calls 16:32:26 that can't be generalized 16:32:46 sridhar_ram: i kinda see mapping witn neutron ml2 drivers :-) like type and mechanism 16:32:58 it sounds like we need an ML2 equivalent model 16:33:04 Sridhar :one more example: we need to use HTTP for tail-f to push configuration 16:33:05 sripriya: Yeah, I see some pattern emerging here! 16:33:08 single plugin, multiple drivers 16:33:19 s3wong: :-) 16:33:40 sripriya: typing that at the same time as you :-) 16:34:00 given we are early in this "exploration" cycle .. I'd say leave the mgmt_driver attr in the API 16:34:16 sridhar_ram: ack 16:34:39 Rajkumar_: those a nice inputs... 16:34:48 Thank you 16:35:27 Tacker, over time, having a rich set of drivers what different transports will help to quickly onboard new VNFs using Tacker 16:35:51 sridhar_ram: yes, that has always been the goal 16:36:01 sridhar_ram: +1 16:36:51 Let me add an some entries in our etherpad backlog to revisit this 16:37:08 anything else on MANO API ? 16:37:29 sridhar_ram: i will submit a a new patchset and respond to your comments 16:37:43 sripriya: sounds good 16:38:07 shrinathsuresh: Rajkumar_: please review the spec at the earliest 16:38:17 lets move on.. 16:38:31 prashantD: hi 16:38:45 hi 16:38:54 #topic Basic AutoScaling 16:39:04 Sridhar - Suresh & Xin are from my team as part of TCS-Comcast Contributors 16:39:05 can you provide an update ? 16:39:26 Rajkumar_: cool. Welcome to the team - folks! 16:39:55 welcome! 16:40:03 Thanks 16:40:10 Rajkumar_: great! Welcome to the team --- what are their IRC nics? 16:40:25 shrinathsuresh: that is Suresh. Welcome! 16:40:25 Xin_ welcome 16:40:38 Xin_: that is Xin. Welcome! 16:41:00 on the autoscaling side it is possible setup a autoscaling enviroment using heat & ceilometer 16:41:31 so I am looking into ceilometer...sridhar_ram pointed me to a good write up on how that is done and I am still going through the writeup 16:41:49 sridhar_ram: speaking of auto-scaling... do we have the policy description for auto-scaling on TOSCA? 16:41:56 As you can image, this is a big topic .. 16:42:07 we have to enhance TOSCA template 16:42:46 it is a big topic, very interesting (probably need to set up LBaaS instance automatically as well), and thanks prashantD for taking on this task 16:42:46 s3wong: there are some simple primitives 16:43:09 s3wong: exactly, almost wrote the same 16:43:25 sridhar_ram: :-) 16:43:33 Auto scaling group can be used for auto scaling with ceilometer policies 16:43:54 scope is to leverage basic Heat autoscaling using Tacker+TOSCA 16:44:09 very, very limited ... to get some proof points 16:44:28 this also ties back to our multi-VDU VNF scenario 16:44:32 we did it with cpu_util 16:44:50 I have been hammering Tacker mostly using "complex" VNFs these days to see how it performs 16:45:13 Rajkumar_: that's cool.. perhaps you can colloborate w/ Prashant 16:45:33 Rajkumar_: I do think Ceilometer is mostly dealing with VM/server specific metrics 16:45:35 Rajkumar : so initially it is just going to be cpu_util 16:46:19 prashantD: Rajkumar_: again, lets keep the scope limited to Heat AutoScaling group + Ceilometer avg cpu_util 16:46:44 s3wong, sridhar_ram : do we need to setup LBAAS or we should be fine without that initially? 16:47:20 I'd vote not to be sucked into a specific VNF 16:47:39 prashantD: how do we load balance traffic otherwise? do we expose new VNF IP address to users every time we scale up? 16:47:55 you need to do lots of LBaaSy things to test your code 16:48:41 sridhar_ram, prashantD: also, I could be wrong, but I thought LBaaS instance is part of the auto-scaling Heat template? 16:49:24 s3wong: prashantD: again, we got to be bit generic here 16:49:46 can't make anything specific that applies only for LB.. atleast in this initial round 16:50:00 * sridhar_ram notes just 10mins left 16:50:07 sridhar_ram: sure. As far as LB is concerned, even NFV MANO spec talked about that as a deployment case 16:50:29 prashantD: I'd suggest you to write a tacker-spec while you are exploring this 16:50:44 sridhar_ram: that for sure 16:51:00 prashantD: it is definitely a big enough feature that we need a spec to review 16:51:29 s3wong: sure, we can apply the auto-scaling feature of Tacker and see if it holds .. but I just want to caution to design Tacker's auto-scaling with only LB in the picture 16:51:36 *not to 16:52:02 sridhar_ram: sure. I do think we can design it with LB and no LB option 16:52:02 #action prashantD to write a tacker-spec for Basic AutoScale 16:52:20 lets move on 16:52:21 sridhar_ram: though the last time I read the MANO spec, the no-LB option is very vague... 16:52:26 sure I will write spec...are we planning on passing traffic with initial auto-scale proof of concept? 16:52:28 s3wong: sure 16:53:02 s3wong: we will remove the vague-ness in the MANO spec.. 16:53:03 :_) 16:53:05 :) 16:53:21 #topic Testing 16:53:48 I'm still waiting for some test to land in the repo before enabling new gate jobs 16:54:03 prashantD: let's get the end to end orchestration flow going --- that is with whatever limited TOSCA defined VNFD w.r.t. auto-scaling, and generate equivalent Heat template and auto-scaling group 16:54:08 I committed one bug fix and its working fine but Jenkins build shows error. Please help us 16:54:39 Rajkumar_, share the link to your patch set 16:54:51 Rajkumar_: sure, we have enough folks here to guide you 16:54:52 http://logs.openstack.org/38/209838/1/check/gate-tacker-pep8/4807afd/ 16:55:00 s3wong : okay, got it, thanx 16:55:01 Jenkins log 16:55:17 patch bug/1481888 16:56:03 I hope w/ new code changes like MANO API & Health mon we will have more unit-tests.. 16:56:27 we are looking to fixup some existing servicevm functional tests 16:56:50 Rajkumar_, The bug does not have link to the patch set 16:56:51 tempest / scenario tests are little further out .. we should consider it for the next cycle.. 16:57:13 #topic Open Discussion 16:57:21 But we followed all the steps correctly 16:57:26 sridhar_ram: what other tests are we running now for gate? 16:57:35 Rajkumar_: commit message shoud be fixed 16:57:42 it cannot exceed 50 characters 16:57:58 that is the Jenkins error 16:58:01 s3wong: just pep8 for now, but that will change soon 16:58:05 :) 16:58:23 Folks - I use this link to look at all Tacker reviews 16:58:28 #link https://review.openstack.org/#/q/project:stackforge/tacker+OR+project:stackforge/python-tackerclient+OR+project:stackforge/tacker-horizon+OR+project:stackforge/tacker-specs,n,z 16:58:28 sridhar_ram: so Rajkumar_ bug fix fails pep8? that shouldn't be too hard to fix, right? 16:58:35 Ok. let me commit again with less chars, is that will resolve the issue? 16:58:37 please bookmark this! 16:58:55 Rajukar_: https://wiki.openstack.org/wiki/GitCommitMessages 16:59:04 sridhar_ram: I am way behind... but I will be off next week, so should pick up on the review backlog 16:59:06 s3wong: Rajkumar_ need to fix his patchset (looks commit msg) 16:59:10 Rajkumar_, sripriya is right about the commit message causing the issue you are seeing 16:59:18 almost time guys! 16:59:33 lets continue if you want in the #tacker channel 16:59:35 Thanks, guys! 16:59:42 we are two week away for Midcycle 16:59:48 s3wong: have a nice vacation! 16:59:54 Thanks. I'll commit again 17:00:07 lets wrap 17:00:11 #endmeeting