Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always evaluate datawarehouse_alerts #14318

Merged
merged 1 commit into from
Apr 6, 2017

Conversation

moolitayer
Copy link

@moolitayer moolitayer commented Mar 14, 2017

Since hawkular alerts are evaluated in an external system, each alerts coming into the system already represents a created alert. Since an opening or resolving alert is picked only once up by the system, skipping an evaluation will always cause us to miss the alert. This PR works in conjunction with ManageIQ/manageiq-ui-classic#678 allowing to add 0 frequency alerts (although rest is more important for us)

@moolitayer
Copy link
Author

@miq-bot add_label bug, providers/containers

@moolitayer
Copy link
Author

@simon3z please review

@moolitayer
Copy link
Author

@simon3z please review when you can

@moolitayer
Copy link
Author

@cben @zgalor please review

@simon3z
Copy link
Contributor

simon3z commented Mar 21, 2017

@moolitayer I commented this in other PRs, I don't like the direction to embed specific logic of DWH in generic classes (as MiqAlert). Even more so if we do it by string comparison (a not even with a constant) 😢
If we're extending the capabilities of MiqAlerts let's do that in a generic way (e.g. we now need validation) and then let's keep the logic in separate modules (e.g. this belongs to the DWH provider I suppose).

@@ -72,6 +73,14 @@ def set_responds_to_events
self.responds_to_events = events unless events.nil?
end

def validate_delay_next_evaluation
next_frequency = (options || {}).fetch_path(:notifications, :delay_next_evaluation)
evaluation_method = expression[:eval_method] if expression.kind_of?(Hash)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suffix if means evaluation_method may be uninitialized, relies on uninitialized vars being nil in Ruby (depends on textual order, works in this case). Personally I would write it another way, but that's a matter of opinion, your call.
E.g. scope everything under if expression.kind_of?(Hash) && expression[:eval_method] == "dwh_generic" on top.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will wait on this one since this will likely take a different approach all together per comment

next_frequency = (options || {}).fetch_path(:notifications, :delay_next_evaluation)
evaluation_method = expression[:eval_method] if expression.kind_of?(Hash)
if !evaluation_method.nil? && evaluation_method == "dwh_generic" && !next_frequency.nil? && next_frequency != 0
errors.add(:notifications, "Datawarehouse alerts must have a 0 notification frequency")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confusing, "0 frequency" means never notify. Perhaps something like "0 notification interval"?
Also consider s/next_frequency/next_interval/ or next_delay...

Copy link
Author

@moolitayer moolitayer Mar 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes those names are much better, unfortunately that is the name in the UI.
At this point we might ask to change that, see ManageIQ/manageiq-ui-classic#678 (comment)

@moolitayer
Copy link
Author

@simon3z This refers to

{:name => "dwh_generic", :description => _("All Datawarehouse alerts"), :db => ["ContainerNode"], :responds_to_events => "datawarehouse_alert",
Maybe we better implement the ability for a validation restriction on that variable so the logic would be in one place?

@moolitayer
Copy link
Author

@gtanzillo can you take a look and comment on the direction of this pr?

can you suggest a direction for #14318 (comment) ? I'm really not sure what would be a good solution for this

@gtanzillo
Copy link
Member

@moolitayer I'm also uncomfortable with special casing DWH alerts. But, a suitable alternative doesn't come to mind. I'll need to give it some thought.

Also, can you elaborate what delay_next_evaluation = 0 means? It's not real clear to me from the description. Thanks.

@moolitayer
Copy link
Author

@gtanzillo yes delay_next_evaluation is only used here as far as I can see.

Lets say X = alert.delay_next_evaluation > 0, and a first event goes into the system triggering alert actions.
If X seconds seconds did not yet pass when a second event comes into the system, the alert would be not be evaluated for that alert.

Skipping evaluation in our use case is never desirable as every incoming alert should be translated to a status regardless of time.

@moolitayer
Copy link
Author

@gtanzillo please review ManageIQ/manageiq-ui-classic#678 as well, it is closely related.

def validate_delay_next_evaluation
next_frequency = (options || {}).fetch_path(:notifications, :delay_next_evaluation)
evaluation_method = expression[:eval_method] if expression.kind_of?(Hash)
if !evaluation_method.nil? && evaluation_method == "dwh_generic" && !next_frequency.nil? && next_frequency != 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@moolitayer Instead of hardcoding dwh_generic here, how about adding a flag to the definition of the expression indicating that is should always be evaluated. Something like this -

diff --git a/app/models/miq_alert.rb b/app/models/miq_alert.rb
index f4db271..0027abf 100644
--- a/app/models/miq_alert.rb
+++ b/app/models/miq_alert.rb
@@ -442,7 +442,7 @@ class MiqAlert < ApplicationRecord
           {:name => :value_mw_garbage_collector, :description => _("Duration Per Minute (ms)"), :numeric => true}
         ]},
       {:name => "dwh_generic", :description => _("All Datawarehouse alerts"), :db => ["ContainerNode"], :responds_to_events => "datawarehouse_alert",
-        :options => []}
+        :options => [], :always_evaluate => true}
     ]
   end

Then you can check that here with something like expression_by_name('dwh_generic')[:always_evaluate]. The same can be done on the UI side. What do you think?

@moolitayer
Copy link
Author

@gtanzillo thanks, please take a look
(also added tests)

@moolitayer
Copy link
Author

@gtanzillo if I understand correctly this should not effect ManageIQ/manageiq-ui-classic#678 could you review that one as well please?

(since only the :delay_next_evaluation and :name fields are sent in creation, the :always_evaluate is only on the backend )

@moolitayer
Copy link
Author

@gtanzillo Please review

@miq-bot
Copy link
Member

miq-bot commented Apr 4, 2017

Checked commit moolitayer@6d0abfa with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
3 files checked, 0 offenses detected
Everything looks good. 🏆

Copy link
Member

@gtanzillo gtanzillo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! 👍

@moolitayer
Copy link
Author

@gtanzillo Is this ready for merge or does it need additional reviews?

@gtanzillo gtanzillo added this to the Sprint 58 Ending Apr 10, 2017 milestone Apr 6, 2017
@gtanzillo gtanzillo merged commit aa40496 into ManageIQ:master Apr 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants