Add planning docs for SMD group-based BMC target selection#24
Conversation
Introduce GROUP_SELECTION.md and HANDOFF_GROUP_SELECTION.md describing how FirmwareUpdateJob can target a set of BMCs via an SMD user-defined group reference instead of a single TargetAddress. - Add optional GroupRef, MaxParallel, and AllowPartialTargets spec fields - Make TargetAddress conditionally required via a BMC selector exclusivity rule (exactly one of TargetAddress or GroupRef) - Preserve backward compatibility and existing per-BMC component selection (Targets/Component) semantics - Consume existing SMD groups only; group lifecycle stays out of scope Signed-off-by: jvd10 <jay.depasse@hpe.com>
bmcdonald3
left a comment
bmcdonald3
left a comment
There was a problem hiding this comment.
Looks good, really just a question about what that handoff doc here is.
| @@ -0,0 +1,171 @@ | |||
| # HANDOFF_GROUP_SELECTION | |||
There was a problem hiding this comment.
I guess I am confused what this file is. The handoff document is supposed to be generated after the implementation (which you have specified in the Output Artifacts section above). This seems like something different.
| - Existing single-`TargetAddress` jobs continue to work unchanged. | ||
| - No changes to `Targets`, `Component`, `OCIReference`, or `Discovery` semantics. | ||
|
|
||
| ## 3. SMD Integration and Reconciliation |
There was a problem hiding this comment.
This is the main thing that's jumping out to me really is like how do we want to handle SMD integration... Given we might be using it for other things down the line, I'm just thinking if there are ways to make it more reusable, but I think that the endpoints really just being /hsm/v2, that does not sound like a difficult integration.
Regardless, I would go with the least amount of code changes for this first pass to get something working and then we can build off that from there.
mbuchmann-hpe
left a comment
mbuchmann-hpe
left a comment
There was a problem hiding this comment.
Need to come up with a plan that can support the multiple hardware in a group.
| All SMD calls use base path `/hsm/v2` (validated; see Section 7). | ||
|
|
||
| 1. Fetch the group and its members: | ||
| - `GET /hsm/v2/groups/{GroupRef}` and read `members.ids[]` (HMS component xnames, conventionally Node xnames). |
There was a problem hiding this comment.
groups/{GroupRef}/members can also be used to just get the member ids.
| Create a firmware update job that targets an SMD group instead of a single BMC: | ||
|
|
||
| ```bash | ||
| curl -sS -X POST http://127.0.0.1:8090/firmwareupdatejobs/ \ |
There was a problem hiding this comment.
Groups, particularly cabinet groups, often consist of hardware featuring multiple models and potentially different vendors. Consequently, you cannot deploy a single binary across an entire group and expect unsupported hardware to handle it. Doing so will result in a failed update at best, or corrupted, non-functional hardware at worst.
Signed-off-by: jvd10 <jay.depasse@hpe.com>
Implements planning/GROUP_SELECTION.md: a FirmwareUpdateJob can now target a set of BMCs via an SMD user-defined group instead of a single BMC. Per-BMC component selection (targets/component) is unchanged and applied to each member. Schema (apis/.../firmwareupdatejob_types.go): - Add spec fields: groupRef, maxParallel, allowPartialTargets - Make targetAddress optional; enforce targetAddress XOR groupRef in Validate - Add status fields: resolutionDetail, memberCount, completedCount, failedMembers SMD integration (internal/smd): - Read-only HSM v2 client: group fetch + ComponentEndpoint -> BMC FQDN - Configurable via SMD_BASE_URL (default http://smd:27779/hsm/v2) and optional SMD_TOKEN bearer Reconciler (pkg/reconcilers): - Resolve group members to BMCs (SMD-authoritative), de-dup by BMC FQDN - Bounded-parallel fan-out (maxParallel, default 1) reusing the once-resolved OCI payload; all-members-must-succeed aggregation - allowPartialTargets controls strict vs. partial resolution - isTerminalError now unwraps wrapped errors via errors.As Tests: validation selector rules, SMD client contract mapping, group resolution, and parallelism-bound tests. Backward compatible: single targetAddress jobs are unchanged. Handoff (planning/HANDOFF_GROUP_SELECTION.md): - Status: implemented + verified; fabrica generate, go mod tidy, go vet, go build, and go test ./... all pass - Documents group selection logic, verified curl commands (validation 400/201, group-mode Resolving->Failed progression, terminal "group not found"), operational/debugging notes, and exact SMD endpoints + error->state mapping - Records 12 plan deviations/decisions made autonomously (open items in plan Section 8, user unavailable), notably: username/password kept required and shared across members (resolves a plan/schema conflict); maxParallel=0 treated as unset->default 1; static-token/no-passthrough SMD auth; malformed SMD response handled as transient-then-failed; ?partition filtering and SMD lock gating not implemented (lock deferred to LOCKING_SUPPORT.md per the plan) - All seven acceptance criteria marked satisfied Signed-off-by: jvd10 <jay.depasse@hpe.com>
3 participants
Introduce GROUP_SELECTION.md and HANDOFF_GROUP_SELECTION.md describing how FirmwareUpdateJob can target a set of BMCs via an SMD user-defined group reference instead of a single TargetAddress.
Checklist
make test(or equivalent) locally and all tests passgit commit -s) with my real name and email<filename>.licensesidecarLICENSES/directoryDescription
Please include a summary of the change and which issue is fixed.
Also include relevant motivation and context.
Fixes #(issue)
Type of Change
For more info, see Contributing Guidelines.