17:02:50 #startmeeting tacker 17:02:50 Meeting started Tue Nov 17 17:02:50 2015 UTC and is due to finish in 60 minutes. The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:51 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:55 The meeting name has been set to 'tacker' 17:02:59 #topic Roll Call 17:03:05 hi 17:03:09 who is here for tacker ? 17:03:13 o/ 17:03:14 natarajk: hi 17:03:31 o/ 17:03:41 o/ 17:04:44 lets get started... 17:04:54 #topic Announcement 17:05:21 Agenda #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Nov_17.2C_2015 17:05:27 o/ 17:05:37 rather lite today.. any open items welcome! 17:05:42 tbh: hi there 17:06:04 sridhar_ram, Hi 17:06:10 hello 17:06:25 Hello all 17:06:25 I did not see any new Blueprints this past week 17:06:26 Sripriya is offically a new core member! 17:06:46 brucet: hi there, hang on a bit.. we will get to it 17:06:52 OK 17:07:09 I believe Sripriya is traveling and not here today 17:07:32 #topic Mitaka Blueprints and RFEs 17:08:18 bobh: any quick update on the tosca-parser activities ? 17:08:56 I created the tosca-parser BP and Sahdev has replied that they will review it soon. I believe I need to create a corresponding heat-translator BP and one in tacker-specs too 17:09:28 I've been working on the tosca-parser changes in the background, hopefully something will be working soon 17:10:00 bobh: sounds good. provide gerrit links when available.. 17:10:07 will do 17:10:14 sorry, a bit late 17:10:34 bobh: have you thought about how the tacker part of the BP will look like ? 17:11:44 sridhar_ram: There are several pieces - (1) incorporating the new tosca-parser library, (2) changes to the existing tosca parsing code to handle the "new" and the "old" formats, and (3) incorporating the new heat-translator capabilities 17:12:08 (2) could be an issue - there are significant differences between what we support today and the official TOSCA NFV Profile 17:12:36 bobh: exactly .. that's what I'm curious about.. the level of feature parity between the two 17:13:23 bobh: anyway, it is fair for you to write up your thoughts in the BP and have everyone here review & comment 17:13:26 sridhar_ram: I need to do a full comparison but I think the differences may be significant 17:13:32 What about existing heat resources? Anything needed there?? 17:13:55 brucet: Do you mean new resources? 17:14:05 Yes. Heat resources 17:14:13 bobh: the two stand out items for us to carry over is mgmt_driver and mon_driver to the new format 17:14:24 Tosca translator >> Heat template, right?? 17:15:16 brucet: right - I think that the existing heat-translator supports (many) more Heat resources than our home-grown translator does today 17:15:42 Oh. This is not built on existing Tosca >> Heat translator?? 17:15:42 brucet: we may find additional things we need in the heat-translator bp/spec after the tosca-parser work is done 17:16:16 brucet: Existing tacker code generates heat from tosca "manually" 17:16:40 brucet: at high level, what is currently in heat-translator is tosca-simple-profile --> heat .. for Mitaka we want to get to tosca-nfv-profile --> heat 17:16:44 brucet: so by moving to the official tosca-parser/heat-translator codebase we will gain a lot of capabilities 17:16:55 brucet: that is the scope of this effort, bobh correct if I'm wrong 17:17:00 OK 17:17:01 sridhar_ram: correct 17:17:06 Got it, thx 17:17:18 brucet: sure 17:18:00 lets discuss more on tosca-parser once some BPs write up show up 17:18:18 bobh: thanks for the update.. looks things chugging nicely here! 17:18:43 tbh: I know you picked up Auto Flavor / Auto Network creation. 17:19:02 tbh: can you provide your thoughts & updates ? 17:19:35 sridhar_ram, I have seen the new rfe reported by you for flavor 17:19:50 https://bugs.launchpad.net/tacker/+bug/1516193 17:19:50 Launchpad bug 1516193 in tacker "Automatic Flavor Creation based on VNFD Template" [Medium,New] - Assigned to bharaththiruveedula (bharath-ves) 17:20:23 tbh: I still need to write on for Auto Network creation :( 17:20:28 sridhar_ram, but I think we will continue with automatic flavor creation once we get the done with tosca parser intergration? 17:20:29 s/on/one/ 17:21:15 tbh: no, I would prefer for us not to put tosca-parser dependency for the things in flight 17:21:15 sridhar_ram, I will write that 17:21:51 sridhar_ram, you mean to use existing tosca parse/heat translator for that? 17:22:43 tbh: bobh: this is the part I need some clarification 17:23:04 tbh: bobh: how do you envision tosca-nfv-parser work will help in this auto-flavor effort ? 17:23:35 sridhar_ram: We need to determine if the existing heat-translator code can generate a heat template that auto creates a flavor, network, etc 17:24:05 sridhar_ram: if it does/can, we will get that functionality for "free" when we move to using tosca-parser/heat-generator 17:24:27 bobh, no, it wont create. It just maps vnf details -> flavor name 17:24:46 tbh: ok, so the next question is where should that capability go? 17:24:50 bobh, sridhar_ram but that too heat-translator is not using nova client to get flavor details 17:25:17 tbh: sridhar_ram I think we could argue that this is an enhancement to heat-translator? 17:25:39 sridhar_ram: Since we want to get out of the heat generation business right? 17:26:04 bobh, sridhar_ram this is related BP https://blueprints.launchpad.net/heat-translator/+spec/match-custom-flavor 17:27:04 bobh, yes, I think it must go in heat translator 17:27:40 tbh: Agree - and if there are admin issues around creating custom flavors that will need to be addressed too - maybe Tacker is "admin"-enough that it's not a problem 17:27:41 bobh: true, but flavor has lot more things riding on it .. it is not just cpu, mem. there are aspect of efficient VNF placement that goes into Nova flavor 17:28:16 sridhar_ram: agree 17:28:44 looks we need more data here. 17:29:21 vishwanathj: you also need to get your efficient placement requirements into the mix and have it supported by what bobh and tbh are building 17:30:02 sridhar_ram, agree 17:30:51 but this criss-cross dependency scares me a bit.. lets see if we can break these into smaller work items among us 17:31:19 if tacker needs to be in the business of flavor create - say using vnfd-create 17:31:50 that will give us some control to handle different performance level metadata 17:32:07 sridhar_ram: that would be one solution - initial analysis during vnfd-create, but it doesn't prevent the available flavors from changing between vnfd-create and vnf-create 17:32:46 bobh: true, in fact I'd suggest we SHOULD NOT rely on existing flavors in the nova flavor-list 17:33:12 bobh: flavor shd always be created using custom uuid and live thru' the lifetime of the vnfd 17:33:35 there is a section in tosca called host_properties: . 17:34:01 sridhar_ram: so it might be that we want to put a layer between the tosca-parser output and the heat-translator input where we do flavor analysis and inject some custom flavor creation into the tree 17:34:32 sridhar_ram: need to ensure that heat-generator will support creating custom flavors 17:34:36 bobh: spot on.. that's a clear value that tacker can bring in 17:34:37 sridhar_ram, bobh yeah, but I don't think new flavor for every vnfd, but analyse flavor details of tacker created flavors 17:36:03 bobh, heat generator you mean tacker heat generator, or heat code? 17:36:10 tbh: in trying to analyze existing flavors, we are mostly trying to be db efficient.. 17:36:10 tbh: Flavors are "cheap" - they don't use any resources by themselves, so I think it is reasonable to tie them to the VDU/VNFD 17:36:21 tbh: I don't think that's an issue 17:36:34 bobh: +1 17:36:50 tbh: sorry - heat-translator - my brain keeps saying heat generator 17:36:51 heat-generator is expected to work only for the OpenStack VIM, right? if we support other VIMs, a different tosco to that particular VIM generator would be needed 17:37:01 vishwanathj: correct 17:37:49 vishwanathj: that's a good point.. current code intermingles tacker functions in heat-parser. 17:37:50 agree 17:38:05 hope we can clean that a bit and get a nice layer of separation 17:38:15 bobh: no pressure ;-) 17:38:36 sridhar_ram: yeah right 17:39:15 tbh: once you've some data .. you can use the RFE bug to write up how you are planning to implement 17:39:32 tbh: we can get to impl after that. fair ? 17:39:39 sridhar_ram, sure 17:40:47 tbh: quickly on network creation, the note I got from tosca folks is .. if network param indicates a "name" we should assume the network is already available (like the way it is today) 17:41:20 if the network: is described as ip_addr/netmask/vlan .. that's the cue to do auto-network creation 17:42:12 anything else to discuss auto-flavor / net area? 17:42:34 sridhar_ram, I think even in second case we can specify name 17:42:39 is that correct? 17:43:11 tbh: sure.. it become more a well known name 17:43:35 lets move on to the next topics 17:43:44 #topic Bugs / Docs / Infra 17:44:14 anyone (include tacker users) want to bring up any significant bugs to our attention ? 17:44:52 sridhar_ram i have a bug on monitoring, looking for bugid.. 17:45:10 santoshkumark: sure... 17:45:28 one thing from my side that is bothering me is https://bugs.launchpad.net/tacker/+bug/1505468 17:45:28 Launchpad bug 1505468 in tacker "Error status after creating a vnf - TypeError: can't be decoded" [High,New] 17:46:10 this shows up periodically with "Port in conflict vdu1_mgmt_port still in use" or something like that 17:46:39 if anyone hits this issue please provide some data in the above bug 17:47:44 santoshkumark: got the bug id ? 17:47:47 https://bugs.launchpad.net/tacker/+bug/1513972 17:47:47 Launchpad bug 1513972 in tacker "vnf monitoring fails after multiple vnf create/delete operations" [Undecided,New] 17:48:37 this bug is seen when vnf creation goes to ERROR state, 17:48:43 sorry, need to drop off 17:49:19 Why will vnf create might be error: one reason is if number of vm limits are exceeded while vnf create.. 17:50:04 santoshkumark: in those situation i would expect the system to gracefully fail... 17:50:12 sridhar_ram: this bug is not a stopper..but can cause monitoring to fail.. 17:50:44 santoshkumark: looks a respawn failed due to resource limits exhaustion ? 17:51:15 sridhar_ram, do we need to monitor, if the VNF goes to ERROR state? 17:51:16 anyway, lets see if anyone have bandwidth to take it up.. 17:51:26 tbh: no 17:51:38 * sridhar_ram 10mins left 17:51:58 sridhar_ram: not sure if respawn.. 17:52:16 any comments on this bug patch https://bugs.launchpad.net/tacker/+bug/1503477 will be appreciated 17:52:16 Launchpad bug 1503477 in tacker "Provide respawn limit for respawn failure policy" [Medium,In progress] - Assigned to bharaththiruveedula (bharath-ves) 17:52:30 it's been so long 17:53:07 tbh: I've looked at it a couple of times but never had time to do a thorough review 17:53:23 tbh: I'll try to spend some time on it this week 17:53:36 bobh, sure thanks 17:54:17 tbh: we can take some of monitoring related enhancements after we make some progress in Mitaka priorities. 17:54:36 sridhar_ram, okay 17:54:38 I need another help from the team .. 17:54:59 anyone here know how to waddle through openstack-infra project-config ? 17:55:23 I could use some help to land tacker repos to pypi 17:56:09 reach out if someone has some expertise here.. 17:56:24 moving on... 17:56:34 #topic Open Discussion 17:57:00 quick poll.. how many of here would like to install Tacker in a non-devstack environment ? 17:57:19 o/ 17:57:22 o/ 17:57:50 o/ 17:58:06 okay.. there is multiple asks coming in the irc channel regardign this 17:58:36 we should take it up as a work item then 17:58:50 anything else ? 17:58:57 sridhar_ram: Also seems like we need a way t validate that heat/nova are working 17:59:15 Lots of questions come in because VNF 'failed to deploy' 17:59:24 bobh: you mean a stack validate ? 17:59:32 * sridhar_ram almost out of time 17:59:33 more like an openstack-validate 17:59:42 is heat working? is nova working? 17:59:53 if the answer to either is no then tacker isn't going to work 17:59:57 i think we should write a RFE and work through it .. 18:00:07 bobh: quite valid.. 18:00:15 times up folks.. 18:00:21 talk to you next week 18:00:24 bye all 18:00:25 bye all 18:00:29 bye 18:00:35 #endmeeting