-
Notifications
You must be signed in to change notification settings - Fork 11
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
Mount info gatherer #284
Mount info gatherer #284
Conversation
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 output looks good to me @arbulu89
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.
Perfect @arbulu89, great work! left some thoughts in the comments but no need to do anything about them
{ | ||
Name: "shared", | ||
Gatherer: "mount_info", | ||
CheckID: "check1", |
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've noticed that sometimes we use the same checkid for factrequests in the tests, while other times we put incrementally increased ones and sometimes we don't put it at all. Should we apply some logic when doing so? if on the contrary, it doesn't matter at all for the tests, should we better just remove it?
No need to change anything, just wondering about 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.
It is true that it doesn't add a lot of real value. This is already tested in other places. At most, if you don't use the NewFactGatheredWithRequest
, it could fail, as you forgot to pass the check id.
For me it is a good practice, as the CheckID
is a mandatory field for our contract data
Value: map[string]entities.FactValue{ | ||
"block_uuid": &entities.FactValueString{Value: ""}, | ||
"fs_type": &entities.FactValueString{Value: ""}, | ||
"mount_point": &entities.FactValueString{Value: ""}, |
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.
For now, this is perfect IMHO, in the future if we want to also detect more complex scenarios we could decompose the mountpoint when it's not found and test backwards if the parent exists, e.g. /usr/sap
passed as argument would first need to check /usr/sap
and if doesn't find it, it would check /usr
and if not found, it could then fallback to /
and just return the details stating in mount_point
the parent mountpoint of that path.
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.
Let's see if we have such a requirement hehe
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.
Hey man codewise lgtm :)
7207cb3
to
d130537
Compare
Add
mount_info
gatherer. This gatherer returns if a given path is mounted, and its information. Besides that, in case of mounted, it returns theblkid
UUID
value of that block.The
path
to check is the required argument.If it is not mounted, it returns all the fields as empty string. I needed to do so, because checking if a path (
/usr/sap
) is not mounted (or it is directly in theroot
folder` is the main reason this gatherer exists.If the path is mounted in nfs-kind of sharing system, the
block_uuid
comes emptySome outputs: