-
Notifications
You must be signed in to change notification settings - Fork 1.6k
sla_config: use mass update for recalculation #12133
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
sla_config: use mass update for recalculation #12133
Conversation
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
4502fac
to
622a011
Compare
Conflicts have been resolved. A maintainer will review the pull request shortly. |
DryRun Security SummaryA multi-file patch introduces potential security risks through modified logging practices, async task argument changes, and SLA configuration retrieval mechanisms that could expose sensitive information and bypass existing validation protections. Expand for full summarySummary: A patch across multiple files modifies SLA configuration, product, and utility functions with changes to logging, function signatures, and async task management. Security Findings:
• Potential Behavioral Changes
• Logging Considerations
• Model Update Mechanism
• SLA Configuration Retrieval
|
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.
Approved
* sla_config_updater: add logging * sla_config: use mass update on changes * sla_config: use mass update on changes * sla_config: use mass update on changes * sla_config: use mass update on changes * sla_config: use mass update on changes * sla_config: use mass update on changes * sla_config: use mass update on changes * sla_config: use mass update on changes * cleanup
This PR optimizes the updating of the
sla_expiration_date
field. A change to an SLA Configuration or Product can trigger a recalculation of this field for all affected findings.Before this PR this took ~8.5 minutes for 20k findings. This is on a i9 16 core with an NVM SSD.
This PR used the
mass_model_updater
function that has proven to work more efficiently. Now the job completes in ~30s time.Before this PR, every finding would be post processed in the background celery work. This isn't needed as a change to the SLA expiration doesn't affect dedupe or pushing to JIRA. Also the product grade would be calculated for each affected finding (so multiple times per product). This is not needed. This background work took over 30 minutes for 20k (I killed the instance after 30 minutes).
The PR also removes some code duplication.
I can imagine this change is also beneficial for Pro users where larger instances are more common, as well as more intensive usage of the instances.