feat: wiring in RackHarwareType with rack-firmware management, as a string#893
Merged
chet merged 1 commit intoNVIDIA:mainfrom Apr 13, 2026
Merged
Conversation
🔐 TruffleHog Secret Scan✅ No secrets or credentials found! Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉 🕐 Last updated: 2026-04-10 16:49:10 UTC | Commit: 4b7f32b |
chet
force-pushed
the
rack-firmware-hardware-type-integration
branch
2 times, most recently
from
f750daf to
2d29898
Compare
chet
changed the title
Contributor
|
LGTM |
anunna0
approved these changes
Apr 13, 2026
Contributor
anunna0
left a comment
anunna0
left a comment
There was a problem hiding this comment.
Looks good, just left a couple of comments.
| .into()); | ||
| } | ||
|
|
||
| // Validate firmware_type matches rack's hardware class. |
Contributor
There was a problem hiding this comment.
Should we remove the firmware_type CLI parameter and just decide which firmware type to apply based on the hardware type? Is there a reason to retain the firmware_type?
|
|
||
| // Validate firmware hardware type and firmware_type against rack capabilities. | ||
| if let Some(rack_type_name) = rack.config.rack_type.as_deref() | ||
| && let Some(capabilities) = api.runtime_config.rack_types.get(rack_type_name) |
Contributor
There was a problem hiding this comment.
Are we skipping the validation step if there is no rack type configured? We should probably at least log something... maybe fail altogether.
chet
force-pushed
the
rack-firmware-hardware-type-integration
branch
from
2d29898 to
e9eaabb
Compare
anunna0
approved these changes
Apr 13, 2026
…tring This wires in the new `RackHardwareType` and `RackHardwareClass` in with the `rack-firmware` management flows, and turns it into newtype over `String` in the process, giving us some more flexiblility as to what we set for values. It was decided we didn't want to be too restrictive with an enumerated list for now. With the plumbing in place, the flow is now: ``` admin-cli rack-firmware create <rack-hardware-type> ... ``` ...to associate a given rack firmware bundle with an expected rack type. And then, when you: ``` admin-cli rack-firmare apply <rack-id> .... ``` ...the backend will now check to make sure the: - The `RackFirmwareType` of the given `RackId` (based on its configured `RackCapabilitiesSet`) matches the configured `RackFirmwareType` for the firmware. - The `RackHardwareClass` of the given `RackId` (based on its configured `RackCapabilitesSet`) matches the configured `firmware_type` (`<dev|prod>`) for the firmware. I also introduced a `RackHardwareType::Any` in here, as if to say "I don't care what the hardware is, just apply the firmware", e.g. ``` admin-cli rack-firmware create any .... ``` ...which will associate that firmware with `RackFirmwareType::Any`, so when you go to `rack-firmware apply`, it will apply to `::Any` hardware. Improved the `rack-firmware list` API call as well with a filtering. Tests included! Signed-off-by: Chet Nichols III <chetn@nvidia.com>
chet
force-pushed
the
rack-firmware-hardware-type-integration
branch
from
e9eaabb to
7a2ef2e
Compare
anunna0
approved these changes
Apr 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This wires in the new
RackHardwareTypeandRackHardwareClassin with therack-firmwaremanagement flows, and turns it into newtype overStringin the process, giving us some more flexiblility as to what we set for values. It was decided we didn't want to be too restrictive with an enumerated list for now.With the plumbing in place, the flow is now:
...to associate a given rack firmware bundle with an expected rack type. And then, when you:
...the backend will now check to make sure the:
RackFirmwareTypeof the givenRackId(based on its configuredRackCapabilitiesSet) matches the configuredRackFirmwareTypefor the firmware.RackHardwareClassof the givenRackId(based on its configuredRackCapabilitesSet) matches the configuredfirmware_type(<dev|prod>) for the firmware.I also introduced a
RackHardwareType::Anyin here, as if to say "I don't care what the hardware is, just apply the firmware", e.g....which will associate that firmware with
RackFirmwareType::Any, so when you go torack-firmware apply, it will apply to::Anyhardware.Improved the
rack-firmware listAPI call as well with a filtering.Tests included!
Signed-off-by: Chet Nichols III chetn@nvidia.com
Type of Change
Related Issues (Optional)
Breaking Changes
Testing
Additional Notes