08:01:13 <ifat_afek> #startmeeting vitrage
08:01:13 <openstack> Meeting started Wed Jul 27 08:01:13 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:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:16 <openstack> The meeting name has been set to 'vitrage'
08:01:33 <eyalb> hi
08:01:53 <elisha_r> hi
08:02:00 <ifat_afek> Hi everyone!
08:02:13 <alexey_weyl> :)
08:04:21 <nbloom> Hi
08:04:32 <ifat_afek> Our agenda today:
08:04:37 <ifat_afek> * Status and Updates
08:04:42 <ifat_afek> * Open Discussion
08:04:52 <ifat_afek> #topic Status and Updates
08:05:16 <ifat_afek> The voting for Barcelona sessions has started!
08:05:25 <ifat_afek> #link https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/
08:05:37 <ifat_afek> Vitrage submitted 8 sessions
08:05:54 <ifat_afek> Please enter the link, and select "Vitrage" in the search box to get the first 7 sessions. Then, select "RCA" to get the last one
08:06:02 <ifat_afek> Good luck to us!!
08:06:12 <ifat_afek> Vitrage mascot selection - our list has slightly changed.
08:06:24 <ifat_afek> Heidi Joy Tretheway, who leads the mascot selection process, said we won't be able to vote for the tree as Senlin are using a forest. I asked her to reconsider it
08:06:31 <ifat_afek> In addition, Telemetry selected a Meerkat, which is a Surricata. I agreed to let them have it.
08:06:41 <ifat_afek> After we lost our two favorite candidates, we thought of adding a Giraffe. It sees everything from above, and its skin can be colored like a Vitrage
08:06:50 <ifat_afek> So our candidates would be: Giraffe, Parrot and Butterfly. If you have other suggestions, maybe we can still add them to the list. Heidi is supposed to close the lists today (for everyone ) and then we should vote
08:06:55 <ifat_afek> #link https://etherpad.openstack.org/p/vitrage-mascot
08:07:05 <ifat_afek> Who wants to update?
08:07:43 <nbloom> Hi, I'll update
08:08:10 <nbloom> I'm nearly done with the zabbix datasource notifications, hopefully I'll get it pushed by the end of this day.
08:10:04 <nbloom> Along with the vitrage part of the code there's also an auxiliary script written which is needed be attached to zabbix as a mediatype, the script is responsible for sending vitrage notifications per zabbix event i.e. trigger value changed from problem to ok and vice versa
08:10:26 <nbloom> that's it for now.. :)
08:10:41 <ifat_afek> nbloom: and the script should be configured in zabbix?
08:11:52 <nbloom> yes, along with the script there is also a readme explaining the process of linking the script to zabbix. In addition, there's a similar rst file that will be published with vitrage's docs
08:12:12 <ifat_afek> nbloom: great, thanks
08:12:27 <ifat_afek> also, please add a blueprint for zabbix notifications datasoruce
08:12:45 <nbloom> sure, will be done today!
08:12:58 <alexey_weyl> I have an update
08:13:19 <alexey_weyl> I am working on Vitrage compitability for liberty cycle
08:14:22 <alexey_weyl> It is almost working, but still have some problem with the change passing the Vitrage tempests, because the keystoneauth1 version is differernt
08:14:44 <alexey_weyl> it is working in the vitrage code, but I still have a problem in the vitrageclient code
08:14:54 <alexey_weyl> need to change there the authentication
08:15:05 <alexey_weyl> Done :)
08:15:32 <ifat_afek> alaxey_weyl: thanks!
08:15:54 <ifat_afek> Anyone else wants to update?
08:17:37 <ifat_afek> We had one action item from the last meeting:
08:17:53 <ifat_afek> * danoffek add heat blueprint
08:17:59 <ifat_afek> He was unable to join the meeting, but I know that he did add this blueprint
08:18:48 <elisha_r> I'll go next
08:20:46 <elisha_r> As part of Zabbix datasource support, there is also an effort (mainly liat and nofar, and hopefully soon myself as well) to add zabbix-based vitrage-templates
08:21:32 <elisha_r> This raises a general issue we need to address: how do we make vitrage work out-of-the-box for users
08:22:08 <elisha_r> The dilemma is as follows: vitrage templates use the name of the alarm as part of their structure
08:22:45 <elisha_r> but the exact name might change for each user (e.g., a cpu-threshold test can be called "cpu util" "cpu load" etc)
08:23:15 <ifat_afek> elisha_r: so it depends on the zabbix configuration, right?
08:24:35 <elisha_r> I think what we need to do is try and locate *classic* packages for zabbix, nagios, sensu etc., and build template suites for these. That way, people can use Vitrage OOTB by adding these test packages.
08:25:23 <ifat_afek> elisha_r: I agree. At least a naiive user will be able to use the classic zabbix packages and have vitrage configured without extra effort
08:25:46 <ifat_afek> and for more complex use cases there will be a need to copy-paste and modify the templates
08:26:49 <elisha_r> Even if we do this, though, I think it raises a question of how to store and manage these template suites. We could (1) have them stored as a list of TARs that can be downloaded separately,
08:27:18 <ifat_afek> why not have them in a folder for copy-paste?
08:27:20 <elisha_r> or (2) they could all be installed by default, but then we need to be able to select which is loaded into vitrage, some sort of config file
08:27:48 <elisha_r> we could do copy-paste, but I think configuration is more simple to manage, allowing turning on/off easily
08:28:04 <ifat_afek> regarding [2] - this is in our roadmap. To have a "bank" of templates, and let the user activate or deactivate them. But of course it is much more work to implement
08:28:43 <ifat_afek> So I guess we can start with [1] and improve it in the next versions
08:29:11 <elisha_r> re [2] - I agree, but I think there is room to distinguish between bulk loading and selecting individual tests.
08:29:18 <elisha_r> but of course, we should start with [1]
08:30:03 <elisha_r> A similar issue should be raised regarding support for external datasource "update" functionality
08:30:19 <ifat_afek> what do you mean?
08:32:03 <elisha_r> for example, for Zabbix support noam (nbloom) wrote a plugin for Zabbix. This is not installed in Vitrage, but in Zabbix, to notify Vitrage of changes. The question is, how to manage these in the code base. For now I think the solution was to have, for each datasource, an "auxiliary" folder to place these, and then have a README/RST to explain where the files should go, how to configure etc.
08:32:40 <ifat_afek> got it. you are right, we need to decide on a consistent way to handle it
08:33:23 <nbloom> I think you're right too
08:33:43 <ifat_afek> cool
08:33:48 <ifat_afek> Any other updates?
08:34:39 <ifat_afek> #topic Open Discussion
08:34:51 <ifat_afek> Anything you would like to raise?
08:36:32 <ifat_afek> I guess we are done for today
08:36:39 <ifat_afek> Goodbye :-)
08:36:43 <elisha_r> bye
08:36:55 <eyalb> bye
08:37:00 <ifat_afek> #endmeeting