17:00:15 #startmeeting tacker 17:00:16 Meeting started Tue Jan 26 17:00:15 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:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:21 The meeting name has been set to 'tacker' 17:00:28 #topic Roll Call 17:00:33 Hi Tackers ! 17:00:35 o/ 17:00:36 o/ 17:00:39 o/ 17:01:05 o/ 17:01:05 all heavy hitters here ;-) 17:01:11 Hi 17:01:25 lets starts... 17:01:31 #topic Agenda 17:01:42 #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Jan_26.2C_2016 17:02:05 #topic Announcement 17:02:22 Midcycle is just few days away ... 17:02:40 #link https://etherpad.openstack.org/p/tacker-mitaka-midcycle 17:02:56 Looking forward for some good discussions... 17:03:32 I propose to skip next week's weekly irc mtg ... 17:03:40 what do you all think ? 17:03:51 ok with me 17:03:55 fine with me 17:04:11 okay with me 17:04:11 fine by me as well 17:04:38 +1 17:04:39 .. canceled then! 17:04:52 #topic Midcycle Meetup Agenda 17:05:06 I've like to firm up the Agenda .. 17:05:49 Bob you will be remote, we will start with your TOSCA related subject... 17:06:01 ok 17:06:28 bobh: so, do you have some material - diagrams or slides to set some context ? 17:06:51 sridhar_ram: I'll put something together and post a link 17:07:25 bobh: sounds good, google doc is better as it is shareable ... 17:07:34 sridhar_ram: ok 17:07:53 tbh: I saw your email .. 17:08:29 hi Tackers 17:08:34 tbh: is timing the issue ? if needed we can let you go first thing in the morning ... 17:08:41 zeih_: howdy! 17:09:01 I am unable to attend meetup sridhar_ram, 17:09:22 sridhar_ram, no we have night shifts for this week 17:09:45 tbh: understood..no worries 17:10:19 we will still run though auto-creation in the agenda for any general discussion... 17:10:37 sridhar_ram, so I just put whatever in my mind in the mail 17:10:40 sridhar_ram, sure 17:10:45 zeih_: are you planning to attend (virtually) midcycle meeting ? 17:11:06 sridhar_ram: yes, part time 17:11:07 tbh: lets briefly discuss that later in this mtg 17:11:24 sridhar_ram, okay 17:11:26 sridhar_ram: due to time zones 17:12:15 zeih_: understood... that something we need to sample / get data in this meeting .. our developer community's availability.. 17:12:27 zeih_: you in european tz ? 17:12:44 sridhar_ram: yes 17:13:09 alright... any other midcycle related thoughts / questions ? 17:13:23 hi sridhar, prashant 17:13:31 is there still interest in scaling? 17:13:34 prashantD: hi there.. long time! 17:13:42 prashantD: in fact, we do.. 17:14:07 prashantD: there is some renewed interest in auto-scalling.. 17:14:20 prashantD: we might need to put that back into our active roadmap... 17:14:39 prashantD: are you planning to attend the midcycle later this week ? 17:14:54 oh okay, yes I will stopby 17:14:56 sridhar_ram: prashantD: from my operator perspective very interesting ;) 17:15:06 hello 17:15:11 s3wong: hi there... 17:15:12 sorry, joining late 17:16:06 zeih any use case on auto-scaling would help us 17:16:14 prashantD: all: if you are planning to attend midcycle part-time (i.e a portion of the two day) - please let me know the time slots.. 17:16:35 * sridhar_ram will retype as brucet just joinied... 17:16:41 all: if you are planning to attend midcycle part-time (i.e a portion of the two day) - please let me know the time slots.. 17:17:20 prashantD: sure 17:17:22 s3wong: it will be great if are present F2F for the service-chaining discussion 17:17:56 s3wong: we can adjsut the agenda items accordingly... 17:18:12 sridhar_ram: it is currently scheduled to be Thurs afternoon? 17:18:17 yep 17:18:27 Sorry I'm late 17:18:52 sridhar_ram: I should be able to accommodate 17:19:01 sridhar_ram: I will come by 17:19:04 s3wong: great.. 17:19:49 again.. the theme is Day1 for current things in flight.. 17:19:54 Was there a discussion on remote attendance? 17:20:07 Day2 for evolution of tacker beyond Mitaka 17:20:29 brucet: yes, I've a webex link now in the etherpad.. 17:20:36 OK. Perfect 17:20:48 sridhar_ram: great --- the rest of the time I will be remotely dialed in 17:21:00 it seems we have an even split between physical and virtual 17:21:03 s3wong: sounds good 17:21:24 anything else related to midcycle ? 17:21:50 moving on... 17:21:59 #topic Auto Image Creation 17:22:27 tbh just sent an email on this .. #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/084979.html 17:23:36 I'm wondering if we need to split out image handling into a separate RFE / spec 17:24:42 as part of the multi-site spec review, we were thinking about how image handling would work... 17:24:43 tbh, just read your email, good suggestion and approach 17:25:11 sridhar_ram, not sure, but if we move image creation to vnf deployment, then we can follow the same steps for all resources 17:26:18 vishwanathj_, :) 17:26:36 tbh: sripriya: how would that work w/ multisite ? 17:26:38 tbh: basically the same workflow as before as you do not need to maintain any state now for all 3 resources 17:27:02 * sridhar_ram thinks it would work just fine :) 17:27:32 the VNFD will have to association of what resources have been created on each of the VIMs 17:27:41 sridhar_ram: in multisite case, the common implementation would be to share a centralized image repository but we need to think through it 17:28:17 sripriya: true, that's a bigger set of capability - for another time :) 17:28:24 sridhar_ram, sridhar_ram yes, we don't need to maintain state for templates 17:28:25 sridhar_ram: but as per tbh's spec, it would create glance images on each of these VIMs 17:29:10 assuming glance image create is deferred to VNF create time ( 3rd apporach) 17:29:41 if the glance image needs to be resolved at VNFD create time, we will have to decide how to resolve 17:29:47 vnf-create pseudocode -- if vnfd already has glance image uuid, all is well.. if not download / upload to glance and stick the glance uuid to VNFD and proceed to instantiate ? 17:30:10 sridhar_ram, yes 17:30:13 yes 17:30:19 we need a dictionary of glance uuid for all VDUs in a VNFD 17:30:48 sridhar_ram, yes we have to maintain a dict for all resources 17:30:52 we also need a new VNF state "DOWNLOADING_IMAGE" 17:31:13 can we use a unique image name that is the same across all VIMs? 17:31:17 ..... are perhaps "PREPARING_IMAGE" 17:31:54 bobh: good point, if we store uuid that doesn't gel well for multi-site 17:32:02 sridhar_ram, tbh, is the plan to use glance for downloading the image or use Heat Flavor rsource? 17:32:05 sridhar_ram, why don't we continue with same states, but if fails, we will store error reason like "image upload failed" ? 17:32:37 tbh, +1 17:32:40 tbh: that could work for near term 17:33:12 vishwanathj_: I'd suggest to use glance direct... 17:33:39 vishwanathj_: Tacker would need more image-management capabilities down the line.. 17:33:57 sridhar_ram, vishwanathj_ I think we use native clients and use respective uuid in heat 17:34:03 ... with ETSI Image mgmt / upgrade in mind 17:34:09 I see 17:34:20 sridhar_ram, oh okay 17:34:57 sridhar_ram, but that states exists if the VNF is deployed for the first time? 17:35:00 tbh: sripriya: have you thought about how this solution would work for multisite ? 17:35:02 I believe I mentioned this in last meeting. Tricircle supports multi site image management. 17:35:46 sridhar_ram, .. because for the next VNF deployment for same VNFD, the states may not be valid, as images are already uploaded 17:36:01 brucet: okay.. that could help when we need to do more in this area. we need to restrict to something simple for now 17:36:40 My point is simply to find out how Tricircle is doing this and either borrow code or implement somethingcompatible 17:36:45 tbh: bear in mind, we will use the same VNFD for multiple sites, if that image is not yet uploaded on that particular VIM it should still show that satte 17:36:48 state* 17:36:53 tbh: true, some states are not applicable for the 2nd time around 17:37:28 brucet: sure.. 17:37:55 sripriya, got it 17:38:27 tbh: overall I like the approach you are suggested, lot simpler than mucking around to make VNFD creation stateful... 17:38:28 sridhar_ram: probably we should maintain the state as PENDING_CREATE but along with that display at what stage of CREATE it is like a simple log info 17:38:44 similar to HEAT api 17:39:11 sripriya, yeah that would be better 17:39:13 tbh: just think through how that solution would gel into multisite... perhaps use "image name" based index as bobh alluded .. 17:39:21 sripriya, some thing like stack_status_reason 17:39:25 tbh: yes 17:39:46 that way we dont need to bother about maintaining states at diff. times 17:39:50 sridhar_ram, sure 17:40:30 sridhar_ram, I think going with name will be helpful, as we reffering from VNFD directly 17:40:33 sripriya: tbh: sounds good to me .. for near term. we might need to come back to enhance states at a later time.. 17:40:56 Is the plan that multi site controller will be stateless?? 17:41:08 tbh: sripriya: meanwhile please look at tricircle if there are any solutions / code to borrow (I'll do the same) 17:41:26 sridhar_ram, sure 17:41:37 brucet: it is stateless for now, 17:41:52 Exactly. An important lesson l;earned from first implementation of Tricircle is that multi site controller should be stateless as far as underlyign OpenStack instances are concerned. 17:41:52 sridhar_ram: will look into it 17:42:21 Great 17:42:54 brucet: good input! 17:43:05 Thx 17:43:15 tbh: anything to discuss on this subject ? 17:43:25 *anything else 17:43:48 sridhar_ram, I think we can do the same for all resources? 17:43:58 tbh: what you mean ? 17:44:01 sridhar_ram, I mean same procedure, as mentioned in mail 17:44:09 sridhar_ram, for example... 17:44:41 tbh: for flavor and network I thought mapping to Heat resource is the natural way to do it... 17:44:47 for networks, we create the networks at vnf creation time and store those UUIDs as dict and reuse 17:44:49 * sridhar_ram reminds that is the next agenda item 17:45:16 tbh: hold that thought for a sec .. we will circle back after TOSCA parser discussion 17:45:26 #topic TOSCA parser integration 17:45:31 sridhar_ram, sure 17:46:05 bobh: congrats on landing TOSCA NFV profile into tosca-parser ! 17:46:10 W00T!! 17:46:16 +1 17:46:17 sridhar_ram: thanks! 17:46:26 bobh: congrats 17:46:38 bobh, congrats 17:46:59 this is significant, IMO.. we are now course correctly at the right direction.. 17:47:03 *correcting 17:47:21 bobh: now, how do you see the wiring going to happen into tacker 17:47:57 sridhar_ram: I'm working to fix a couple of issues we found in tosca-parser and heat-translator - should be available soon 17:48:33 bobh: I see.. 17:48:33 sridhar_ram: I'm working on an "overlay" of the Tacker attributes onto the VDU definition 17:48:53 Is the thinking that the Heat template generated by the translator will be directly usable to instantiate a VNF? 17:48:54 bobh, would this change any of the attributes in the tacker VNFD template? 17:49:56 brucet: That's the hope. Tacker will need to "prune" some attributes out of the ToscaTemplate object before passing it to heat-translator but the results of the translator should be usable in Heat 17:50:15 That makes sense to me 17:50:42 vishwanathj_: The TOSCA templates will have a different version and format but I'm trying to maintain all of the functionality between the two formats 17:50:53 How is a Tacker VNFD template related to a Tocsa NFV template? 17:51:26 Tacker will use the "version" attribute of the template (which doesn't exist in the template today) to determine that it needs to run through the tosca-parser and heat-translator 17:51:58 there will be a Tacker imports file that will add the additional properties needed by tacker onto the existing VDU/CP/etc ibjects 17:52:43 after tosca-parser generates a ToscaTemplate object, Tacker will need to retrieve all of it's custom information, for monitoring, etc, and prune it out of the object before passing it to the Translator to create the Heat template 17:53:13 bobh, I see, sort of makes sense, thanks for the explanation 17:53:30 bobh: cool, in this case it should prune image related stuff out as well, that something tbh's code need to kick in to handle 17:53:32 I found an issue where heat-translator does not allow you to specify a flavor or image directly today - that's a problem, but I have a patchset submitted to allow it and Sahdev has agreed to the change 17:53:55 So Tosca NFV template will drive Heat and other Tack subsystems? 17:54:06 brucet: yes, that's the plan 17:54:15 Then how is Tacker VNFD template related? What does it do? 17:54:52 The Tacker VNFD template will now contain the TOSCA NFV yaml instead of the custom-Tacker-yaml format that we use today 17:55:05 Ah.......... 17:55:23 we'll maintain backward compatibility for at least one release, but I think we should move completely to TOSCA ASAP 17:55:38 bobh: totally agree! 17:55:39 +1 17:55:41 OK. So there is an existing Tacker template format that will be subsumed by Tosca NFV Template 17:55:42 we can do POlicies, Artifacts, lifecycle, etc 17:55:48 brucet: yes 17:55:54 Got it. Thx 17:56:00 bobh: please code in a "deprecated" warning right away :) 17:56:09 brucet: and we will drive some of the things that Tacker needs for implementation northbound into the spec 17:56:09 * sridhar_ram 4 mins left in the clock 17:56:18 bobh : scaling will require additional changes? 17:56:34 brucet: since the NFV spec as it sits today is not very implementable 17:56:38 Now I am seeing the forest through the trees. Thx greatly bobh 17:57:03 OK 17:57:09 prashantD: scaling will require policy defintions, and server implementation, but should be possible 17:57:23 brucet: np 17:57:36 "overlay" that bobh mentions would be our playground for new features... 17:57:48 i'll try to have something "sort of" working or at least documented by Thursday 17:57:56 .. we should plan to push them back into TOSCA NFV profile as a follow on 17:57:57 working might be a stretch 17:58:18 bobh: that would be great.. 17:58:37 bobh: .. an helloworld always helps 17:58:49 sridhar_ram: exactly what I'm working on :-) 17:58:58 lets wrap it up for today... 17:59:05 #topic Open Discussion 17:59:17 sridhar_ram: could we try to push them in TOSCA NFV profile in parallel? 17:59:23 again, no irc meeting next Tuesday... 17:59:32 zeih_: absolutely... 17:59:38 zeih_: .. that's the plan 17:59:51 #link https://www.openstack.org/telecoms-and-nfv/ 18:00:22 zeih_: that's a good whitepaper.. Tacker is heavily mentioned 18:00:26 times up 18:00:28 nice report 18:00:43 see you most of you in midcycle 18:00:46 #endmeeting