08:05:45 #startmeeting tacker 08:05:46 Meeting started Tue Nov 19 08:05:45 2019 UTC and is due to finish in 60 minutes. The chair is dkushwaha. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:05:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:05:50 The meeting name has been set to 'tacker' 08:05:56 #topic Roll Call 08:06:00 Hi 08:07:03 hello keiko-k 08:07:17 Hello 08:07:30 hi 08:08:33 hi all 08:08:38 lets start.. 08:08:46 #chair joxyuki 08:08:47 Current chairs: dkushwaha joxyuki 08:09:05 #topic BP 08:09:43 I could not have community work after summit, and started today 08:10:17 keiko-k, I have posted some comments on your spec 08:10:29 #link https://review.opendev.org/#/c/591866 08:11:00 Thanks. I will check it later 08:12:13 Main challenge i see is regarding introducing image create in vnfm side 08:13:55 dkushwaha: Heat doesn't support creation of image using file that's present in the CSAR 08:14:13 so we are planning to use openstacksdk in tacker to create images 08:15:03 Heat only allows to create image using web-download method, no support for glance-direct. 08:16:36 tpatil, yo mean, we needs glance driver ? 08:16:37 Also when the VNF will be terminated, tacker will need to delete those images created for a deployment flavor. 08:17:33 tpatil, +1 08:17:35 openstacksdk connection to call glance image create aPI to create image from file. 08:18:26 instead of using glance-client, I think using openstacksdk would help to interact with many other cross services including heat client. 08:19:54 ok 08:20:04 tpatil, I agree to delete those created image, but I think this responsibilities(create/delete image) should not be at VNFM level. 08:20:40 dkushwaha, ideally yes. 08:21:43 so I think we should move that functionality to NFVO fron VNFM after V release 08:22:11 sorry, after V release -> V release or after 08:22:31 joxyuki: agree, as in U release, we are not planning to make any changes to the NFVO 08:25:51 ok, so lets make approach like: introduce an infra driver for glance api, that will be called as in pre_vnf_instantiation, and post_termination to create and delete those images 08:26:28 and in future we will move tose calls to NFVO side 08:26:49 joxyuki, tpatil wdyt ? 08:27:20 dkushwaha: why infra driver? IMO, a new method in existing openstack driver would also do the same job. 08:29:31 tpatil, we should have abstraction layer of openstack VIM and kubernetes VIM. 08:30:21 to create image, we will need VIM and it could be openstack or kubernetes. 08:30:37 joxyuki, +1, tpatil, my opinion is to not to mix image task with vnf instantiation 08:32:35 and it will reduce future refactoring tasks 08:32:59 tpatil, yes. So we should have a rapper to abstract interfaces of openstack glance and k8s image management(I am not sure). 08:34:54 ok, so no need to add image creation interface to VnfAbstractDriver, but create a new one which VNFM will instantiate for now, and later it will be instantiate by NFVO, correct? 08:38:19 almost yes, if you mean "instantiate" -> "image create". 08:38:46 joxyuki: Yes 08:40:56 tpatil, yes, Ex. it is like heat_client in infra_driver, and will be called in some pre_vnf_instantiation to create image 08:42:12 dkushwaha: Yes, it's clear now 08:43:19 anything else from anyone 08:43:21 ? 08:44:22 #topic OpenDiscussion 08:45:14 We have a nice group pic from PTG https://www.dropbox.com/sh/1my6wdtuc1hf58o/AACU49pjWxzFNzcZJgjLG8n1a?dl=0&preview=Tacker.JPG 08:46:48 yeah! I included it in my summit & PTG report. 08:47:41 Do we have anything else? otherwise we can close this meeting 08:47:53 Nice photo!!! 08:48:02 About Event alarm support, 08:48:45 First I checked zabbix plugin, but it support only command in VNF, so it is not suit our requirement... 08:49:58 I'd like to know if event_alarm is supported. Is there any good approach to confirm it? 08:52:09 takahashi-tsc, I needs to check, will notify you 08:54:32 Thanks, if you give us an just overview, we will investigate the details. 08:55:11 takahashi-tsc, see https://review.opendev.org/#/c/561840/11/specs/stein/reservation-vnfm.rst line264 08:55:45 we are using OS::Aodh::EventAlarm when handling reservation notification. 08:56:45 I think this does not meet your requirements but just information. 08:57:23 Thank you. Is this using EventAlarm for a specific purpose? i.e. we requires another feature to use EventAlarm directly 08:57:37 anyway, I'll check the above, thanks! 08:58:25 yes, this is only for reservation handling, we cannot use it for general alarming. 08:59:13 OK, I got it. 08:59:59 Thanks all. time up.. 09:00:10 closing this meeting 09:00:20 #endmeeting