Update runbook
Quick start

OneView documentation

Update runbook

Prepare, preflight, apply, validate, and recover a controlled update.

Purpose and ownership

This runbook covers a client-controlled OneView software update. The client host administrator decides when to apply an available release and runs the command displayed by the installed application. A source-managed localhost command only changes the locally reported test version and is not a software release installation.

Prerequisites

Before scheduling an update, confirm:

  • the license is active and required online services are reachable;
  • the installed version, architecture, and health are known;
  • the server, network, database, and HTTPS address are healthy;
  • current database and installation backups exist and have a tested restore owner;
  • release notes have been reviewed;
  • integration owners understand the maintenance window; and
  • no unrelated network, database, or credential change will run at the same time.

Never place database credentials, setup or activation values, application credentials, or verification records in a change ticket.

Apply

  1. Open License & Updates → System updates.
  2. Select Check now.
  3. Review the target version, compatibility, package size, and release notes.
  4. Confirm maintenance and backup owners are ready.
  5. Check whether Update instructions identifies an installed-server update command or a source-checkout command.
  6. For an installer-managed deployment, copy the installed server's authoritative command without editing it.
  7. Run it on that OneView host, confirm the source and target versions, enter y only after final approval, and keep the terminal attached through a final outcome.
  8. For a source-managed localhost, first confirm the checkout already contains the code intended for testing. Stop the backend, run the exact platform- and path-specific command shown locally, then restart the backend through the checkout's normal approved development workflow.
  9. Treat the source-checkout command only as a change to the locally reported/test version. It does not download or install published code, packages, images, migrations, or other release contents.
  10. Do not add or wait for a manual handoff code; neither supported workflow uses one.

For an installer-managed update, the terminal and dashboard show progress. A temporary browser disconnection during a service restart is expected and is not by itself a failure. A source-checkout command has no installer progress stages; after restart, confirm the local backend reports the intended test version.

Validate

Before reopening integration traffic:

  1. Confirm the terminal reached a final outcome.
  2. Confirm the dashboard shows the expected installed version.
  3. Run the sanitized installation report and network health checks.
  4. Confirm normal sign-in and license status.
  5. Review sessions, vendor connections, and activity logs.
  6. Run approved synthetic verifications for critical Sub-modules.
  7. Reopen traffic gradually and monitor client-owned infrastructure.

Record only safe version, timing, health, and request-reference evidence.

Failed or interrupted update

If the command reports Previous release restored, validate the restored version before reopening traffic.

If it reports Failed, or if the host or updater stops before a final outcome:

  1. Keep integration traffic paused.
  2. Confirm no updater process is still running.
  3. Preserve the terminal output and safe attempt reference.
  4. Do not edit the database, generated deployment configuration, backup contents, or update status.
  5. Use the recovery instruction displayed by the installed operational tooling for that exact attempt and version.
  6. If recovery cannot prove a healthy deployment, use the Disaster-recovery runbook.

Do not reconstruct recovery commands from memory or another installation. Do not bypass package, compatibility, backup, health, or restoration checks.

Change checklist

  • Installed version and health confirmed.
  • Update check completed and release notes reviewed.
  • Database, installation backup, and maintenance owners assigned.
  • Integration traffic and communication coordinated.
  • Installed server command used unchanged, or the exact local source-checkout command was used only to set the reported test version.
  • Installer source/target confirmed in the terminal, or the source-run version confirmed after backend restart.
  • Installer terminal remained attached through a final outcome, when applicable.
  • Version, HTTPS, sign-in, license, vendor, and synthetic checks passed.
  • Any interrupted attempt followed the installed recovery guidance without manual state edits.