16:01:26 #startmeeting tacker 16:01:26 Meeting started Tue Aug 30 16:01:26 2016 UTC and is due to finish in 60 minutes. The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:29 The meeting name has been set to 'tacker' 16:01:38 #topic Roll Call 16:01:45 o/ 16:01:46 o/ 16:01:46 o/ 16:01:48 o/ 16:01:51 o/ 16:01:51 o/ 16:01:56 o/ 16:02:03 o/ 16:02:04 o/ 16:02:05 o/ 16:02:22 hello everyone! 16:02:28 let's start.. 16:02:36 #chair bobh sripriya 16:02:37 Current chairs: bobh sridhar_ram sripriya 16:02:51 #topic Announcements 16:02:56 Few quick ones.. 16:03:21 hello 16:03:52 #link https://releases.openstack.org/newton/schedule.html 16:04:04 We are in newton-3 / feature freeze territory ! 16:04:34 We need to be extra careful what we land until Sept 15th (newton release deadline) 16:04:52 next.. 16:05:05 Please join me to welcome Yong Sheng to the core team! 16:05:12 #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/102356.html 16:05:35 Our geo diversity is quite amazing! 16:05:49 next.. 16:05:53 Final Tacker client for Newton 0.7.0 is released 16:05:58 #link http://lists.openstack.org/pipermail/openstack-announce/2016-August/001496.html 16:06:28 thanks for all those who pushed patchsets and reviews to make this happen..! 16:06:50 any other quick general shout outs ? 16:07:13 moving on.. 16:07:28 #topic Newton Release Status 16:07:59 let's go around and to see any sticking issues in the features expected to land in next couple of weeks... 16:08:14 tung_doan: how is your alarm monitoring coming along ? 16:08:24 tung_doan: any major issues blocking you ? 16:08:41 sridhar: alarm monitor is almost done. https://review.openstack.org/#/q/status:open+project:openstack/tacker+branch:master+topic:tacker-alarming 16:09:26 sridhar: i will need reviews latter 16:09:31 tung_doan: does this include ceilometer alarm driver ? 16:09:43 sridhar: yes, sure 16:10:27 tung_doan: sorry, i haven't looked closely.. which specific patchset has ceilometer related things ? 16:10:29 sridhar: alarm framework is already lauched. But it still need to review 16:10:53 sridhar: np. https://review.openstack.org/#/c/362975/ 16:11:45 tung_doan: i was looking for requirements.txt changes to pull in ceilometer client.. 16:12:14 tung_doan: anyways, will review... 16:12:27 team - need your help in the review of alarm mon.. 16:12:30 sridhar: thanks 16:12:56 it is coming in late, so.. 16:13:36 can someone volunteer to work with tung_doan to go beyond code review to pull the patchset and verify the functinality .. while the patchsets are still out 16:13:54 sridhar_ram, I can help 16:13:57 sridhar: thanks you guys.. I will try to modify if possible in the rest time 16:14:20 janki: great, thanks.. 16:14:42 sridhar_ram, mention not :) 16:14:57 sridhar: thanks janki 16:15:02 tung_doan: please watchout for issues reported by janki !! 16:15:22 moving on to...vnffg 16:15:24 sridhar: sure.. it is important time for me 16:15:38 sridhar: janki thank :) 16:15:47 trozet: s3wong: hi, can you give an update where we stand on this feature 16:15:49 tung_doan, welcome :) 16:16:10 sridhar_ram: hello 16:16:36 trozet: sorry, for the abrupt pull into the meeting :) 16:16:51 trozet: s3wong: trying to get a sense of what is remaining for this whole feature .. 16:16:51 sridhar_ram: it seems, we have very large patchset. it will be good if we can reduce patch size in the future 16:16:54 sridhar_ram: the plugin/ext side is almost done. Need to get the abstract driver and janki's patch through (if not already done). I then need to test the plugin with the client that was merged 16:17:09 sridhar_ram: I am doing integration of driver with trozet's plugin 16:17:12 diga: this was the preferred method 16:17:20 diga: the blame is on me, to consolidate at slightly coarse grain level 16:17:27 sridhar_ram: found some bugs (on my side), will post new patch sometime this week 16:17:29 *to ask them 16:17:33 trozet: okay 16:17:49 trozet, I have uploaded PS addressing the comments 16:17:59 sridhar_ram, s3wong: can we get the abstract driver taken care of? and janki's patch? 16:18:18 trozet: what's to take care of? merge? 16:18:19 trozet: yes, those two are definitely close to land 16:18:26 sridhar_ram, a separate error_response will be droppped by API layer. Also error_response column is not present in the client 16:18:50 s3wong: for abstract driver need your review s3wong 16:18:51 janki: understood, i was about to response.. let's skip error_reason for now 16:19:01 *respond 16:19:12 sridhar_ram, yes. I do have an idea though. we can discuss that after meeting 16:19:32 sridhar_ram, trozet: I am still the author of abstract driver, should I even +2 it :-) 16:19:44 trozet: in fact, even the plugin / db / extn side seems to have gotten enough eyeballs.. that patchset would be next (in this series) 16:19:56 s3wong: haha i don't mean you have to +2...just feedback on what I posted 16:20:02 s3wong: like is it ok or not 16:21:18 trozet: beyond the plugin / ext, abstract driver, n-sfc implementation .. what is remaining to be posted ? 16:21:59 sridhar_ram: that should be it --- it is end to end already with these 16:22:06 sridhar_ram: i need to do the real TOSCA validation of the VNFFGD 16:22:24 sridhar_ram: there are a few places where i have TODO (like validating all the VNFs are on the same VIM) 16:22:26 s3wong: trozet: yes, the TOSCA portion is critical... 16:22:45 sridhar_ram: but not too much other than testing everything together and seeing what doesnt work 16:22:46 trozet: do you need substitution_mapping support for your TOSCA needs ? 16:22:59 bobh: ^^ 16:23:07 sridhar_ram: I think we decided on ignoring that for the first pass 16:23:13 sridhar_ram: to make things less complicated 16:23:27 trozet: probably a good idea 16:23:40 trozet: sure, thats a fine approach for this first iteration 16:24:01 trozet: any help you need ? I hv some interest in VNFFG 16:24:02 i believe we need that more for NSD and NSD + VNFFGD 16:24:58 diga: I could use help testing the whole thing 16:25:04 diga: once it's ready 16:25:05 s3wong: any blockers for your n-sfc implementation ? 16:25:06 trozet: sure 16:25:18 sridhar_ram: no, other than day job :-) 16:25:29 s3wong: heh 16:25:31 s3wong: :) 16:26:02 diga: similar to what janki is doing for alarm-mon, it will be great if can team up w/ these folks to give this a spin end-to-end with all the patchsets out .. that would be awesome 16:26:24 sridhar_ram: Sure. I will 16:26:35 trozet: janki: haiwei: s3wong: sripriya: amazing tag teaming so far in executing this feature ..! 16:27:01 sridhar_ram, thanks :) 16:27:51 BTW, a talk submission on this feature is accepted for barcelona summit.. 16:27:53 #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15335/orchestrating-vnf-forwarding-graphs-and-sfc-using-opendaylight-neutron-and-tacker 16:28:13 sridhar_ram: Absolutely, will like to work with trozet & s3wong for every help they need from my side reviewing, testing etc 16:28:25 even more reason to finish this and show a kickass demo! 16:28:39 yeah diga, if you also want to review 2k lines that would be helpful ;) 16:28:56 diga: great, thanks! 16:28:57 trozet: :) 16:29:00 sridhar_ram: i'll plan on picking up and pushing new changes thursday 16:29:05 moving on.. 16:29:22 sridhar_ram: so if we can get abstract driver and vnf resources done by then, i twill reduce hte number of moving parts under me 16:29:54 trozet: Thursday sounds good 16:29:54 trozet: absolutely.. we can take care of them in a day 16:30:20 (someone else needs to give a +2 on abstract-driver) 16:30:25 s3wong: if you can review trozet's updates to your abstract driver .. we are good to go 16:30:33 thanks 16:30:44 sridhar_ram: sure --- still not appropriate to give a +2 :-) 16:31:25 s3wong: will review the patch 16:31:35 sripriya; Thanks! 16:31:39 s3wong: understood.. just leave a note to us in the irc channel 16:31:48 next, ... VNFC 16:32:01 #link https://review.openstack.org/#/c/339798/ 16:32:35 For VNFC BP, We have pushed a WIP patch already https://review.openstack.org/#/c/358321/ 16:32:50 review of spec is ongoing, 16:33:24 manikanta_tadi: we need more folks to review this... 16:33:36 mike_m: your comments are quite helpful .. 16:33:40 the tasks still left are sample templates,devref, functional tests which myself and tbh are taking up 16:33:52 bobh: did you had a chance to look at this spec ? 16:34:06 sridhar_ram: briefly - I'll take another look 16:34:40 bobh, Thanks .. 16:34:43 I'm looking for bit more consensus on where we are heading .. even if we implement just a portion of the whole thing 16:35:42 I have a concern with the VNF requirement of needing the heat api agent. 16:35:46 I do realize this is a "new" feature that seems to slide in .. we can bring this in as an "experimental" feature in newton 16:35:59 mike_m: can you elaborate pls? 16:36:30 i was wondering of a more agnostic approach for the VNF. This makes the feature very OpenStack VNF specific. 16:37:01 mike_m: couldn't agree more.. 16:37:15 sridhar_ram: mike_m me too 16:37:46 I see the cloud-init as the only viable approach in this short period of time. Couldn't that satisify the initial startup requirements? 16:38:02 mike_m: we absolutely want Tacker be a TOSCA Orchestrator engine .. for multiple VIM types (openstack, vmware, aws, etc) and for NFV and beyond (like enterprisey use-cases) 16:38:57 mike_m: we already support cloud-init in Tacker's TOSCA in the form of user-data.. 16:39:36 sridhar_ram: but user_data could easily be mapped to a different VIM without requiring specific changes to the image 16:40:07 Looking at this at a different angle, do you think the config of a VNF/VNFC might be more related to the EM interface? 16:40:21 sridhar_ram: if a VNF relies on specific Heat functionality for creation, it is pretty much tying itself to OpenStack anyway 16:40:40 bobh: you make use of the fact cloud-init is supported in different VIMs, agree but it can't support mid-life vnfc install / uninstall 16:41:10 sridhar_ram: agree, do we know of similar capabilities in other VIMs? 16:41:22 In some respects, mid-life management might be more related to em. 16:41:41 bobh: cloud-init is supported in many VIMs - definitely vmware and aws 16:42:16 sridhar_ram: was thinking about the heat-specific config resources - SoftwareDeployment/SoftwareCOnfig/etc 16:42:41 bobh: back to your question on making this heat specific, that is why i want to see this spec talk more about the VNFC changes in TOSCA and plugin and *most importantly* describe an abstract interface from plugin to infra_driver.. 16:43:12 bobh: .. it is upto the infra_driver to use any available mechanism -- cloud-init, ssh, SoftwareDeployment, etc 16:43:44 mike_m: my understanding is EM aspects comes once the VNFC s/w is in place in the target VDU.. 16:43:48 sridhar_ram: right, which I was uncomfortable with specifying the heat driver in the VNFC config 16:44:13 mike_m: but we need to get the bits in place first and that is what we need some clarity 16:44:40 bobh: agree, that part doesn't gel for me as well.. 16:44:50 agree 16:46:39 if we scope this work to describe TOSCA VNFC dom will be given to infra_driver and infra_driver will take care of honoring it (or erroring out as un-supported) would that be okay for this initial attempt? 16:47:21 plugin and TOSCA part doesn't (and shouldn't) know about SoftwareDeployement happening underneath 16:47:31 that sounds like the right approach to me 16:47:47 sridhar_ram: agree - and the TOSCA shouldn't tell the orchestrator which infra to use 16:47:56 sridhar_ram, agree, this sounds good to me too 16:48:02 bobh: mike_m: fair enough..! 16:48:26 manikanta_tadi: please incorporate these in the spec and let's see how far we can push :) 16:48:49 sridhar_ram: Sure, will make the changes accordingly 16:48:50 manikanta_tadi: continue to iterate these in your WIP patchsets 16:49:04 alright.. moving on.. 16:49:19 #topic Ocata Feature Grooming 16:49:59 I'd like to kick start Ocata feature planning in the background as we wrap up Newton 16:50:25 as usual there is going to be a etherpad .. 16:50:44 .. no surprise there, but i've left it empty this time :) 16:51:00 #link https://etherpad.openstack.org/p/tacker-ocata-grooming 16:51:40 based on the midcycle and other recent discussions .. 16:52:18 I'd like to propose a decomposed vim-infra driver framework as one of the top items for next cycle 16:52:37 sridhar_ram: I am writting one spec for new API framework implementation like we discussed last time, will submit it to ocata repo. I have done enough study on that 16:52:42 has there been more discussions regarding this one: https://blueprints.launchpad.net/tacker/+spec/em-module? Could this be added as a potential for Ocata? 16:52:58 please capture the items you think that is important for Ocata 16:53:20 diga: sure, that's great 16:53:31 mike_m: yes, that be taken up as well.. 16:53:42 sridhar_ram: yep 16:54:04 it will be also nice to come up w/ a relative priority among different items 16:54:36 capturing in the blueprint is definitely a better option 16:54:52 we can use the etherpad to socialize the idea 16:55:05 sridhar_ram: +1 16:55:43 we will obviously have few carry overs from newton.. like NSD 16:55:58 no bp yet, but vmware vim. 16:56:12 likely a long shot for now, but certainly can be discussed. 16:56:40 mike_m: sure, in fact i noticed there is a oslo.vmware .. 16:56:42 #link https://github.com/openstack/oslo.vmware 16:56:49 sridhar_ram, OSC support ? 16:56:50 something we can leverage 16:56:58 I saw that, was wondering the same. 16:57:19 manikanta_tadi: yes, but relative priority will be low IMO 16:57:25 mike_m: sridhar_ram : I think lets have seperate etherpad for vmware vim, we can list out all in detail there 16:57:34 sridhar_ram, so, can we start for ocata now? 16:57:45 ok 16:57:53 diga: yes, vmware vim will be biggee.. 16:58:21 sridhar_ram: yeah 16:58:29 dkushwaha: yes, the spec work can start.. the patchsets can merge only after stable/newton is pulled.. roughly after Sept 15th 16:58:54 dkushwaha: can you please update ur NSD patchset to ocata dir ? 16:59:06 sridhar_ram, yes sure 16:59:19 alright, let's continue to groom this Ocata list over next few meetings.. 16:59:23 time's almost up 17:00:02 use the etherpad to capture any ideas to be entertained for Ocata.. it could be features or code clean 17:00:06 thats it 17:00:10 bye folks 17:00:13 #endmeeting