-
Notifications
You must be signed in to change notification settings - Fork 38
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
FS-1123: Supermicro (SMC) BIOS config Get, Set and Reset support via SUM #392
Conversation
8cc9139
to
318630b
Compare
@splaspood is this ready for review? set reviewers in that case. |
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 this work,
I would prefer we stick to explicit returns instead of implicit across the code base. sum
cannot be a provider by itself and needs to move into internal/sum and wrapped by the Supermicro provider. Additional comments inline
1638530
to
678cddf
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #392 +/- ##
==========================================
+ Coverage 37.48% 42.44% +4.95%
==========================================
Files 78 61 -17
Lines 6405 5544 -861
==========================================
- Hits 2401 2353 -48
+ Misses 3782 2970 -812
+ Partials 222 221 -1 ☔ View full report in Codecov by Sentry. |
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 think hand-making your own mocks is not useful here. Using a test-mock generator will allow you to avoid having to expose test infrastructure in the interface and give you better flexibility.
@@ -1,4 +1,4 @@ | |||
FROM mcr.microsoft.com/devcontainers/go:1-1.21-bullseye | |||
FROM mcr.microsoft.com/devcontainers/go:1-1.22-bullseye |
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.
why are we using a Microsoft golang container?
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'd guess simply because that's what's suggested in the devcontainer documentation/examples. My understanding is there's nothing really special about the devcontainer image(s) so we could replace that with anything.
SetStdout([]byte) | ||
SetStderr([]byte) | ||
SetExitCode(int) |
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.
Do these have to be exported?
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'd have to review the code in more detail, but my guess would be these are exported for use in testing. They are exported here because they were exported in the ironlib code that this was directly copied from.
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.
when we're using a mock library, these would not be required
internal/executor/fake_executor.go
Outdated
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.
Why not use mockery
or gomock
here?
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.
Only because this already existed in our code base. I don't have anything against using these libs...
"github.com/pkg/errors" | ||
) | ||
|
||
// Executor interface lets us implement dummy executors for tests |
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 comment says this is for tests but this interface is used the the sum
package which is not a test package. which one is it, for tests or not?
Also, why is this a package at all? As far as i can tell this is only used in the sum
package. This should probably just be move there.
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's external to the sum package with the expectation that there could/would be other similar utilities needing this in the future.
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.
what the the other utilities that will need and or implement this? if we dont have other uses we should hold off creating this.
This also is a big interface and its purpose and value add are not very clear. are we planning on replacing all calls to the os/exec
with this?
"Do not define interfaces before they are used: without a realistic example of usage, it is too difficult to see whether an interface is even necessary, let alone what methods it ought to contain." - https://go.dev/wiki/CodeReviewComments#interfaces
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 do not have any currently pending, so your argument about not implementing it before it's necessary is valid.
That being said, this code was already implemented elsewhere for a very similar use case so it was adopted nearly as-is. The presumption is that we'd need the currently unused functionality as we add more vendor utilities as we've seen in ironlib.
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.
im not familiar with the ironlib code base. does ironlib already have the supermicro update manager code? should we just be importing from ironlib?
I'm also confused. you say "do not have any currently pending" and "as we add more vendor utilities". How can this be both?
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.
Ironlib has many things, but not sum. I was referring to the Executor/FakeExecutor stuff that's used for testing/execing in ironlib.
While I do not currently have any vendor utilities in the queue, I can envision a future with supporting other vendor's utilities where this code would be reused.
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.
should we just be importing from ironlib?
ironlib is meant to execute vendor utilities in an OS running on the host.
bmclib is meant to execute actions/calls remotely and so I think this fits in here
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 we plan to continue using this code over the longer term vs something off the shelf as suggested by @DoctorVin , I'd argue that this should be extracted into an external package that both projects could import, but we haven't finalized those plans one way or the other at this point.
…ate mananger(sum)
Will evaluate using an alternate mocking tool for both ironlib and bmclib in the future.
What does this PR implement/change/remove?
BIOS config management support for Supermicro (SMC) platforms implemented as a wrapper over Supermicro Update Manager (SUM).
Description for changelog/release notes
BIOS config management support for Supermicro (SMC) platforms.