-
Notifications
You must be signed in to change notification settings - Fork 43
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 rule instance table in executor #3899
Conversation
c137cec
to
60bbaa6
Compare
c8f7e7b
to
8cbbbce
Compare
) | ||
|
||
// ProfileAggregate represents a profile along with rule instances | ||
type ProfileAggregate struct { |
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.
These new types are intended to address the fact that neither the protobuf or the database schema representations of Profile
match up neatly with what a lot of the code in minder actually needs. These will be used elsewhere in the codebase in future.
|
||
// ActionConfiguration stores the configuration state for a profile | ||
type ActionConfiguration struct { | ||
Remediate ActionOpt |
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.
These fields are isolated into an inner struct because various parts of the engine code previously passed around the whole profile to just get these two values.
ID uuid.UUID | ||
Name string | ||
ActionConfig ActionConfiguration | ||
Rules []RuleInstance |
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.
This type has Aggregate
in the name because it contains a list of rule instances as well as just representing the profile itself.
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
package profiles |
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.
This file could do with a test suite, but in practice most of it is already covered by existing unit tests.
d140cec
to
bb47df5
Compare
This PR changes the executor to load rule instances from the `rule_instances` table instead of using the serialized protobufs in `entity_profiles`. Using the `rule_instances` table, a new querying method is added to load all profiles relevant to evaluation, along with the rule instances for the entity type being evaluated. Two domain-level types - `ProfileAggregate` and `RuleInstance` are defined to represent the result of these queries. I have removed a lot of the protobuf usage from the evaluation code since converting to and from protobufs just adds complexity, and the new types line up with the values and types expected by the evaluation code. Tested locally, but definitely needs some smoke testing before rollout.
bb47df5
to
6c3e420
Compare
// The query is written in such a way that if a profile is deleted between | ||
// the rule instance query and this query, it will simply be omitted from | ||
// the results. | ||
profiles, err := p.store.BulkGetProfilesByID(ctx, maps.Keys(rulesByProfileID)) |
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.
One advantage of this new approach is that we do not have to query all profiles in the projects and then filter in the code - we can filter out irrelevant profiles at query time.
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.
this is very nice.
What do you think would be the best way to also retrieve selectors at the same time? For the old way of listing profiles by ID and project, we added a helper select and a join in 881c672 do you think we should use a similar approach here?
Alternatively we could add another query in the loop over profiles to get the profile selectors.
@dmjb I think this can be taken out of draft and unless you want more eyes, I'm fine acking the PR, too. I've tried different combinations of profiles with different entities and both evaluation, alerts and remediations work fine. The code is also looking much nicer. |
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.
You'll probably want to remove the DNM from the PR subject so that it doesn't appear in git history
PR #3899 accidentally removed a call to GetOnOffState, which allows individual actions to override the remediation and alerting status in the profile. This leads to some unusual behaviour, such as attempting to run the noop alerts and remediations instead of skipping them. This PR reinstates the calls to GetOnOffState, but changes the function to accept the ActionOpt status for that action type instead of taking a pointer to the entire profile.
PR #3899 accidentally removed a call to GetOnOffState, which allows individual actions to override the remediation and alerting status in the profile. This leads to some unusual behaviour, such as attempting to run the noop alerts and remediations instead of skipping them. This PR reinstates the calls to GetOnOffState, but changes the function to accept the ActionOpt status for that action type instead of taking a pointer to the entire profile.
This PR changes the executor to load rule instances from the
rule_instances
table instead of using the serialized protobufs inentity_profiles
.Using the
rule_instances
table, a new querying method is added to loadall profiles relevant to evaluation, along with the rule instances for
the entity type being evaluated. Two domain-level types -
ProfileAggregate
andRuleInstance
are defined to represent theresult of these queries. I have removed a lot of the protobuf usage from
the evaluation code since converting to and from protobufs just adds
complexity. The fields in the new domain types match up better with
the types expected by the engine code.
Tested locally, but definitely needs some smoke testing before rollout.
Summary
Provide a brief overview of the changes and the issue being addressed.
Explain the rationale and any background necessary for understanding the changes.
List dependencies required by this change, if any.
Fixes #(related issue)
Change Type
Mark the type of change your PR introduces:
Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist: