> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/cloud-for-dpi/agent-skills/openstack-usage-toolkit/openstack-compute.md). # OpenStack Compute Operate tenant VMs and verify resize decisions. {% hint style="info" %} **Skill** `openstack-compute` · version 0.1.0 · [Chapter 3](/experience-digital-transformation/cloud-for-dpi/chapter-3.md) · [Source](https://git.vanillacore.net/giga/cloud-skills/src/commit/5ef20352d7e160cb5145c3773a7f002e1f03d5a3/skills/openstack-compute) · [Install and use](/experience-digital-transformation/cloud-for-dpi/agent-skills/install-and-use.md) {% endhint %} Create tenant VMs, inspect existing servers, start, stop, reboot, prepare resize, confirm or revert resize, and remove explicitly selected servers. Use discovered image, flavor and network IDs. This is an operational skill for existing OpenStack environments, independent of the Chapter 3 lab. Teach the mechanism when the user needs it, then use the same tools for actual work. Do not force an experienced user to complete a chapter or create a disposable project. ## When to use Use for a bounded compute task in a supplied OpenStack project. Use the chapter practitioner for a full IaaS lesson or chapter handoff. Do not install or repair the OpenStack control plane. Route controller-owned resources to their active OpenTofu, CAPI or GitOps owner rather than changing them underneath that owner. ## Inputs Collect the task, existing local cloud profile, exact project ID and region, target IDs, ownership evidence, intended resource values and data decisions. Read `references/usage.md` for the domain flow and `references/operations-api.md` for the exact context and action field names supported by the executable helper. Ask only for missing fields needed by this action; do not invent catalogue values or assume admin permissions. Credentials remain in the operator's protected local configuration. Runtime inputs, plans and evidence belong in a protected working copy, not this installed skill. Bash/POSIX semantics are required for these examples; Windows execution uses WSL. Python 3.10+ and OpenStackClient are required. CLI syntax is checked against OpenStackClient 8.2.0; cloud API behavior and policy are discovered per target. ## Procedure 1. Explain the requested outcome and identify its administrative boundary. Reuse the existing case ID, profile, project, region and stable IDs. A profile is not a permission grant. 2. Resolve the installed skill path and operator-supplied work path. Copy `assets/operator-kit/` to a new protected working directory; verify its checksums before writing local inputs. 3. For inspection, run the read-only command below. Return real permitted results plus unavailable or denied checks. Do not request change approval for a read-only diagnosis. 4. For a change, confirm ownership and data handling, then prepare exactly one supported action. The helper builds a saved plan through a fixed action catalogue; it does not accept arbitrary shell commands. Preparation performs read-only API checks but no cloud mutation. 5. Show the exact target, intended change, dependencies, interruption/data impact, verification and failure continuation. Obtain explicit approval for that saved plan digest. A general request to help or approval of inspection is not mutation approval. 6. Execute only that approved plan. Recheck identity and target before changing state, keep waits bounded, and preserve IDs after creation even if later validation fails. Do not automatically retry a failed create or silently delete partial resources. 7. Read back the affected service state and relationships. Explain what succeeded, what remains, and whether another independently approved operation is needed. Pass the real operation record to the coordinator. Create may use private networking without a floating IP. A successful Nova create or ACTIVE state does not prove guest access. Resize reaching VERIFY\_RESIZE is a decision point, not final acceptance: compare the target flavor and workload checks, then request a separate confirmation or revert. Preserve persistent data decisions before deletion. ## Working commands Resolve `SKILL_DIR` and `WORK_DIR` from actual host/operator inputs. The paths below are placeholders, not environment defaults. ```bash set -euo pipefail SKILL_DIR=/absolute/path/to/installed/openstack-compute WORK_DIR=/absolute/path/to/protected/new-operation umask 077 test ! -e "$WORK_DIR" mkdir -p "$(dirname "$WORK_DIR")" cp -R "$SKILL_DIR/assets/operator-kit" "$WORK_DIR" cd "$WORK_DIR" python3 scripts/verify_kit.py python3 scripts/openstack_ops.py --help ``` Create the local context according to `references/operations-api.md`, without credentials, then inspect: ```bash python3 scripts/openstack_ops.py inspect \ --context context.json --domain compute \ --evidence inspection.json ``` Use a domain-appropriate `--resource-id` for a specific existing target when the API contract requires it. Refer to the bundled action catalogue for supported parameters and complete examples. Environment discovery and troubleshooting are read-only; their next change is routed to the corresponding compute, networking or storage skill. For a mutating domain, preparation and execution are separate: ```bash python3 scripts/openstack_ops.py prepare \ --context context.json --request request.json --plan proposal.json # Review proposal.json and obtain approval of its exact digest. APPROVED_PLAN_SHA256=operator_supplied_approved_digest python3 scripts/openstack_ops.py execute \ --plan proposal.json --approve "$APPROVED_PLAN_SHA256" \ --evidence execution.json ``` The shell placeholder is not approval evidence. Never substitute a newly computed digest for one the operator actually approved. Reuse a prior result as evidence, not as authorization to replay a change. There is no automatic rollback guarantee after an API mutation: preserve affected IDs and prepare an explicit recovery or cleanup action. ## Output Return a concise answer plus the real helper result. The operational contract is `openstack-operation-record/v1`; its required fields and statuses are defined locally in `references/operations-api.md` and produced by the helper. Preserve case identity, domain/action, target project/region, execution level, checks, stable resource IDs, findings, status and bounded next action. Do not turn offline fixture output into cloud evidence. ```yaml schema: openstack-operation-record/v1 case_id: domain: compute action: project_id: region: execution_level: checks: [] resource_ids: [] findings: [] status: next_action: ``` Do not include token values, credentials, raw client stderr, cloud configuration, secret-bearing user data, private keys, state or plan bodies in chat. A local plan can be reviewed at its protected path without publishing its contents. Report a denied operation precisely; it does not establish that all project work is impossible. ## Learning and review `ask` explains one task. `learn` teaches it through a real or explicitly synthetic case. `work` uses Spec -> Run -> Validation. Repeat. `review` separates syntax, authorization, resource state and service behavior. In `challenge` mode, obtain the learner attempt and stop before the correction when no attempt exists; never run a live mutation merely to demonstrate an answer. ## Verification The case, project and region match the supplied target. Local values are discovered or explicitly supplied. Each claimed operation is supported by the helper's action catalogue. Preparation did not mutate. Execution required the actual approved plan digest and direct ownership. Evidence names the strongest supported result, records partial failures and keeps guest/application or recovery claims separate from IaaS observations. Verify standalone installation and offline fixtures; live acceptance requires an explicitly approved real target. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/cloud-for-dpi/agent-skills/openstack-usage-toolkit/openstack-compute.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.