admin_rb
85 lines
5.0 KiB
Markdown
85 lines
5.0 KiB
Markdown
# Core 3.3.0rc3 integration review
|
|
|
|
This is a source-based review of the user-supplied Core archive, not a native Windows
|
|
Update qualification. AIM Core remains separately deployed and unmodified.
|
|
|
|
## Source basis
|
|
|
|
Authoritative Core topics: `ADDON_AGENTS.md`, `AGENTS.md`,
|
|
`scripts/docs/RELEASE_NOTES.md`, `RELEASE_HANDOFF.md`, `ADDON_SUPPORT.md`, `ADDON_API.md`,
|
|
`OPERATION_RESULTS.md`, `PLAYBOOKS.md`, `VALIDATION.md`, `SANITY.md`,
|
|
`scripts/docs/INSTALLATION.md`, and `deploy/README.md`.
|
|
|
|
The supplied Core ZIP contains 200 files under `aim-core-3.3.0rc3/`. Its sidecar and
|
|
ZIP integrity were checked before extraction. Archive hashes and unchanged-source
|
|
comparison are in this release's verification record.
|
|
|
|
Compared with the supplied Core 3.3.0rc1 (the actual previous WebGUI integration),
|
|
there are three added files: two Windows patch-cycle tasks and the Core installation
|
|
guide. No files were removed in that comparison. The source-version/metadata,
|
|
patch runbook/filter/catalog/schema and documentation changed. The semantic catalog
|
|
difference is confined to `maintenance_patch_os`; eight other reporting schemas are
|
|
byte-identical. Core's runtime, credentials, service transport, target-outcome,
|
|
hierarchy and staging implementations are unchanged in this comparison. This is not
|
|
an assertion that the new patch runbook was executed successfully here.
|
|
|
|
## Existing public boundaries retained
|
|
|
|
Service/wire/event API remains 1.0. Reports still use `aim_output_v1` publication and
|
|
`aim_operation_result_v1` final results, with `result_contract` captured at review.
|
|
Reports arrive at finalization, not as raw debug/stdout. Detailed progress remains
|
|
`play_task_host_v1`; native target outcomes and the two-home staging preflight remain.
|
|
No new execute-request field, credential channel, service or filesystem access is needed.
|
|
|
|
## New rc2/rc3 patch metadata consumed
|
|
|
|
Core's catalog provides reboot delay (minutes, 0..1440), reboot message and the
|
|
Windows-only `os_patching_rescan_after_reboot` boolean. Its catalog hint is `false`.
|
|
The WebGUI obtains these options and constraints from public discovery, not a
|
|
parallel defaults table. Unchanged controls are omitted to preserve inventory/role
|
|
precedence; a catalog hint is not a resolved effective inventory setting.
|
|
|
|
Windows now discovers a deterministic queue, installs one discovered update per
|
|
native invocation and stops a wave at a reboot boundary. With continuation disabled,
|
|
an AIM-performed reboot can end a successful run with `continuation_required: true`
|
|
and `remaining_updates_known: false`. An explicitly reviewed true continuation value
|
|
allows Core to rediscover after reboot, bounded to 12 cycles. This is within one Core
|
|
operation, not permission for the add-on to create more jobs.
|
|
|
|
A wave finishing without reboot can perform a final read-only search; this does not
|
|
extend the approved installation queue. When `remaining_updates_known` is true,
|
|
`pending` is the recorded final discovery only. When false, the WebGUI must not show
|
|
a pre-reboot queue or zero-length list as the established next-wave state.
|
|
|
|
The patch report adds pre/post reboot observations, delay, deferred state and a stop
|
|
reason (introduced in Core rc2). Windows adds optional continuation, cycle and
|
|
remaining-update-knowledge fields in rc3. Individual failed updates carry Core's
|
|
unsigned/hex HRESULT, reason and bounded safe message. `install_not_allowed` is not
|
|
proof of a pending reboot; `preexisting_reboot_required` is an independent Core
|
|
preflight observation. The UI displays provided codes; it does not parse fatal text,
|
|
Windows logs or native error messages.
|
|
|
|
## Consumer changes made
|
|
|
|
- Qualify exact Core 3.3.0rc3 in adapter/executor/CLI/deployment metadata, while keeping
|
|
live capability negotiation and version rejection intact.
|
|
- Surface all catalog-driven patch controls and platform hints, with a review note
|
|
separating reboot from continuation and preserving explicit true/false vs inherited.
|
|
- Add a report presentation model for continuation, deferred reboot, pre-existing
|
|
reboot and bounded-cycle stop conditions. This never changes the job/Core verdict.
|
|
- Present remaining updates according to the new knowledge flag; keep raw *structured
|
|
report JSON* available separately, not unrestricted process output.
|
|
- Preserve historical schemas and data. The same `patch_summary_v1` identifier has a
|
|
larger closed shape now: newly added reboot fields and failure `message`/hex fields
|
|
are required where declared. Old jobs render with their recorded schema, never
|
|
revalidated against today's catalog or backfilled with invented false values.
|
|
- Retain journal, reports, modal, owner/admin visibility and existing retention limits.
|
|
|
|
## Qualification boundary
|
|
|
|
Core's current VALIDATION.md records static/filter/schema and disposable deployment
|
|
checks, not native Ansible 2.19.11/Windows Update/service-sandbox acceptance of rc3.
|
|
WebGUI test outcomes are recorded independently in VERIFICATION.md. Source tests and
|
|
synthetic report fixtures do not certify Windows servicing ordering, reboots, pending
|
|
update state, Server 2012 R2, or every delegated service environment.
|