On Tue, Jan 24 2017, Afek, Ifat (Nokia - IL) wrote: > Vitrage, and I assume that other projects, needs an “Alarm Manager”. The role > of an Alarm Manager is to store all alarms in the system, keep their history, > notify on changes, etc. Vitrage does not declare itself as an Alarm Manager, > mainly because we understood that this is the role of Aodh.
What you describe is a database. There are tons of database out there that you can use to store data. Define a model and Vitrage can have its own data storage for alarms, metadata, whatever you want. Plus, it will be way more performant than using Aodh! :-) Creating alarms via the Aodh API just to make it store the alarms in a SQL database the alarms is kinda… pointless. Let Vitrage just use a database directly. Because in that case what are the perks of using Aodh, except saying that it uses Aodh. But indeed, I think what you describe is some kind of centralizer database. I don't think being a database has any interest for Aodh (nor for Vitrage). The only upside of using Aodh instead of a database directly would be to make alarms readable by the user. But that therefore exposes Vitrage internal datastore. And since user should not manipulate alarms created by Vitrage, directly, I don't see any gain in that either. Aodh is not /just/ an alarm data store. Its real features are in the evaluators and notifiers. So the whole "generic" alarm approach is about keeping the "define and store and notify alarms" part into Aodh while having the "evaluate/trigger alarms" being outisde Aodh (in this case in Vitrage). As I already said a while back, I think it's OK to have that and externalize the evaluator. But you also have to keep in mind the original use case and design of Aodh: being a user accessible API that provides alarm definition, evaluation and triggering. I hope that enlighten things a bit more! :-) Cheers, -- Julien Danjou /* Free Software hacker https://julien.danjou.info */
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
