-
Notifications
You must be signed in to change notification settings - Fork 13
ROX-12238: Add node analysis package #911
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
Conversation
a506b38
to
a5de780
Compare
Images are ready for the commit at 0ab82fb. To use the images, use the tag |
You can generate the diff by changing the merge into branch from master to 'jvdm/ROX-12238/1/pull' in this case. |
pkg/analyzer/nodes/node.go
Outdated
matcher := requiredfilenames.SingletonOSMatcher() | ||
files, err := extractFilesFromDirectory(rootFSdir, matcher) | ||
if err != nil { | ||
return Components{}, err |
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 am curious in case of error, why not returning (nil, err)?
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.
No reason. Happy to change if there is an exact concern on returning an empty 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.
In that case, it is recommended to use nil.
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.
Could you please share a reference of why this is the recommendation?
I've found https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices but that is for slices, which are treated as empty when nil
. Could not find something specific for structs in general.
pkg/analyzer/nodes/node.go
Outdated
if err != nil { | ||
return Components{}, nil | ||
} | ||
// File reading errors during analysis failed are not exposed to DetectFiles, |
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.
nit: ... during failed analysis...
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.
👍
fileExtractionErrorCountMetric = prometheus.NewHistogram(prometheus.HistogramOpts{ | ||
Name: "file_extraction_error_count", | ||
Help: "Number of files in an node filesystem scan that failed to read", | ||
Buckets: []float64{50, 100, 500, 1000}, |
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.
Is 50 too small as error count histogram?
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.
Same as above.
pkg/analyzer/nodes/node.go
Outdated
return filepath.WalkDir(filepath.Join(n.root, dir), func(fullPath string, entry fs.DirEntry, err error) error { | ||
if err != nil { | ||
if filesIsNotAccessible(err) { | ||
m.ErrorCount() |
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.
The errorcount is only for filesIsNotAccessible error? If so, is it good to specify it in the context of the error for the reader of the metrics?
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.
Not sure if I follow. Are you suggesting we should modify the metric to make it more clear that it is tracking only inaccessible files, or something entirely different?
Notice that on every other error we fail the scan entirely.
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.
The metrics by themselves suggest that it is the error count. Even if we fail the scan, the metrics readers are not in the context of the scan. You could either count all the errors or make it clear with either name or help of the metrics.
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.
👍 Thanks for clarifying.
}, nil | ||
} | ||
|
||
// Get implements analyzer.Files |
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.
Can you explain more the function of Get function?
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.
The details are explained in the documentation of analyzer.Files
. If you have a better way of linking them together let me know.
41b9775
to
c257e53
Compare
a5de780
to
1354404
Compare
If I target the PR into |
1354404
to
0ab82fb
Compare
/retest |
@jvdm: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
// the files of a filesystem or image layer. For layers, the parent layer should | ||
// be specified. For filesystems, which don't have the concept of intermediate | ||
// layers, or the root layer, use `nil`. Notice that language components are not | ||
// extracted by DetectFromFiles, but if provided they are annotated with |
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.
if provided they are annotated with certified RHEL dependencies
Not sure I follow
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.
Language components are not detected by this function, rather they are detected by the analyzers embedded in the matcher. But we pass components here so that the certified RHEL path will annotate the components with package info.
Personally, I would leave that piece out of the detector, arguing that it should be its responsibility to annotate language components. But OK the way it is.
fileExtractionMatchCountMetric.Observe(m.fileCount) | ||
fileExtractionInaccessibleCountMetric.Observe(m.inaccessibleCount) | ||
} | ||
*m = FileExtractionMetrics{} |
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.
if m == nil
, then this will segfault
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.
+1
|
||
// Information about extracted files. | ||
type fileMetadata struct { | ||
// If true, the file has executable permissions. |
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.
Is this also a regular file?
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.
// will stop returning entries and the error will be available at readErr(). | ||
// Analyzer are expected to handle missing files gracefully during analysis and | ||
// check readErr() to confirm all potential data was read. | ||
type filesMap 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.
can we add a line
var _ analyzer.Files = (*filesMap)(nil)
See https://github.com/uber-go/guide/blob/master/style.md#verify-interface-compliance
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.
+1
|
||
// readErr returns the first error encountered when reading file content, and | ||
// resets the error, enabling re-scans using the same map. | ||
func (n *filesMap) readErr() error { |
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.
who calls this?
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.
Just after clair.DetectFromFiles()
(now clair.DetectComponents()
), to verify if there was any error when reading files during detection.
wantErr: assert.NoError, | ||
}, | ||
{ | ||
name: "when file is extractable and size is bigger then the limit then return nothing", |
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.
nit: than instead of then
wantExists: true, | ||
}, | ||
{ | ||
name: "when file is in map and is extractable but does not exist, then keep error", |
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.
how does this happen?
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.
Between extraction and reading the file might have moved, was deleted, changed permission or something else happened to the underlying filesystem (e.g. failures).
if err != nil { | ||
return nil, nil | ||
} | ||
// File reading errors during analysis are not exposed to DetectFiles, hence we |
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.
nit: DetectFromFiles
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.
+1
This PR is built on top of #904 (please filter commits in the diff for a narrowed view of the changes).
Add
Analyze()
topkg/analyzer/nodes
, including related changes to allow external packages (in particular, Compliance) to consume it.node.Analyze
is built on the recently introduced interfaces added topkg/analyzer
, and re-usesclair.DetectContentFromFile()
.Other marginal changes:
analyzer
package.Tests
UTs.
Local validation, here's the code (omitting imports):
Next steps: E2E.