08:00:13 <ifat_afek> #startmeeting vitrage 08:00:14 <openstack> Meeting started Wed Mar 21 08:00:13 2018 UTC and is due to finish in 60 minutes. The chair is ifat_afek. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:00:17 <openstack> The meeting name has been set to 'vitrage' 08:00:18 <ifat_afek> Hi :-) 08:01:04 <annarez> Hi :) 08:01:06 <Idan_Kinory> Hi 08:01:06 <Liat> Hi 08:01:54 <yujunz> hi 08:01:54 <nivo> hey 08:02:43 <eyalb> \o/ 08:03:44 <ifat_afek> First update: I would like to nominate dwj to a Vitrage core contributor :-) I will send an email to OpenStack mailing list later today 08:03:52 <eyalb> +2 08:04:00 <yujunz> +2 08:04:12 <annarez> congratulations!! 08:04:25 <dwj> Thanks~ 08:04:56 <ifat_afek> Welcome :-) 08:05:01 <Idan_Kinory> congratulations :) 08:05:06 <ifat_afek> Next - we have continued the equivalence/merge alarm and resource design. 08:05:13 <ifat_afek> #link https://review.openstack.org/550534 08:05:19 <ifat_afek> #link https://review.openstack.org/547931 08:05:27 <ifat_afek> yujunz, dwj: any update on your side? 08:05:42 <dwj> No 08:05:42 <ifat_afek> and peipei of course :-) 08:05:55 <ifat_afek> So how do we continue? 08:06:16 <yujunz> I discussed about the topic with peipei and want to clarify a few things. 08:06:26 <ifat_afek> OK 08:07:23 <yujunz> Firstly the use case for us is mainly the merge of reported and monitored alarm. 08:07:42 <yujunz> Sorry reported and deduced 08:08:43 <yujunz> Since we are actually deducing an alarm which should be reported. So the there is less conflict in properties than two distinct data sources. 08:09:09 <ifat_afek> Makes sense 08:11:04 <yujunz> So I wonder if you have the use case for two different alarm data sources like nagios and zabbix at the same time or currently what you are facing is mainly the resource equivalent 08:11:23 <ifat_afek> Not now, but we might have this use case in the future 08:11:41 <ifat_afek> We are not working on Prometheus datasource, and we might add Grafana, that will also include Prometheus alarms 08:12:01 <yujunz> not or now? :-) 08:12:27 <ifat_afek> now :-) 08:13:01 <peipei> so the use case that two monitored alarms are equivalent should be supported any how,right? 08:14:12 <ifat_afek> We won’t need it in Rocky, but we will probably need it some time in the future (within a year maybe), and then we don’t want to have two different mechanisms 08:14:53 <yujunz> You mean two mechanism for resource and alarm? 08:14:57 <ifat_afek> For resource merge, we can handle k8s datasource without it, since it knows exactly the Nova datasource properties 08:15:12 <ifat_afek> I mean two mechanisms for deduced and complete merge 08:15:36 <ifat_afek> Because if I understand you correctly, you are saying that maybe we could have a smaller refactoring now that will only solve your use case 08:15:56 <ifat_afek> I agree that it might be easier, the question is what we will do in the future 08:16:07 <ifat_afek> Will you ever need the full merge functionality? 08:16:11 <ifat_afek> In ZTE? 08:18:35 <peipei> We have discussed that maybe we can use equivalence for resource, and merge for alarm. 08:19:08 <ifat_afek> Another future use case is merge of Vitrage discovery agent and Nova, but this won’t happen in Rocky either 08:19:22 <ifat_afek> And we don’t know the details yet 08:19:35 <ifat_afek> peipei: why? 08:20:17 <peipei> Because equivalence for alarm will be complex。 08:20:42 <ifat_afek> Also for resources, right?… 08:21:50 <peipei> If we support bidirectional deduce, maybe number of scenarios will rise by exponential... 08:22:17 <ifat_afek> So you don’t want to duplicate the scenarios, that’s the main motivation? 08:22:29 <ifat_afek> I would say it’s not complex, but it has a performance issue 08:23:47 <ifat_afek> But in order to not-duplicate scenarios, I believe we need the merge option that I suggested, where we keep all properties all all datasources 08:24:06 <ifat_afek> Or do you want to make a special handling without it, just because it is Vitrage and not two external monitors? 08:25:15 <yujunz> Are you talking about merge option #2 ? 08:26:05 <ifat_afek> I think so 08:26:18 <ifat_afek> Unless we find a way for option #1 without scenario duplication 08:27:56 <peipei> You mean overwrite in merge option #1? 08:28:29 <peipei> or equivalence option? 08:28:52 <ifat_afek> I mean overwrite merge option #1 08:28:59 <ifat_afek> I understood that you don’t want equivalence 08:29:56 <ifat_afek> BTW, we didn’t discuss it in the last meeting, but - are you sure that you won’t reach an endless loop in the bi-directional templates? 08:30:24 <annarez> peipei why is scenario duplication in the case of bidirectional deduce will be exponential? 08:33:10 <peipei> In the template A OR B -> C, and zabbix A ~ nagios A, and zabbix B~ nagios B, 4 scenarios will be matched. 08:33:44 <ifat_afek> So this is not related to bidirectional deduction, right? 08:34:07 <peipei> Yes. 08:34:59 <peipei> I mean if in bi-diretional, number of nodes and edged both rise fastly 08:35:02 <ifat_afek> So this is the performance problem we discussed. The question is how many such equivalences you expect to have 08:36:05 <ifat_afek> Regarding bidirectional: you will have C -> suspect V 08:36:17 <ifat_afek> So this will not be duplicatied 08:36:26 <ifat_afek> V for Vitrage :-) 08:37:53 <ifat_afek> BTW, it is important to note that in your example we WON’T execute four scenarios. There will be a single trigger, say zabbix A. So we will only execute scenarios related to Zabbix A, and there will be two of them. The Nagios A scenarios will be ignored at this stage 08:38:33 <ifat_afek> And again, what matters is how many duplicated scenarios you expect to have 08:40:46 <yujunz> I think performance is just one side of concerns. There is a complexity issue in the deducing model. 08:41:30 <ifat_afek> What do you mean? 08:41:45 <yujunz> With equivalent entities in the graph, it is no longer a tree, but probably a a mesh. 08:42:18 <ifat_afek> It hasn’t been a tree for a long time :-) with RCA and ‘causes’ edges 08:42:23 <ifat_afek> And Heat stacks 08:42:27 <ifat_afek> But I understand what you mean 08:43:11 <ifat_afek> But why does it matter so much? the sub-graph matching algorithm should work as before 08:45:03 <peipei> I wonder whether duplicated scenarios will lower performance of sub-graph matching algorithm? 08:46:25 <ifat_afek> Can I ask something? why is it actually so important to create a suspect alarm? why not write a template like ‘ if C and not A then run diagnose action’? without having an intermediate suspect vertex? 08:47:04 <ifat_afek> Why do you think that duplicated scenarios will have lower performance? it only means that we will execute more scenarios 08:48:11 <ifat_afek> We should chose one of two solutions: 1. IMO is more robust, but with a performance penalty 2. Better performance, but very complex implementation 08:48:14 <ifat_afek> That’s how I see it 08:50:05 <peipei> Ok, and merge option #2 may be more complex to implement. 08:50:46 <peipei> And I can send a more detailed design about merge option lator by mail. 08:51:01 <ifat_afek> What option are you talking about? 08:51:11 <ifat_afek> I meant 1. equivalence and 2. merge option #2 08:51:12 <peipei> merge option #2 08:51:28 <ifat_afek> Regarding merge option #1 - I think it still requires scenario duplication 08:51:48 <ifat_afek> Ok 08:53:06 <ifat_afek> Two unrelated quick updates, before we end the meeting 08:53:19 <ifat_afek> #topic Vancouver summit 08:53:38 <ifat_afek> We are going to have many Vitrage sessions in Vancouver :-) 08:54:04 <yujunz> How many? I got 1/3 :-) 08:54:30 <ifat_afek> #link https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=vitrage 08:54:40 <ifat_afek> 7 total, one of them by WindRiver 08:54:51 <ifat_afek> About the alarm banner that they implemented 08:55:11 <ifat_afek> Not all of them are *about* Vitrage, but they will mention Vitrage 08:56:22 <ifat_afek> Next, we can ask for a forum discussion. We need to think if there is an issue we would like to discuss 08:56:28 <ifat_afek> #link http://lists.openstack.org/pipermail/openstack-dev/2018-March/127944.htmlx 08:56:33 <ifat_afek> #link https://wiki.openstack.org/wiki/Forum/Vancouver2018 08:56:38 <ifat_afek> #link https://wiki.openstack.org/wiki/Forum 08:56:51 <ifat_afek> I created an etherpad, at the moment it is empty 08:56:57 <ifat_afek> #link https://etherpad.openstack.org/p/YVR-vitrage-brainstorming 08:57:42 <ifat_afek> And last issue: StoryBoard migration. annarez and I checked it and we have a few unclear issues. We emailed OpenStack representative and got no response yet. So for now it is on hold 08:57:51 <ifat_afek> Anything else? we have 3 minutes left 08:59:13 <ifat_afek> Bye, see you next week :-) 08:59:16 <yujunz> Bye 08:59:19 <eyalb> bye 08:59:24 <annarez> bye 08:59:25 <dwj> Bye 08:59:26 <Liat> by 08:59:34 <Liat> bye 09:00:01 <ifat_afek> #endmeeting