09:01:09 #startmeeting vitrage 09:01:10 Meeting started Wed Jan 6 09: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. 09:01:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:01:14 The meeting name has been set to 'vitrage' 09:01:18 Hello There :) 09:01:23 hello 09:01:27 Hi everyone, welcome back  09:01:34 hi 09:02:23 hi all :) 09:02:27 hi 09:02:30 hi 09:02:39 long time... 09:02:47 hi 09:03:05 hi all 09:03:07 long time no see 09:06:23 Our agenda: 09:06:32 * Current status and progress 09:06:38 hi 09:06:40 * Review action items 09:06:50 * Next steps 09:06:57 * Open Discussion 09:07:07 #topic Current status and progress 09:07:25 A short update about Vitrage documentation: Maty checked this issue, and we cannot place our documentation in the official openstack place (http://docs.openstack.org) until we are accepted under the big tent. 09:07:37 I suggest that for now we add our detailed design diagrams in Vitrage main page 09:07:58 Update on what I did: I started working on Nagios plugin for the synchronizer. As a first stage, I’m going to implement the get_all for nagios services (tests). 09:08:01 hello 09:08:16 For notifications, we have decided not to register to Nagios event handlers, as it raises security issues (how will Nagios call vitrage). Instead, we will take Nagios snapshots periodically and compare them. 09:08:34 I was also involved in the discussions on the consistency process (with alexey_weyl, elisha_r and Asi), and plan to document the use cases and challenges. We should continue with the design this week. 09:08:57 We worked on the first integration of the synchronizer, processor, graph, api and UI. 09:09:04 alexey_weyl, can you update? 09:09:10 I would love to 09:09:25 Hi 09:09:59 I have performed the integration of the synchronizer + processor + transformer. Now it works and runs 09:10:51 In addition I have a created an openstack service for "vitrage-graph" which runs the the synchronizer, entity graph, consistency and api handler oslo services 09:11:17 if you want to run it, you can do: "sudo pip install -e." 09:11:34 which will install the services, and then you can run "vitrage-graph" 09:11:39 cool! 09:12:03 very nice 09:12:21 Ohad, can you update about our discussions with PinPoint? 09:12:26 cool! 09:12:43 We had a meeting with PinPoint – OPNFV project aiming to provide RCA framework for NFVI and VIM layers focusing on network issues. 09:12:56 We found good alignment between use cases from both projects covering failures from physical and virtual layers. PinPoint are working on gap analysis to find out which information/ data exists in different projects or tools in order to understand root cause of failures and to define the APIs needed for it. 09:13:32 @Ohad - can you explain what "aiming" means? 09:13:33 It looks like Vitrage perfectly match for providing the get physical/virtual topology and mappings APIs and we will keep working together on this. 09:14:08 @alexey_weyl: cool - lets do next week integration including zones, hosts and instances :) 09:14:52 @lhartal: sounds great :) 09:15:25 alexey_weyl: this is great, let's do the full integration next week 09:15:59 #action alexey_weyl continue with the integration, including zones, hosts and instances 09:16:01 Elisha: PinPoint is a requirement project 09:16:35 Ok :) 09:17:06 Ohad, elisha_r: we are in the process of finalizing vitrage API so we can send the definition to PinPoint, and verify it matches their use cases 09:17:29 I am still working on api 09:17:45 first version was written with a simple filter 09:18:05 next we will use a more complex filter 09:18:22 i did an integration with UI 09:18:55 they are using the client and were able to retrieve a mock graph 09:19:02 Eyalb: once we have a version, please share it with PinPoint 09:19:23 still need to work with dany to call the api handler 09:19:33 ohad sure 09:19:43 thats it 09:19:51 eyalb, so once Dani is done, we will have an end-to-end integration? 09:20:10 hopefully yes 09:20:16 great 09:20:38 nadav_yakar, can you update about the synchronizer status? 09:20:59 we have finalized the synchronizer design which includes hosts, zones and instances snapshotting and notifications propagation. I have checked in the synchronizer's plugin execution framework and worked with Alexey to integrate it with the vitrage graph 09:22:06 get_all for host and zone are ready 09:22:40 yes, the instances snapshotting process is also checked in 09:22:57 great 09:23:24 who else wants to update? 09:24:52 I've started compiling information on how Vitrage will work with Neo4J or Titan (or any other persistant GraphDB) that can replace NetworkX. 09:25:05 I did little research about oslo.service and it's multi-thread support 09:26:07 It seems that we can use one process with multi-thread of greenlet while working with networkx 09:26:33 And multi processes while working with Neo4j 09:26:51 or other graph db that support access from multi processes 09:27:24 Sounds great! good solution! 09:27:29 my update: currently working to implement the Get Topology query api over NetworkX, so we can request a filtered subgraph of the entity graph. 09:27:43 emaiin, so the design for networkx is finished for now? 09:28:26 ifat_afek: if think is finished 09:28:34 great 09:28:42 I think it's finished 09:29:01 any other updates? if not, let's move on 09:29:28 #topic Review action items 09:29:39 • ifat_afek check Aodh integration workaround and update Ceilometer blueprints 09:29:50 I sent an email to Aodh mailing list, and specifically to Julien and Ryota. Got no reply, could be because of the holidays. Will try again in a week or two. 09:30:12 I also emailed Aodh and asked them not to remove the ability to send notifications about alarm status changes (they planned to remove it), because we want to register to these notifications. 09:30:26 • nadav_yakar checkin a basic synchronizer FW for the vitrage graph to interface with and see that we are on the same page 09:30:40 done 09:30:44 • ifat_afek check how we should add vitrage documentation 09:30:47 i have a question, NetworkX is persistent or it has a way to keep the graph in RAM? 09:30:55 sorry for stepping in :) 09:31:13 in memory only 09:31:19 cool, thanks 09:31:55 looks like an interesting project 09:32:03 Let me expand a bit on NetworkX 09:32:53 We started with NetworkX b/c it's pure python (and the only significant graph DB in python project we could find). 09:33:06 It's in-memory 09:33:51 However, for good performance we are already working now on a design that will allow using persistant graph-DB, such as Neo4J and Titan, instead. 09:34:52 Already now, in our design, we use a interface called "Graph Driver" that will remain the same even when we replace the graph DB backend in the future. 09:35:32 elishar_r : why there is a performance problem ? i would assume that in-memory should be faster then persistant one in general 09:35:42 or the package itself (NetworkX) is not so good? 09:36:34 NetworkX itself has reasonable performance, as-is. however, there are a few other performance issues we want to address. 09:36:58 first of all, it's not persistant. that means that if Vitrage fails, we need to rebuild the DB when it goes back online 09:37:40 second of all, in pure python there is little support for real multi-threading, while when using a persistant DB like Neo4J we can access it in parallel from different sources. 09:38:26 elisha_r: thanks for explaining, it make sense 09:38:45 finally, doing things in-memory means we cannot leverage distribution, and limits the graph size as well. Those are the main points 09:38:53 sure :) 09:39:18 But networkx is very use full for dev env 09:39:30 you don't need to install any 3rd party DB 09:40:00 BTW, we found out that networkx is already in use in openstack (by TaskFlow project if I'm not mistaken) 09:40:41 And networkx really fast 09:41:10 ok, let's go back to the action items 09:41:12 • ifat_afek check how we should add vitrage documentation 09:41:16 done, already discussed it 09:41:31 • decide on Vitrage next use cases 09:43:09 We talked about the second use case. It will include the evaluator for RCA purposes, nagios synchronizer (only snapshots), and physical resources synchronizer 09:43:35 #topic Next Steps 09:43:42 so we already discussed the integration 09:43:54 and the second use case 09:43:58 anything else? 09:44:48 I want to adapt our synchronizer framework 09:44:53 We hope to start working on message bug listener plugin 09:44:54 #action finalize get topology API 09:44:56 for nova 09:45:35 adapt our framework per our design changes and oslo conventions 09:45:45 #action ifat_afek update the documentation on vitrage main page with our latest design diagrams (of vitrage graph and the synchronizer) 09:46:13 #topic Open Discussion 09:46:26 I had a look yesterday at Telemetry and Monasca IRC meeting logs, to see if they are doing anything that interests us. 09:46:48 Monasca started working on a cassandra time-series DB. This is not related directly to Vitrage, but if they introduce cassandra to Openstack and handle cassandra installation, it might help us in our future “real” graph-database implementation. 09:47:00 #link https://blueprints.launchpad.net/monasca/+spec/monasca-cassandra 09:47:19 As for Ceilometer, I noticed two interesting issues: 09:47:40 They want to improve their alarm rules. They will define complex conditions of and/or over several threshold conditions. 09:47:51 #link https://blueprints.launchpad.net/ceilometer/+spec/composite-threshold-rule-alarm 09:48:07 one of their future targets (i.e. not for mitaka?) is application level monitoring 09:48:17 #link https://wiki.openstack.org/wiki/Telemetry/RoadMap 09:48:27 anything else? 09:51:29 we are going to present Vitrage first demo next week 09:51:37 We're planing to display the first use case: Vitrage show topology 09:52:12 including zones, hosts and instances 09:54:01 cool, is this going to be recorded? 09:54:07 yes 09:54:11 great 09:55:02 we will put a link in Vitrage website 09:55:38 cool! we will also email it to openstack dev list 09:56:15 #action: presenting first Vitrage demo 09:56:34 Thumbs up! 09:56:34 an update on behalf of Marina: she prepared a dev stack that we can use for our tempest tests 09:57:33 see you next week then 09:57:54 cya! 09:57:57 bye 09:58:05 bye bye :) 09:58:09 bye 09:58:12 bye 09:58:17 bye 09:58:32 #endmeeting