Re: [openstack-dev] [Vitrage] [aodh] Integration with doctor

2017-07-09 Thread Juvonen, Tomi (Nokia - FI/Espoo) 
Hi,

Inline for “set instance state”

Br,
Tomi


From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Sunday, July 09, 2017 3:14 PM
To: dong.wenj...@zte.com.cn; openstack-dev@lists.openstack.org
Subject: Suspected SPAM - Re: [openstack-dev] [Vitrage] [aodh] Integration with 
doctor

Hi dwj,

Adding [aodh] for item #2.
Please see my answers inline.

Best Regards,
Ifat.



From: "dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>" 
<dong.wenj...@zte.com.cn<mailto:dong.wenj...@zte.com.cn>>
Date: Friday, 7 July 2017 at 10:53

Hi,



For the integration Vitrage with doctor, I have some issues which need to be 
confirmed~  :)



1.  Notification strategies: conservative (nova->Aodh)

@Ifat

In the host_down_scenarios.yaml[1], we only set the host state as error.

But in doctor current use case, we need to call nova API 'nova reset-state' to 
set instance state as error to trigger the event alarm and notify the consumer.

Is it needed to be fix?

[Tomi] Either to have this fixed or propose an alternative in Doctor project 
where project (tenant) is able to have alarm about instances affected by other 
means. Project anyhow already know about “host forced down” in Nova servers API 
trough “host_status”, so it is just about getting an alarm on instance (server) 
level also.

We need to add 'Aodh' and 'Nova' notifier plugins in Vitrage config file for 
doctor integration,  right?



[Ifat] Vitrage currently doesn’t call set instance state, but this can easily 
be added. The required steps are:

  *   Add “set state” action for the instances in the template yaml file
  *   In the Nova notifier, add a call to nova reset-state API
  *   The Aodh plugin is not needed in this case, since the flow is Vitrage -> 
Nova -> Aodh with no direct calls from Vitrage to Aodh





2. Notification strategies: shortcut  (inspector->Aodh)

@Ryota

Do we have any plans to change to shortcut notification?

@Ifat

If we use the shortcut notification, in the Aodh notifier plugin, maybe we need 
to create aodh alarm with 'alarm_actions'.



[Ifat] The Aodh plugin is defined as a POC, and is not very usable. We have 
discussed with the Aodh team possible enhancements (like adding an 
“external/custon alarm” in Aodh) that will enable creating an Aodh alarm from 
Vitrage, but we didn’t reach a clear conclusion. There are a few problems with 
the current implementation, related to the facts that the event-alarm does not 
exactly suit the use case; and that Vitrage may raise the same alarm several 
times for different instances. If you chose the shortcut strategy, we will have 
to open this discussion again.

Having that said, I believe that the shortcut strategy is much better for 
Vitrage. While on the conservative strategy we can support notifications to 
Nova, in the shortcut strategy we can write the Aodh plugin once and support 
all kinds of notifications (to Nova, Neutron, Heat or even external components) 
with no additional effort.





Correct me if I miss something.



[1]. 
https://github.com/openstack/vitrage/blob/master/etc/vitrage/templates.sample/host_down_scenarios.yaml



BR,

dwj










__
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] [aodh] Integration with doctor

2017-07-09 Thread Afek, Ifat (Nokia - IL/Kfar Sava) 
Hi dwj,

Adding [aodh] for item #2.
Please see my answers inline.

Best Regards,
Ifat.



From: "dong.wenj...@zte.com.cn" 
Date: Friday, 7 July 2017 at 10:53


Hi,



For the integration Vitrage with doctor, I have some issues which need to be 
confirmed~  :)



1.  Notification strategies: conservative (nova->Aodh)

@Ifat

In the host_down_scenarios.yaml[1], we only set the host state as error.

But in doctor current use case, we need to call nova API 'nova reset-state' to 
set instance state as error to trigger the event alarm and notify the consumer.

Is it needed to be fix?



We need to add 'Aodh' and 'Nova' notifier plugins in Vitrage config file for 
doctor integration,  right?



[Ifat] Vitrage currently doesn’t call set instance state, but this can easily 
be added. The required steps are:

· Add “set state” action for the instances in the template yaml file

· In the Nova notifier, add a call to nova reset-state API

· The Aodh plugin is not needed in this case, since the flow is Vitrage 
-> Nova -> Aodh with no direct calls from Vitrage to Aodh





2. Notification strategies: shortcut  (inspector->Aodh)

@Ryota

Do we have any plans to change to shortcut notification?

@Ifat

If we use the shortcut notification, in the Aodh notifier plugin, maybe we need 
to create aodh alarm with 'alarm_actions'.



[Ifat] The Aodh plugin is defined as a POC, and is not very usable. We have 
discussed with the Aodh team possible enhancements (like adding an 
“external/custon alarm” in Aodh) that will enable creating an Aodh alarm from 
Vitrage, but we didn’t reach a clear conclusion. There are a few problems with 
the current implementation, related to the facts that the event-alarm does not 
exactly suit the use case; and that Vitrage may raise the same alarm several 
times for different instances. If you chose the shortcut strategy, we will have 
to open this discussion again.

Having that said, I believe that the shortcut strategy is much better for 
Vitrage. While on the conservative strategy we can support notifications to 
Nova, in the shortcut strategy we can write the Aodh plugin once and support 
all kinds of notifications (to Nova, Neutron, Heat or even external components) 
with no additional effort.





Correct me if I miss something.



[1]. 
https://github.com/openstack/vitrage/blob/master/etc/vitrage/templates.sample/host_down_scenarios.yaml



BR,

dwj










__
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