08:01:09 <ifat_afek> #startmeeting vitrage
08:01:10 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:13 <openstack> The meeting name has been set to 'vitrage_'
08:01:14 <ifat_afek> hi everyone :-)
08:01:20 <elisha_r> Hi
08:01:56 <eyalb> hi
08:02:59 <danoffek> hi guys
08:03:07 <idan_hefetz> Hi all!
08:05:38 <ifat_afek> #topic Status and Updates
08:05:59 <ifat_afek> 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 <ifat_afek> I plan to do it tomorrow, and then ask to create stable/newton branch for vitrage projects.
08:06:19 <ifat_afek> The final release is scheduled for October 6.
08:06:35 <ifat_afek> 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 <ifat_afek> . I also want to check why vitrage bliueprints are not displayed nicely in https://specs.openstack.org/openstack/vitrage-specs/
08:07:04 <ifat_afek> Who has other updates?
08:07:15 <elisha_r> I do
08:09:06 <elisha_r> 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 <elisha_r> 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 <elisha_r> 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 <elisha_r> However, this approach will eventually run into difficulties as well - with large setups, this could still be TMI.
08:12:42 <elisha_r> 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 <elisha_r> 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 <elisha_r> selecting a different resource would show the "relevant" info for that resource
08:14:35 <ifat_afek> elisha_r: interesting. so we will have a predefined set of portions?
08:14:46 <elisha_r> This, as a business-logic approach seems right to me.
08:15:03 <elisha_r> ifat_afek: good point, I've given that some thought as well
08:16:07 <elisha_r> 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 <ifat_afek> because it would show a smaller graph?
08:16:44 <elisha_r> Exactly.
08:17:19 <elisha_r> 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 <ifat_afek> cool, I like this idea
08:17:46 <ifat_afek> but it won’t be trivial to define or implement
08:19:42 <elisha_r> 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 <ifat_afek> so you mean the api for get topology will accept a yaml file as an input?
08:21:22 <ifat_afek> this could work
08:21:33 <elisha_r> 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 <ifat_afek> right
08:22:36 <elisha_r> 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 <ifat_afek> cool
08:23:13 <ifat_afek> I suggest we have a blueprint, and/or discuss it in the design session in Barcelona
08:23:40 <elisha_r> 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 <elisha_r> "
08:24:01 <elisha_r> but perhaps there we need a different type of view.
08:24:34 <elisha_r> Anyhow, yes, lets discuss it in Barcelona. Can we set up a BP with the intent of discussing it there?
08:24:40 <ifat_afek> I completely agree
08:24:48 <ifat_afek> sure
08:25:19 <ifat_afek> #topic Preparations for Barcelona
08:25:35 <ifat_afek> I know that elisha_r, eyalb and myself are going to Barcelona. Anyone else?
08:25:46 <ifat_afek> OpenStack published the suggested schedule for the design sessions:
08:25:54 <ifat_afek> #link https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458&single=true
08:26:08 <ifat_afek> 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 <ifat_afek> I created a new etherpad for planning the design sessions, please add your ideas:
08:26:42 <ifat_afek> #link https://etherpad.openstack.org/p/vitrage-barcelona-design-sessions
08:29:46 <ifat_afek> 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 <ifat_afek> #topic Open Discussion
08:30:08 <ifat_afek> anything else?
08:33:20 <ifat_afek> goodbye then
08:33:27 <eyalb> bye
08:34:13 <ifat_afek> #endmeeting