Miachael,
I have read the commit to add set_config_files, which could be used for testing
another config file. I have some questions:
1. Why need set self._args via __call__? Valid self._args throw exceptions in
register_cli_opt, so limit its usage scenerio.
2. Any openstack test code are u
All,
Currently, event-alarm is one-shot style: don't fire again for same event. But
threshold-alarm is limited periodic style:
1. only get 1 fire for continuous valid datapoints.
2. Would get a new fire if insufficient data followed by valid ones, as we reset
alarm state upon insufficient data
notifier, if the ACK recieved, reset the alarm state to OK, if timeout
occured, set the alarm state to 'UNKNOWN'. If 'alarm_action' has not
been set, we just need to recored the alarm state transition history.
在 2015/9/8 7:26, Zhai, Edwin 写道:
All,
Currently, event-alarm i
All,
I saw some patches from Chris Dent to enable functions in devstack/*. But it
conflicts with devstack upstream so that start each ceilometer service twice. Is
there any official way to setup ceilometer as devstack plugin?
Best Rgds,
Edwin
__
Chris,
Thanks for clarification.
On Tue, 15 Sep 2015, Chris Dent wrote:
On Tue, 15 Sep 2015, Zhai, Edwin wrote:
I saw some patches from Chris Dent to enable functions in devstack/*. But
it conflicts with devstack upstream so that start each ceilometer service
twice. Is there any official
All,
I'm writing a BP for meter rename @ https://review.openstack.org/#/c/183419/
Simply speaking, we will translate meter querying API for both input and output
if ender user specify an known renamed meter.
Gordon has a performance concern to translate the output given possible huge
number o
All,
I observed various "meters" and "metrics" with almost same meaning in telemetry
part of admin-guild-cloud.
Just curious about the minor difference. If they are interchangeable, we can
pick up one for confusion.
Best Rgds,
Edwin
All,
I'd like make some clarification for the event-alarm timeout design as many of
you have some misunderstanding here. Pls. correct me if any mistakes.
I realized that there are 2 different things, but we mix them sometime:
1. event-timeout-alarm
This is one new type of alarm that bracket *.
Gordon,
Thanks for your comments.
Pls. check my answer and flow chart below.
On Wed, 21 Sep 2016, gordon chung wrote:
=== event-alarm timeout implementation =
As it's for event-alarm, we need keep it as event-driven. Furthermore,
for quick response, we need use event for ti
Thanks for your clarification, see my comments below.
On Thu, 22 Sep 2016, gordon chung wrote:
On 22/09/2016 2:40 AM, Zhai, Edwin wrote:
See
https://github.com/openstack/aodh/blob/master/aodh/evaluator/event.py#L158
evaluate_events is the handler of the endpoint for 'alarm.all
. This executor processes
inbound notifications on the server’s thread, blocking it from processing
additional notifications until it finishes with the current one."
Note: If the “eventlet” executor is used, the threading and time library need to
be monkeypatched.
On Fri, 23 Sep 2016, Zhai, E
On Fri, 23 Sep 2016, gordon chung wrote:
On 23/09/2016 2:18 AM, Zhai, Edwin wrote:
There are many targets(topics)/endpoints in above ceilometer code. But
in AODH, we just have one topic, 'alarm.all', and one endpoint. If it is
still multi-threaded, there is already potential race
12 matches
Mail list logo