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

Migrate trusty eval engine to Trusty v2 API. #5013

Merged
merged 3 commits into from
Nov 25, 2024

Conversation

blkt
Copy link
Contributor

@blkt blkt commented Nov 20, 2024

Summary

This change migrates trusty evaluation engine to use Trusty v2 API. Most of the changes apply to the intermediate representation we recently added to decouple Trusty from Minder, but some additional changes were required due to some fields becoming optional and nullable.

Note: this change is again meant to be bug-compatible with the current evaluation engine, so we treat the lack of "score" as a score of 0, thus triggering false positives as done by the current engine. The idea is to build on top of this to fix known issues of the engine before migrating it to Data Sources.

Fixes stacklok/minder-stories#77

Change Type

  • Bug fix (resolves an issue without affecting existing features)
  • Feature (adds new functionality without breaking changes)
  • Breaking change (may impact existing functionalities or require documentation updates)
  • Documentation (updates or additions to documentation)
  • Refactoring or test improvements (no bug fixes or new functionality)

Testing

Updated unit tests, ran smoke tests locally.

Review Checklist:

  • Reviewed my own code for quality and clarity.
  • Added comments to complex or tricky code sections.
  • Updated any affected documentation.
  • Included tests that validate the fix or feature.
  • Checked that related changes are merged.

@blkt blkt self-assigned this Nov 20, 2024
go.mod Outdated Show resolved Hide resolved
internal/engine/eval/trusty/actions.go Outdated Show resolved Hide resolved
@blkt blkt force-pushed the feat/trusty-engine-v2-api branch from 5432bcd to c4601e0 Compare November 21, 2024 08:25
@coveralls
Copy link

coveralls commented Nov 21, 2024

Coverage Status

coverage: 54.582% (-0.05%) from 54.633%
when pulling 026b68d on feat/trusty-engine-v2-api
into 0c315ea on main.

@blkt blkt force-pushed the feat/trusty-engine-v2-api branch 2 times, most recently from 6b37f59 to 026b68d Compare November 22, 2024 12:09
@blkt blkt marked this pull request as ready for review November 22, 2024 12:23
@blkt blkt requested a review from a team as a code owner November 22, 2024 12:23
evankanderson
evankanderson previously approved these changes Nov 22, 2024
Copy link
Member

@evankanderson evankanderson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few small comments, but nothing to block you if you want to go ahead as-is.

Comment on lines 308 to 318
respSummary, err := trustyClient.Summary(ctx, input)
if err != nil {
return nil, fmt.Errorf("failed getting summary: %w", err)
}

respPkg, err := trustyClient.PackageMetadata(ctx, input)
if err != nil {
return nil, fmt.Errorf("failed getting package metadata: %w", err)
}

respAlternatives, err := trustyClient.Alternatives(ctx, input)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not required, but you might want to issue these calls in parallel, since they may be around a second each. It's a bunch more code, though, so it's also fine to just leave a comment for now:

Suggested change
respSummary, err := trustyClient.Summary(ctx, input)
if err != nil {
return nil, fmt.Errorf("failed getting summary: %w", err)
}
respPkg, err := trustyClient.PackageMetadata(ctx, input)
if err != nil {
return nil, fmt.Errorf("failed getting package metadata: %w", err)
}
respAlternatives, err := trustyClient.Alternatives(ctx, input)
summary := make(chan *v2types.PackageSummaryAnnotation, 1)
metadata := make(chan *v2types.TrustyPackageMetadata, 1)
alternatives := make(chan *v2types.PackageAlternatives, 1)
errors := make(chan error)
defer go func() {
close(summary)
close(metadata)
close(alternatives)
close(errors)
}
go func() {
resp, err := trustyClient.Summary(ctx, input)
errors <- err
summary <- resp
}()
go func() {
resp, err := trustyClient.PackageMetadata(ctx, input)
errors <- err
metadata <- resp
}()
go func() {
resp, err := trustyClient.Alternatives(ctx, input)
errors <- err
alternatives <- resp
}
for (int i = 0; i < 3; i++) {
err := <- errors
if err != nil {
return nil, fmt.Errorf("Trusty call failed: %w", err)
}
}
respSummary := <- summary
respPkg := <- metadata
respAlternatives := <-alternatives

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I integrated this suggestion.

}

res := makeTrustyReport(dep, resp)
respProvenance, err := trustyClient.Provenance(ctx, input)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This would follow the same pattern above)

}

res := makeTrustyReport(dep, resp)
respProvenance, err := trustyClient.Provenance(ctx, input)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know whether the Trusty client is emitting metrics on these calls that we could use to track performance over time?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it emits the following metrics via headers, but they're not yet exposed by the client library.

x-ratelimit-limit: 480, 480;w=3600
x-ratelimit-remaining: 479
x-ratelimit-reset: 2879

I'm adding an issue to stacklok/trusty-sdk-go to expose them.
stacklok/trusty-sdk-go#57

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd actually meant the HTTP client-observed latency distribution and error rate

Comment on lines +354 to +357
const (
better packageComparison = iota
worse
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the same contract as e.g. slices.SortFunc and use positive numbers to indicate a > b, and negative numbers for a < b?

That would also allow us to use slices.SortFunc elsewhere for lists of packages with the comparison function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, comparePackages arguments are of different types, so it would not be possible to use that as argument to slices.SortFunc.

I'm inclined to keep this implementation because

  • it's unclear whether smaller-is-better or greater is
  • the score is deprecated, so this comparison doesn't really make sense anymore
  • we're moving pr_trusty_check rule to Data Sources and Rego evaluation type

@@ -428,8 +448,12 @@ func newSummaryPrHandler(
}, nil
}

func preprocessDetails(s string) string {
scanner := bufio.NewScanner(strings.NewReader(s))
func preprocessDetails(s *string) string {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change this to take a *string? (If so, this looks like the correct behavior)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because its argument maliciousInfo.Details is now a pointer to string.
I can change this, but I'd have to move the nil check to the caller.


return res
}

func makeScoreComponents(descr map[string]any) []scoreComponent {
func addSummaryDetails(res *trustyReport, resp *trustytypes.PackageSummaryAnnotation) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we get a nil annotation response without an error? If not, maybe pass through the concrete type or document that it can't be nil.

Comment on lines -397 to +472
Score: &alt.Score,
Score: alt.Score,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 to removing pointer types where possible; it reduces the number of times we need to remember nil checks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add an issue to stacklok/trusty-sdk-go to improve quality by removing pointer types where possible.
stacklok/trusty-sdk-go#58

blkt added 3 commits November 25, 2024 13:24
This change migrates `trusty` evaluation engine to use Trusty v2
API. Most of the changes apply to the intermediate representation we
recently added to decouple Trusty from Minder, but some additional
changes were required due to some fields becoming optional and
nullable.

Note: this change is again meant to be bug-compatible with the current
evaluation engine, so we treat the lack of `"score"` as a score of
`0`, thus triggering false positives as done by the current
engine. The idea is to build on top of this to fix known issues of the
engine before migrating it to Data Sources.

Fixes stacklok/minder-stories#77
@blkt blkt force-pushed the feat/trusty-engine-v2-api branch from ed006e4 to bae5027 Compare November 25, 2024 12:25
@blkt
Copy link
Contributor Author

blkt commented Nov 25, 2024

@evankanderson I should have addressed all comments.
I'll be traveling today, could you kindly merge this if you think it's ok?

@evankanderson evankanderson merged commit 3fbc363 into main Nov 25, 2024
25 checks passed
@evankanderson evankanderson deleted the feat/trusty-engine-v2-api branch November 25, 2024 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants