fix(ocp/connect): consume forge_kubeconfig channel with kubeconfig_content fallback (v1.0.1) - #67
Open
JLCode-tech wants to merge 1 commit into
Open
Conversation
…ntent fallback (v1.0.1) Precedence for the kubeconfig local is now: local.forge_kubeconfig (injected by BNK-Forge's config_writer whenever this workspace's project has a registered cluster) > var.kubeconfig_content (manual/standalone override, kept for backward compat) > the existing token-based yamlencode fallback. Matches the try(local.forge_kubeconfig, ...) convention already used by cert-manager and live-observability-* modules, so ocp/connect picks up the project's registered-cluster kubeconfig automatically instead of requiring a manually-supplied kubeconfig_content. Follows from the review discussion on bnk-forge PR #406. Bumps module.version 1.0.0 -> 1.0.1 since BlueprintRelease content is immutable per version.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
infra/ocp/connectv1.0.1 — consume forge's established kubeconfig channel instead of relying solely on the module-privatekubeconfig_contentvariable.New precedence in
local.kubeconfig:local.forge_kubeconfig(injected by forge when the project has a registered cluster — fresh from DB each run, normalized, SSH-tunnel-rewritten)var.kubeconfig_contentwhen non-empty (manual / standalone use — unchanged behavior)api_server_url+oc_token(unchanged)Why
Review discussion on bnk-forge PR #406: the module never referenced
local.forge_kubeconfig/forge_kubeconfig_content, so_inject_forge_kubeconfig_locals' usage gate skipped it and users had to hand-paste kubeconfigs (or worse, stale placeholder values persisted in module overrides). Adopting the catalog-widetry(local.forge_kubeconfig, …)idiom (same as cert-manager, live-observability-loki) fixes that at the source and picks up capabilities the backend variable-injection path doesn't have (per-run refresh, SSH-tunnel server rewrite).Because the forge local now wins whenever a registered cluster exists, stale
kubeconfig_contentoverrides (e.g. a persisted"<username>"placeholder) no longer break deploys.Verification
tofu fmt -checkclean;tofu validatepasses with the forge-injected locals shape (stubbnk_forge_locals.tf).tofu validatewithout any injected locals fails on the undeclared local — verified byte-identical behavior on the unmodified cert-manager module, i.e. the pre-existing catalog-wide convention, not a regression (forge always injects the locals file before init/validate for modules referencing it).module.jsonvalid JSON; version bumped 1.0.0 → 1.0.1 so the release re-imports (BlueprintRelease immutability).Follow-up (flagged, out of scope)
outputs.tfexposesoutput "kubeconfig_content"with the same name as the input variable; now that the output can reflect the forge-injected value, a rename to something likeresolved_kubeconfigwould clarify — left untouched here to keep the diff minimal.