17:00:24 #startmeeting tacker 17:00:31 Meeting started Tue Feb 23 17:00:24 2016 UTC and is due to finish in 60 minutes. The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:35 The meeting name has been set to 'tacker' 17:00:41 #topic Roll Call 17:00:44 o/ 17:00:45 o/ 17:00:46 who is here for tacker ? 17:00:54 hello 17:01:03 o/ 17:01:07 o/ 17:01:16 Hello 17:01:20 howdy everyone! 17:01:27 lets start... 17:01:32 #topic Agenda 17:01:39 #info #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Feb_23.2C_2016 17:01:58 #topic Annoucements 17:02:36 Big tent application is under review by OpenStack TC - #link https://review.openstack.org/#/c/276417 17:02:53 progressing well with many +1 votes! 17:03:24 way to go 17:04:11 nice! 17:04:17 Mitaka release schedule is at #link http://releases.openstack.org/mitaka/schedule.html 17:04:39 we are at R-6 (release - 6weeks) 17:04:52 the windows is closing soon for Mitaka :( 17:05:16 Nothing else to announce from my side... 17:05:36 hope we will have something *big* to announce next week :) 17:05:50 looking forward to that big announcement 17:05:56 vishwana_: yep 17:06:05 fingers crossed! 17:06:18 #topic Enhanced VNF Placement update 17:06:29 Spec at #link https://review.openstack.org/#/c/257847 17:06:39 vishwana_: can you please share updates where we are ? 17:06:59 sridhar_ram, sure.... 17:08:06 FYI: I have an initial Work In Progress patchset https://review.openstack.org/#/c/269295/ that validates some of whats documented in the blueprint.... 17:09:41 I have been able to test successfully the VNFD template proposals in the blueprint for CPU Pinning, Huge Pages, NUMA topology in my WIP patchset.... 17:10:04 vishwana_: cool, what is remaining to wrap up the spec ? 17:10:33 I anticipate that the VNFD template proposal will undergo changes in terminology with feedback from Bob and you ..... 17:11:23 vishwana_: yes, I'm working with TOSCA nfv group to introduce these granular cpu-archiecture attributes in TOSCA NFV profile.. 17:12:12 I am currently calling out some properties under host section .... 17:12:48 vishwana_: current thought is it will be moved as "capabilities" of the VDU node itself 17:12:57 I expect those to be renamed as tosca.nodes.Compute 17:13:22 vishwana_: okay 17:13:23 sridhar_ram, yes 17:14:19 I can help to get the template part of this spec. 17:14:29 the one other major part is to see how sr-iov capability would be specified.... 17:15:06 ignoring tacker for a moment, how it is specified in heat hot templates ? 17:15:21 vishwna_: This was going to bemy question 17:15:57 Is the plan to translate everything to HOT? If so, the spec should have an example translation. 17:16:28 sridhar_ram, brucet, great question ... 17:16:37 I am currently in the midst of setting up a server with a Intel NIC card that has SR-IOV capabilities.... 17:17:47 am first trying to make sure that I am successfully able to create a SR-IOV port using neutron followed by booting a VM using Nova by specifying the sriov port... 17:18:57 So first test a non automated setup 17:19:04 vishwana_: make sense 17:19:15 have run into some issues ..... consulting with sgordon to resolve the issue.....once the issue is resolved, I will investigate how it works with heat 17:19:40 vishwana_: sounds good / rather practical ! 17:20:06 given our release timeline, my suggestion would be keep sr-iov as a stretch goal and in a separate patchset .. 17:20:29 let the CPU related placement be on the initial patchset and continue review, merge.. 17:20:33 sridhar_ram, great suggestion, makes sense keeping the release timeline in mind 17:21:04 I don't want to risk this whole feature just for sr-iov... 17:21:32 however, as I imagine, you would keep pushing to get sr-iov in.. we still have room 17:21:52 from closing the spec perspective, I need to respond to bobh and your initial comments and incorporate the TOSCA NVF terminology 17:22:28 lets make a call on sr-iov by end of this week... 17:22:45 those are the items I think of as big items for now as related to closing the spec..... 17:22:48 whether it is going to stay in this spec or will get split out into a separate one 17:22:58 sridhar_ram, agree on the call by end of the week for sr-iov 17:23:17 vishwana_: sounds good, anything else ? 17:23:32 anyone else have any question on this topic ? 17:24:08 sridhar_ram, I am expecting that network creation will be part of automatic resource creation and will be leveraged by the enhanced vnf code 17:24:21 vishwana_: for sr-iov part ? 17:24:36 sridhar_ram: EPA will consume tosca parser changes from bobh? 17:25:18 sripriya: yes 17:25:38 sridhar_ram, in general for both any networks specified as part of network_interfaces section under VDU 17:25:48 vishwana_: you should plan to move your WIP to be based on bobh's WIP 17:25:58 * sridhar_ram looking for bobh's WIP link 17:26:09 so there is no extra functionality to be handled by Tacker or is the entire template offloaded to tosca parser? 17:26:16 #link https://review.openstack.org/#/c/278121/ 17:26:57 there are two parts... 17:27:20 sridhar_ram, makes sense that my WIP be based on bobh's WIP 17:27:31 1) the spec portion will go into tosca-parser (or for now stay in tacker_nfv.yaml overlay over nfv profile) 17:27:56 2) HOT translation portion need to be coded in tacker itself (and not in heat-translator) 17:28:06 I see 17:28:11 ah ok.. 17:28:52 I thought that the HOT generator was also part of the translator 17:29:39 TOSCA NFV >> Intermediate format >> Hot or Tacker feature implementation 17:29:46 brucet: as discussed in previous call there will be a portion of HOT translation in tacker related to flavor creation 17:30:50 Meaning that the flavor is created outside of HOT?? 17:30:50 heat-translator's flavor handling is something we couldn't consume.. 17:31:41 bobh would have the answer, he is not around today 17:31:53 OK. 17:32:38 we don't have both bobh and tbh in this call today.. there are in the food chain in front of vishwana_ 17:32:50 that would flush out our dependencies .. 17:33:36 agree 17:33:48 anything else on this? if not lets move on.. 17:34:11 #topic Liberty Release updates 17:34:28 For the folks who weren't tracking... 17:34:52 we have a stable/liberty but we haven't pushed a release pypi for liberty.. 17:35:21 it was pending on few things .. particularly on device API deprecation 17:35:41 now dkushwaha is helping to get the deprecation done... 17:36:20 now I'm looking to make a liberty release once that lands 17:36:36 sridhar_ram, most probably I will finish it by tomorrow 17:36:44 if anyone have some critical things they need to see it into Liberty please cherrypick ASAP 17:37:09 dkushwaha_: np, thanks for the getting this in! 17:37:39 this release will be consumed by few downstream projects like OPNFV 17:38:26 moving on... 17:38:38 #link VNF Scaling 17:38:48 #topic VNF Scaling 17:39:20 I'd like to have some preliminary discussion on VNF scaling ... particularly at the requirement level 17:39:49 did you see my email yesterday?? 17:39:50 what kind of VNF scaling you folks would like to see "enabled" through Tacker ? 17:40:04 brucet: yes, 17:40:18 OK. 17:40:28 brucet: sorry didn't had time to reply, we should do these discussion in the ML, btw 17:40:45 ML?? 17:40:53 Mailing list 17:40:54 OK 17:41:00 I'll send now 17:41:06 mailing-list - openstack-dev with [tacker] tag 17:41:14 sridhar_ram : we have any input from outside, about what are interested in? 17:41:46 however I want to intentionally skip the implementation for a moment and think about what make sense for NFV operator 17:42:07 OK 17:43:10 prashantD: I can share what I've been asked to provide off tacker.. I'd also like to get folks opinion here ... 17:44:00 brucet: prashantD: my questions are around manual scaling vs auto scaling... 17:44:24 if auto-scaling are we looking at traditional cpu load 17:45:20 I would think you would want to take any type of application generated signal to trigger a scaling operation. 17:45:44 I think this can actually be done with Heat using signals 17:45:59 brucet: agree, scaling based on "triggers".. 17:46:16 trigger could be from application or even some external monitoring s/w 17:46:27 Yes 17:46:54 one of the trigger could be manual ? from the operator ? 17:47:08 Yes 17:47:32 btw, there are some operators interested in manual "VNF" scaling .. when tacker is used as a VNF manager. 17:47:41 remember the discussion on Senlin a while ago? 17:48:04 I know Senlin includes a method for an application to generate a trigger. 17:48:23 there would be a higher level NSD getting a scale up event and NSO will call Tacker to scale up and that scale up will look like "manual" scale up request 17:48:26 And Senlin functionality will ve incorporated into Heat as Resources 17:49:03 That's the approach I would use 17:49:05 yeah, we need to look into Senlin, I checked with their PTL, heat resource for Senlin resources will be available in Miraka 17:49:18 Ah... Very good 17:49:52 I'm trying to see how we could stack the chips.. 17:50:18 get a simple "trigger" based scale up / down framework.. 17:50:22 The problem that I see is there is nothing defined in Tosca NFV for scaling policy 17:50:37 a specific VDU will scale up / down within a {min, max} range 17:51:02 there are some constructs in Simple Profile we can consume 17:51:06 Yes. But where would trigger be defined? 17:51:14 they have a nice event --> trigger --> action sequence 17:51:14 For triggers?? 17:51:34 If you could point me to it I qwould appreciate 17:51:42 sridhar_ram, brucet: yes, how will user trigger scale event with senlin? 17:52:15 There is an HTTP based API that Senlin listens for to trigger events 17:52:43 IMO we need a tacker VDU trigger into Senlin to be in the loop.. 17:53:10 i see, so user will have to use a non-tacker interface to trigger scale event? 17:53:20 this trigger could be used (a) for manual scale request coming to tacker or (b) any mon driver in tacker getting a "scale up" resp 17:53:31 You could abstract the Senlin interface with a Tacker interface 17:53:59 So NFV app >> Tacker Trigger >> Senlin Trigger 17:54:22 yeah, something like that.. 17:54:35 Or if Tosca defines triggers then this could be used to drive Senlin Trigger API 17:54:47 prashantD: we need some experimentation trying out Senlin 17:55:19 I actually thought there was a trigger mechanism in Heat today without Senlin. 17:55:26 I can check into this. 17:55:43 brucet : in heat there is a stack-update 17:55:58 And you send a signal?? 17:56:00 if I step back I see two models... (a) set and forget model - scale using cpu load, mem, etc that Senlin can figure out (b) based on trigger that Tacker will "facilitate" 17:56:05 which allows you to scale and that is what i am doing 17:56:18 OK 17:56:53 If we could start without depending on Senlin I think that would be better 17:57:22 do you folks see value in implementing manual scaling using heat stack-update until we get some sense out of Senlin ? 17:57:31 Yes 17:57:52 The basics between manual and automated scaling are the same 17:58:03 prashantD: did you re-write your spec into one for manual scaling ? 17:58:08 brucet: agree 17:58:09 You need to create an autoscaling group in Heat in both cases 17:58:29 sridhar_ram : i wrote a separate manual scaling spec 17:58:34 Is there already a scaling spec? 17:58:48 * sridhar_ram almost out of time 17:58:50 https://review.openstack.org/#/c/283163/ 17:58:57 I will look at this now 17:59:04 I didn;t know there was already a apec 17:59:13 brucet: prashantD: lets continue the discussion in that spec.. 17:59:20 brucet : there is also a auto-scaling one, based on ceilometer though 17:59:27 brucet: looks this showed up could be days back :) 17:59:47 lets continue the discussion next week.. 17:59:55 In any case, I'll be happy to review exosting spec. 18:00:03 No need to send email to list then. 18:00:15 brucet: agree, lets continue in gerrit! 18:00:21 times up.. 18:00:26 thanks folks .. 18:00:32 #endmeeting