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