08:00:15 <ifat_afek> #startmeeting vitrage
08:00:19 <openstack> Meeting started Wed Mar 14 08:00:15 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:21 <ifat_afek> Hi :-)
08:00:24 <openstack> The meeting name has been set to 'vitrage'
08:00:27 <eyalb> \o/
08:02:57 <ifat_afek> Agenda:
08:03:02 <ifat_afek> •	Status and updates
08:03:10 <ifat_afek> * Vancouver Forum Brainstorming
08:03:18 <ifat_afek> * StoryBoard Migration
08:03:26 <ifat_afek> * Open Discussion
08:03:33 <ifat_afek> #topic Status and updates
08:03:46 <ifat_afek> I’m working on the resource equivalence design, which of course relates to the alarm merge design.
08:03:52 <ifat_afek> #link https://review.openstack.org/550534
08:03:57 <ifat_afek> #link https://review.openstack.org/547931
08:05:05 <ifat_afek> The design is quite complicated… idan_hefetz and I just realized there is a problem with any design that I suggested (merge the vertex, keep all properties)
08:05:29 <ifat_afek> The problem is - what happens if the user wants to *change* the equivalence definitions? how can we un-merge the vertex?
08:06:02 <ifat_afek> And on the other direction - what if there are two alarms, Nagios and Zabbix, and the user looks and decides that they should be merged. How can we merge two already existing vertices?
08:06:46 <ifat_afek> idan_hefetz has a new idea for the design, but basically we thought that it might be easier to talk or have a webex
08:06:59 <ifat_afek> peipei: what do you think?
08:08:28 <peipei> As for merging two already existing vertices, we have not considered it yet.
08:09:17 <ifat_afek> It is a use case that we must support. We didn’t think about it either. But it is a very reasonable requirement
08:09:50 <ifat_afek> The requirement is to let the end user change his mind about the equivalence. merge or not merge - that’s the implementation details
08:11:48 <ifat_afek> The design that supports un-merge is to keep different vertices and add ‘equivalent’ edges between them. For un-merge, we will simply remove the edge. But this desing has an overhead of making the evaluator consider many more sub-graphs
08:12:59 <yujunz> In my opinion, the restrictions mainly come from the fact that we rely on the same entity graph for both for user view and internal evaluation.
08:13:31 <yujunz> User requires a simple view and internally we want detailed relationship.
08:13:40 <ifat_afek> I think that the entity graph should be used for internal evaluation. The API can return a merged/aggregated graph if needed
08:13:47 <ifat_afek> I agree
08:14:47 <ifat_afek> So how do you suggest we proceed?
08:15:39 <ifat_afek> We currently have two optional designs, neigher of them answers all use cases. And I hope we can unite them to one design.
08:15:54 <peipei> I think we can find a way to talk or a webex like you suggest.
08:16:08 <ifat_afek> Ok. Sounds good
08:16:21 <ifat_afek> Do you have a preferred time?
08:17:20 <yujunz> I have regular meeting on Monday. Other time slot are all OK.
08:17:33 <peipei> The time period like weekly meeting on a work day works, I think.
08:18:01 <ifat_afek> yujunz: Are you busy the entire Monday?
08:18:32 <yujunz> One hour meeting on UTC0730-0830
08:19:33 <ifat_afek> So are there hours that you are available? or maybe it’s evening for you?
08:19:47 <ifat_afek> (I’m getting confused by the time differences)
08:20:12 <yujunz> Evening is not so convenient. But I can attend if have to.
08:20:34 <ifat_afek> No need, just please let me know when it is convinient
08:21:25 <yujunz> Every workday before UTD0930
08:21:39 <yujunz> UTC
08:21:51 <peipei> same for me
08:22:51 <ifat_afek> yujunz: So Monday at 8:30 UTC will work for you?
08:23:09 <ifat_afek> We are not sure if we can be prepared by tomorrow, and Tuesday is less convinient for us
08:24:17 <ifat_afek> If not, then maybe we can use the next IRC meeting for this discussion only
08:24:31 <ifat_afek> And have it on webex
08:24:33 <yujunz> Monday is good for me.
08:25:01 <yujunz> And if it does not finish in one hour, we can continue on weekly meeting slot on webex
08:25:06 <ifat_afek> Ok, so it’s scheduled for Monday
08:25:20 <idan_hefetz> Cool :)
08:25:31 <ifat_afek> Sounds good. And if it doesn’t finish in one hour, it might be a good idea to take the time and think about the new ideas offline anyway
08:25:43 <ifat_afek> Do you want to have a webex, or use your zoom?
08:26:29 <yujunz> Both are OK for me.
08:27:01 <ifat_afek> We feel that the sound in zoom is better
08:27:13 <ifat_afek> But we can also schedule a webex if you prefer
08:27:20 <yujunz> OK, then I will host it on zoom next Monday
08:27:26 <ifat_afek> Great
08:27:27 <eyalb> +2
08:27:33 <ifat_afek> Let’s move on
08:27:58 <ifat_afek> One more update from me: I’m involved in the self-healing SIG. Now trying to document the Vitrage-Mistral integration
08:28:05 <ifat_afek> That’s it. Anyone else wants to update?
08:29:35 <idan_hefetz> yup
08:29:42 <idan_hefetz> I have this commit for rpc collector:
08:29:47 <idan_hefetz> https://review.openstack.org/#/c/550455/
08:29:57 <idan_hefetz> It fails miserably :( as in the gate oslo.service timers dont run, and I still fail to understand the cause.
08:30:14 <idan_hefetz> Another issue that keeps comming up in this commit is a MessagingTimeout exception during vitrage init.
08:31:18 <idan_hefetz> I hope to solve this soon so if anyone here has any suggestions... so i can move on to the next step of high availability - graph init from database.
08:32:01 <idan_hefetz> That's me..
08:32:23 <ifat_afek> Thanks. Anyone else wants to update?
08:34:08 <ifat_afek> #topic Vancouver Forum Brainstorming
08:34:17 <ifat_afek> We have an option to submit a proposal for a forum discussion in Vancouver
08:34:25 <ifat_afek> \This is similar, I think, to a design session, but is more focused on users, high level and community wide issues. More details can be found here:
08:34:31 <ifat_afek> #link http://lists.openstack.org/pipermail/openstack-dev/2018-March/127944.htmlx
08:34:36 <ifat_afek> #link https://wiki.openstack.org/wiki/Forum/Vancouver2018
08:34:40 <ifat_afek> #link https://wiki.openstack.org/wiki/Forum
08:34:47 <ifat_afek> If you have ideas for a forum discussion, please add them to the following etherpad:
08:34:51 <ifat_afek> #link https://etherpad.openstack.org/p/YVR-vitrage-brainstorming
08:36:38 <ifat_afek> #topic StoryBoard Migration
08:37:11 <ifat_afek> I checked the StoryBoard a bit. In general, StoryBoard is planned to replace Launchpad. In practice, most projects are not there yet.
08:37:20 <ifat_afek> I got a personal email asking to migrate Vitrage to StoryBoard. I believe that this is an automatic process that requires from us a minimal effort.
08:37:27 <ifat_afek> So what is StoryBoard? It is developed as an OpenStack project, and looks like modern story tracking projects. For example, you can look at the self-healing board:
08:37:31 <ifat_afek> #link https://storyboard.openstack.org/#!/board/57
08:37:35 <ifat_afek> #link https://storyboard.openstack.org/#!/story/2001430
08:37:41 <ifat_afek> The advantages that I see are that the status and the progress is more clear.
08:37:58 <ifat_afek> The disadvantages are, IMO – first that there is currently no way to mark a story/task as related to a certain release. And second, that bugs are handled as regular stories. This was done on purpose, to help in cases where it is not clear if something is a bug or a feature; but personally I find it confusing.
08:38:05 <ifat_afek> If you have any comments, objections, whatever, let me know before I progress with the migration.
08:39:43 <ifat_afek> #topic Open Discussion
08:39:51 <ifat_afek> Any other issue you want to discuss?
08:41:25 <ifat_afek> Bye then, see you on Monday
08:41:46 <yujunz> bye
08:41:47 <annarez> bye see you :)
08:41:59 <ifat_afek> #endmeeting