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

Use settings for filtered events #23320

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

@agrare agrare requested review from Fryguy and kbrock as code owners January 29, 2025 19:04
@@ -95,16 +95,16 @@ def before_exit(message, _exit_code)
def sync_blacklisted_events
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 can go away entirely - we already sync_settings

Copy link
Member Author

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

Copy link
Member Author

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
Copy link
Member

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.

Copy link
Member Author

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

@Fryguy
Copy link
Member

Fryguy commented Jan 29, 2025

I realize this is WIP, but MUCH EXCITE

@Fryguy Fryguy self-assigned this Jan 29, 2025
Array(::Settings.ems["ems_#{provider_name.underscore}"].try(:blacklisted_event_names))
Array(::Settings.ems["ems_#{ems_type}"].try(:blacklisted_event_names))
Copy link
Member Author

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

@agrare agrare requested a review from jrafanie as a code owner January 29, 2025 19:42
Comment on lines 91 to 93
def filtered_events
@ems.class.default_blacklisted_event_names
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.

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
Copy link
Member Author

@agrare agrare Jan 29, 2025

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

Copy link
Member

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?

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 it was just implemented globally, because reasons - I don't recall it being for anything but event catchers in practice.

Copy link
Member Author

@agrare agrare Jan 31, 2025

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)

@Fryguy
Copy link
Member

Fryguy commented Jan 29, 2025

Obligatory @-mention of @jrafanie for this wonderful 🔥 ✂️ 🗑️

miq-bot pushed a commit to ManageIQ/manageiq-cross_repo-tests that referenced this pull request Jan 30, 2025
@agrare
Copy link
Member Author

agrare commented Jan 30, 2025

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 .default_blacklisted_event_names method and is only a handfull of them. The second will be to change the Settings blacklisted_event_names to match the new filtered_event_names name and will hit way more providers.

@jrafanie
Copy link
Member

Obligatory @-mention of @jrafanie for this wonderful 🔥 ✂️ 🗑️

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?

@Fryguy
Copy link
Member

Fryguy commented Jan 31, 2025

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.

@agrare
Copy link
Member Author

agrare commented Jan 31, 2025

I believe there is a column for "system" blacklisted events

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.

@agrare agrare changed the title [WIP] Use settings for filtered events Use settings for filtered events Feb 5, 2025
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.

3 participants