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

replace usage of dmidecode with kenv on FreeBSD #621

Merged
merged 1 commit into from
Nov 6, 2020

Conversation

igalic
Copy link
Collaborator

@igalic igalic commented Oct 22, 2020

Proposed Commit Message

FreeBSD lets us read out kernel parameters with kenv(1), a user-space utility that's shipped in "base"
We can use it in place of dmidecode(8), thus removing the dependency on sysutils/dmidecode, and the restrictions to i386 and x86_64 architectures that this utility imposes on FreeBSD.

Additional Context

I added this code, and while it opened the doors for more BSD stuff to be added, I'd like to remedy this restriction.
I'd also like to remind that @goneri already pointed this path out a year ago: #42 (comment)

Test Steps

run kenv | grep smbios on your favourite FreeBSD machine, and notice that unlike dmidecode you can just run it without being root!

Checklist:

  • My code follows the process laid out in the documentation
  • I have updated or added any unit tests accordingly
  • I have updated or added any documentation accordingly

@igalic igalic changed the title add translation table for dmidecode to kenv replace usage of dmidecode with kenv on FreeBSD Oct 22, 2020
@goneri
Copy link
Contributor

goneri commented Oct 22, 2020

You can also drop dmidecode from the dependency list in tools/build-on-freebsd.

@igalic
Copy link
Collaborator Author

igalic commented Oct 22, 2020

this is far from done…

cloudinit/util.py Outdated Show resolved Hide resolved
@igalic igalic force-pushed the fix-regression/dmidecode-freebsd branch 3 times, most recently from 1dd9a74 to 40e58d0 Compare October 26, 2020 18:06
@igalic igalic force-pushed the fix-regression/dmidecode-freebsd branch 2 times, most recently from 5f552de to 66f7751 Compare November 3, 2020 10:00
@TheRealFalcon TheRealFalcon self-assigned this Nov 3, 2020
@igalic igalic force-pushed the fix-regression/dmidecode-freebsd branch from faee463 to 963690e Compare November 5, 2020 11:03
Copy link
Collaborator

@smoser smoser left a comment

Choose a reason for hiding this comment

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

Fix the hard coded path and the exception. Humor me and think about the DMIDECODE map rework.

cloudinit/dmi.py Outdated Show resolved Hide resolved
cloudinit/dmi.py Outdated Show resolved Hide resolved
cloudinit/dmi.py Show resolved Hide resolved
@igalic igalic force-pushed the fix-regression/dmidecode-freebsd branch 2 times, most recently from e8dddce to 37ca15c Compare November 6, 2020 10:03
@igalic igalic requested a review from smoser November 6, 2020 10:07
Copy link
Collaborator

@smoser smoser left a comment

Choose a reason for hiding this comment

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

looks good. some comments inline.

one thought... I think we could use functools.lru_cache on is_container. In real life, the result is never going to change... we don't go from being inside a container to not inside a container in the same python process (at least cloud-init doesn't). And that will save us several calls to subprocess.

I did a quick test, and adding lru_cache didn't seem to break any unit tests. Probably because we don't actually have unit tests for the is_container function.

_is_container_systemd,
_is_container_upstart,
_is_container_old_lxc,
_is_container_freebsd)
Copy link
Collaborator

Choose a reason for hiding this comment

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

i just threw this together, with no test at all. i'm surprised that it apparently passes tests.

I think it is probably sane to put _is_container_freebsd before upstart or old_lxc... as i think its probably more likely for this new thing in cloud-init to run on freebsd than a 2014 era linux.

return False
try:
subp.subp(cmd)
return True
Copy link
Collaborator

Choose a reason for hiding this comment

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

i dont know on convention, but it seems maybe move 'return True' to outside the try. as it is probably more than a little bit unlikely for 'return True' to raise a subprocesserror. (and yes, i'm fully aware that I wrote that).

cloudinit/dmi.py Show resolved Hide resolved
cloudinit/dmi.py Outdated
@@ -111,6 +140,9 @@ def read_dmi_data(key):
if syspath_value is not None:
return syspath_value

if is_FreeBSD():
return _read_kenv(key)

Copy link
Collaborator

Choose a reason for hiding this comment

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

seems like you might as well bump this up above the '_read_dmi_syspath' call.
theres no point in looking in /sys on freebsd, right? So that would always be a wasted stat (inside _read_dmi_syspath) on freebsd. And on linux we'd just pay the '@lru_cache' call is_FreeBSD.

I'm not sure if that is clear...
short summary: just move this up above the call to _read_dmi_syspath.

warn "No kenv program. Cannot read $sys_field."
return 1
}
case "$1" in
Copy link
Collaborator

Choose a reason for hiding this comment

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

you shoudl use $sys_field rather than $1.

return 1;;
esac
val=$(kenv -q $kenv_field 2>/dev/null) || return 1
_RET="$val"
Copy link
Collaborator

Choose a reason for hiding this comment

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

i think this looks good,. thanks.
I suggest shortening kenv_field and sys_field to ename and sname.

*) error "Unknown field $sys_field. Cannot call kenv."
return 1;;
esac
val=$(kenv -q $kenv_field 2>/dev/null) || return 1
Copy link
Collaborator

Choose a reason for hiding this comment

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

you should quote $kenv_field here just to be pedantic.

@igalic
Copy link
Collaborator Author

igalic commented Nov 6, 2020

looks good. some comments inline.

one thought... I think we could use functools.lru_cache on is_container. In real life, the result is never going to change... we don't go from being inside a container to not inside a container in the same python process (at least cloud-init doesn't). And that will save us several calls to subprocess.

I did a quick test, and adding lru_cache didn't seem to break any unit tests. Probably because we don't actually have unit tests for the is_container function.

yeah… i noticed that, but didn't wanna go there yet…

my brave suggestion is to add @lru_cache on top of def read_dmi_data(key).
I don't know how often we duplicate calls throughout the code-base, but yeah… it "might" help

dmi_decode() {
local sys_field="$1" dmi_field="" val=""
command -v dmidecode >/dev/null 2>&1 || {
warn "No dmidecode program. Cannot read $sys_field."
return 1
}
case "$1" in
case "$sys_field" in
Copy link
Collaborator

Choose a reason for hiding this comment

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

thank you for fixing that.

@igalic igalic force-pushed the fix-regression/dmidecode-freebsd branch 2 times, most recently from cc5fb80 to 432e709 Compare November 6, 2020 18:10
FreeBSD lets us read out kernel parameters with kenv(1), a user-space
utility that's shipped in "base" We can use it in place of dmidecode(8),
thus removing the dependency on sysutils/dmidecode, and the restrictions
to i386 and x86_64 architectures that this utility imposes on FreeBSD.

Co-authored-by: Scott Moser <smoser@brickies.net>
@igalic igalic force-pushed the fix-regression/dmidecode-freebsd branch from 432e709 to c557eb0 Compare November 6, 2020 18:21
@smoser smoser merged commit d83c0bb into canonical:master Nov 6, 2020
@igalic igalic deleted the fix-regression/dmidecode-freebsd branch November 6, 2020 19:45
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.

None yet

4 participants