crowbar: Generate an event when a cluster config is changed #171
Conversation
This file contains 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
houndci-bot
reviewed
Jan 4, 2017
| @@ -15,6 +15,8 @@ | |||
| # limitations under the License. | |||
| # | |||
|
|
|||
| require 'set' | |||
There was a problem hiding this comment.
Style/StringLiterals: Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping. (https://github.com/SUSE/style-guides/blob/master/Ruby.md#stylestringliterals)
For now, we're only interested in changes in the public/admin name of haproxy. This event will be consumed by OpenStack barclamp so they know that the endpoint is changing. We may add other relevant attributes to the event later on if required.
aspiers
approved these changes
Feb 2, 2017
rsalevsky
approved these changes
Feb 6, 2017
scottwulf
added a commit
to scottwulf/crowbar-core
that referenced
this pull request
Aug 23, 2017
Rebase of PR crowbar#952 Only committing the infrastructure changes For usage example(s), 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.
scottwulf
added a commit
to scottwulf/crowbar-core
that referenced
this pull request
Aug 23, 2017
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.
scottwulf
added a commit
to scottwulf/crowbar-core
that referenced
this pull request
Aug 23, 2017
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.
scottwulf
added a commit
to scottwulf/crowbar-core
that referenced
this pull request
Aug 29, 2017
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.
scottwulf
added a commit
to scottwulf/crowbar-core
that referenced
this pull request
Aug 29, 2017
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.
scottwulf
added a commit
to scottwulf/crowbar-core
that referenced
this pull request
Aug 30, 2017
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
For now, we're only interested in changes in the public/admin name of
haproxy. This event will be consumed by OpenStack barclamp so they know
that the endpoint is changing.
We may add other relevant attributes to the event later on if required.
Depends on crowbar/crowbar-core#952