Alex/openstack-dashboard-app
Watch
1
0
Fork
You've already forked openstack-dashboard-app
 0
Code Issues 2 Pull requests Releases Wiki Activity Actions

Real-cloud VM actions missing: implement Horizon instance action coverage #10

New issue
Open
opened 2026-11-05 17:30:59 +01:00 by Alex · 0 comments
Alex commented 2026-11-05 17:30:59 +01:00
Owner

Delivery status

All five commits (044888a, 53e680d, 3630678, afb0eb2, 6df1532) are now pushed to origin/main. Remote HEAD was verified as 6df1532cca8632c0c2c6066faf1b9ec2ab5de076.

Implementation and local checks are delivered. This issue remains open for native desktop and live-cloud acceptance, including the compatibility limits already documented below. No native/live-cloud pass is claimed.

Report

The real-cloud instance inventory has no VM action menu. The reporter supplied artifacts/screenshot-2026-11-05_17-28-51.png as the target Horizon action overview (23 entries). The screenshot remains local; do not commit screenshots or generated evidence.

Verified source findings

Reviewed publication repository at commit e48cd75.

  • app/src/features/profiles/CloudProfile.svelte:237: the table includes row actions for images, volumes, volume snapshots, networks, subnets and ports. Instances only have a details button and are excluded from the action column.
  • app/src/features/profiles/InstanceDetails.svelte: the instance dialog displays details with Refresh and Close; it provides no VM operations.
  • app/src/features/cloud-actions/operation-client.ts:2-3: source kinds and write actions do not include management of existing instances.
  • app/worker/cloud_operation_schema.py:8-12: worker intents and affected-resource declarations have no existing-instance mutations. Existing launch creates a VM from an image/snapshot; it does not manage an existing VM.
  • app/worker/cloud_operations.py:168-258: execution handles image, volume, launch and delegated network operations, with no existing-instance action implementation.
  • app/src/features/fixture-menus/compute/registry.ts advertises some compute operations, but fixture-provider.ts executes them against synthetic local rows. These are not real-cloud VM actions.

This is an end-to-end missing feature, not only a hidden dropdown.

Requested action coverage (source implemented; runtime acceptance still open)

  • Create Snapshot
  • Associate Floating IP
  • Attach Interface
  • Detach Interface
  • Edit Instance
  • Attach Volume
  • Detach Volume
  • Update Metadata
  • Edit Security Groups
  • Edit Port Security Groups
  • Console
  • View Log
  • Rescue Instance
  • Pause Instance
  • Suspend Instance
  • Shelve Instance
  • Resize Instance
  • Lock Instance
  • Soft Reboot Instance
  • Hard Reboot Instance
  • Shut Off Instance
  • Rebuild Instance
  • Delete Instance

Include complementary actions where appropriate for the current server state: Start, Unpause, Resume, Unshelve, Unlock, Unrescue, and Confirm/Revert Resize. The screenshot shows one state; do not enable every action unconditionally.

Implementation and acceptance requirements

  1. Provide a real-cloud per-instance action menu using the shared row-action UI and dedicated instance domain/application modules. Keep UI, API execution and persistence separate.
  2. Add fixed validated worker intents and SDK execution. Reuse existing scoped connection binding, fresh resource checks, one-use request fences, outcome journal and cache invalidation. Determine the resources affected by each action (including instances, images, volumes, ports and floating IPs).
  3. Gate each action on fresh server/task/lock state, project ownership, policy, supported extensions and microversion. Explain denied or unsupported operations; stale cache state alone must not authorize writes.
  4. Collect action-specific fields and resource selections in dialogs; confirm disruptive/destructive operations. Handle resize confirmation/revert, rebuild image/boot constraints, and attachment ownership explicitly.
  5. Treat asynchronous API acceptance separately from completion; refresh affected resources, show failures and uncertain outcomes, and never automatically replay uncertain writes.
  6. Handle console URLs and log contents as sensitive ephemeral data; validate console URLs before opening and exclude credentials, console tokens, log bodies and metadata values from diagnostic logs/journals.
  7. Validate relevant source contracts and builds without committing test suites or artifacts, per AGENTS.md. Live-cloud operation verification is still required before claiming end-to-end completion.

Suggested implementation order

  1. Core lifecycle: start/stop, soft/hard reboot, lock/unlock and delete, including shared instance preparation and action infrastructure.
  2. Edit, metadata, snapshot, resize/confirm/revert and rebuild.
  3. Floating IPs, interfaces, volumes and security-group workflows.
  4. Console/logs and rescue, pause, suspend and shelve workflows with complementary actions.

Current status

Implemented locally in commit 044888a (pushed to origin/main). The local Horizon reference was inspected at commit 42c90d0cc4b140c4ace5691302248a2e12837f66, including instance tables, forms, edit workflows and Neutron security-group updates. Source coverage includes the 23 reported menu workflows plus their complementary actions. UI, worker intents/SDK execution, scoped preflights, request fences, journaling and cache invalidation are connected end to end.

Validation passed:

  • npm run check: zero errors and warnings; npm run build passed.
  • Worker source compilation and dependency/source manifest validation passed.
  • 34 actual-SDK cases against a disposable local HTTPS provider covered lifecycle, snapshot, rebuild/rescue, interfaces, volumes, floating IPs, security groups, console and logs.
  • Negative checks blocked stale state/stamps, wrong project, locked/busy VMs, foreign attachments, bootable-volume detachment, occupied floating IPs and missing confirmation before writes.
  • Actual operation-runner checks covered fences, journaling, 403 rejection and unknown 503 outcomes without replay. Metadata, console URLs and log contents were excluded from the durable journal.
  • Browser checks covered the real CloudProfile integration, state/lock-aware menus, keyboard access, confirmations, single submission, metadata and IP/port selection, logs and responsive dialogs.

Limits: Nova 2.9–2.37; descriptions need 2.19. Rebuild/rescue currently support image-backed instances. Multiattach is excluded, and bootable volumes cannot be detached by this workflow. HTTPS is required for console URLs. These limits are documented in docs/INSTANCE-ACTIONS.md.

The native desktop build could not be run because Rust/Cargo are absent in this environment. Live-cloud acceptance has not been performed and no real cloud resources were mutated. The issue remains OPEN for native/runtime acceptance; checked boxes record implemented source coverage, not successful operations on the reporter's cloud.

## Delivery status All five commits (`044888a`, `53e680d`, `3630678`, `afb0eb2`, `6df1532`) are now pushed to `origin/main`. Remote HEAD was verified as `6df1532cca8632c0c2c6066faf1b9ec2ab5de076`. Implementation and local checks are delivered. This issue remains open for native desktop and live-cloud acceptance, including the compatibility limits already documented below. No native/live-cloud pass is claimed. ## Report The real-cloud instance inventory has no VM action menu. The reporter supplied `artifacts/screenshot-2026-11-05_17-28-51.png` as the target Horizon action overview (23 entries). The screenshot remains local; do not commit screenshots or generated evidence. ## Verified source findings Reviewed publication repository at commit e48cd75. - `app/src/features/profiles/CloudProfile.svelte:237`: the table includes row actions for images, volumes, volume snapshots, networks, subnets and ports. Instances only have a details button and are excluded from the action column. - `app/src/features/profiles/InstanceDetails.svelte`: the instance dialog displays details with Refresh and Close; it provides no VM operations. - `app/src/features/cloud-actions/operation-client.ts:2-3`: source kinds and write actions do not include management of existing instances. - `app/worker/cloud_operation_schema.py:8-12`: worker intents and affected-resource declarations have no existing-instance mutations. Existing `launch` creates a VM from an image/snapshot; it does not manage an existing VM. - `app/worker/cloud_operations.py:168-258`: execution handles image, volume, launch and delegated network operations, with no existing-instance action implementation. - `app/src/features/fixture-menus/compute/registry.ts` advertises some compute operations, but `fixture-provider.ts` executes them against synthetic local rows. These are not real-cloud VM actions. This is an end-to-end missing feature, not only a hidden dropdown. ## Requested action coverage (source implemented; runtime acceptance still open) - [x] Create Snapshot - [x] Associate Floating IP - [x] Attach Interface - [x] Detach Interface - [x] Edit Instance - [x] Attach Volume - [x] Detach Volume - [x] Update Metadata - [x] Edit Security Groups - [x] Edit Port Security Groups - [x] Console - [x] View Log - [x] Rescue Instance - [x] Pause Instance - [x] Suspend Instance - [x] Shelve Instance - [x] Resize Instance - [x] Lock Instance - [x] Soft Reboot Instance - [x] Hard Reboot Instance - [x] Shut Off Instance - [x] Rebuild Instance - [x] Delete Instance Include complementary actions where appropriate for the current server state: Start, Unpause, Resume, Unshelve, Unlock, Unrescue, and Confirm/Revert Resize. The screenshot shows one state; do not enable every action unconditionally. ## Implementation and acceptance requirements 1. Provide a real-cloud per-instance action menu using the shared row-action UI and dedicated instance domain/application modules. Keep UI, API execution and persistence separate. 2. Add fixed validated worker intents and SDK execution. Reuse existing scoped connection binding, fresh resource checks, one-use request fences, outcome journal and cache invalidation. Determine the resources affected by each action (including instances, images, volumes, ports and floating IPs). 3. Gate each action on fresh server/task/lock state, project ownership, policy, supported extensions and microversion. Explain denied or unsupported operations; stale cache state alone must not authorize writes. 4. Collect action-specific fields and resource selections in dialogs; confirm disruptive/destructive operations. Handle resize confirmation/revert, rebuild image/boot constraints, and attachment ownership explicitly. 5. Treat asynchronous API acceptance separately from completion; refresh affected resources, show failures and uncertain outcomes, and never automatically replay uncertain writes. 6. Handle console URLs and log contents as sensitive ephemeral data; validate console URLs before opening and exclude credentials, console tokens, log bodies and metadata values from diagnostic logs/journals. 7. Validate relevant source contracts and builds without committing test suites or artifacts, per AGENTS.md. Live-cloud operation verification is still required before claiming end-to-end completion. ## Suggested implementation order 1. Core lifecycle: start/stop, soft/hard reboot, lock/unlock and delete, including shared instance preparation and action infrastructure. 2. Edit, metadata, snapshot, resize/confirm/revert and rebuild. 3. Floating IPs, interfaces, volumes and security-group workflows. 4. Console/logs and rescue, pause, suspend and shelve workflows with complementary actions. ## Current status Implemented locally in commit `044888a` (pushed to origin/main). The local Horizon reference was inspected at commit `42c90d0cc4b140c4ace5691302248a2e12837f66`, including instance tables, forms, edit workflows and Neutron security-group updates. Source coverage includes the 23 reported menu workflows plus their complementary actions. UI, worker intents/SDK execution, scoped preflights, request fences, journaling and cache invalidation are connected end to end. Validation passed: - `npm run check`: zero errors and warnings; `npm run build` passed. - Worker source compilation and dependency/source manifest validation passed. - 34 actual-SDK cases against a disposable local HTTPS provider covered lifecycle, snapshot, rebuild/rescue, interfaces, volumes, floating IPs, security groups, console and logs. - Negative checks blocked stale state/stamps, wrong project, locked/busy VMs, foreign attachments, bootable-volume detachment, occupied floating IPs and missing confirmation before writes. - Actual operation-runner checks covered fences, journaling, 403 rejection and unknown 503 outcomes without replay. Metadata, console URLs and log contents were excluded from the durable journal. - Browser checks covered the real CloudProfile integration, state/lock-aware menus, keyboard access, confirmations, single submission, metadata and IP/port selection, logs and responsive dialogs. Limits: Nova 2.9–2.37; descriptions need 2.19. Rebuild/rescue currently support image-backed instances. Multiattach is excluded, and bootable volumes cannot be detached by this workflow. HTTPS is required for console URLs. These limits are documented in `docs/INSTANCE-ACTIONS.md`. The native desktop build could not be run because Rust/Cargo are absent in this environment. Live-cloud acceptance has not been performed and no real cloud resources were mutated. The issue remains OPEN for native/runtime acceptance; checked boxes record implemented source coverage, not successful operations on the reporter's cloud.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Alex/openstack-dashboard-app#10
No description provided.