01:01:27 #startmeeting tacker 01:01:28 Meeting started Wed Dec 16 01:01:27 2015 UTC and is due to finish in 60 minutes. The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot. 01:01:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 01:01:32 The meeting name has been set to 'tacker' 01:01:38 #topic Roll Call 01:01:45 o/ 01:01:48 o/ 01:01:50 who is here for tacker mtg ? 01:01:56 vishwanathj: sripriya: hi there! 01:02:38 hi 01:02:57 prashantD_: howdy 01:03:10 lets give few mins, before we start. 01:05:18 #topic Agenda 01:05:25 #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Dec_16.2C_2015_-_APAC_Timezone 01:05:32 #topic Annoucements 01:05:57 Tacker Midcycle meetup is planned for end of Jan 2016 01:06:14 this is a F2F meeting to be held in San Jose, CA 01:06:33 Here is the poll for possible dates - #link http://goo.gl/forms/8hVPXcmoqz 01:07:12 Please provide your inputs! 01:07:40 hello 01:07:49 next.. we are heading towards Holiday season in US 01:08:04 s3wong: hi, we just getting started... 01:08:22 sridhar_ram: yes 01:08:44 I won't be available for next two weeks... 01:08:55 .. any volunteers to run the mtg ? 01:09:10 or do think we shd skip next two weekly meeting ? 01:09:18 i vote for skipping 01:09:31 +1 01:09:33 +1 01:09:36 for some of us we can use the time to do some review 01:09:45 review -> reviews 01:09:55 +1 01:09:56 vishwanathj: true, our review queue is quite deep 01:10:20 yup, and also implementing the bluprints itself 01:10:40 +1 01:11:02 alright.. lets skip. we will reconvene at our usual time on Jan 5th 01:11:28 anything else to announce / heads up ? 01:11:53 lets move on... 01:12:04 #topic Mitaka blueprint updates 01:12:16 sridhar_ram: python jobs are enabled for python-tackerclient 01:12:50 sripriya: oh, yeah.. thanks for pointing out and thanks to Yong Sheng from 99cloud 01:13:04 gongysh: are you here ? 01:13:42 sridhar_ram: so any new python-tackerclient changes will need to include unit tests coverage 01:14:02 sripriya: true... 01:14:41 and also the original device unit test cases will be removed eventually which is currently enabled 01:15:35 sripriya: I hope we can convert these to "vnf" client test cases 01:16:39 sridhar_ram: yes, it is actually a "conversion" there should be no other major impacts as it is based on devices 01:16:50 lets see if yong sheng joins to take up Efficient VNF placement topic 01:17:13 sripriya: okay.. 01:18:13 sripriya: do you want to give a quick update on Multi-VIM ? 01:18:31 sripriya: .. or shd I say multi-site ? ;-) 01:19:02 sridhar_ram: sure, there have been some great inputs/comments on the spec. I need to upload a new version of spec incorporating these inputs 01:19:38 sridhar_ram: :-) yes we have transitioned to "multi-site VIM" 01:19:47 sripriya: I like it :) 01:20:05 Nice 01:20:19 sripriya: I'm happy to see all those nice discussions.. 01:20:38 sridhar_ram: i understand there were concerns on the term. itself regarding multisite/multiregions/VIMs which we have discussed on the spec, 01:21:14 sridhar_ram: also we have moved on from VIM O to NFV O as the end goals of this new component is resource management across VIMs as per ETSI doc 01:21:15 sripriya: we need to strike a balance between MANO taxonomy and the actual openstack multisite deployments methods 01:21:51 sripriya: yes, multi-vim is *one* of the building blocks on NFVO 01:22:34 sripriya: while we are not taking up Resource reservation / allocation .. this feature shd evolve into that in the future 01:22:41 overall quite pleased... 01:22:55 sridhar_ram: the workflow will be pretty much NFVO->VIM->Regions->Availability_Zones->Cells that will constitute as vim selection for VNF placement 01:23:36 sridhar_ram: agree 01:23:50 sripriya: wow.. that's quite a level of granular placement control.. 01:24:35 sridhar_ram: :) or it can be just NFVO->VIM (With defaults) 01:25:11 sripriya: okay.. keep in mind, there is also automated test complexity and horizon work 01:25:41 sripriya: .. so we need to keep the scope not run away too much.. 01:26:09 sridhar_ram: yes, with these inputs coming in, i observe there will be lot more work on horizon side as much as the server side 01:26:42 afveitch: hi, we are discussing multi-vim / multi-site.. 01:27:05 ok 01:27:43 sridhar_ram: I am still thinking about the best way to address the things you wrote in your response 01:28:09 sridhar_ram: i have not through much on the automated test complexity , but if we are doing this with multiple devstack installs, it will be good to understand if this is feasible in openstack jenkins 01:28:30 thought* 01:28:37 afveitch: there is also some nomenclature / terminology that's cluttering us a bit.. 01:28:53 sripriya: true, it will be good to check w/ infra team apriori 01:29:31 sridhar_ram: Yes, agreed. I think if we can align the mapping of the Heat multi region with the MANO docs, it would be good 01:30:20 sridhar_ram: That is part of what I am working to put into my follow up to comments - then send for general review. 01:30:22 afveitch: ... bottomline if Tacker support VIM endpoints with multiple Regions along with support for AZ we would've implicitly covered OpenStack multi-site deployments using Regions 01:31:10 afveitch: .. sure, lets continue the discussion in the gerrit, so that it gets captured in place... 01:31:12 sridhar_ram: Yes, I think you are correct. Frankly, I am working to get more familiar with the multi region to be confident in myself in responding 01:31:49 sridhar_ram: agree with that plan 01:32:18 afveitch: no worries. You point on "multi-site" is interesting .. in fact, as mentioned in the comment, it will be nice to group all VIMs in a specific "site" .. perhaps even plot them in a google maps enabled dashboard :) 01:32:41 hope I'm not fantasizing too much :) 01:33:02 sridhar_ram: a man's reach should exceed his grasp :-) 01:33:27 afveitch: perfect! like it 01:33:46 anything else - major - on multi-site vim ? 01:34:12 sridhar_ram: not for me, I joined late and will review the log. 01:34:25 afveitch: sure... 01:34:30 sridhar_ram: nothing from my end, i will upload a new spec for further discussions 01:34:41 sripriya: sounds good... 01:35:14 lets move on.. 01:35:29 tbh: do you want to give a quick update on auto-resource creation ? 01:36:09 sridhar_ram, Hi, I want to readdress the comments mentioned in bp 01:36:36 tbh: which specific one ? 01:36:51 but sridhar_ram I want to know about what do you mean by template parametrization 01:37:28 tbh: remember we discussed (perhaps even decided) to create flavors during VNFD creation... 01:37:43 sridhar_ram, yes 01:37:48 tbh: ... that may not work if some of the properties like num_cpu is parameterized.. 01:38:09 tbh: .. you can create flavors only at vnf-creation time 01:38:50 sridhar_ram, yes, but we thought later of sending those details to heat with out tacker creating it 01:39:15 sridhar_ram, so that will come under vnf creation time, right? but I haven't updated in specs yet 01:39:53 tbh: ah, yes... do you use heat to create flavor on the fly during vnf instantiation time ? 01:40:06 sridhar_ram, yes 01:40:20 sridhar_ram, and the scope of flavor is same as vnf 01:40:42 hi 01:41:00 gongysh: hi there, we are discussion auto-resource creation spec from tbh 01:41:08 cool 01:41:08 tbh: yeah, that shd work.. 01:41:14 sridhar_ram: tbh: essentially glance image upload is the only case that happpens during vnfd-create operation? 01:41:44 sridhar_ram, sripriya yes 01:42:06 sripriya, you asked about if about flavor duplicity 01:42:14 tbh, how about flavor creation? 01:42:20 sripriya, sridhar_ram we can have duplicate flavors 01:43:30 gongysh, as sridhar_ram said if the template is parametrized we cannot create flavors at vnfd creation time 01:43:30 isnt that redundant for the user, as an operator i dont want to create duplicate flavors for each vnf requests 01:43:41 tbh: ^ 01:44:02 sripriya, but as we decided earlier flavors are cheap 01:44:35 sridhar_ram, but template parametrization case will apply for image creation also? 01:44:39 tbh: agree it was cheap when it was associated with VNFD... 01:44:58 tbh: no, we shdn't allow that IMO 01:45:26 sridhar_ram, because images are of large sizes 01:45:56 tbh: .. back to flavors we are now taking about number of flavors -at worst case == number of VDUs in the controller.. 01:46:04 tbh: .. that doesn't look good 01:46:10 tbh: then i will end up having a huge list of flavors in my deployment which is not preferred (and is ugly) even though the operation is inexpensive 01:46:34 sridhar_ram, sripriya but we have a solution that we have implemented for this 01:47:03 sripriya, sridhar_ram https://review.openstack.org/#/c/252834/ 01:47:21 folks - lets wrap this discussion and continue in gerrit.. I'd like to discussion Efficient VNF placement 01:47:28 *discuss 01:47:32 sripriya, sridhar_ram heat translator can return the best match for the flavor 01:47:43 sridhar_ram, okay 01:47:50 tbh: will take a look, thanks 01:47:58 tbh: that look promising! 01:48:09 #topic Efficient VNF Placement 01:48:33 gongysh: vishwanathj: hi folks.. can you give a quick update on the scope & where you are ? 01:48:56 sridhar_ram, I have uploaded a spec for it 01:49:09 thanks to gongysh for starting the patchset.... 01:49:13 gongysh: link ? 01:49:22 sridhar_ram, https://review.openstack.org/#/c/257847/ 01:49:43 I plan to add to it and collaborate alongside gongysh 01:49:56 gongysh: awesome... that's a good kick start.. ! 01:49:57 It will depend on tbh's resource creation BP 01:50:33 gongysh: true, and tbh's BP depends on bobh's tosca work.. and that worries me :( 01:50:41 but, since we can create flavor already, just as tbh said, we can begin the coding for flavor creation. 01:51:17 gongysh: cool.. 01:51:41 gongysh: please work with vishwanathj to split some areas for faster progress... 01:52:11 we need testing much. since the openstack CI dose not provide numa and sriov testing host. 01:52:44 I remember Cisco contributed some CI for sr-iov.. but agree that will be challenging 01:52:51 vishwanathj, you can update the https://review.openstack.org/#/c/252834/ to include what tasks you will do. 01:53:26 gongysh, I have some ideas with regards to make the VNFD content for NUMA, CPU Pin, Huge Pages and vCPU topology more generic...shall discuss with you 01:53:41 vishwanathj, sure 01:54:01 btw, what are the must-have features ? 01:54:07 gongysh, thanks 01:54:18 are we shooting to include pci-passthru and sr-iov in this scope 01:54:37 I see it as being called out as stretch for mitaka in the spec 01:54:43 sridhar_ram, sriov should be the first thing. 01:55:26 gongysh: okay.. it will be great to bring it in.. 01:55:50 gongysh: .. I was not sure about the effort involved 01:56:17 * sridhar_ram I hope we can extend this mtg few mins beyond the top of the hour... 01:56:29 * sridhar_ram .. if needed 01:56:59 alright.. that's cool.. I'll let you and vishwanathj march on.. 01:57:24 this is a crucial feature for Tacker.. ! good luck :) 01:57:35 gongysh, looking forward to collobarating with you and learning from your experience 01:58:06 anything else on EPA / EVP topic ? 01:58:06 vishwanathj, haha, do it together, and make it happen. 01:58:17 most definitely 01:58:25 sridhar_ram, shall we begin coding before spec is merged? 01:59:07 gongysh: well.. you need some amount of coding to write good blueprints :) .. yes, as long as you are ready to alter as we go! 01:59:53 good to see the blueprint start.. lets continue the discussion in gerrit.. 02:00:00 ok 02:00:05 #topic Open Discussion 02:00:24 as discussed earlier.. there is no IRC meeting for next two weeks 02:00:31 we will reconvene Jan 5th.. 02:00:43 tacker core will be around to merge patchsets .. so keep the work going! 02:00:53 * sridhar_ram taking two weeks off 02:00:56 sridhar_ram: are there any priority patchsets that needs to be closed within this week before holidays? 02:01:53 sripriya: nothing pops at this time.. but noticed the queue is deep and we need to keep clearing them .. 02:02:02 sridhar_ram: ok 02:02:04 sripriya: .. to keep things manageable 02:02:29 I will be around :-) 02:02:30 one heads up / request for help - please flag patchsets that need to go to stable/liberty.. 02:02:36 gongysh: any update on the nova patchset if it will merged soon? 02:02:37 s3wong: thanks! 02:03:19 will plan to release pypi pkgs for liberty / 0.2.0 in first week of Jan 02:03:22 sripriya, no luck. network related patch is always slow in nova. 02:03:32 no network guys in nova cores. 02:03:55 gongysh: that's bad.. no wonder nova-network --> neutron is in bad state 02:04:15 gongysh: thanks for update 02:04:15 sridhar_ram, it is true. 02:04:22 gongysh: in fact I want this nova fix in stable/liberty ... 02:04:28 +1 02:04:28 gongysh: .. is that possible ? 02:04:46 yes, definitely 02:04:51 I will push it. 02:05:00 gongysh: thanks! 02:05:04 cool! 02:05:17 gongysh: I'm glad you joined Tacker team! 02:05:36 anything else team ? 02:05:45 * sridhar_ram we are 5mins overtime 02:05:47 thats it from me 02:05:52 sridhar_ram, my pleasure 02:06:29 alright.. if you taking a break / vacation.. have a nice time and a safe holiday season.. 02:06:35 if you going to work.. happy coding! 02:06:41 see you all next year! 02:06:44 same to you, bye 02:06:52 bye! happy holidays! 02:06:54 bye 02:06:56 Happy holidays everyone, bye 02:07:05 Happy Holidays, Bye 02:07:11 bye team! lets rock on in 2016 02:07:12 happy holidays. bye 02:07:20 #endmeeting