feat: add support to create_client_with_vendor#57
Merged
chet merged 1 commit intoNVIDIA:mainfrom Apr 9, 2026
Merged
Conversation
Trying to approach this as something that makes sense, in the general sense, even though this is the first use-case for it. The motivator here is, since a Lite-On power shelf has no vendor details in the service root, the Redfish client cannot determine the vendor hardware type, so it defaults back to a `RedfishStandard` client, and not a `LiteOnPowerShelf` client. This means that when the client calls `set_machine_password_policy`, it fails, because it's using the `RedfishStandard` implementation, and not the `LiteOnPowerShelf` implementation; the Lite-On imlpementation uses an `AccountService` call, and not the "default" `AccountLockoutCounterResetAfter` call). So right now my choices are to either: - Skip `set_machine_password_policy` entirely for power shelves. - Introduce a way to set a specific vendor on a client, and bypass the service root check.
chet
changed the title
poroh
approved these changes
Apr 9, 2026
chet
added a commit
to chet/bare-metal-manager-core
that referenced
this pull request
Apr 9, 2026
This adds support in `site-explorer` for creating a vendor-specific client. The existing code allowed you to `create_client` with `initialize: <bool>`, where `<bool>` determined if the client should interrogate the service root to auto-detect the vendor `(true)`, OR if it should just fall back and give you a `RedfishStandard` vendor client `(false)`. This change makes it so instead of `initialize: <bool>`, it becomes `initialize: Option<RedfishVendor>`. If you set `None`, then you get the auto-detected vendored client. If you set `Some(vendor)`, then you get a client with a pre-configured vendor (e.g. instead of `initialize` it forcing it to be `RedfishStandard`, you can now actually say what you want it to be. **Why is this being done?** In this case, *Lite-On Power Shelves* (`RedfishVendor::LiteOnPowerShelf`) DON'T expose vendor information in the service root, making it so auto-detection is impossible. This means clients pointed at power shelves end up calling back to `Unknown` (which gives you a `RedfishStandard` client). The problem here is during site-exploration, when we try to `set_machine_password_policy`, we have a client that has fallen back to the `::RedfishStandard` implementation, which is actually incorrect (and it fails), because there is a `::LiteOnPowerShelf`-specific implementation for `set_machine_password_policy` (it needs to call `AccountService` and not `AccountLockoutCounterResetAfter`). The implementation in `libredfish` is there, but it's impossible for us to actually use it in `site-explorer` due to us not being able to explicitly set a vendor. Support to actually *set* a vendor didn't actually exist in `libredfish` either, but I added it in NVIDIA/libredfish#57, so now I can use it! Signed-off-by: Chet Nichols III <chetn@nvidia.com>
10 tasks
chet
added a commit
to chet/bare-metal-manager-core
that referenced
this pull request
Apr 9, 2026
This adds support in `site-explorer` for creating a vendor-specific client. The existing code allowed you to `create_client` with `initialize: <bool>`, where `<bool>` determined if the client should interrogate the service root to auto-detect the vendor `(true)`, OR if it should just fall back and give you a `RedfishStandard` vendor client `(false)`. This change makes it so instead of `initialize: <bool>`, it becomes `initialize: Option<RedfishVendor>`. If you set `None`, then you get the auto-detected vendored client. If you set `Some(vendor)`, then you get a client with a pre-configured vendor (e.g. instead of `initialize` it forcing it to be `RedfishStandard`, you can now actually say what you want it to be. **Why is this being done?** In this case, *Lite-On Power Shelves* (`RedfishVendor::LiteOnPowerShelf`) DON'T expose vendor information in the service root, making it so auto-detection is impossible. This means clients pointed at power shelves end up calling back to `Unknown` (which gives you a `RedfishStandard` client). The problem here is during site-exploration, when we try to `set_machine_password_policy`, we have a client that has fallen back to the `::RedfishStandard` implementation, which is actually incorrect (and it fails), because there is a `::LiteOnPowerShelf`-specific implementation for `set_machine_password_policy` (it needs to call `AccountService` and not `AccountLockoutCounterResetAfter`). The implementation in `libredfish` is there, but it's impossible for us to actually use it in `site-explorer` due to us not being able to explicitly set a vendor. Support to actually *set* a vendor didn't actually exist in `libredfish` either, but I added it in NVIDIA/libredfish#57, so now I can use it! Signed-off-by: Chet Nichols III <chetn@nvidia.com>
chet
added a commit
to chet/bare-metal-manager-core
that referenced
this pull request
Apr 9, 2026
This adds support in `site-explorer` for creating a vendor-specific client. The existing code allowed you to `create_client` with `initialize: <bool>`, where `<bool>` determined if the client should interrogate the service root to auto-detect the vendor `(true)`, OR if it should just fall back and give you a `RedfishStandard` vendor client `(false)`. This change makes it so instead of `initialize: <bool>`, it becomes `initialize: Option<RedfishVendor>`. If you set `None`, then you get the auto-detected vendored client. If you set `Some(vendor)`, then you get a client with a pre-configured vendor (e.g. instead of `initialize` it forcing it to be `RedfishStandard`, you can now actually say what you want it to be. **Why is this being done?** In this case, *Lite-On Power Shelves* (`RedfishVendor::LiteOnPowerShelf`) DON'T expose vendor information in the service root, making it so auto-detection is impossible. This means clients pointed at power shelves end up calling back to `Unknown` (which gives you a `RedfishStandard` client). The problem here is during site-exploration, when we try to `set_machine_password_policy`, we have a client that has fallen back to the `::RedfishStandard` implementation, which is actually incorrect (and it fails), because there is a `::LiteOnPowerShelf`-specific implementation for `set_machine_password_policy` (it needs to call `AccountService` and not `AccountLockoutCounterResetAfter`). The implementation in `libredfish` is there, but it's impossible for us to actually use it in `site-explorer` due to us not being able to explicitly set a vendor. Support to actually *set* a vendor didn't actually exist in `libredfish` either, but I added it in NVIDIA/libredfish#57, so now I can use it! Signed-off-by: Chet Nichols III <chetn@nvidia.com>
chet
added a commit
to chet/bare-metal-manager-core
that referenced
this pull request
Apr 9, 2026
This adds support in `site-explorer` for creating a vendor-specific client. The existing code allowed you to `create_client` with `initialize: <bool>`, where `<bool>` determined if the client should interrogate the service root to auto-detect the vendor `(true)`, OR if it should just fall back and give you a `RedfishStandard` vendor client `(false)`. This change makes it so instead of `initialize: <bool>`, it becomes `initialize: Option<RedfishVendor>`. If you set `None`, then you get the auto-detected vendored client. If you set `Some(vendor)`, then you get a client with a pre-configured vendor (e.g. instead of `initialize` it forcing it to be `RedfishStandard`, you can now actually say what you want it to be. **Why is this being done?** In this case, *Lite-On Power Shelves* (`RedfishVendor::LiteOnPowerShelf`) DON'T expose vendor information in the service root, making it so auto-detection is impossible. This means clients pointed at power shelves end up calling back to `Unknown` (which gives you a `RedfishStandard` client). The problem here is during site-exploration, when we try to `set_machine_password_policy`, we have a client that has fallen back to the `::RedfishStandard` implementation, which is actually incorrect (and it fails), because there is a `::LiteOnPowerShelf`-specific implementation for `set_machine_password_policy` (it needs to call `AccountService` and not `AccountLockoutCounterResetAfter`). The implementation in `libredfish` is there, but it's impossible for us to actually use it in `site-explorer` due to us not being able to explicitly set a vendor. Support to actually *set* a vendor didn't actually exist in `libredfish` either, but I added it in NVIDIA/libredfish#57, so now I can use it! Signed-off-by: Chet Nichols III <chetn@nvidia.com>
chet
added a commit
to NVIDIA/ncx-infra-controller-core
that referenced
this pull request
Apr 9, 2026
#878) ## Description This adds support in `site-explorer` for creating a vendor-specific client. The existing code allowed you to `create_client` with `initialize: <bool>`, where `<bool>` determined if the client should interrogate the service root to auto-detect the vendor `(true)`, OR if it should just fall back and give you a `RedfishStandard` vendor client `(false)`. This change makes it so instead of `initialize: <bool>`, it becomes `initialize: Option<RedfishVendor>`. If you set `None`, then you get the auto-detected vendored client. If you set `Some(vendor)`, then you get a client with a pre-configured vendor (e.g. instead of `initialize` it forcing it to be `RedfishStandard`, you can now actually say what you want it to be. **Why is this being done?** In this case, *Lite-On Power Shelves* (`RedfishVendor::LiteOnPowerShelf`) DON'T expose vendor information in the service root, making it so auto-detection is impossible. This means clients pointed at power shelves end up calling back to `Unknown` (which gives you a `RedfishStandard` client). The problem here is during site-exploration, when we try to `set_machine_password_policy`, we have a client that has fallen back to the `::RedfishStandard` implementation, which is actually incorrect (and it fails), because there is a `::LiteOnPowerShelf`-specific implementation for `set_machine_password_policy` (it needs to call `AccountService` and not `AccountLockoutCounterResetAfter`). The implementation in `libredfish` is there, but it's impossible for us to actually use it in `site-explorer` due to us not being able to explicitly set a vendor. Support to actually *set* a vendor didn't actually exist in `libredfish` either, but I added it in NVIDIA/libredfish#57, so now I can use it! Leveraged existing tests in this case to ensure it works as intended. I have integration tests for switches and power shelves in separate pending PR; I'll end up updating those to accommodate this change. Signed-off-by: Chet Nichols III <chetn@nvidia.com> ## Type of Change <!-- Check one that best describes this PR --> - [ ] **Add** - New feature or capability - [x] **Change** - Changes in existing functionality - [ ] **Fix** - Bug fixes - [ ] **Remove** - Removed features or deprecated functionality - [x] **Internal** - Internal changes (refactoring, tests, docs, etc.) ## Related Issues (Optional) <!-- If applicable, provide GitHub Issue. --> ## Breaking Changes - [ ] This PR contains breaking changes <!-- If checked above, describe the breaking changes and migration steps --> ## Testing <!-- How was this tested? Check all that apply --> - [ ] Unit tests added/updated - [ ] Integration tests added/updated - [ ] Manual testing performed - [ ] No testing required (docs, internal refactor, etc.) ## Additional Notes <!-- Any additional context, deployment notes, or reviewer guidance --> Signed-off-by: Chet Nichols III <chetn@nvidia.com>
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
2 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.
Trying to approach this as something that makes sense, in the general sense, even though this is the first use-case for it.
The motivator here is, since a Lite-On power shelf has no vendor details in the service root, the Redfish client cannot determine the vendor hardware type, so it defaults back to a
RedfishStandardclient, and not aLiteOnPowerShelfclient.This means that when the client calls
set_machine_password_policy, it fails, because it's using theRedfishStandardimplementation, and not theLiteOnPowerShelfimplementation; the Lite-On imlpementation uses anAccountServicecall, and not the "default"AccountLockoutCounterResetAftercall).So right now my choices are to either:
set_machine_password_policyentirely for power shelves.I'm attempting to do the latter!