08:01:35 #startmeeting tacker 08:01:36 Meeting started Tue Feb 25 08:01:35 2020 UTC and is due to finish in 60 minutes. The chair is dkushwaha. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:01:39 The meeting name has been set to 'tacker' 08:02:16 #topic Roll Call 08:02:23 Hello 08:02:37 Hello 08:03:11 hi 08:03:50 Hi all 08:04:19 #chair joxyuki 08:04:20 Current chairs: dkushwaha joxyuki 08:04:25 lets start.. 08:04:38 #topic Specs 08:05:31 keiko-k regarding comment on https://review.opendev.org/#/c/591866/ 08:06:01 could you give some imputes on intermediate VNF states 08:06:11 *inputs 08:07:00 Actually consumers don't have any way to check LCM operation states 08:07:36 There is related ETSI compliant API which consumers can check the status with 08:07:49 We will implement the API in next release. 08:09:11 actually my comment is not about having query api, but mentaining the statu 08:09:25 states.. 08:09:59 I wonder, how to move out if VNF stuck in some error or other states 08:11:46 If we do not have intermediate states, there is no way to find out what is going on currently 08:12:31 Right 08:13:01 joxyuki any comment on that? 08:13:58 I agree with you, dkushwaha. But, in fact, there is no such intermediate states in ETSI standard. 08:14:13 is it? 08:15:05 if so, I am ok with that. But keiko-k kindly re-verify the same. 08:15:36 I mean to re-verify from ETSI side 08:15:43 Noted. 08:15:46 no, ETSI statandard doesn't for now 08:16:12 Hi all. I am late 08:16:23 sorry, I meant ETSI standard v2.6.1. 08:16:40 please check latest version, keiko-k. 08:17:13 hi, hyunsikyang 08:17:28 hello hyunsikyang 08:18:10 joxyuki Okay 08:18:53 keiko-k, once you verify, please comment on spec. If no support in ETSI, I will merge the spec 08:19:10 @dkush 08:19:38 dkushwaha Got it. I will make a comments on spec after checking ETSI document. 08:19:53 thanks 08:20:29 Keiko-/ check my comment too. 08:20:58 hyunsikyang yes. Thanks for reviewing it. I will fix the spec and upload it. 08:21:06 Thanks 08:22:50 joxyuki, something from you? 08:23:37 thanks for your comment on https://review.opendev.org/#/c/705611/ 08:23:51 I will upload new patch soon. 08:24:47 joxyuki Thanks 08:25:17 Could you review my spec https://review.opendev.org/#/c/693121/ ? 08:26:57 keiko-k 08:27:01 keiko-k sure 08:27:22 does it have dependencies on https://review.opendev.org/#/c/591866/ ? 08:27:41 Yes 08:28:15 I see 08:30:04 keiko-k, As of now I doesn't have comments on that spec, although my approach was to go through with indirect mode ass we had discussed in PTG. But ok, I will check it again 08:32:09 I think so. align Tacker with ETIS spec is good approche. BUT, we need deep discussion for that. If we can make a long plan for it, it also good:) 08:34:24 joxyuki needs your help to review https://review.opendev.org/#/c/693121/ 08:35:15 Yes, it is in my list. 08:35:41 thanks 08:35:45 moving next.. 08:36:38 I have nothing from my side 08:37:04 I have two things. 08:37:24 BTW, Welcomeback dkushwaha 08:37:40 one is this. https://review.opendev.org/#/c/677866/ 08:37:43 hyunsikyang Thanks :) 08:37:53 this one already finished review. I hope that it will merge soon. 08:38:02 Another one is this. https://review.opendev.org/#/c/674761/ 08:39:00 Please check it! 08:39:53 hyunsikyang ok. I will review it 08:40:24 Thanks. After finish it, we will move next topic:) 08:41:24 I hope, will do it by tomorrow 08:42:06 thanks! 08:43:16 Nothing from my side anymore! 08:44:10 takahashi-tsc joxyuki do we have anything else to discuss? 08:44:39 no 08:44:47 1 from my side, https://review.opendev.org/#/c/700167/ 08:47:18 Thanks for review, everyone said all conditions should be in "condition:" block, so I'll put event_type value in the block. 08:47:53 e.g. 08:48:21 type: tosca.policies.tacker.EventAlarming triggers: vdu1_event_healing: event_type: type: tosca.events.vdu implementation: ceilometer condition: description: VM delete resource_type: instance 08:48:22 event_type: compute.instance.delete.end metadata: VDU1 action: [vdu_autoheal] 08:48:25 Oops... 08:48:46 type: tosca.policies.tacker.EventAlarming triggers: vdu1_event_healing: event_type: type: tosca.events.vdu implementation: ceilometer condition: constraint: VM delete resource_type: instance 08:48:47 event_type: compute.instance.delete.end metadata: VDU1 action: [vdu_autoheal] 08:50:34 Sorry... anyway, I put "event_type: compute.instance.delete.end" in condition: block. 08:50:42 its difficult to see the changes here, could you please share in pastbin 08:50:47 ohk 08:51:21 takahashi-tsc why to put it in condition ? 08:51:28 please see https://github.com/openstack/tacker/blob/484c05a898da0392680d2a55a3f33f4fcbacddfd/samples/tosca-templates/vnfd/tosca-vnfd-alarm-scale.yaml#L59 08:52:18 For EventAlarm, event_type is just value. 08:52:19 https://docs.openstack.org/heat/queens/template_guide/openstack.html#OS::Aodh::EventAlarm-hot 08:53:06 I think event_type is condition in this case. 08:54:25 I didn't get it, might be I am missing something here 08:57:37 In the case of MetricAlarm, we should specify threshold, aggregation_method and so on, and they are translated to Alarm properties. 08:57:45 https://docs.openstack.org/heat/queens/template_guide/openstack.html#OS::Aodh::GnocchiAggregationByResourcesAlarm-hot 08:58:16 In event case, event_type is just alarmproperties, so I think event_type should be condition in TOSCA. 08:59:50 Then, what do you plan to specify in event_type? 09:00:26 condition: 09:01:15 no, I mean, don't you use event_type? 09:01:45 time guys. 09:02:11 closeing this meeting. 09:02:11 Sorry... I write my opinion on opendev... 09:02:20 thanks. 09:02:24 takahashi-tsc thanks 09:02:54 thanks all 09:02:57 #endmeeting