Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
Hi Tim,
Sounds good. I’ll take a look at the links you sent below and will let you know
if I have any questions.
Thanks,
Alexey
From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Thursday, May 12, 2016 9:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
Hi Alexey,
That sounds like a good use case. If I understand it correctly, the use case
can be accomplished by doing two things:
1. Writing a Vitrage datasource driver that whenever it receives an alarm,
pulls Vitrage's API. I'd recommend having the datasource driver pulling
periodically, and a push simply requests an immediate refresh of that data.
That way, the data is available as soon as you create the datasource driver.
That would mean your datasource driver inherits from both the
PushedDataSourceDriver and PollingDataSourceDriver classes. Pulling data has
been in Congress since day 1, and all but one of our drivers pull data, so
there are plenty of examples in congress/datasources. Push is new
functionality that Masahito added in Mitaka.
Here are the docs on writing a datasource driver. I'd start with pulling the
data from Vitrage and adding the push functionality once that is working (using
the request_refresh() method from the PushedDataSourceDriver base class to
force the poller to immediately pull the data).
http://docs.openstack.org/developer/congress/cloudservices.html
2. Writing a policy that uses the information about the host alarm that the
datasource driver pulled. Below are 2 examples, where I'm assuming that the
vitrage datasource driver creates a table called host_alarm within Congress.
- reactive policy like "whenever the host alarm is ON, pause all the VMs on
that host".
Something like:
execute[nova:pause(vm)] :- vitrage:host_alarm(host), nova:servers(id=vm,
hostId=host)
- monitoring policy: "whenever the host alarm is ON, all the VMs on that host
belong to the violation table"
violation(vm) :- vitrage:host_alarm(host), nova:servers(id=vm, hostId=host)
Here are the docs on writing such policies.
Basic policy:
http://docs.openstack.org/developer/congress/policy.html
Reactive policy:
http://docs.openstack.org/developer/congress/enforcement.html#manual-reactive-enforcement
Tim
On Thu, May 12, 2016 at 1:45 AM Masahito MUROI
<muroi.masah...@lab.ntt.co.jp<mailto:muroi.masah...@lab.ntt.co.jp>> wrote:
Hi Alexey,
Thanks for clarified! I understood your use-case.
Anyway, as Tim mentioned before, implementing Vitrage driver seems to be
a good first step to integrate both.
best regards,
Masahito
On 2016/05/10 20:00, Weyl, Alexey (Nokia - IL) wrote:
> Hi Masahito,
>
> In addition, I wanted to add that the reason Congress needs to get the data
> from Vitrage by a pushing mechanism and not via polling, is so there won't be
> a delay from when the event occurs and when Congress receives it. Using
> polling, it will take a number of seconds (the polling interval time, 30
> seconds by default) until Congress will receive the data.
>
> The reason of course why we need it, is to make the whole process work much
> faster, and be consistent with other projects such as OPNFV Doctor (that
> wants events to happen in less than 1 second).
>
> Alexey
>
>> -Original Message-
>> From: Weyl, Alexey (Nokia - IL)
>> [mailto:alexey.w...@nokia.com<mailto:alexey.w...@nokia.com>]
>> Sent: Tuesday, May 10, 2016 1:45 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
>> Collaboration
>>
>> Hi Masahito,
>>
>> Thanks for your question.
>>
>> There are two main reasons why we need to get alarms from Vitrage
>> initially.
>>
>> First, there are alarms that Vitrage generates ("deduced alarms") based
>> on its user-defined templates and topology. Also, there are alarms that
>> come from external sources outside of OpenStack, which Aodh and other
>> projects do not hold. This information could also be valuable for
>> Congress regardless of the RCA functionality.
>>
>> Second, since Vitrage retrieves alarms from multiple sources, the RCA
>> API takes as input the Vitrage-Id of the alarm. To know what that ID
>> is, you will need to first get the Alarms from Vitrage.
>>
>> Does this make sense? Would there be a different flow you think could
>> work?
>>
>> Best Regards,
>> Alexey
>>
>>> -Original Message-
>>> From: Masahito MUROI
>>> [mailto:muroi.masah...@lab.ntt.co.jp<mailto:muroi.masah...@lab.ntt.co.jp>]
>>> Sent: Tuesday, May 10, 2016 11:00 AM
>>> To:
>>> openstack-dev@lists.open
Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
Hi Alexey,
That sounds like a good use case. If I understand it correctly, the use
case can be accomplished by doing two things:
1. Writing a Vitrage datasource driver that whenever it receives an alarm,
pulls Vitrage's API. I'd recommend having the datasource driver pulling
periodically, and a push simply requests an immediate refresh of that
data. That way, the data is available as soon as you create the datasource
driver.
That would mean your datasource driver inherits from both the
PushedDataSourceDriver and PollingDataSourceDriver classes. Pulling data
has been in Congress since day 1, and all but one of our drivers pull data,
so there are plenty of examples in congress/datasources. Push is new
functionality that Masahito added in Mitaka.
Here are the docs on writing a datasource driver. I'd start with pulling
the data from Vitrage and adding the push functionality once that is
working (using the request_refresh() method from the PushedDataSourceDriver
base class to force the poller to immediately pull the data).
http://docs.openstack.org/developer/congress/cloudservices.html
2. Writing a policy that uses the information about the host alarm that the
datasource driver pulled. Below are 2 examples, where I'm assuming that
the vitrage datasource driver creates a table called host_alarm within
Congress.
- reactive policy like "whenever the host alarm is ON, pause all the VMs on
that host".
Something like:
execute[nova:pause(vm)] :- vitrage:host_alarm(host), nova:servers(id=vm,
hostId=host)
- monitoring policy: "whenever the host alarm is ON, all the VMs on that
host belong to the violation table"
violation(vm) :- vitrage:host_alarm(host), nova:servers(id=vm,
hostId=host)
Here are the docs on writing such policies.
Basic policy:
http://docs.openstack.org/developer/congress/policy.html
Reactive policy:
http://docs.openstack.org/developer/congress/enforcement.html#manual-reactive-enforcement
Tim
On Thu, May 12, 2016 at 1:45 AM Masahito MUROI <muroi.masah...@lab.ntt.co.jp>
wrote:
> Hi Alexey,
>
> Thanks for clarified! I understood your use-case.
>
> Anyway, as Tim mentioned before, implementing Vitrage driver seems to be
> a good first step to integrate both.
>
> best regards,
> Masahito
>
> On 2016/05/10 20:00, Weyl, Alexey (Nokia - IL) wrote:
> > Hi Masahito,
> >
> > In addition, I wanted to add that the reason Congress needs to get the
> data from Vitrage by a pushing mechanism and not via polling, is so there
> won't be a delay from when the event occurs and when Congress receives it.
> Using polling, it will take a number of seconds (the polling interval time,
> 30 seconds by default) until Congress will receive the data.
> >
> > The reason of course why we need it, is to make the whole process work
> much faster, and be consistent with other projects such as OPNFV Doctor
> (that wants events to happen in less than 1 second).
> >
> > Alexey
> >
> >> -Original Message-
> >> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> >> Sent: Tuesday, May 10, 2016 1:45 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> >> Collaboration
> >>
> >> Hi Masahito,
> >>
> >> Thanks for your question.
> >>
> >> There are two main reasons why we need to get alarms from Vitrage
> >> initially.
> >>
> >> First, there are alarms that Vitrage generates ("deduced alarms") based
> >> on its user-defined templates and topology. Also, there are alarms that
> >> come from external sources outside of OpenStack, which Aodh and other
> >> projects do not hold. This information could also be valuable for
> >> Congress regardless of the RCA functionality.
> >>
> >> Second, since Vitrage retrieves alarms from multiple sources, the RCA
> >> API takes as input the Vitrage-Id of the alarm. To know what that ID
> >> is, you will need to first get the Alarms from Vitrage.
> >>
> >> Does this make sense? Would there be a different flow you think could
> >> work?
> >>
> >> Best Regards,
> >> Alexey
> >>
> >>> -Original Message-
> >>> From: Masahito MUROI [mailto:muroi.masah...@lab.ntt.co.jp]
> >>> Sent: Tuesday, May 10, 2016 11:00 AM
> >>> To: openstack-dev@lists.openstack.org
> >>> Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> >>> Collaboration
> >>>
> >>> Hi Alexey,
> >>>
> >>> This use case sounds interesting. To be clarified it, I have a
&g
Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
Hi Alexey,
Thanks for clarified! I understood your use-case.
Anyway, as Tim mentioned before, implementing Vitrage driver seems to be
a good first step to integrate both.
best regards,
Masahito
On 2016/05/10 20:00, Weyl, Alexey (Nokia - IL) wrote:
Hi Masahito,
In addition, I wanted to add that the reason Congress needs to get the data
from Vitrage by a pushing mechanism and not via polling, is so there won't be a
delay from when the event occurs and when Congress receives it. Using polling,
it will take a number of seconds (the polling interval time, 30 seconds by
default) until Congress will receive the data.
The reason of course why we need it, is to make the whole process work much
faster, and be consistent with other projects such as OPNFV Doctor (that wants
events to happen in less than 1 second).
Alexey
-Original Message-
From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
Sent: Tuesday, May 10, 2016 1:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
Collaboration
Hi Masahito,
Thanks for your question.
There are two main reasons why we need to get alarms from Vitrage
initially.
First, there are alarms that Vitrage generates ("deduced alarms") based
on its user-defined templates and topology. Also, there are alarms that
come from external sources outside of OpenStack, which Aodh and other
projects do not hold. This information could also be valuable for
Congress regardless of the RCA functionality.
Second, since Vitrage retrieves alarms from multiple sources, the RCA
API takes as input the Vitrage-Id of the alarm. To know what that ID
is, you will need to first get the Alarms from Vitrage.
Does this make sense? Would there be a different flow you think could
work?
Best Regards,
Alexey
-Original Message-
From: Masahito MUROI [mailto:muroi.masah...@lab.ntt.co.jp]
Sent: Tuesday, May 10, 2016 11:00 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
Collaboration
Hi Alexey,
This use case sounds interesting. To be clarified it, I have a
question.
On 2016/05/10 0:17, Weyl, Alexey (Nokia - IL) wrote:
Hi Tim,
I agree – creating a datasource from Vitrage to Congress is the
first step, and we should have some concrete use case in mind to
help guide this process.
The most straightforward use case I would suggest is when there is
a
problem on an instance that is caused by some problem on the
physical host. Then:
·Vitrage will notify about an alarm on the instance, which Congress
will receive
Why does Congress need to receive the alarm? DataSouce Driver pulls
data from Vitrage, so it looks like Congress should only pull the
cause of the failure from Vitrage.
Best regards,
Masahito
·Congress can then call the Vitrage RCA API. The response will
state
that the cause of the instance alarm is the host alarm.
·Congress policy can define that in such a case, the instance
should
be migrated to (or healed on) a different physical host
Does this seem like a good first step for you?
Thanks,
Alexey
*From:*Tim Hinrichs [mailto:t...@styra.com]
*Sent:* Saturday, May 07, 2016 2:43 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [vitrage] [congress] Vitrage-
Congress
Collaboration
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.w...@nokia.com <mailto:alexey.w...@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
Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
Hi Masahito,
In addition, I wanted to add that the reason Congress needs to get the data
from Vitrage by a pushing mechanism and not via polling, is so there won't be a
delay from when the event occurs and when Congress receives it. Using polling,
it will take a number of seconds (the polling interval time, 30 seconds by
default) until Congress will receive the data.
The reason of course why we need it, is to make the whole process work much
faster, and be consistent with other projects such as OPNFV Doctor (that wants
events to happen in less than 1 second).
Alexey
> -Original Message-
> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> Sent: Tuesday, May 10, 2016 1:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> Collaboration
>
> Hi Masahito,
>
> Thanks for your question.
>
> There are two main reasons why we need to get alarms from Vitrage
> initially.
>
> First, there are alarms that Vitrage generates ("deduced alarms") based
> on its user-defined templates and topology. Also, there are alarms that
> come from external sources outside of OpenStack, which Aodh and other
> projects do not hold. This information could also be valuable for
> Congress regardless of the RCA functionality.
>
> Second, since Vitrage retrieves alarms from multiple sources, the RCA
> API takes as input the Vitrage-Id of the alarm. To know what that ID
> is, you will need to first get the Alarms from Vitrage.
>
> Does this make sense? Would there be a different flow you think could
> work?
>
> Best Regards,
> Alexey
>
> > -Original Message-
> > From: Masahito MUROI [mailto:muroi.masah...@lab.ntt.co.jp]
> > Sent: Tuesday, May 10, 2016 11:00 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> > Collaboration
> >
> > Hi Alexey,
> >
> > This use case sounds interesting. To be clarified it, I have a
> > question.
> >
> > On 2016/05/10 0:17, Weyl, Alexey (Nokia - IL) wrote:
> > > Hi Tim,
> > >
> > > I agree – creating a datasource from Vitrage to Congress is the
> > > first step, and we should have some concrete use case in mind to
> > > help guide this process.
> > >
> > > The most straightforward use case I would suggest is when there is
> a
> > > problem on an instance that is caused by some problem on the
> > > physical host. Then:
> > >
> > > ·Vitrage will notify about an alarm on the instance, which Congress
> > > will receive
> > >
> > Why does Congress need to receive the alarm? DataSouce Driver pulls
> > data from Vitrage, so it looks like Congress should only pull the
> > cause of the failure from Vitrage.
> >
> > Best regards,
> > Masahito
> >
> > > ·Congress can then call the Vitrage RCA API. The response will
> state
> > > that the cause of the instance alarm is the host alarm.
> > >
> > > ·Congress policy can define that in such a case, the instance
> should
> > > be migrated to (or healed on) a different physical host
> > >
> > > Does this seem like a good first step for you?
> > >
> > > Thanks,
> > >
> > > Alexey
> > >
> > > *From:*Tim Hinrichs [mailto:t...@styra.com]
> > > *Sent:* Saturday, May 07, 2016 2:43 AM
> > > *To:* OpenStack Development Mailing List (not for usage questions)
> > > *Subject:* Re: [openstack-dev] [vitrage] [congress] Vitrage-
> Congress
> > > Collaboration
> > >
> > > 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
> > >
> > > Le
Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
Hi Masahito,
Thanks for your question.
There are two main reasons why we need to get alarms from Vitrage initially.
First, there are alarms that Vitrage generates ("deduced alarms") based on its
user-defined templates and topology. Also, there are alarms that come from
external sources outside of OpenStack, which Aodh and other projects do not
hold. This information could also be valuable for Congress regardless of the
RCA functionality.
Second, since Vitrage retrieves alarms from multiple sources, the RCA API takes
as input the Vitrage-Id of the alarm. To know what that ID is, you will need to
first get the Alarms from Vitrage.
Does this make sense? Would there be a different flow you think could work?
Best Regards,
Alexey
> -Original Message-
> From: Masahito MUROI [mailto:muroi.masah...@lab.ntt.co.jp]
> Sent: Tuesday, May 10, 2016 11:00 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> Collaboration
>
> Hi Alexey,
>
> This use case sounds interesting. To be clarified it, I have a
> question.
>
> On 2016/05/10 0:17, Weyl, Alexey (Nokia - IL) wrote:
> > Hi Tim,
> >
> > I agree – creating a datasource from Vitrage to Congress is the first
> > step, and we should have some concrete use case in mind to help guide
> > this process.
> >
> > The most straightforward use case I would suggest is when there is a
> > problem on an instance that is caused by some problem on the physical
> > host. Then:
> >
> > ·Vitrage will notify about an alarm on the instance, which Congress
> > will receive
> >
> Why does Congress need to receive the alarm? DataSouce Driver pulls
> data from Vitrage, so it looks like Congress should only pull the cause
> of the failure from Vitrage.
>
> Best regards,
> Masahito
>
> > ·Congress can then call the Vitrage RCA API. The response will state
> > that the cause of the instance alarm is the host alarm.
> >
> > ·Congress policy can define that in such a case, the instance should
> > be migrated to (or healed on) a different physical host
> >
> > Does this seem like a good first step for you?
> >
> > Thanks,
> >
> > Alexey
> >
> > *From:*Tim Hinrichs [mailto:t...@styra.com]
> > *Sent:* Saturday, May 07, 2016 2:43 AM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
> > Collaboration
> >
> > 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.w...@nokia.com <mailto:alexey.w...@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
> >
Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
Hi Alexey, This use case sounds interesting. To be clarified it, I have a question. On 2016/05/10 0:17, Weyl, Alexey (Nokia - IL) wrote: Hi Tim, I agree – creating a datasource from Vitrage to Congress is the first step, and we should have some concrete use case in mind to help guide this process. The most straightforward use case I would suggest is when there is a problem on an instance that is caused by some problem on the physical host. Then: ·Vitrage will notify about an alarm on the instance, which Congress will receive Why does Congress need to receive the alarm? DataSouce Driver pulls data from Vitrage, so it looks like Congress should only pull the cause of the failure from Vitrage. Best regards, Masahito ·Congress can then call the Vitrage RCA API. The response will state that the cause of the instance alarm is the host alarm. ·Congress policy can define that in such a case, the instance should be migrated to (or healed on) a different physical host Does this seem like a good first step for you? Thanks, Alexey *From:*Tim Hinrichs [mailto:t...@styra.com] *Sent:* Saturday, May 07, 2016 2:43 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration 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.w...@nokia.com <mailto:alexey.w...@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-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@
Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
Hi Tim, I agree – creating a datasource from Vitrage to Congress is the first step, and we should have some concrete use case in mind to help guide this process. The most straightforward use case I would suggest is when there is a problem on an instance that is caused by some problem on the physical host. Then: · Vitrage will notify about an alarm on the instance, which Congress will receive · Congress can then call the Vitrage RCA API. The response will state that the cause of the instance alarm is the host alarm. · Congress policy can define that in such a case, the instance should be migrated to (or healed on) a different physical host Does this seem like a good first step for you? Thanks, Alexey From: Tim Hinrichs [mailto:t...@styra.com] Sent: Saturday, May 07, 2016 2:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration 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.w...@nokia.com<mailto:alexey.w...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration
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.w...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ 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
