OpenKeel: the sovereign French Cloud solution of the inherent group, with a European reach Discover inherent

Reverse-spec · Services

nova — Scenarios

Scenarios — nova — branch stable/2026.2

Branch stable/2026.2 @ 8df1922926dd (34.0.0 + 7 commits) — repository https://opendev.org/openstack/nova — analysed on 2026-10-28

Related files: REST API · errors · interactions · async processing.

Participants: API = nova-api, SC = super-conductor, SCH = nova-scheduler, CMP = nova-compute (source/destination), APIDB / CELLDB = API and cell databases, PL = Placement, NEU = Neutron, CIN = Cinder, GL = Glance, MQ = RabbitMQ. Database access from computes goes through the cell conductor; it is drawn as direct for readability.

1. Boot a server

POST /servers returns 202 as soon as the request is recorded in the API database; the instance does not exist in any cell until the conductor has scheduled it.

sequenceDiagram
  autonumber
  actor U as User
  participant API as nova-api
  participant APIDB as API DB
  participant SC as nova-conductor
  participant SCH as nova-scheduler
  participant PL as Placement
  participant CELLDB as cell DB
  participant CMP as nova-compute
  participant NEU as Neutron
  participant CIN as Cinder
  participant GL as Glance
  U->>API: POST /v2.1/servers
  API->>GL: GET /v2/images/{id}
  API->>NEU: GET ports / networks (validation, resource requests)
  API->>APIDB: INSERT request_specs, build_requests, instance_mappings (1 tx)
  API->>SC: AMQP cast schedule_and_build_instances (topic conductor)
  API-->>U: 202 {server: {id, adminPass}} + Location
  SC->>SCH: AMQP call select_destinations (long_rpc_timeout)
  SCH->>PL: GET /allocation_candidates
  SCH->>PL: PUT /allocations/{instance} (claim)
  alt no host / claim impossible
    SCH-->>SC: NoValidHost
    SC->>CELLDB: INSERT instance in cell0 (vm_state=error) + fault
    SC->>APIDB: instance_mappings.cell_id=cell0, DELETE build_requests
  else host selected
    SCH-->>SC: [selection + alternates]
    SC->>APIDB: SELECT host_mappings (host → cell)
    SC->>CELLDB: INSERT instances, block_device_mapping, tags
    SC->>APIDB: UPDATE instance_mappings.cell_id, DELETE build_requests
    SC->>CMP: AMQP cast build_and_run_instance (topic compute, server=host)
    CMP->>PL: GET /allocations/{instance}
    CMP->>NEU: POST/PUT ports (binding:host_id)
    CMP->>CIN: POST attachments (3.44), complete
    CMP->>GL: GET /v2/images/{id}/file (image cache)
    CMP->>CMP: driver.spawn (wait network-vif-plugged)
    NEU->>API: POST /os-server-external-events network-vif-plugged
    API->>CMP: AMQP cast external_instance_event
    alt spawn ok
      CMP->>CELLDB: vm_state=active, launched_at
    else retryable failure
      CMP->>PL: DELETE /allocations/{instance}
      CMP->>SC: AMQP cast build_instances (next alternate)
    else fatal
      CMP->>CELLDB: vm_state=error + instance_faults
    end
  end

Diagnostics: server stuck in BUILD with task_state=scheduling → conductor/scheduler logs ("Failed to schedule instances", "Got no allocation candidates from the Placement API"); ERROR with "No valid host was found" → instance lives in cell0, check Placement inventories/traits and request filters; stuck in spawning → compute log and Neutron (network-vif-plugged never sent, vif_plugging_timeout); GET /servers/{id}/os-instance-actions/{req} shows which compute step failed.

2. Delete a server

sequenceDiagram
  autonumber
  actor U as User
  participant API as nova-api
  participant APIDB as API DB
  participant CELLDB as cell DB
  participant CMP as nova-compute
  participant NEU as Neutron
  participant CIN as Cinder
  participant PL as Placement
  U->>API: DELETE /v2.1/servers/{id}
  API->>APIDB: SELECT instance_mappings / build_requests
  alt still a build request
    API->>APIDB: DELETE build_requests (build cancelled)
  else instance in a cell, compute up
    API->>CELLDB: task_state=deleting, instance action delete
    API->>CMP: AMQP cast terminate_instance
    CMP->>CMP: driver.destroy
    CMP->>NEU: unbind / delete ports
    CMP->>CIN: DELETE attachments (delete_on_termination volumes deleted)
    CMP->>PL: DELETE /allocations/{instance}
    CMP->>CELLDB: vm_state=deleted, deleted=id
  else compute down or shelved-offloaded (local delete)
    API->>CIN: detach / delete attachments
    API->>PL: DELETE /allocations/{instance}
    API->>CELLDB: destroy instance
  end
  API-->>U: 204

Diagnostics: 409 AllocationDeleteFailed → Placement unreachable or generation conflict; a guest still running for a deleted instance is caught by _cleanup_running_deleted_instances (05 § 4.3); ports left behind → Neutron logs of the compute's unbind calls.

3. Resize (cold migration) and confirm

sequenceDiagram
  autonumber
  actor U as User
  participant API as nova-api
  participant SC as nova-conductor
  participant SCH as nova-scheduler
  participant PL as Placement
  participant SRC as compute (source)
  participant DST as compute (destination)
  U->>API: POST /servers/{id}/action {resize: {flavorRef}}
  API->>API: check state ACTIVE/STOPPED, quota for the new flavor
  API->>SC: AMQP call/cast migrate_server (task_state=resize_prep)
  SC->>PL: POST /allocations (move instance allocation to migration consumer)
  SC->>SCH: AMQP call select_destinations
  SCH->>PL: PUT /allocations/{instance} on destination
  SC->>DST: AMQP cast prep_resize
  DST->>DST: resource tracker claim
  DST->>SRC: AMQP cast resize_instance
  SRC->>SRC: power off, migrate disk
  SRC->>DST: AMQP cast finish_resize (topic compute-alt)
  DST->>DST: driver.finish_migration, ports bound to destination
  DST-->>U: status VERIFY_RESIZE (observed by GET)
  U->>API: POST /servers/{id}/action {confirmResize: null}
  API->>SRC: AMQP cast confirm_resize
  SRC->>SRC: cleanup source guest
  SRC->>PL: DELETE /allocations/{migration}
  alt revertResize instead
    API->>DST: AMQP cast revert_resize
    DST->>SRC: AMQP cast finish_revert_resize (topic compute-alt)
    SRC->>PL: POST /allocations (give allocation back to instance)
  end

Diagnostics: instance back to ACTIVE with an instance fault and no resize → scheduling failed (NoValidHost, migration error); stuck in resize_migrating → source compute log; VERIFY_RESIZE forever → resize_confirm_window is 0 by default, the user must confirm.

4. Live migration

sequenceDiagram
  autonumber
  actor A as Admin
  participant API as nova-api
  participant SC as nova-conductor
  participant SCH as nova-scheduler
  participant PL as Placement
  participant SRC as compute (source)
  participant DST as compute (destination)
  participant NEU as Neutron
  A->>API: POST /servers/{id}/action {os-migrateLive: {host: null}}
  API->>SC: AMQP cast live_migrate_instance (task_state=migrating)
  API-->>A: 202
  SC->>PL: POST /allocations (instance → migration consumer)
  SC->>SCH: AMQP call select_destinations
  SC->>DST: AMQP call check_can_live_migrate_destination
  DST->>SRC: AMQP call check_can_live_migrate_source
  SC->>SRC: AMQP cast live_migration
  SRC->>DST: AMQP call pre_live_migration (topic compute-alt)
  DST->>NEU: create inactive port bindings for destination
  SRC->>SRC: driver.live_migration (memory copy)
  alt success
    SRC->>NEU: activate destination bindings
    SRC->>DST: AMQP cast post_live_migration_at_destination (compute-alt)
    SRC->>PL: DELETE /allocations/{migration}
  else failure / abort (DELETE /servers/{id}/migrations/{mid})
    SRC->>DST: AMQP cast rollback_live_migration_at_destination
    SRC->>PL: POST /allocations (back to instance on source)
  end

Diagnostics: GET /servers/{id}/migrations shows progress (memory/disk bytes); a migration stuck running can be forced (force_complete) or aborted; "Live migration failed." in the source compute log; port binding errors appear in Neutron.

5. Attach a volume

sequenceDiagram
  autonumber
  actor U as User
  participant API as nova-api
  participant SC as nova-conductor
  participant CIN as Cinder
  participant CMP as nova-compute
  U->>API: POST /servers/{id}/os-volume_attachments {volumeId}
  API->>CIN: GET /volumes/{id} (status, AZ, multiattach)
  API->>SC: AMQP call attach_volume (long timeout)
  SC->>CMP: AMQP call reserve_block_device_name (creates BDM)
  SC->>CIN: POST /attachments (3.44, reserve)
  SC->>CMP: AMQP cast attach_volume
  SC-->>API: BDM
  API-->>U: 200 {volumeAttachment: {device, id, serverId, volumeId}}
  CMP->>CIN: PUT /attachments/{id} (host connector)
  CMP->>CMP: driver.attach_volume
  CMP->>CIN: POST /attachments/{id}/action complete

Diagnostics: volume stuck reserved/attaching → compute log for attach_volume; the BDM exists but the device is missing → driver error recorded as instance action event compute_attach_volume; for shelved-offloaded servers no compute is involved (the attachment completes immediately).

Source: reverse-spec-nova/04-scenarios_stable-2026.2.md. The _rewrite/ and _inventory/ files are not published on the site.