Remove unnecessary deployment gates and record preparation
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# Feature 0016: Deploy the D&D Pipeline to `pipeline-dnd`
|
||||
|
||||
Status: blocked
|
||||
Status: in_progress
|
||||
|
||||
## Summary
|
||||
|
||||
@@ -205,9 +205,9 @@ Record non-secret choices in the implementation plan or deployment runbook:
|
||||
paths so dependency installation and playbook execution use the same
|
||||
inventory and installed content. Distinguish those paths from this
|
||||
development workspace.
|
||||
- Confirm that `pipeline-dnd` runs the supported Ubuntu 26.04 environment and
|
||||
that its existing `eric` account provides SSH access and the sudo access
|
||||
required by the roles.
|
||||
- The target must satisfy the roles' Ubuntu 26.04 and access requirements.
|
||||
Normal connection, role guards, and privileged tasks can establish these;
|
||||
separate platform or sudo probes are not required acceptance tests.
|
||||
- Establish the controller's existing Vault password or identity mechanism
|
||||
and operator availability to populate the four credential values in the
|
||||
encrypted host file. Record how Vault is selected, never its password or
|
||||
@@ -273,10 +273,11 @@ suite defaults.
|
||||
preserves `dilfs` as the default campaign through the existing standalone
|
||||
role variable, and inherits Feature 0015's storage and publishing defaults.
|
||||
- `dnd_pipeline_secrets` maps the required typed runtime keys to host Vault
|
||||
variables, and the actual values exist only in a valid Ansible
|
||||
Vault-encrypted file.
|
||||
- No plaintext credential value is present in any tracked revision, diff,
|
||||
command example, validation output, or deployment documentation.
|
||||
variables. Credential values in the consumer repository are Vault-encrypted;
|
||||
runtime delivery uses the suite's existing restricted secrets files.
|
||||
- This feature introduces no plaintext credential values into commits, diffs,
|
||||
command examples, validation output, or documentation. A repository-wide
|
||||
historical secret audit is not an acceptance requirement.
|
||||
- Legacy Narratio storage values are either represented through the current
|
||||
pipeline interface or deliberately retired; no stale high-precedence host
|
||||
variable can override the selected suite configuration accidentally.
|
||||
@@ -287,9 +288,9 @@ suite defaults.
|
||||
- The controller uses the selected collection commit even if collection
|
||||
version `0.1.0` was already installed. The documented inventory, role, and
|
||||
collection paths correspond to the operational controller.
|
||||
- On a controller bootstrapped from that manifest, `ansible-doc` resolves
|
||||
`rakestraw.dnd.pipeline` and each role dependency, and the new playbook
|
||||
passes syntax checking.
|
||||
- Public dependency installation succeeds, and the new playbook passes syntax
|
||||
checking with the installed collection and roles. Documentation rendering
|
||||
with `ansible-doc` is not required for deployment acceptance.
|
||||
- The initial limited playbook run against `pipeline-dnd` completes
|
||||
successfully using the encrypted inventory and ordinary sudo-capable remote
|
||||
account.
|
||||
@@ -299,7 +300,9 @@ suite defaults.
|
||||
shared pipeline through runtime-group membership.
|
||||
- One operator-selected D&D session completes transcription, processing,
|
||||
storage, and publishing, and its expected published output is observable at
|
||||
the configured destination.
|
||||
the configured destination. Either supported runtime identity may execute
|
||||
it. Production is the default profile; the operator may select the testing
|
||||
profile while retaining the same processing and publication acceptance scope.
|
||||
- The operational documentation explains dependency installation, Vault use,
|
||||
deployment invocation, the login-session membership caveat, convergence
|
||||
verification, and representative pipeline invocation without disclosing
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Implementation Plan 0016: Deploy the D&D Pipeline to `pipeline-dnd`
|
||||
|
||||
Status: blocked
|
||||
Status: in_progress
|
||||
|
||||
Target executor: GPT-5.6-Terra
|
||||
|
||||
@@ -31,6 +31,14 @@ scope, rationale, target state, and acceptance criteria.
|
||||
Do not solicit secrets in chat or create placeholder credentials.
|
||||
- Stop dependent work when operational inputs are missing or validation fails.
|
||||
Record the concrete blocker; local checks do not prove a live deployment.
|
||||
- Evaluate failures against the required outcome. Documentation rendering,
|
||||
incidental warnings, and optional diagnostics are not deployment acceptance
|
||||
gates. Report them separately unless they demonstrate a failure of required
|
||||
installation, parsing, convergence, or application behavior. Do not add new
|
||||
checks as mandatory conditions during execution.
|
||||
- Reuse successful validation evidence while its inputs remain unchanged.
|
||||
Rerun affected checks after changes; do not repeat entire stages solely to
|
||||
produce another record or because a non-blocking diagnostic failed.
|
||||
- Scope blockers to the operation that requires the missing input. Complete
|
||||
Stages 1–2 locally without remote SSH, production Vault values, or an
|
||||
acceptance session. Controller/SSH/Vault inputs gate Stage 3; session and
|
||||
@@ -70,7 +78,7 @@ scope, rationale, target state, and acceptance criteria.
|
||||
at the stage that needs them.
|
||||
- Local tooling is already installed and verified: Ansible Core 2.21.3 in
|
||||
`/home/eric/Workspace/ansible-dnd/.venv`. Use its `bin/ansible`,
|
||||
`bin/ansible-playbook`, `bin/ansible-galaxy`, and `bin/ansible-doc`, or prepend
|
||||
`bin/ansible-playbook` and `bin/ansible-galaxy`, or prepend
|
||||
that `bin` directory to `PATH`. No activation is required for absolute paths.
|
||||
|
||||
## Repository Scope
|
||||
@@ -134,6 +142,8 @@ Workspace: `Close storage review and begin host deployment`.
|
||||
|
||||
## Stage 2: Prepare the Consumer Playbook and Inventory
|
||||
|
||||
Completion: complete (consumer `12b2462`)
|
||||
|
||||
### Objective and Owning Repository
|
||||
|
||||
Make `rakestraw-ansible` a complete consumer of the reviewed suite snapshot.
|
||||
@@ -184,8 +194,8 @@ dependency paths, install from public sources with
|
||||
`ansible-galaxy install -r requirements.yml`. Configure role and collection
|
||||
destinations through Ansible configuration/environment; avoid a role-only
|
||||
custom path that would skip the collection section of the mixed manifest.
|
||||
Confirm resolution with `ansible-doc -t role rakestraw.dnd.pipeline` and the
|
||||
five `rakestraw.<app>` role names.
|
||||
Successful installation and playbook syntax checking are the dependency
|
||||
validation boundary. `ansible-doc` renders documentation and is not required.
|
||||
|
||||
For local checks, use the workspace executables and the checked-out inventory.
|
||||
Configure isolated role and collection paths explicitly. From the consumer
|
||||
@@ -238,8 +248,10 @@ checkout. Acceptance-session selection is not a prerequisite for this stage.
|
||||
### Required Changes and Validation
|
||||
|
||||
Before installation, confirm the operational controller's Ansible version and
|
||||
effective inventory, role, and collection paths. Confirm Ubuntu 26.04 and the
|
||||
existing `eric` account's required sudo access through read-only target checks.
|
||||
effective inventory, role, and collection paths. The target must support the
|
||||
roles' Ubuntu 26.04 contract and required sudo operations; ordinary connection,
|
||||
fact gathering, role platform guards, and privileged tasks establish these
|
||||
conditions. Separate preflight probes are optional troubleshooting, not gates.
|
||||
Have the operator create `inventory/host_vars/pipeline-dnd/vault.yml` encrypted
|
||||
in full, defining the four roadmap credential variables. Commit ciphertext
|
||||
with intent `Add encrypted D&D host credentials` after checking the diff
|
||||
@@ -262,8 +274,9 @@ encrypted inventory and recorded Vault options before convergence.
|
||||
Immediately repeat the identical command after success. Require
|
||||
`changed=0`, `failed=0`, and no unreachable hosts on the repeat.
|
||||
3. On the target, execute
|
||||
`sudo -u narratio /usr/local/bin/narratio config validate`, then validate
|
||||
with `--profile testing`. The managed default campaign should make an
|
||||
`sudo -u narratio /usr/local/bin/narratio config validate`.
|
||||
Testing-overlay validation is optional; it has already passed suite review
|
||||
and is not changed by this deployment. The managed default campaign should make an
|
||||
explicit campaign selector unnecessary.
|
||||
4. Start a fresh login as `eric` and execute the same default native validation
|
||||
without switching user, demonstrating usable supplementary group access.
|
||||
@@ -304,7 +317,8 @@ Do not erase existing state to create a fixture.
|
||||
|
||||
### Required Changes and Validation
|
||||
|
||||
1. As `eric` in a fresh authorized login, run:
|
||||
1. Under either supported runtime identity (`narratio` or `eric` with effective
|
||||
runtime-group membership), run:
|
||||
|
||||
```text
|
||||
narratio session validate SESSION_ID --campaign CAMPAIGN --session SESSION_FILE
|
||||
@@ -312,7 +326,9 @@ Do not erase existing state to create a fixture.
|
||||
narratio session artifacts SESSION_ID --remote --campaign CAMPAIGN --session SESSION_FILE
|
||||
```
|
||||
|
||||
Substitute the operator-recorded values and use the production profile.
|
||||
Substitute the operator-recorded values. Production is the default; an
|
||||
operator-selected testing profile is also valid if the exercise covers the
|
||||
agreed processing and publication path. Record the selected profile.
|
||||
The session document remains operational input; no session-management task
|
||||
belongs in the playbook. Observe transcription, processing, and successful
|
||||
publication. Do not force reprocessing or reduce the selected artifact set
|
||||
@@ -349,8 +365,9 @@ this stage.
|
||||
|
||||
### Preconditions
|
||||
|
||||
Stages 1–4 completed with committed changes and actual deployment/session
|
||||
evidence. A blocked live exercise does not satisfy this stage.
|
||||
Record progress at any stopping point, including a live-operation blocker.
|
||||
Full implementation handoff requires Stages 1–4 and actual deployment/session
|
||||
evidence; a partial handoff must explicitly identify uncompleted stages.
|
||||
|
||||
### Required Changes and Validation
|
||||
|
||||
@@ -390,20 +407,24 @@ independent review.
|
||||
merge commits are `cf3de016ee09edf91afc3bc1addfd926d4a172ad`,
|
||||
`77f67adbc0f700e88bc15554e02052eaa22f1033`, and
|
||||
`46913446765e86ecfb29ebad9955d579ef6a4c7e`.
|
||||
- Stage 2 local consumer preparation is next. The rejected target SSH identity,
|
||||
- Stage 2 local consumer preparation is complete. The rejected target SSH identity,
|
||||
operational controller details, and Vault workflow/values remain Stage 3
|
||||
prerequisites. The acceptance session/audio selection remains a Stage 4
|
||||
prerequisite. No live deployment has begun.
|
||||
- Stage 2 consumer changes are prepared but not committed because required
|
||||
validation exposed a compatibility conflict in the reviewed dependency pins.
|
||||
Installation from the mixed public manifest succeeded, the playbook selected
|
||||
only `pipeline-dnd`, and syntax checking passed. With the required Ansible
|
||||
Core 2.21.3 toolchain, `ansible-doc -t role` resolves the pipeline, Seriatim,
|
||||
and Audita roles, but rejects the pinned `v0.1.0` Notarius, Scriptorium, and
|
||||
Narratio argument specifications because public options lack required
|
||||
`description` fields. The plan keeps those repositories read-only and
|
||||
requires reporting demonstrated pin conflicts rather than changing them, so
|
||||
Stage 2 and all dependent work are blocked pending an approved resolution.
|
||||
- Stage 2 consumer changes are committed in `12b2462`. Installation from the
|
||||
public manifest, host selection, and syntax checks passed. The former
|
||||
`ansible-doc` gate was unnecessary and has been removed: missing argument
|
||||
descriptions prevent documentation rendering, not the demonstrated role
|
||||
loading. The prepared consumer diff was reviewed and whitespace checks passed
|
||||
before committing. Resume at Stage 3 when its operational inputs are
|
||||
available. No dependency pin change is needed.
|
||||
|
||||
## Non-blocking Follow-up
|
||||
|
||||
The pinned Notarius, Scriptorium, and Narratio `v0.1.0` roles lack option
|
||||
descriptions required by `ansible-doc` documentation rendering. Consider adding
|
||||
descriptions in a separate role documentation change and normal later release.
|
||||
This is not a Feature 0016 acceptance criterion or a reason to change its pins.
|
||||
|
||||
## Open Questions
|
||||
|
||||
|
||||
@@ -4,9 +4,10 @@ Last updated: 2026-09-21
|
||||
|
||||
Current milestone: Operational D&D pipeline deployment
|
||||
|
||||
Current focus: Feature 0016 Stage 2 is blocked because Ansible Core 2.21.3
|
||||
rejects missing argument-spec descriptions in the pinned Notarius, Scriptorium,
|
||||
and Narratio `v0.1.0` roles during the required `ansible-doc` validation.
|
||||
Current focus: Resume Feature 0016 at Stage 3 once controller, SSH, and Vault
|
||||
inputs are available. Stage 2 is committed in consumer `12b2462`. The
|
||||
unnecessary `ansible-doc` gate has been removed; role documentation omissions
|
||||
are a separate non-blocking follow-up.
|
||||
Feature 0015 is complete after independent review found no remediation issue.
|
||||
|
||||
| ID | Deliverable | Owner | State | Evidence or next step |
|
||||
@@ -35,7 +36,7 @@ Feature 0015 is complete after independent review found no remediation issue.
|
||||
| F0013 | Publish the first coordinated suite release | all Ansible repositories and workspace | done | Public [`rakestraw.dnd` 0.1.0 release](https://gitea.maximumdirect.net/eric/ansible-collection-dnd/releases/tag/v0.1.0); documentation remediation completed in pipeline `78afffe` and collection `5e695f3` |
|
||||
| F0014 | Enroll existing pipeline operators | ansible-role-dnd-pipeline, ansible-collection-dnd, and workspace | done | Pipeline `c13f726` and collection import `c0b0ebd` passed their complete integration suites and independent review with no remediation findings |
|
||||
| F0015 | Enable D&D S3 storage and publishing | ansible-role-dnd-pipeline, ansible-collection-dnd, and workspace | done | Pipeline `51566afcf69083cdbb5b5718f2544c86b079001c`, collection fixture `cf3de016ee09edf91afc3bc1addfd926d4a172ad`, collection squash `77f67adbc0f700e88bc15554e02052eaa22f1033`, and collection merge `46913446765e86ecfb29ebad9955d579ef6a4c7e` passed the complete repository suites and independent review with no remediation findings |
|
||||
| F0016 | Deploy the D&D pipeline to `pipeline-dnd` | rakestraw-ansible and workspace | blocked | Stage 1 is in consumer `716a80ef68208537dacfa5f0f22259bf42ae6279`; Stage 2 public installation and syntax checks pass, but required `ansible-doc` validation rejects missing descriptions in three pinned `v0.1.0` role argument specifications |
|
||||
| F0016 | Deploy the D&D pipeline to `pipeline-dnd` | rakestraw-ansible and workspace | in_progress | Stage 1: consumer `716a80e`; Stage 2: consumer `12b2462`, with public installation, host selection, and syntax checks passed; resume Stage 3 when operational inputs are available |
|
||||
| A0001 | Audit completed standalone-role test suites | workspace and standalone roles | done | Findings recorded in `docs/roadmap/test-suite-audit-findings.md` |
|
||||
| R0001 | Simplify completed standalone-role test suites | workspace and standalone roles | done | Role commits `e08c63c`, `d2d0b9d`, and `cfecf37` passed implementation and independent review |
|
||||
|
||||
|
||||
Reference in New Issue
Block a user