08:02:43 #startmeeting tacker 08:02:45 Meeting started Tue Sep 10 08:02:43 2019 UTC and is due to finish in 60 minutes. The chair is dkushwaha. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:02:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:02:48 The meeting name has been set to 'tacker' 08:02:56 #topic Roll Call 08:03:22 Hi 08:03:59 Hi all 08:05:14 hello all 08:05:48 Hi dkushwaha 08:05:54 Hello 08:06:05 hi 08:06:57 #chair joxyuki 08:06:57 Current chairs: dkushwaha joxyuki 08:07:21 #topic announcement 08:08:20 We have to release client libs code freeze is in this week, so we needs to merge client code soon 08:09:09 #topic BP 08:09:46 tpatil, any update from ur side on VNF package? 08:09:54 dkushwaha: you have given one review comment on python-tackerclient patch: https://review.opendev.org/#/c/679956/2/tackerclient/osc/v1/vnfpkgm/vnf_package.py@54 08:10:32 as per ETSI specs, tenant_id or project_id cannot be passed in the request body when you create a VNF package 08:11:27 we are getting the project_id that is available in the tacker context and setting it during creation of vnf package in tacker-api service 08:12:27 tpatil, not sure why we can passe it. This way we may loose multi-tenancy 08:13:18 IMO, its beeter to get in as additional params 08:13:26 with tacker context, multi-tenancy will be retain 08:13:48 becoz it all works using token, when you get a token you need to specify username, password and project name 08:15:13 In tacker case, endpoint doesn't include tenant_id, but in other projects it's there. 08:15:51 tpatil, ok, lets go with current way, we needs to check it again and we may keep it as further AI 08:16:38 I will comeback soon 08:16:44 dkushwaha: Sure, Thanks 08:17:24 rest parts looks fine to me, and just reviewing https://review.opendev.org/#/c/679958/ 08:17:35 dkushwaha: let me confirm, so there is no need to add tenant_id for this release, correct? 08:18:28 tpatil, IMO we need to add it 08:18:50 but might be we can check it later 08:19:14 yea, i mean not needed in this release 08:19:37 dkushwaha: Understood, Thanks 08:20:55 joxyuki, please help to review https://review.opendev.org/#/q/topic:bp/tosca-csar-mgmt-driver+project:openstack/python-tackerclient 08:21:12 so that we can get it in soon 08:21:25 dkushwaha: Talking about tosca-parser, we have got two +2 but workflow is not yet set. 08:22:05 tpatil, yea i seen it, i will ask them to get it in 08:23:04 dkushwaha: Thanks, some of the unit tests are failing becoz it depends on the tosca-parser changes 08:23:56 #link : https://review.opendev.org/#/c/675600/ 08:25:05 #topic Open Discussion 08:26:18 tpatil, ok, lets wait to merge tosca patch. 08:27:12 I do not have other topics to discuss now 08:27:32 I have a one question:) 08:28:06 Anyway, we implement tacker-fenix integration. So we uploaded it. https://review.opendev.org/#/c/681157/ 08:28:12 as a WIP. 08:28:45 hyunsikyang, thanks for update. 08:29:01 But, I just want to ask your guys about alarm url. 08:29:03 hyunsikyang, please go ahead your question 08:29:27 we implemented it to create alarm url for each VDU. 08:30:05 At the first time, we just think that VNF maintenance happen by each VNF unit. 08:30:59 but, IMO, when we think about multi VDU in one VNF, it should manage for each VDU. 08:31:35 What your guys think about it? 08:34:25 hyunsikyang, I think maintenance work will be done at VNF level, not for a single instance but for all instances in VNF 08:35:41 hyunsikyang, caould you please explains some use cases where it needed at specific VDUs 08:35:42 ? 08:36:18 In the ETSI standard, one of the example is vEPC for VNF. 08:37:24 It means that each VDU is one of the component of vEPC. To support maintanance for each component, I think each VDU needs maintenance. 08:37:50 BUt, we also consider maintenance as a VNF level, too. 08:38:46 Other question, Do you think multi VDU deployed to different host? 08:39:22 CAN I THINK VDU AS A vnfc? 08:40:29 hyunsikyang, yes a VNF can multiple VDUs/vnfc 08:40:32 for the first question, yes. VDUs can be deployed to different host. 08:41:37 I think so. 08:43:34 hyunsikyang, As per your current spec, we needs to apply same maintenance policies for each instances in VNFs 08:44:27 what is the mean of each instance? 08:44:31 only for VNF? 08:45:13 hyunsikyang, i mean the each VDUs 08:45:59 maintenance should be true inside each VDU 08:46:03 ok 08:46:06 thanks 08:48:00 So if we also consider maintenance for VNF level, we will add that function for vnf url 08:48:12 we will think about it:) 08:48:15 thanks all 08:48:31 hyunsikyang, +1 08:49:15 hyunsikyang, JangwonLee, I will be great if you add test cases in your patch. 08:50:34 Do we have anything else to discuss? otherwise we can close this meeting 08:52:19 Thanks Folks 08:52:33 Closing this meeting 08:52:42 #endmeeting