v1.1.0

New Features

• proliant oneview activity: shows OneView's Activity feed — the named operations it ran (/rest/tasks: firmware updates, refreshes, background inventory collection) merged with health/condition alerts (/rest/alerts), newest first, mirroring the OneView GUI's Activity page (Name, Resource, Date, Duration, State, Owner). This is where a firmware update's real per-phase progress and, crucially, its actual failure reason show up. By default the feed lists only top-level operations (matching the GUI, which hides each operation's subtask tree behind an expander) and shows a live running-duration for in-progress tasks. Drill into an operation's nested subtask tree — the exact hierarchy the GUI shows when you expand a row, with each subtask's own state/percent and live phase text (e.g. "Stage firmware 80% completed", "Initiating loading of images on the interconnect / reboot") — with --tree [NAME], or live-follow a running operation until it finishes with --watch (refresh interval --interval SECONDS). This is the CLI equivalent of watching the GUI Activity page during a firmware rollout, so a multi-minute "Logical enclosure firmware update" no longer looks stuck at the parent task's flat 0% while its interconnects actually flash underneath. Filter the feed with --resource NAME (substring, e.g. LE01), --state STATE (e.g. Error), --limit N, --all-tasks (include subtasks), or restrict to --tasks-only/--alerts-only; --json for scripting. Inline resource references embedded in task/alert text are shown by name instead of raw {"name":…,"uri":…} JSON.
• proliant oneview update enclosure --concurrency N (--scope shared-infra-and-profiles only): submits up to N server-profile firmware updates at once instead of always one at a time. Default is 1 (unchanged, fully sequential) — researched against HPE's own tooling first: no official OneView REST API, PowerShell library, Python SDK, or Ansible collection updates server-profile firmware in bulk either, they all loop one profile at a time, so sequential remains the safe default. Profiles are submitted in waves of up to N; each wave's requests are polled to completion before the next wave starts. A failed/blocked/unverified profile does not stop later waves — each profile targets an independent physical server, so one server's firmware trouble has no bearing on whether the rest of the batch can still update safely (see the Bug Fixes entry below for why this matters even at the default N=1). The confirmation panel now also warns how many compute modules will power-cycle simultaneously when N > 1, and the live progress display shows one bar per in-flight profile instead of a single reused bar.
• proliant oneview server-profiles reapply <NAME>: the CLI equivalent of the OneView GUI's server-profile "Reapply configuration" action — fetches the profile's current, already-stored configuration and PUTs it straight back unmodified, making OneView reconcile whatever is actually out of sync on the live hardware (network/storage settings, BIOS, boot order, firmware consistency). This is what clears alerts like "Server hardware has been inserted into the enclosure bay — Resolution: Reapply the server profile" (e.g. after a hardware re-insertion or an eFuse power-cycle) without changing any profile setting. Prompts with a type-to-confirm safety gate before touching live hardware (skip with --yes); shows a live progress bar for the underlying task, same as update enclosure.
• proliant oneview update enclosure --scope profiles-only: updates just the targeted logical enclosure's server-profile compute firmware and skips the logical-enclosure/interconnect step entirely — no GUI equivalent (the GUI's "Update firmware" dialog always bundles shared infra in). Added after a live rollout got stuck with shared infra reporting "unverified" (OneView said the interconnect update completed, but it hadn't actually installed), which blocked all 6 pending server-profile firmware updates behind it indefinitely under the existing shared-infra-first ordering. A server-profile firmware PUT is its own independent OneView operation — not HPE-documented as depending on the LE rollout finishing — so profiles-only lets compute firmware proceed on its own schedule while the shared-infra issue is investigated separately.
• proliant oneview server-profiles update <NAME>: rolls out an SSP firmware baseline to one named server profile's compute module directly, without requiring (or touching) its logical enclosure at all — narrower than update enclosure --scope profiles-only, which still updates every profile under a given LE. Useful for bringing a single server current (e.g. right after an efuse/reapply) without waiting on or affecting its enclosure-mates. Shows the plan and applies directly (no separate --execute flag, unlike update enclosure) — gated by a plain yes/no confirm prompt (skip with --yes), plus the same baseline/install-type/force flags as update enclosure.

Bug Fixes

• proliant oneview update enclosure --scope profiles-only / --scope shared-infra-and-profiles: fixed a batch of server-profile firmware updates silently stopping after the first profile that failed/blocked/unverified, never even attempting the rest of the targeted profiles — confirmed live: a 6-profile profiles-only batch stopped dead after the first server's drive firmware hung and failed, leaving 5 completely unrelated servers untouched with no indication they'd been skipped. Each server profile targets an independent physical server, so one server's firmware trouble has no bearing on whether the others can still update safely — every targeted profile is now always attempted, and the result summary reports each failed/blocked/unverified profile individually (not just whichever one happened to be last) alongside how many succeeded normally. This applies at any --concurrency, including the default of 1.
• proliant oneview update enclosure --execute: a failed firmware update now shows OneView's own actionable error reason and remediation inline instead of an unhelpful "Check the OneView UI / 'proliant oneview reports'" (a command that has nothing to do with firmware). For example, forcing an update through a non-redundant fabric with --activation-mode parallel while the enclosure's compute modules are still powered on now reports OneView's real error — "…servers are currently powered on. Firmware update cannot be initiated until the listed servers within the logical enclosure are powered off." plus its "Power off the listed servers and retry" recommended action — pulled from the task's own taskErrors, and points you at the new proliant oneview activity for the full task detail.
• proliant oneview interconnects describe: fixed a misleading "Firmware baseline" line that showed the logical enclosure's assigned/target SSP as if it were already installed, even when the update had actually failed or was blocked (confirmed live: a blocked SY-2025.10.01 rollout kept showing as "Firmware baseline" long after the interconnect had never left its real SY-2023.05.01 baseline). Always shows the same three plain fields as the GUI's own "General" page — "Firmware baseline", "Firmware version from baseline", and "Installed firmware version" — with no separate "target"/"not yet applied" concept invented on top, now sourced from the Logical Interconnect's own actually-installed SPP tracking instead of the logical enclosure's request-only pointer; any mismatch between the baseline's version and what's installed is simply visible by comparing those two lines, exactly like the GUI.
• proliant oneview update enclosure --execute: fixed garbled/overlapping terminal output that could appear around the validation-warning "Proceed anyway despite this warning?" prompt and between targets. The live progress bar was being torn down and rebuilt from scratch for every target and every validation-warning retry; it's now a single persistent bar reused (reset in place) across the whole run and only actually stopped for the interactive prompt, matching Rich's supported pattern and avoiding the terminal corruption some terminals showed under the old repeated stop/start churn. Each finished target now also prints a permanent "✓ NAME updated." line so you have a written record even though the bar itself gets reused for the next target.
• proliant oneview update enclosure --execute: fixed a false "SSP apply complete. Updated N target(s)." reported for a logical-enclosure firmware update that OneView actually blocked and never applied. OneView reports this case as a Warning task at 100% ("firmware update was successful with warning") when a non-redundant fabric would be disrupted by the update — the CLI treated Warning as success unconditionally. It now re-checks whether the update actually landed before declaring success; the first pass of this fix compared the enclosure's own target-baseline pointer (which OneView sets immediately on request and never rolls back, so it still read "changed" even when blocked — the same root cause as the plan-phase bug below), so it's now cross-checked against each Logical Interconnect's actual installed SPP instead, same as the plan check. When they disagree, the CLI now shows OneView's real warning/resolution text and prompts to proceed anyway (see below) instead of silently reporting success.
• proliant oneview update enclosure: split "proceed through the non-disruptive-fabric validation warning" from "force-reinstall firmware" into two independent knobs (they were previously conflated, so confirming the warning always set forceInstallFirmware too). Clearing only the validation guard (validateIfLIFirmwareUpdateIsNonDisruptive) is the guard-only "proceed"; --force independently forces a reinstall and bypasses the guard up front. This is what makes the on-the-spot A/B choice below possible — proceed (guard-only) vs. force (disruptive) are now genuinely different requests, matching how the GUI treats accepting a redundant-fabric warning versus forcing through a non-redundant one.
• proliant oneview update enclosure --execute: when a firmware update is blocked by OneView's non-redundant-fabric validation, the CLI now reliably shows the real reason and resolution steps instead of a blank message. OneView nests the actual VALIDATION_FAILED_FOR_LOGICAL_INTERCONNECT error two levels deep in the task tree (Logical enclosure firmware update → per-interconnect Update firmware → the validation subtask); the CLI previously looked only at the top task and its direct children, so the "…does not have redundant connectivity configured for one or more uplink sets: pvlan-uplinkset…" text was dropped. It now walks the whole task subtree to surface OneView's own warning + recommended actions, matching the GUI's warning modal.
• proliant oneview update enclosure (plan and --execute): fixed the plan wrongly reporting a logical enclosure as "current / up to date" when a previous rollout to that same baseline had actually been blocked or never finished. OneView sets the enclosure's own target-baseline pointer as soon as an update is requested, and never rolls it back if the update fails — so comparing only that pointer against the requested baseline could say "up to date" even while every interconnect underneath was still running the old firmware. The plan now cross-checks each enclosure's Logical Interconnects' actual installed SPP (the same source the GUI's own "Installed:" state uses) before trusting a "no change needed" verdict, and reports "target baseline set but not yet installed" when they disagree.
• proliant oneview update enclosure --execute: fixed the validation-warning "Proceed anyway despite this warning? [y/N]" prompt silently swallowing its own "[y/N]" hint — Rich's terminal library parses [...] as markup, and [y/N] isn't a valid style, so it vanished, leaving no visible indication of what to type. Typing "OK" (the literal wording our own prompt tells you to click) wasn't recognized either and silently declined instead of proceeding. Now renders the hint correctly and also accepts "ok"/"okay" alongside "y"/"yes". Found and fixed the same swallowed-hint bug in proliant oneview update appliance run's "Select image [1-N]" prompt and proliant spp download's "Proceed with download? [Y/n]" prompt.
• proliant oneview update enclosure --execute: the live progress bar polled for task status every 20s, so a target that resolves in under ~20s (e.g. immediately blocked by a validation guard) showed no visible progress at all until it suddenly appeared "100% complete" — reduced polling to every 5s for more responsive, granular feedback. The bar also now shows an explicit "Checking whether the update actually applied…" message (in yellow) the moment a task lands in a Warning state, instead of leaving a 100% Warning frame on screen looking like a confident, finished success while the CLI goes and determines whether that warning meant "done, minor note" or "blocked, nothing changed".
• proliant oneview update enclosure --execute: a plain "Completed" task (not just the already-handled "Warning" case) is no longer trusted unconditionally either — live-tested with --activation-mode parallel, a rollout reported "Completed" after only ~7 seconds while the real interconnect stage+activate cycle underneath kept running for several more minutes. The CLI cross-checks the actual installed baseline the same way it does for "Warning", now repolling every 5s for up to 5 minutes (not just one brief grace re-check) to give OneView's asynchronous LI-firmware activation time to actually finish. If it still disagrees once that window elapses, this surfaces as an honest "SSP apply reported complete but could not be verified" instead of a blind "SSP apply complete." — unlike a validation-guard block, this isn't auto-retried with --force (there's no known reason that would help), it just tells you to double-check via oneview interconnects describe or the OneView Activity log before trusting the result.
• proliant oneview update enclosure --scope shared-infra-and-profiles: fixed the scope silently being downgraded to shared-infra-only on the actual OneView request even though the plan preview correctly listed every server profile as a target — the logical-enclosure firmware PATCH always sent "firmwareUpdateOn": "SharedInfrastructureOnly" regardless of --scope, so server profiles were never actually included in the apply. --scope shared-infra-and-profiles now reaches OneView as SharedInfrastructureAndServerProfiles as intended.
• proliant oneview update enclosure --execute: fixed the live progress bar showing a contradictory "100% Running" for several minutes during a server-profile compute update (confirmed live: a task genuinely still ~9 minutes from finishing showed "100%" the whole time). The bar overlays the deepest currently-active subtask's own phase text/percent onto the display (e.g. "Update frame link module firmware 30%" instead of the root task's own flat 0%) — but once that active subtask's own children had all already finished (e.g. "Power on" and "Generate install set" both long Completed), a "pick whichever was touched most recently" fallback grabbed one of those finished children and showed its 100% as if it were live progress. It now only descends into a level's still-Running child; if none exists, it keeps showing the deepest node that's actually in flight instead of a stale, completed one. Also fixed the progress text occasionally showing a raw {"name":"Enclosure-01, bay 6","uri":"/rest/server-hardware/…"} JSON blob inline (OneView embeds these for the GUI to render as links) instead of just the plain resource name.
• proliant oneview update enclosure --execute / server-profiles update / server-profiles reapply: fixed the live progress bar showing a stuck "0%" for the entire duration of a server-profile compute firmware update, even though the GUI's Activity page showed real, moving step-by-step progress (confirmed live: an "Apply profile" task's own percentComplete sat flat at 0 for the whole ~12 minute run). OneView tracks this task type's actual progress in a separate computedPercentComplete field (step-weighted, the same value the GUI's own bar reads) alongside completedSteps/totalSteps, which the CLI never looked at. It now prefers computedPercentComplete when present and shows a "step N/M" counter alongside the bar, falling back to the old plain field for task types that don't populate it.
• All commands: fixed a UnicodeEncodeError crash when output is piped or redirected on Windows (a non-TTY). Rich falls back to the legacy Windows console renderer, which encodes with the OS code page (cp1252 on most systems) where UI glyphs used throughout the CLI — ↔, ✓, ⚠, •, box-drawing, progress bars — have no mapping and raised mid-render (e.g. proliant oneview update enclosure ... | tee log.txt crashed right after printing the plan panel). stdout/stderr are now reconfigured to UTF-8 at startup so redirected output is robust regardless of the console code page.
• Tab completion: fixed roughly 40 flags across ilo/com/oneview/spp (e.g. update enclosure --concurrency, mac list --address, ilo network set static --ip) never appearing in --<TAB> flag-name completion at all — confirmed live: --concurrency was completely absent from proliant oneview update enclosure LE01 --<TAB> even though --help listed it correctly. These flags all suppress file-path completion for their value via a shared suppress_file_completion() helper, which used argcomplete's own SuppressCompleter — argcomplete treats that as "hide this option from completion entirely," not just "don't complete a value for it." The helper now returns a plain empty-list completer instead, which still avoids suggesting workspace files for the value but no longer hides the flag itself.
• proliant oneview activity / activity --tree / activity --watch: fixed a task's own percent showing a stuck "0%"/misleadingly low number for a server-profile compute firmware "Apply profile" task, even mid-run with the GUI's own Activity page showing real, moving progress (confirmed live: an in-progress "Apply profile" task showed 0% here while its computedPercentComplete was actually 44% with 23/24 steps done). This was the same root cause already fixed for the live update enclosure --execute progress bar in v1.1.0 (OneView leaves this task type's plain percentComplete frozen at 0 and tracks its real, step-weighted progress in computedPercentComplete instead) but that fix was never ported to the activity feed's own task normalization. activity/--tree/--watch now prefer computedPercentComplete the same way, and --tree/--watch also show a "step N/M" counter under each subtask alongside its Name/phase, matching the GUI's own subtask log.
• proliant oneview activity --tree / --watch: fixed two follow-up issues found live on a failed "Apply profile" task. First, the new "step N/M" counter above could read as a nonsensical step 26/24 once OneView's completedSteps counter (which simply increments once per progress-log entry, including retried power-cycle attempts and the final failure entry) overtook totalSteps (a fixed early estimate that's never revised upward) — it now shows step 26 (plan: 24) once completed exceeds the original plan, instead of an impossible-looking fraction. Second, each subtask only ever showed its single latest progress line, so the "Apply profile" row lost the GUI's full scrolling history (e.g. every "Stage component N/6 - name.fwpkg" / "Install component N/6" line as they happened) — it now shows every recorded progress-log entry for that subtask, oldest first, matching what the GUI's own expanded Activity view displays.
• proliant oneview update enclosure --execute / server-profiles update / server-profiles reapply: the live progress bar shown while an update is actually running had this exact same "only ever the single latest line" limitation as the activity --tree/--watch bug above — it's driven by a separate, independent task-normalization function that predates that fix and was never updated to match, so it kept showing just one dim phase line (e.g. "Power on server.") no matter how much detail the GUI's own Activity page was displaying underneath. It now prints every new progress-log entry (e.g. each "Stage component N/8 - name.fwpkg" line) above the bar as it happens — permanent, scrolling lines, not just the bar's own single-line description — matching the GUI. update enclosure --concurrency > 1's multi-row bar prefixes each printed line with its target's name so concurrently-running targets' interleaved logs stay attributable to the right one.
• Tab completion (bash/zsh): a sole, fully-resolved multi-word completion (e.g. proliant oneview server-hardware-types describe SY 480 Gen10 2) is now inserted quoted ('SY 480 Gen10 2') instead of backslash-escaped (SY\ 480\ Gen10\ 2) — the escaped form is technically valid but easy to mistake for multiple separate completions when read back. Ambiguous common-prefix listings (more than one match sharing a prefix) still use backslash-escaping as before, since quoting those would leave an unmatched open quote in the buffer while the user keeps typing. Re-running install.sh upgrades an existing bash/zsh completion installation in place instead of leaving the old block untouched. Windows PowerShell completion already quoted multi-word values correctly and needed no change.
• proliant oneview server-profiles describe: fixed a crash (AttributeError: 'NoneType' object has no attribute 'rsplit') on a server profile created directly rather than from a template, where serverProfileTemplateUri is null — now shows an empty template name instead of raising.
• proliant oneview server-profiles update / update enclosure: a server profile using an "online" install type (FirmwareAndOSDrivers, or plain FirmwareOnly) now fails fast with a specific, actionable reason instead of silently polling the full 5-minute verify timeout — confirmed live on the same profile with both install types: left with its compute module powered off, it stayed installState: "Pending" for 12+ hours straight under FirmwareAndOSDrivers, then hit the exact same thing again under FirmwareOnly right after switching to it, since neither install type is actually offline — both hand the install off to HPE Smart Update Tools (SUT) running inside the guest OS, so both need the server booted before an install can ever finish (only FirmwareOnlyOfflineMode, i.e. --install-type firmware-offline, flashes directly via iLO with no OS/SUT involvement at all). The CLI now checks the server's power state (and HPE SUT's reported state) as soon as the first verify check disagrees, and — when it can identify this specific case — reports it immediately instead of leaving the terminal showing a repeating "Verifying the update actually applied (OneView is still activating)…" for the full timeout with a generic, misleading message at the end. Suggests powering the server on, or re-running with --install-type firmware-offline to flash directly via iLO without needing an OS boot at all.
• proliant oneview server-profiles update / update enclosure: fixed the live "step N/M" counter reading ahead of the progress lines actually printed to the terminal — confirmed live on a firmware-offline apply that showed "step 23/26" while only 23 lines had scrolled by, because OneView bumps its own completedSteps for every progressUpdates entry including ones with a blank status message, which the CLI already filters out of the visible log. The counter now always reflects the number of lines actually shown instead of OneView's raw (and occasionally blank-inclusive) count, so it can never look out of sync with what's on screen.
• proliant oneview servers describe: a Critical/Warning server status now shows a Status: line and the underlying active alert(s) (severity + description, matching the GUI's own Alerts panel), instead of only coloring a single status dot — confirmed live: bay7 showed status: Critical from OneView's own API with a firmware-integrity-scan alert, but every other panel (Hardware/Device Inventory/Utilization) looked completely normal, making the Critical state easy to miss entirely. server-profiles describe already surfaced its own profile-level alerts this way; servers describe had no equivalent for server-hardware-level alerts.
• Tab completion (all commands): pressing Tab with nothing typed for a positional value (e.g. right after servers describe ) no longer mixes -h/--help in among the real completions — confirmed live: this returned -h, --help, and all 7 bay names as one ambiguous, zero-common-prefix list, so repeated Tab-cycling could insert -h into the command by mistake instead of a server name. Flags are still offered normally as soon as a leading - is actually typed (argcomplete's own default, always_complete_options=True, was suggesting them unconditionally).
• proliant oneview servers list: rows are now sorted by enclosure and bay number (e.g. bay 1, 2, ... 10) instead of whatever order OneView's API happened to return, which was effectively random — confirmed live: a 7-server enclosure listed as bays 2, 3, 5, 1, 4, 6, 7. Added a Status column (OK/Warning/Critical, matching the colored health icon in the GUI's Server Hardware list) — parse_server() was silently dropping OneView's own status field even though every other list view (enclosures, networks, server-profiles, etc.) already surfaces it next to State. Also reformatted the iLO firmware column's verbose release date (iLO5 v3.17 Dec 02 2025) into a compact iLO5 v3.17 (2025.12.02), applied to both servers list and servers describe.
• proliant oneview servers describe / power/efuse/server-profiles reapply / interconnects describe (anything taking a server, enclosure, profile, or interconnect NAME): a name like "Enclosure-01,bay 7" (no space after the comma) now matches "Enclosure-01, bay 7" instead of failing with "not found" — confirmed live: tab-completing a bay name and then editing it by hand is easy to get the comma-spacing wrong on, especially since the shell already forces backslash-escaping the space (Enclosure-01,\ bay\ 7). Name lookups now normalize whitespace and comma spacing (in addition to the existing case-insensitive match) before comparing.

Enhancements

• proliant oneview update enclosure (no NAME): launches an interactive, menu-driven wizard instead of requiring every flag up front — walks through logical enclosure, baseline, scope, install type (when applicable), activation mode, force, and a final review/execute question, one numbered choice at a time. Type b at any step to go back and change a previous answer, or c/q to cancel without changing anything. Passing NAME (with or without other flags) still works exactly as before for scripting/automation; the wizard requires an interactive terminal and is unavailable in --json mode.
• proliant oneview release: shows HPE's published Synergy Software Releases compatibility matrix — for every Composer (HPE OneView) version, which SSP is recommended and which are additionally supported. Marks the row matching the currently-connected appliance when reachable; works offline otherwise. The same source data already backs the compatibility note shown by update enclosure's plan.
• proliant oneview update enclosure --activation-mode {orchestrated,parallel}: exposes OneView's own -InterconnectActivationMode choice. orchestrated (default) flashes one side of each redundant Logical Interconnect pair at a time so the fabric stays up; if an uplink set isn't redundant OneView raises its non-disruptive validation warning, which you can proceed through (exactly as with the GUI's "Review the warnings… click OK to proceed") to apply the update with a brief interruption limited to the affected uplinks. parallel flashes every interconnect at once regardless of redundancy — a full network outage during the update, and OneView additionally requires the affected compute modules to be powered off first — and is clearly flagged as disruptive in the confirmation panel. When a target stays blocked, the CLI surfaces OneView's own reason and "Resolution:" steps (e.g. restore uplink-set redundancy) rather than prescribing a specific hardware action.
• proliant oneview update enclosure --execute: when OneView blocks a target update on its non-disruptive-fabric validation guard, the CLI now shows OneView's own warning and its "Resolution:" remediation steps inline — the exact same text as the OneView GUI's "Review the warnings. If the conditions are acceptable, then click OK to proceed." modal, with embedded resource references (logical interconnects, server profiles) shown by name instead of raw JSON — plus a read-only "which uplink set / which leg" diagnostic the GUI makes you hunt for: for each flagged uplink set it lists every live uplink leg across the interconnect pair (location, port, link state, negotiated speed) and a plain-language note on why it isn't redundant (a down leg, a single-sided set, or a speed mismatch) and what to fix (verified live: pinpoints pvlan-uplinkset on LE01-LIG-VC100 with its Bay 3 leg up at 10G and its Bay 6 leg down). It then presents an on-the-spot A/B choice: A) abort and fix the fabric redundancy first (recommended, no disruption), or B) force the update through now — the disruptive path that actually gets a genuinely non-redundant fabric to update (clears the guard and force-reinstalls), briefly interrupting the affected uplinks and any server profiles riding them, matching accepting the GUI's warning. Previously the prompt only offered a plain "proceed anyway" that cleared the guard without forcing — which, confirmed live, an Orchestrated per-interconnect redundancy block simply re-rejected, so it never actually got through. --yes proceeds non-disruptively (guard-only, may still stay blocked on a truly non-redundant fabric); --force takes path B non-interactively; --json never prompts.
• Replaced proliant oneview firmware apply and proliant oneview upgrade ... with a unified proliant oneview update command family, matching OneView's own "Update firmware" dialog instead of a confusing set of flags:
  • proliant oneview update enclosure <NAME> — roll out an SSP baseline to one named logical enclosure. --baseline picks the SSP (defaults to newest, so the same rollout can be repeated against different baselines for consistency testing); --scope shared-infra (default) updates only frame link modules + interconnects, --scope shared-infra-and-profiles also rolls the baseline out to every server profile OneView shows under that enclosure's compute modules — the CLI now discovers those profiles itself instead of requiring --server-profile/--all-profiles. The old --all-enclosures/--logical-enclosure/--server-profile/--all-profiles flags are gone; a logical enclosure name is now a required argument, mirroring the GUI's per-enclosure dialog.
  • proliant oneview update appliance {readiness,run,pending,cancel,cleanup} — same appliance-software-upgrade commands as the old proliant oneview upgrade, just renamed under update to sit next to update enclosure.

---