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

Ems event groups - allow provider settings #13942

Closed

Conversation

durandom
Copy link
Member

Allow provider plugins to participate in setting up EmsEvent.event_groups

In order to provide settings for event_handling.event_groups every provider had to include its event names into settings.yml - which grew massively to beyond recognition.

To split these into settings.yml in the provider repos I have to hook into the event_groups method (see [1] for reasons).
This patch iterates over all registered provider plugins and looks for the same event_handling.event_groups structure under the provider name key.

Eg.

:amazon:
  :event_handling:
    :event_groups:
      :addition:
        :critical:
        - AWS_EC2_Instance_CREATE
        - AWS_EC2_Instance_UPDATE
        - AWS_EC2_Instance_DELETE
      :power:
        :critical:
        - AWS_EC2_Instance_running
        - AWS_EC2_Instance_shutting-down
        - AWS_EC2_Instance_stopped

Then it merges the hash and more important merges the arrays of events.

see inline comments for questions

Includes #13941
Follows the suggestion in [1]

[1] ManageIQ/manageiq-providers-amazon#138

@@ -24,8 +24,22 @@ def self.task_final_events
::Settings.event_handling.task_final_events.to_hash
end

def self.provider_plugin_keys
Copy link
Member Author

Choose a reason for hiding this comment

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

could this method go into Vmdb::Plugins for re-use?

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good to me, maybe something like @provider_plugins to be populated on initialize.

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, makes sense. Then I can also skip the begin / rescue dance below

@miq-bot miq-bot added the wip label Feb 16, 2017
@durandom durandom force-pushed the ems_event_allow_provider_settings branch from 8360059 to 63318ae Compare February 16, 2017 14:55
Vmdb::Plugins.instance.vmdb_plugins.collect do |plugin|
begin
ManageIQ::Providers::Inflector.provider_name(plugin).downcase.to_sym
rescue ManageIQ::Providers::Inflector::ObjectNotNamespacedError
Copy link
Member Author

Choose a reason for hiding this comment

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

Do not suppress exceptions.

is it ok here?

Copy link
Member

Choose a reason for hiding this comment

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

I would probably compare the class names instead...

plugin.class.name.starts_with?("ManageIQ::Providers")

def self.event_groups
::Settings.event_handling.event_groups.to_hash
provider_plugin_keys.each_with_object(::Settings.event_handling.event_groups.to_hash) do |provider_key, event_groups|
next unless provider_event_group = ::Settings.fetch_path(provider_key, :event_handling, :event_groups)
Copy link
Member Author

Choose a reason for hiding this comment

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

Assignment in condition - you probably meant to use ==.

nope, I mean it. Should I split into two lines?

end
end.compact
end

def self.event_groups
Copy link
Member Author

Choose a reason for hiding this comment

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

If this is ok, I probably want to do this for bottleneck_event_groups too

if event_groups_val.kind_of?(Array) && provider_groups_val.kind_of?(Array)
event_groups_val + provider_groups_val
else
event_groups_val
Copy link
Member Author

Choose a reason for hiding this comment

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

this is meant to preserve String values like :name:

@durandom
Copy link
Member Author

@miq-bot add_labels pluggable providers, enhancement
@miq-bot assign @Fryguy

@Fryguy @bdunne please review

@durandom
Copy link
Member Author

@bdunne refactored to move the provider_plugins to Vmdb::Plugins. While there I made some imho internal methods private.

@durandom
Copy link
Member Author

If you guys are ok with it, I'll add some tests

@vmdb_plugins = []

Rails.application.railties.each do |railtie|
next unless railtie.class.name.start_with?("ManageIQ::Providers::") || railtie.try(:vmdb_plugin?)
Copy link
Member

Choose a reason for hiding this comment

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

@durandom Would you mind adding this to the engine.rb on the plugin generator? It would simplify this code.

def vmdb_plugin?
  true
end

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, I can. It's on my TODO 😄

Copy link
Member

Choose a reason for hiding this comment

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

Can the registered_provider_plugins logic be split into a stand alone PR, independent of EmsEvents and moving the initializer logic?

@vmdb_plugins = []

Rails.application.railties.each do |railtie|
next unless railtie.class.name.start_with?("ManageIQ::Providers::") || railtie.try(:vmdb_plugin?)
Copy link
Member

Choose a reason for hiding this comment

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

Can the registered_provider_plugins logic be split into a stand alone PR, independent of EmsEvents and moving the initializer logic?

@durandom
Copy link
Member Author

I'll extract the Vmdb::Plugins changes to #13941

@bdunne
Copy link
Member

bdunne commented Feb 17, 2017

@durandom I feel like thee are three different things. Listing Provider plugins, EmsEvents, and Plugin initialization

@durandom
Copy link
Member Author

durandom commented Feb 20, 2017

@bdunne

Once those are merged, I'll rebase this on top of them

@miq-bot
Copy link
Member

miq-bot commented Feb 20, 2017

This pull request is not mergeable. Please rebase and repush.

@@ -4,11 +4,17 @@ class Plugins

attr_reader :vmdb_plugins
attr_reader :registered_automate_domains
attr_reader :registered_provider_plugins
Copy link
Member

Choose a reason for hiding this comment

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

I think this should have been removed during rebase.

@durandom durandom force-pushed the ems_event_allow_provider_settings branch from c95e71b to 4113773 Compare February 20, 2017 20:42
@durandom durandom changed the title [WIP] Ems event groups - allow provider settings Ems event groups - allow provider settings Feb 20, 2017
@durandom
Copy link
Member Author

@miq-bot remove_label wip

@bdunne refactored a bit and squashed commits

@miq-bot miq-bot removed the wip label Feb 20, 2017
@durandom
Copy link
Member Author

@bdunne added specs for the change, please re-review

@durandom durandom force-pushed the ems_event_allow_provider_settings branch from 1c469fd to 70ca0a8 Compare February 21, 2017 11:49
Copy link
Member

@bdunne bdunne left a comment

Choose a reason for hiding this comment

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

Not too familiar with eventing, but 👍 LGTM
@Fryguy Any concerns?

Copy link
Member

@Fryguy Fryguy left a comment

Choose a reason for hiding this comment

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

I'm not a fan of the toplevel :amazon key given that we already have a toplevel :ems key that is designed for pluggable ems settings. I think the events can be nested under the respective key under the toplevel :ems key, and then there is no need to have any knowledge about plugins at all. The Settings constant will just contain everything in a known location and we can walk it. In this way there is no need to couple EmsEvent to Vmdb::Plugins at all.

So, for example, the Settings will look like:

:ems:
  :ems_amazon:
    :event_handling:
      :event_groups:
        :addition:
          :critical:
          - AWS_EC2_Instance_CREATE
          - AWS_EC2_Instance_UPDATE
          - AWS_EC2_Instance_DELETE
        :power:
          :critical:
          - AWS_EC2_Instance_running
          - AWS_EC2_Instance_shutting-down
          - AWS_EC2_Instance_stopped

Then, since we know that there's a bunch of provider specific keys under :ems, we just walk the keys, and look for ones with event_groups within them.

core_event_groups = ::Settings.event_handling.event_groups.dup

Settings.ems.each_with_object(core_event_groups) do |(_provider_type, provider_settings), event_groups|
  next unless provider_settings.event_groups
  # Existing deep_merge code
end

To take this a little further, the deep_merge method comes from the deep_merge gem, so you can probably replace the entirety of your merge code, with code that works exactly like how Config::Options works under the covers, but with merging of arrays enabled (or overwrite disabled, as it were):

event_groups.deep_merge!(provider_settings.event_groups.to_hash, :preserve_unmergeables => false, :overwrite_arrays => false)

@durandom
Copy link
Member Author

@Fryguy thanks for the review

we already have a toplevel :ems key that is designed for pluggable ems settings.

I saw that and was about to put it right there, but then I thought it's actually a good chance to move away from :ems, as we want to pivot toward talking about Providers and Managers.

But you have a point in decoupling from Vmdb::Plugins that we can just walk whatever is under :ems. (Maybe we can replace that by :provider sometime 😄

How about ditching the ems_ prefix then? So Settings.ems.amazon? Just say no and I'll put it at Settings.ems.ems_amazon (and put up a PR to change it, hehe)

deep_merge method comes from the deep_merge gem

oh, nice. Can I use this, although it's a dependency from the config gem? So it might go away if config drops the dependency. But for this I have the test...

@durandom
Copy link
Member Author

Wether it be :ems.ems_amazon or :ems.amazon doesnt need to be part of this PR, because this will now consume everyhing under :ems

I chose not to use deep_merge from the deep_merge gem, because a) it adds another dependency and b) it will allow to overwrite string values (the :name key - see here )

@durandom durandom force-pushed the ems_event_allow_provider_settings branch from 23f277b to e686839 Compare February 23, 2017 15:45
@miq-bot
Copy link
Member

miq-bot commented Feb 23, 2017

Checked commits durandom/manageiq@80c8cb7~...e686839 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
3 files checked, 0 offenses detected
Everything looks good. 🍪

@durandom
Copy link
Member Author

@Fryguy please see my last 2 comments, ok now?

@durandom
Copy link
Member Author

@Fryguy pling pling, are you good with this?

@Fryguy
Copy link
Member

Fryguy commented Mar 6, 2017

Closed in favor of #13942

@Fryguy Fryguy closed this Mar 6, 2017
@miq-bot
Copy link
Member

miq-bot commented Mar 6, 2017

This pull request is not mergeable. Please rebase and repush.

@NickLaMuro
Copy link
Member

@Fryguy Was following the changes and additions to Vmdb::Plugins, and came across this PR, and noticed that in your comment from above:

Closed in favor of #13942

That it is this PR that you are referencing instead of some other one. Did you mean #14177 perhaps? Based on the PR description, seems like that is the case, but wanted to confirm.

@durandom
Copy link
Member Author

@NickLaMuro that is correct.

self referencing PR links should throw a null pointer exception 8/

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