Open Stack

Hi Alexey,

Thanks for the overview of how you see a Congress-Vitrage integration being
valuable.

I'd imagine that the right first step in this integration would be creating
a new datasource driver within Congress to pull data from Vitrage.  It
doesn't need to pull all the data in your list to start, but enough so that
we can try writing policy over that data.  It's helpful to have a policy in
mind that you want to write and then set up the datasource driver to grab
enough of the Vitrage data to write that policy.  Here are the relevant
docs.

Datasource drivers
http://docs.openstack.org/developer/congress/cloudservices.html

Writing policy
http://docs.openstack.org/developer/congress/policy.html

Let me know if you have any questions,
Tim



On Wed, May 4, 2016 at 11:51 PM Weyl, Alexey (Nokia - IL) <
alexey.weyl at nokia.com> wrote:

> Hi to all Vitrage and Congress contributors,
>
> We had a good introduction meeting in Austin and we (Vitrage) think that
> we can have a good collaboration between the projects.
>
> Vitrage, as an Openstack Root Cause Analysis (RCA) Engine, builds a
> topology graph of all the entities in the system (physical, virtual and
> application) from different datasources. It thus can enrich Congress by
> providing more data about what is happening in the system. Additionally,
> the Vitrage RCA and deduce alarms & states mechanism can enhance the
> visibility of faults and how they inter-relate.  By using this information
> Congress could then execute different policies and perform more accurate
> actions.
>
> Another good property of Vitrage is that it can receive data also from
> non-openstack sources, like Nagios, which monitor the physical resources,
> including Switches (which are not modeled today in OpenStack).
>
> There are many ways in which Congress-Vitrage combination would be
> helpful. To take just one example:
> a. If a physical Switch is down, Vitrage can raise deduced alarms on the
> connected hosts and on the virtual machines affected by this change in
> switch state.
> b. Congress will then be notified by Vitrage about these alarms, which can
> set off Congress policies of migration.
> c. Furthermore, due to the RCA functionality, Congress will be aware that
> the Switch error is the source of the problem, and can determine the best
> place to create new instances of the VMs so that this  switch fault will
> not impact the new instances.
>
> As you can see, for each fault, we can use Vitrage to link it to other
> faults, and create alarms to reflect them. This is all done via Vitrage
> Templates, so the system is configurable to the needs of the user. Thus
> many more cases such as the example above could be thought of.
>
> To summarize, Vitrage can enrich Congress with the following four features:
> a. RCA
> b. Deduced alarms
> c. Physical, virtual and application layers
> d. Graph structure and topology of the system that defines the connections
> and relationships between all entities on which we can run quick graph
> algorithms to decide different actions to perform
>
> If you can think of additional use cases that can be used here, please
> share ☺
>
> For more data about Vitrage and its insights please take a look here:
> https://wiki.openstack.org/wiki/Vitrage
>
> Best Regards,
> Alexey Weyl
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160506/900cc558/attachment.html>