Blacklisted events are not user-configurable

[carbonin]

There are two issues that are contributing to this problem.

1. Editing the blacklisted events list for an provider type does not create a BlacklistedEvent record
   • This feels like it should happen directly
   • Better yet an actual UI or API for blacklisted events would be ideal
2. Some (all?) providers override the base implementation of ExtManagementSystem.default_blacklisted_event_names
   • This is relevant because it causes the events added to the advanced config to not be seen on seed
   • The base implementation is here and an example of the overridden version for rhv is here
   • If the provider plugins merged their event names with the ones in config (i.e. called super) the user's events would at least get created at the next seed.

Right now the only way for a user to create a new blacklisted event is to do so manually through the rails console.
Ideally there would be a UI and API for blacklisted events, but failing that we should at least honor the events configured in the advanced settings screen.

cc @agrare

• Devise name schema for providers with multiple managers (amazon, openstack, ovirt, vmware)
• Determine if we want to keep these values in code or put all of them into settings
• delete unnecessary method from manageiq-providers-amazon/app/models/manageiq/providers/amazon/cloud_manager.rb
• fix manageiq-providers-amazon/app/models/manageiq/providers/amazon/network_manager.rb
• delete unnecessary method from manageiq-providers-azure/app/models/manageiq/providers/azure/cloud_manager.rb
• fix manageiq-providers-openstack/app/models/manageiq/providers/openstack/storage_manager/cinder_manager.rb
• fix manageiq-providers-openstack/app/models/manageiq/providers/openstack/infra_manager.rb
• fix manageiq-providers-openstack/app/models/manageiq/providers/openstack/network_manager.rb
• fix manageiq-providers-openstack/app/models/manageiq/providers/openstack/cloud_manager.rb
• fix manageiq-providers-ovirt/app/models/manageiq/providers/ovirt/infra_manager.rb
• fix manageiq-providers-ovirt/app/models/manageiq/providers/ovirt/network_manager.rb
• fix manageiq-providers-vmware/app/models/manageiq/providers/vmware/infra_manager.rb
• fix manageiq-providers-vmware/app/models/manageiq/providers/vmware/cloud_manager.rb
• oracle has blacklisted events in settings
• other providers have nothing in settings, but can be overridden

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the traige process documentation.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[kbrock]

so sounds like 2 options:

• edit the provider's blacklisted events to merge with super
• move the events into settings.

Do we really want this list to be user configurable?

[kbrock]

Autodetecting these changes seems a bit over the top. Especially since this will typically be done from rails console. Sure, auto detection would be nice, but the bigger fish to fry here is allowing this to be configurable by the customer)

SettingsChange.create!(
  :resource => MiqRegion.my_region,
  :key      => "/ems/ems_vmware/blacklisted_event_names",
  :value    => ["TaskEvent"]

BlacklistedEvent.seed

Currently, we use the following code to add an event to vmware:

BlacklistedEvent.create!(:event_name => "TaskEvent", :provider_model => "ManageIQ::Providers::Vmware::InfraManager", :system => false)

[Fryguy]

So, IMO, this should 100% be in settings. We come out of the box with a list of default events in the settings, pluggable by provider, then the user can update it as needed. We should delete the BlacklistedEvent model, the blacklisted_events table, and provide a data migration for any existing user records in blacklisted_events over to the settings, if possible. There is also the "sync" of blacklisted_events, which can go away because we already have syncing of settings.

While we're at it, we should rename blacklisted_events to something else like filtered_events. I feel the latter is much clearer in intent.

This is the original issue to move the event filters into the database: #3273 & #3636. However I don't know what the motivation was behind it. I think it was because way back we used to have separate files for different configurations, and this was also before the settings revamp allowing user changes and layering, so this looks like an effort to make it easier for users.

[Fryguy]

@agrare I think the new PRs have broken a spec on master which verifies the count of BlacklistedEvent. See #23319 (comment)

  1) BlacklistedEvent.seed re-seeds deleted event filters
     Failure/Error: expect(described_class.count).to eq(total_blacklist_entry_count - 1)

       expected: 129
            got: 127

       (compared using ==)
     # ./spec/models/blacklisted_event_spec.rb:14:in `block (3 levels) in <top (required)>'

[agrare]

Fixed by ManageIQ/manageiq-providers-vmware#936