16:03:05 #startmeeting tacker 16:03:07 Meeting started Tue Jun 28 16:03:05 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:03:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:10 The meeting name has been set to 'tacker' 16:03:22 #topic Roll Call 16:03:30 hi 16:03:32 who is here ? 16:03:38 o/ 16:03:41 o/ 16:03:41 o/ 16:03:50 o/ 16:03:57 o/ 16:03:58 hi all 16:04:13 hello all ! 16:04:25 o/ 16:04:26 let's start.. 16:04:31 #topic Agenda 16:04:44 #link https://wiki.openstack.org/wiki/Meetings/Tacker 16:05:33 Also, given tung_doan is here i would like to get few words from his side on alarm-monitor 16:05:51 sridhar_ram: ok 16:05:51 #topic Annoucements 16:06:38 #info Tacker client version 0.4.0 (newton) is released 16:06:41 #link http://lists.openstack.org/pipermail/openstack-announce/2016-June/001259.html 16:07:05 We have been making regular releases off stable branches. This is the first time we are starting to make a tackerclient release off master. 16:07:22 nice ! 16:07:30 will add tackerclient to global-requirements for us and other projects (like Mistral) to use 16:07:51 FYI, https://review.openstack.org/#/c/334641/ 16:07:54 cool! 16:07:55 KanagarajM: thanks! 16:07:59 cool 16:08:07 yes, finally! 16:08:44 OpenStack Barcelona Summit talk submission deadline is fast approaching 16:09:11 You folks should try to put a good set of submissions on Tacker! 16:09:21 s/a/a lot of/ 16:09:36 sridhar_ram, i'm thinking of the Scaling could be nice topic :) 16:09:50 with alarm in place 16:09:50 KanagarajM: of course ! 16:09:55 JULY 13, 2016 AT 11:59PM PDT (JULY 14 6:59 UTC) IS THE DEADLINE TO SUBMIT A TALK 16:10:20 Please watchout for local UTC time... and don't make it last minute :) 16:10:30 KanagarajM: scaling + monitoring is impossible? I try to do it 16:10:33 moving on... 16:10:56 #topic OPNFV Summit Update 16:11:16 Videos are available at Videos - https://www.youtube.com/channel/UC3EjXLJbub0tPFpnI3vEmYg 16:11:34 Tacker design summit session is available at https://www.youtube.com/watch?v=DSaQth_nJHI 16:12:00 In short, lot of NFV MANO discussions and sessions.. 16:12:17 Open-O, OpenBaton and Tacker was discussed quite a bit 16:12:56 Two demos using Tacker + VNFFFG where shown in the demo floor 16:13:09 Kudos to trozet efforts !! 16:13:26 thanks :) 16:13:35 +1 16:13:38 +1 16:13:40 great job trozet! 16:13:41 good to see the tacker values :) 16:13:53 we also need to engage more with various OPNFV Projects 16:14:21 FuncTest is of immediate importance... we need Tacker tests running in OPNFV Scenario testbed 16:14:31 sridhar_ram: sorry late 16:14:55 We also have an oppurtunities to engage with lots of other projects like VNF Event Stream (VES), Domino, ... 16:15:05 bobh: howdy! we are just warming up 16:15:20 There is also a main Tacker talk session, still waiting for the youtube link... 16:15:25 will pass it onto the team... 16:15:29 when i get it 16:15:54 meanwhile, if some you want to work on Tacker on the OPNFV project do let me know.. i will connect you with the right people 16:16:02 *some of you 16:16:17 any questions ? 16:16:33 moving on.. 16:16:46 #topic Alarm-Monitoring 16:17:02 * sridhar_ram apologizes for the slight change in agenda order 16:17:15 tung_doan: can you please give an update where this spec stands ? 16:17:37 reviewers of alarm-spec : please pitch in :) 16:18:05 sridhar_ram: I already updated spec last week: https://review.openstack.org/#/c/306562/14/specs/newton/alarm-based-monitoring-driver.rst 16:19:09 sridhar_ram: i wtill wait for reviewers. Also, I updated CLI cmmand in L146. Let see. 16:19:48 tung_doan: one area i've some concern is, this spec refers to some scaling related things.. wouldn't that be an overlap with what is in the scaling spec ? 16:20:24 sridhar_ram: absolutely not. 16:20:56 ah, perhaps i was looking at an older version.. my bad 16:21:12 alright, cool then.. 16:21:30 sridhar_ram: IMO, scaling will be done once triggers sent by Ceilometer. it totally different scenario 16:21:48 bobh: as usual i'm going to bug you to review this :) 16:21:58 tung_doan: perfect! 16:22:03 sridhar_ram: currently, I am going with this 16:22:20 sridhar_ram: I figured :-) 16:22:34 tung_doan: what happens after an alarm from ceilometer is totally upto what is specified in the TOSCA template.. 16:23:02 tung_doan: .. at some point in the future an action might involving sending an SMS - who knows 16:23:22 *involve 16:23:34 tung_doan: thanks for the update 16:23:40 sridhar_ram: regrading to notification like SMS, I already think about it 16:23:59 tung_doan: ha, ha.. that is not futuristic enough :) 16:24:12 tung_doan: will you be creating a new abstract driver for the alarm framework? 16:24:45 sridhar_ram: right 16:25:56 tung_doan: did u catch srirpriya's questions ? 16:26:31 sridhar_ram: what question? sridhar :) 16:26:54 nevermind, let's take it to #tacker after the meeting 16:27:02 need to get back to the rest of the agenda 16:27:07 tung_doan: thanks for the update.. 16:27:22 i hope we can land alarm and scaling spec soon 16:27:27 and move on to code-reviews 16:27:38 sridhar_ram: please take some minitues to review my specs.. Thanks 16:28:03 tung_doan: bobh is on it ;-) 16:28:15 #topic VNFFG --> VNFM --> networking-sfc interaction 16:28:36 s3wong: trozet: that was a good discussion in the channel on this topic.. 16:28:48 I've capture this based on that... 16:29:00 #link http://paste.openstack.org/show/523666/ 16:29:36 FYI, for the folks interested in the VNF-FFG workflow... please take a look at the ^^ diagram 16:29:56 trozet: s3wong: does this flow sounds about right ? 16:30:23 sridhar_ram: looks good 16:30:40 what is the vnffg abstract driver? 16:30:52 oh nvm 16:30:53 trozet: abstract class for all drivers 16:30:55 i forgot about hte new driver 16:31:07 trozet: common interface for all drivers 16:31:16 shouldnt VNFM also have an abstract driver? 16:31:31 looks reasonable ! also should we look to typing the descriptor in the catalog http://paste.openstack.org/show/523666/ 16:32:20 typo ^^ https://review.openstack.org/#/c/333216/1/tacker/extensions/nfvo.py 16:32:23 trozet: it really should :-) 16:32:38 trozet: i didn't get the question.. we do have abstract infra drivers.. https://github.com/openstack/tacker/blob/master/tacker/vm/infra_drivers/abstract_driver.py 16:33:11 maybe the diagram just doesn't show it 16:33:18 sridhar_ram: I think trozet was talking about the diagram 16:34:30 s3wong: trozet: do you mean a VNFM abstract driver for NFVO to call ? 16:34:32 trozet: are you referring to the heat infra_driver? 16:34:42 * sridhar_ram is still puzzled 16:34:54 there is just a direct line from VNFM to heat 16:35:13 i would htink there would be abstraction there, since there is abstraction between VNFFG to it's VIM type 16:35:18 sridhar_ram: in the diagram, between VNFM plugin and Heat infra driver, there should be an infra abstract driver layer 16:35:21 i don't mean to hold up the meeting 16:35:56 trozet: ah, yes, indeed.. there is an infra abstract driver as i poiinted out earlier 16:36:06 trozet: no worries... 16:36:26 trozet: you never know where some wrong assumptions 16:36:55 trozet: s3wong: i'd like to get some clarity on this get_vnf_details() ... 16:36:57 sridhar_ram: s3wong: trozet: are we introducing a new abstract driver for vnffg or will it merge with existing abstract_vim_driver? 16:37:39 sripriya: probably new, as the driver is specific to VNFFG 16:37:46 sridhar_ram: yes 16:37:48 sripriya: i'm not sure yet because I haven't looked at the VIM driver 16:37:55 sripriya: i'd suggest we leave this separate and no tie w/ abstract_vim_driver 16:38:13 s3wong: sridhar_ram: ok 16:38:46 get_vnf_details() in this flow, it should be any special for VNFFG .. i think it should be a generic enhancement 16:39:21 +1 16:39:21 GET /vnfs/ with some flag indicating "details" should return more information about the VNF 16:39:49 sridhar_ram: +1 16:39:50 all the heat resources created for the VNF - VDUs, CPs, 16:40:07 trozet: what do you think ? 16:40:35 sridhar_ram, +1 it would be nice enhancement. 16:40:37 can we make that a generic enhancement and VNFFG patchsets will have dependecny on that 16:40:59 * sridhar_ram my typing malaise is back :( 16:41:09 sridhar_ram: something like GET /vnfs/uuid/detail .. 16:41:17 sridhar_ram: I think it should be generic, and return VNFD logical mapping names to VNFD instance components 16:42:05 sripriya: that would work, or even a flag in the json request body.. no hard opinion here 16:42:37 sridhar_ram: who is going to implement the API? :-) 16:42:44 sridhar_ram: sure 16:42:46 trozet: sounds good.. we can use this to do 'tacker vnf-show --details ' 16:43:39 trozet: do you have some code already in place to get such vnf-details ? 16:43:51 trozet: do you need some help from the community on this peice 16:43:53 ? 16:44:05 sridhar_ram: no code. If someone wants to implement that it would be helpful 16:44:40 any volunteers ? 16:44:48 janki_: i remember you were interested in pitching in for VNFFG .. is this something you can help ? 16:45:12 sridhar_ram: sure, was just typing that only 16:45:28 janki_: cool, thanks... 16:45:32 :) 16:45:48 janki_: please keep in mind this will be blocking dependency for trozet 16:46:04 janki_: so, keep trozet happy :) 16:46:07 Ok, will get right to it 16:46:20 janki_: thanks! 16:46:43 i hope that diagram can be used in some vnffg-defref 16:47:02 s3wong: trozet: janki_ : thanks! 16:47:05 moving on.. 16:47:17 janki_: thanks! 16:47:23 #topic Grooming Midcycle Meetup topics 16:47:26 sridhar_ram, should we start to typing the descriptor in the catalog, seems it got missed over the discussions :) 16:47:39 #undo 16:47:40 Removing item from minutes: 16:47:48 * sridhar_ram oops 16:47:55 s3wong: my pleasure 16:48:01 #topic VNFFG 16:48:20 KanagarajM: can you please elaborate ? 16:49:10 sridhar_ram, we now bring anothe descriptor for the VNFFGD. 16:49:29 KanagarajM: yes, that's correct 16:49:39 sridhar_ram, so instead of modelling it as new resource in REST, should be update the existing VNFD to be generic enough to hold the all kind of descriptor 16:50:20 KanagarajM: no, VNFD is for VNFs... VNFFGD descriptor flows covering multiple VNFs.. 16:50:30 KanagarajM: they don't logically map 16:50:48 sridhar_ram, i am not telling to directly on the VNFD, 16:51:40 sridhar_ram, instead make a VNFD as generic enough to hold VNFD, VNFFGD 16:52:29 hmm... VNFFGD is actually close to NSD descriptor than VNFD 16:53:08 I say we keep the descriptors separate 16:53:19 a single descriptor would be long 16:53:25 these descriptors are something we are preserving from ETSI architecture... i don't think we should overload VNFD to also include FFGD.. 16:53:29 it might become difficult for new comers to grap it 16:53:37 the later refers to multiple VNFs 16:53:43 given almost similar short forms for the terms 16:53:49 sridhar_ram, by using another attributed called 'type' this would make catalog simple 16:53:49 https://review.openstack.org/#/c/333216/1/tacker/extensions/nfvo.py i tried to comment the same 16:54:09 sridhar_ram, no... some thing like as below 16:54:43 KanagarajM: sure.. we need to take up the topic of "NFV Catalog" evolution as a topic in our midcycle meetup 16:54:57 sridhar_ram, sure. 16:55:09 lets take this offline in the channel.. or continue in the next week's call.. 16:55:26 sridhar_ram, yeah. 16:55:49 #topic Midcycle Meetup 16:55:58 #link https://etherpad.openstack.org/p/tacker-newton-midcycle 16:56:13 Please enter your topics of interest.. 16:57:10 Also, please respond to the following Doodle poll to pick a date in the last weekl of July.. 16:57:24 picking a time will be a challenge 16:58:01 i've suggested a time that seems equally painful for everyone (ex US east coast) 16:58:17 please pick upto 2 slots 16:59:08 if you have other time slots in mind or if this suggested slot doesn't work.. please give a shout out.. 16:59:23 #topic Open Discussion 16:59:34 thanks everyone for joining today... 16:59:48 that all the time we have 16:59:56 bye 17:00:06 bye 17:00:08 bye 17:00:14 #endmeeting