Create event hook infrastructure#1308
Merged
scottwulf merged 1 commit intocrowbar:masterfrom Aug 30, 2017
Merged
Conversation
matelakat
suggested changes
Aug 24, 2017
Contributor
matelakat
left a comment
matelakat
left a comment
There was a problem hiding this comment.
My Main worry is that a non-properly implemented event handler might prevent other handlers to be called.
| begin | ||
| service.event_hook(role, event, details) | ||
| rescue StandardError => e | ||
| raise "Error while executing event hook of #{barclamp} for #{event}: #{e.message}" |
Contributor
There was a problem hiding this comment.
Maybe we want to include that it is for a specific proposal - as if the barclamp has multiple proposals, it might fail in one of them?
| role = proposal.role | ||
| next if role.nil? | ||
| begin | ||
| service.event_hook(role, event, details) |
Contributor
There was a problem hiding this comment.
What happens if event_hook is implemented badly and raises an error? I guess in that case we raise and do not execute the hook for the rest of the barclamps?
houndci-bot
reviewed
Aug 29, 2017
| Rails.logger.error( | ||
| "Error while executing event_hook for barclamp '#{barclamp}', " \ | ||
| "proposal '#{proposal.name}', and event '#{event}'. " \ | ||
| "Error message is '#{e.message}'.") |
There was a problem hiding this comment.
Layout/MultilineMethodCallBraceLayout: Closing method call brace must be on the line after the last argument when opening brace is on a separate line from the first argument.
Rebase of PR crowbar#952 but only including the new infrastructure class For usage examples, see: crowbar#952 crowbar/crowbar-ha#171 crowbar/crowbar-openstack#717 There are several cases where we have events that should trigger some activity in some other part of Crowbar. For instance: - when the public name of a node is saved, it may impact the endpoint of an OpenStack service - when the public name of the VIP of haproxy is changed, it impacts the endpoint of OpenStack services - when the keystone proposal is applied, we may want to reapply all proposals that depend on keystone What we need for this is the ability to notify about the events in the rails application and then dispatch the notifications to hooks which listen for them and decide if some action should be triggered. The main reason we didn't have this in the past is that we likely don't want to do that in the foreground of the rails application. But now that we have delayed_job, we can send the notifications and run the hooks in the background. In this commit, we add the simple infrastructure about notifications and hooks: - the events are defined with a name and a hash that contains the details of the event. The structure of the hash depends on the event. - a simple dispatcher exists that simply connects the hooks to the events. - the hooks only exist for service objects for the time being; a service object simply needs to have a event_hook method to register the hook, and will need to filter for the events it cares about. The signature of event_hook is as follows: def event_hook(role, event, details) It could be argued that the hooks should be registered for some specific events (hence moving the filter to the event dispatcher), but it's not worth the complexity for now.
matelakat
approved these changes
Aug 30, 2017
Contributor
Contributor
|
@scottwulf we usually wait for 2 approvals before merging. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rebase of PR #952 but only including the new infrastructure class
For usage examples, see:
#952
crowbar/crowbar-ha#171
crowbar/crowbar-openstack#717
There are several cases where we have events that should trigger some
activity in some other part of Crowbar. For instance:
of an OpenStack service
endpoint of OpenStack services
proposals that depend on keystone
What we need for this is the ability to notify about the events in the
rails application and then dispatch the notifications to hooks which
listen for them and decide if some action should be triggered.
The main reason we didn't have this in the past is that we likely don't
want to do that in the foreground of the rails application. But now that
we have delayed_job, we can send the notifications and run the hooks in
the background.
In this commit, we add the simple infrastructure about notifications and
hooks:
the events are defined with a name and a hash that contains the
details of the event. The structure of the hash depends on the event.
a simple dispatcher exists that simply connects the hooks to the
events.
the hooks only exist for service objects for the time being; a
service object simply needs to have a event_hook method to register
the hook, and will need to filter for the events it cares about. The
signature of event_hook is as follows:
def event_hook(role, event, details)
It could be argued that the hooks should be registered for some specific
events (hence moving the filter to the event dispatcher), but it's not
worth the complexity for now.