On Mon, Dec 07 2015, AFEK, Ifat (Ifat) wrote: > Our goal is to get as much information as we can from various data > sources. If you connect Nagios to telemetry project, and we can get > nagios alarms directly from Aodh, it would be great. Is it something > that you planned on doing for Mitaka?
Unfortunately nobody planned to work on a Nagios -> Ceilometer/Gnocchi connector. That maybe a good idea, and the fact that is not planned is not necessarily a blocker. If someone wants to jump in… > Our current use cases focus on giving value to the cloud admin. These > are mostly UI use cases; the admin will be able to: > > - view the topology of his environment, the relations between the > physical, virtual and applicative layer and the statuses all resources > - view the alarms history (there is an existing blueprint for it[1]) > - view alarms about problems that Vitrage deduced could happen, even > if no other OpenStack component reported these problems (yet) > - view RCA information about the alarms I find it odd to have UI use cases first, as their terribly large for a MVP. Unless Vitrage already exists and you have all the code figured out. :) The way I see the big pictures, Vitrage should be done as some sort of an engine on top of Ceilometer/Gnocchi/Aodh and leverage them to do RCA analysis. So what's missing in those projects to make that happen should be done, and Vitrage should start as a MVP; and then we can iterate, both on Vitrage side and both on the telemetry projects. I have the feeling that you're trying to bite a too large portion at once and that you may crash because of that. > In order to support these use cases, we will get input from various > data sources, process and evaluate it based on configurable templates, > trigger new alarms in Aodh and calculate RCA information. > On top of it, we will have Vitrage API to query the information and > show it in horizon. > In case you haven't seen in yet, our high level architecture is on > Vitrage main page[2], and in the coming days we plan to document also > the lower level design. I just looked at it, at it's very interesting. All the high level functionalities make sense and provide values. But if you try to solve them all 5 at once, I'm afraid you're going to either build a monster (with a lot of overlap with other projects, hard to maintain, etc) or just crash because you'll be blocked by all other OpenStack projects. That's the big issue when starting to build a project on top of others OpenStack bricks. Overall I'm just saying that because it's still not clear to me which part you're trying to solve in this thread and how we can help you. What can we provide in our projects, that you miss, that could help you, concretely? What feature we need to work on next? It would be awesome to have _one_ use-case described end-to-end that you would like to solve with Vitrage, leveraging various OpenStack projects, that you cannot solve right now because of missing pieces. Then we could start identifying these missing pieces and implement/fix them. :-) -- 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
