-
Notifications
You must be signed in to change notification settings - Fork 900
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
Use settings for filtered events #23320
base: master
Are you sure you want to change the base?
Conversation
@@ -95,16 +95,16 @@ def before_exit(message, _exit_code) | |||
def sync_blacklisted_events |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can go away entirely - we already sync_settings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I'm testing that the @filtered_events
ivar is also reloaded when settings change (ref vs copy) when pointing to the Config object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup confirmed that @filtered_events
had the old copy of the array but after sync_config
@ems.class.default_blacklisted_event_names
has the updated list so that's perfect.
@@ -57,7 +57,7 @@ def self.http_proxy | |||
end | |||
|
|||
def self.default_blacklisted_event_names |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably want to rename this to blacklisted_event_names
, since it's not a default anymore. If we really need the default there is a way to load the settings without the user's changes, but that feels unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this is the goal, will need to sync with a number of providers at the same time hence wip
I realize this is WIP, but MUCH EXCITE |
Array(::Settings.ems["ems_#{provider_name.underscore}"].try(:blacklisted_event_names)) | ||
Array(::Settings.ems["ems_#{ems_type}"].try(:blacklisted_event_names)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE this will let us delete most of the overrides in the providers, I think Vmware::InfraManager is the only one where ems_type != the settings key
def filtered_events | ||
@ems.class.default_blacklisted_event_names | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE we probably don't even need this method since the providers could use their Settings.ems.ems_type directly
@@ -266,7 +266,6 @@ def sync_config | |||
Vmdb::Settings.reload! | |||
@my_zone ||= MiqServer.my_zone | |||
sync_worker_settings | |||
sync_blacklisted_events |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wild that this was in the base MiqWorker::Runner
class 🤷
Not sure why the EventCatcher didn't just do this in after_sync_config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wow, this must be old... I wonder what non-event workers would need to sync blacklisted events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was just implemented globally, because reasons - I don't recall it being for anything but event catchers in practice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I don't see any rationale in the original PR for why it was in the base base worker. The sync_blacklisted_events method was added to the BaseManager::EventCatcher::Runner
in an earlier commit in the same PR then added to the base worker towards the end (guessing they saw it wasn't being called so just added it to the base class)
Obligatory @-mention of @jrafanie for this wonderful 🔥 ✂️ 🗑️ |
From Pull Request: ManageIQ/manageiq#23320
There are two sets of changes that will involve dependent provider prs, the first is what I have linked right now which just changes the providers which had overridden the |
It's definitely has the adds/deletes ratio done correctly! haha, I can't wait to see the migration ... how do we migrate from what we have now in some things using black listed events model to settings? |
I believe there is a column for "system" blacklisted events, so we can filter on that for "user" events. Then, we'd have to stick it into an existing provider-specific payload, and I'm actually not sure how to do that without picking either a random provider, or just putting it under all providers. Vmdb::Settings has a way to get the "base" configuration before applying the user overrides, so you could grab the provider's out of the box list of filtered events, then tack on the extra event(s) and write it directly to the SettingsChange table. |
Any events added via Advanced Settings and then seeded would be marked as system, the only ones which wouldn't would be if someone manually created a BlacklistedEvent record via the rails console. I think the only guaranteed way is going to be to have in the migration a map of provider_model=>settings_key and a full list of default blacklisted settings per settings_key. |
Dependents:
#19707