08:01:09 #startmeeting vitrage 08:01:10 Meeting started Wed Sep 21 08:01:09 2016 UTC and is due to finish in 60 minutes. The chair is ifat_afek. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:01:13 The meeting name has been set to 'vitrage_' 08:01:14 hi everyone :-) 08:01:20 Hi 08:01:56 hi 08:02:59 hi guys 08:03:07 Hi all! 08:05:38 #topic Status and Updates 08:05:59 Newton release schedule: As vitrage release mode in Ocata is cycle-with-intermediary, we have time until Sunday to release our final version for Newton 08:06:11 I plan to do it tomorrow, and then ask to create stable/newton branch for vitrage projects. 08:06:19 The final release is scheduled for October 6. 08:06:35 In addition, I started checking our documentation. I submitted a change for adding vitrage developer guide documents under http://docs.openstack.org/developer/vitrage 08:06:46 . I also want to check why vitrage bliueprints are not displayed nicely in https://specs.openstack.org/openstack/vitrage-specs/ 08:07:04 Who has other updates? 08:07:15 I do 08:09:06 I would like to raise some thoughts and new directions regarding the entity graph horizon display, and as a result also the API support 08:09:55 Currently, this screen shows the entire entity graph, regardless of size, complexity etc. As a result, for complex graphs, it is difficult to "find your way" within this graph 08:11:07 This can be tackled in two ways. The first is to use smart graph layout, which will organize the graph in a more visually-appealing manner. For example, clustering vertices by type, hierarchies etc. 08:11:45 However, this approach will eventually run into difficulties as well - with large setups, this could still be TMI. 08:12:42 Instead, I think we should take the second approach: to present portions of the graph, allowing the user to select what types of resources/entities will be displayed 08:13:48 For example, if the user selects a Heat stack, he would see the entity graph portion consisting of all the stack resources, alarms on these, and (possibly) the physical hosts of these virtual resources 08:14:15 selecting a different resource would show the "relevant" info for that resource 08:14:35 elisha_r: interesting. so we will have a predefined set of portions? 08:14:46 This, as a business-logic approach seems right to me. 08:15:03 ifat_afek: good point, I've given that some thought as well 08:16:07 For starters, we could of course have some "static" predefined scope. For example, showing everything within a few hops from the initial resource. This would not make sense "business wise", but it would still give a clearer picture of the system than what we have today 08:16:34 because it would show a smaller graph? 08:16:44 Exactly. 08:17:19 But the real solution IMO is to build for each resource a template, just like the vitrage templates we have now, and treat this issue using subgraph matching (with some slight changes). 08:17:36 cool, I like this idea 08:17:46 but it won’t be trivial to define or implement 08:19:42 Not so sure. To me it seems pretty straight forward. We would start of course with built-in templates. For example, you could build a structure like: stack-->instance-->host. When a user requests the heat stack entity graph, we would run subgraph matching as is starting from this stack in the graph, and it will return all the subgraphs of that structure. Then we only need to merge the graphs (simple union of sets), and w 08:20:22 so you mean the api for get topology will accept a yaml file as an input? 08:21:22 this could work 08:21:33 There is one difference from what we have in our current template matching - vitrage conditions need to match EXACTLY, whereas here we want also SUB-MATCHES of this structure. But knowing the code, I think it's a simple extension of what we have 08:21:55 right 08:22:36 For starters these will be in a folder, just like the vitrage templates are today, and would be added/removed manually. In the future we could allow crud, selection of policies etc - just like we plan to do with the current templates. 08:22:52 cool 08:23:13 I suggest we have a blueprint, and/or discuss it in the design session in Barcelona 08:23:40 One last thing - I still think that having a view where we see everything is important. This view will function as a "heat-map", to detect problems or problematic "areas 08:23:44 " 08:24:01 but perhaps there we need a different type of view. 08:24:34 Anyhow, yes, lets discuss it in Barcelona. Can we set up a BP with the intent of discussing it there? 08:24:40 I completely agree 08:24:48 sure 08:25:19 #topic Preparations for Barcelona 08:25:35 I know that elisha_r, eyalb and myself are going to Barcelona. Anyone else? 08:25:46 OpenStack published the suggested schedule for the design sessions: 08:25:54 #link https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458&single=true 08:26:08 I asked to move one of our Friday sessions to another day, and agreed to liberate the other one, so in total we will have three – one fishbowl session (in a bigger room) and two work rooms 08:26:34 I created a new etherpad for planning the design sessions, please add your ideas: 08:26:42 #link https://etherpad.openstack.org/p/vitrage-barcelona-design-sessions 08:29:46 elisha_r and myself submitted two “brown bag” talk proposals. These are 10-minutes talks in smaller rooms than the regular sessions. We are waiting for the response. 08:29:59 #topic Open Discussion 08:30:08 anything else? 08:33:20 goodbye then 08:33:27 bye 08:34:13 #endmeeting