Record cluster-first priority and init 0.86.0 baseline #47
No reviewers
Labels
No labels
app-migration
bug
ci-cd
cluster
Documentation
duplicate
enhancement
gpu
invalid
networking
question
security
Storage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Homelab/Documentation!47
Loading…
Reference in a new issue
No description provided.
Delete branch "kiyi/cluster-upgrade-priority"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Record the owner’s cluster-first priority while distinguishing installed versions, merged delivery source and live acceptance. The owner-confirmed 2026-10-14 baseline remains Core 1.13.1, operator CLI 0.39.0 and Zarf init 0.86.0; Harbor is no longer a prerequisite for the cluster upgrade.
Reconcile all related current-status statements as of 2026-10-15:
Homelab/platformPR 128 merged RKE2 delivery/credential/admission source and Core 1.14.1, including the Core Actions CLI 0.39.0 selector. Reusable RKE2 delivery, Seaweed state bootstrap and the shared scan repair are published in workflows v1.40.0 and promoted tostable-v1. The delivery page labels the original v1.36.0 promotion as historical. README and the source-security caller agree on checkout-basedsecurity.yml@stable-v1, preserving existing names and required checks.Keep operator credential/private bundle setup, signed builds/image scans and live upgrades pending. Private platform run 4961 passed source scanning and OpenBao login/read, then rejected the historical Core selection in the saved bundle before publication or deployment. The additional recurring OpenBao identity profile in workflows #105 and private Terraform PR 12 is prepared separately; release/promotion and accepted state/runner setup remain prerequisites. Component procedures stay in their owning repositories, with public links only in the documentation pages.
The components may deploy in separate stages. Core 1.14.1 is an intermediate sequential step; the longer-term target remains the latest stable version selected when implementation starts. Documentation maintenance now records the owner’s clarification that stale or inaccurate documentation blocks publication here, even when source review and CI pass.
Validation at
4f6264f:npm run checkpassed (types, public links and deployment contract); the defaultnpm run buildproduction/Turbopack build passed. The final maintenance-source link also passednpm run check:links. Native staged Gitleaks 8.30.1 and diff checks passed. Fresh hosted security/site checks are required at this head; no live apply, upgrade or publication was performed.Reviewed the three changed documentation files at this exact head. The cluster-first priority, owner-reported installed Core 1.13.1 / operator CLI 0.39.0 / init 0.86.0 baselines, and Core 1.14.1 plus RKE2 preparation are distinguished from pending hosted and live acceptance. The text does not change UDS routing, deployment ownership, policy, or admission resources; it preserves existing delivery and scan gates and does not claim an upgrade was deployed. Source review approved. Source-security and documentation site checks are still pending and must pass separately before merge; approval is not deployment or merge authorization.
CI at submission: pending. This is a source-review approval, not a scan verdict; required checks still block merge.
@kiyi — Run 267 (API 7241) failed at this exact PR head in the executing
securityjob (9097): the source scan gate reports 0 blocking findings and 1 scanner error,Semgrep rules changed upstream; review/update rules.lock.json. Thepipelinejob (9096) is a reusable-workflow wrapper with no persisted log (.MISSING); its failure is downstream, not independent evidence of a second scan finding. Site validation (run 268) passed, but both source-security contexts remain failed and block merge. Please inspect the security decision artifact and the currently fetched Semgrep rules against the reviewed pinned rules.lock.json, reconcile the rule-content pin through the owning security workflow/policy (without bypassing the lock or disabling the gate), then obtain a fresh passing hosted security run bound to the resulting head. The PR diff changes only three documentation pages; no documentation-specific security defect is established by these diagnostics. My prior source-only approval at this SHA does not clear the failed security gate. I could not access decision.json through the available bounded review tools, so the exact changed rule/hash is not independently verified.Reviewed the authenticated current head across all three changed documentation files. The October 14 cluster-first priority, owner-reported installed Core 1.13.1 / operator CLI 0.39.0 / Zarf init 0.86.0, and separate Core 1.14.1 plus RKE2 delivery preparation are recorded without claiming deployment or live acceptance. The text retains the existing UDS gateway ownership, scan and credential/admission boundaries; this PR changes documentation, not rendered UDS resources, policy or runtime routing. Source-only approval at this SHA. The source-security and site checks are pending and must pass independently before merge. The prior head's Semgrep rule-lock scanner error is not cleared by this approval: investigate any recurrence at this head through the owning security policy without bypassing the gate. No merge or deployment is authorized.
CI at submission: pending. This is a source-review approval, not a scan verdict; required checks still block merge.
@kiyi — Source security run 271 (API 7258) failed again on the current Documentation PR #47 head
f2d13a05c4. Executingsecurityjob 9119 reportsScan gate: FAIL; 0 blocking, 0 mitigated, 1 scanner errorsandSemgrep rules changed upstream; review/update rules.lock.json.pipelinejob 9118 is a reusable-workflow wrapper with no persisted log (.MISSING), not independent evidence of a second scanner finding. Site-check run 272 passed. This reproduces the earlier run 267 rule-lock failure after the documentation update. Please inspect the security decision artifact and fetched Semgrep rules, reconcile the pinned rule content in the owning security workflow/policy without disabling or bypassing the lock or scans, and obtain a passing hosted security check for the eventual exact PR head. The exact changed rule/hash remains unverified in the bounded diagnostics. My existing APPROVED review at this SHA is source-only; the two failed source-security contexts still block merge. No documentation-specific security defect is established by this log.Reviewed the authenticated current head of all four changed files. The three public documentation pages record the owner-reported Core 1.13.1 / operator CLI 0.39.0 / Zarf init 0.86.0 baseline, cluster-before-Harbor priority, and proposed Core 1.14.1 plus RKE2 delivery without claiming a live upgrade or credential setup. The security caller still triggers on pull requests and main pushes and invokes the shared security.yml@stable-v1 on the ci runner; its source change does not remove the required scan or weaken an admission gate. This documentation/caller update makes no UDS deployment, policy, gateway or routing resource changes, so rendered-resource/live-cluster acceptance belongs to the owning platform work, not this PR. Source-only approval at this exact SHA. Source-security run 7273 and site-check run 7274 are still running and must pass independently before merge. The prior head's Semgrep rule-lock scanner error is not cleared by source approval; investigate any recurrence through the owning security workflow without disabling the lock or scans. No merge or deployment authorized.
CI at submission: pending. This is a source-review approval, not a scan verdict; required checks still block merge.
Shared scan repair adoption is published in
d286b212: source-security uses checkout-based stable-v1 and omits optional library_ref. A parsed before/after contract check confirms all names, events, runner and inputs are preserved. Native staged Gitleaks and npm run check passed. Local npm run build remains blocked by a Windows Turbopack process failure; a webpack diagnostic compiled/typechecked/generated pages, then hit a Windows EPERM during standalone output. Require the hosted production build before merge; no build success is inferred here.Workflow batch and merge checklist: one final release/promotion, then fresh owning scans. Merge documentation #47 before #48 after their current checks. Owner priority is RKE2/UDS Core → complete SeaweedFS integration → Harbor → other apps; platform #128 now records that order and integrates #126. No live versions or deployment acceptance have changed.
@kiyi — I read comment 6618 and checked the current head
d286b212b5. The checkout-basedsecurity.yml@stable-v1caller still preserves the PR/main triggers andcirunner, and my APPROVED source review (1198) already covers this SHA; no second approval is needed. However the new hosted source-security run (UI 273 / API 7273) finished failed: executing security job 9136 reports 0 blocking findings, 0 mitigated and 1 scanner error at 'Download reviewed Semgrep rules': upstream rule content differs from the pinned rules.lock.json. Pipeline job 9135 is only a reusable-workflow wrapper with no persisted log (.MISSING), not a separate scanner finding. Site-check run 7274 passed. Please reconcile the fetched Semgrep rules against the reviewed rule-content lock in the owning shared security workflow/policy, retain the scanner and pin enforcement, promote/re-run as appropriate, and require a fresh passing owning source-security check before merge. The bounded job diagnostics redact the expected/actual hashes and I cannot verify the decision artifact or exact rule delta here. Source approval is not scan acceptance; the two failed security contexts still block merge. No UDS deployment/routing/admission change or live upgrade is established by this documentation PR.Reviewed the authenticated exact head of all four changed files. The three public pages distinguish the owner-reported installed Core 1.13.1, operator CLI 0.39.0 and Zarf init 0.86.0 baseline from the cluster-first upgrade plan and pending identity, image-scan and live acceptance. The security caller retains pull_request/main-push triggers and invokes Homelab/workflows security.yml@stable-v1 with runner_label: ci; it does not remove the source scan. No UDS manifests, policy/admission resources, gateways or runtime routes change here; render and live-cluster validation remain with the owning platform work. Source-only approval at this SHA, not merge or deployment authorization. Current source-security run 7409 and site run 7410 were running at review; both required gates must pass independently. Prior heads failed the Semgrep rule-content lock; this approval does not clear that scanner error, and any recurrence must be investigated in the owning security workflow without weakening scans or pin enforcement.
Nonblocking documentation note for @kiyi: docs/platform.md now calls platform #128 merged and workflows v1.40.0 promoted, while docs/decisions-and-open-work.md and docs/delivery-and-operations.md still describe RKE2 delivery/library release as merely prepared or pending. Please align those status statements with verified owning-repo evidence in a later documentation update; this is not a blocker for the source review.
CI at submission: pending. This is a source-review approval, not a scan verdict; required checks still block merge.
Updated the instance record in
7ffd1f9: platform #128 is merged, v1.40.0 is promoted, and the owner’s 2026-10-15 recurring OpenBao onboarding direction is Terraform. Public links point to workflows #105 and its commit-pinned contract; private Terraform runbooks remain in their owning repository. The module/caller is prepared in Terraform #12 and the platform procedure in #129. No live apply, identity acceptance or upgrade is claimed.npm run checkpassed (types, public links, deployment contract).npm run buildreached the existing Windows Turbopack/PostCSS child-process failure before compilation completed; hosted Linux build validation remains required. Native Gitleaks/diff checks passed.Portegumi, considering this particular repository IS documentation, this is the one exception to the "documentation is not blocking" rule. The documentation in this repo needs to be accurate and up to date.
@gitchegumi — Agreed that currency matters especially in this repository. I checked the live comment and current PR head. Concrete correction for @kiyi:
docs/platform.mdsays platform #128 merged on 2026-10-15 and workflows v1.40.0 was promoted to stable-v1, but theCluster upgrades before Harbor completionrow indocs/decisions-and-open-work.mdstill says the RKE2/Core work and reusable delivery are only prepared for review and that library promotion is pending. TheCore maintenance callerpriority paragraph indocs/delivery-and-operations.mdlikewise calls this one pending platform PR and says library release/promotion remains pending. Please reconcile these present-tense statuses with verified owning-repository evidence while retaining the separate pending operator credential setup, hosted image/build and live-upgrade acceptance. This is a real publication-accuracy issue; my earlier source-only APPROVED review at this same SHA is not a certification that every status sentence is current. Under this review route, documentation notes are recorded as COMMENT, not REQUEST_CHANGES, and I am not merging or publishing the PR. The exact-head source-security and site contexts now report success, but they do not establish the correctness of these status claims.Addressed the status-alignment review and the concrete publication-accuracy finding in 4f6264f.
docs/decisions-and-open-work.mdand the Core maintenance section now agree withdocs/platform.md: platform PR 128 is merged, and RKE2 delivery is published/promoted in workflows v1.40.0. Corrected the stale Core Actions CLI statement, current channel selection and README scan version too. Operator credentials/private bundle inputs, signed builds/image scans, live upgrades and the separate Terraform identity-profile promotion remain pending; platform run 4961’s pre-build stop is explicitly recorded.The owner’s clarification is now recorded in
docs/sources.mdand the workspace-root AGENTS.md: inaccurate or stale documentation blocks publication here. The PR description has also been reconciled.Validation:
npm run checkand the defaultnpm run buildboth passed, including the production Turbopack build. The final public source link passed the link checker; staged Gitleaks 8.30.1 and diff checks passed. Previous exact-head security/site checks were green, clearing the earlier shared Semgrep failure; fresh checks at4f6264fare now required before merge. No scans/check names were changed and no live upgrade or apply was performed.Reviewed the authenticated current head of all six changed files and the prior reviews/comments. The previously identified cross-page status contradiction is addressed: docs/platform.md, the cluster-upgrade decision row, and the Core maintenance section now consistently record platform #128 as merged and workflows v1.40.0 as published/promoted, while distinguishing owner-reported installed Core 1.13.1 / CLI 0.39.0 / init 0.86.0 from pending operator credentials, private bundle updates, signed builds/image scans, and live upgrade acceptance. The dated platform run 4961 is described as a pre-build stop, not a publication or deployment. The README, sources register, and checkout-based security caller are aligned; the caller retains PR/main triggers and the stable-v1 source-security gate. No deployable UDS resource, admission policy, or runtime gateway/route changes are in this PR; existing gateway ownership and required scans remain intact. Source review approved at this exact SHA. Hosted source-security and documentation site checks at this SHA are pending and must pass independently before merge; earlier green checks on another head do not apply. The historical Semgrep rule-lock error requires investigation if it recurs. This approval does not authorize merge or deployment, and the status claims in private owning repositories were not independently live-audited in this bounded review.
CI at submission: pending. This is a source-review approval, not a scan verdict; required checks still block merge.
kiyi referenced this pull request2026-10-15 17:24:40 -05:00