feat(framework): Add k3d harness infra proof#7384
Draft
msheller wants to merge 16 commits into
Draft
Conversation
0948f40 to
42b4c0e
Compare
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
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.
Issue
Description
This PR is F7b in the Kubernetes executor rollout stack. F7a introduced the portable evidence bundle/schema scaffold for a future integrated k3d launch-path harness. The next slice needs a local, optional way to prove the Kubernetes infrastructure assumptions for that future harness without yet running the full SuperLink AppIo, SuperExec, and TaskExecutor path.
Related issues/PRs
Stacked on #7383.
Proposal
Explanation
This PR extends the dev-maintained Kubernetes executor harness with an explicit
infra-proofmode. The mode records k3d infrastructure, namespace, TLS material contract, and RBAC proof evidence through the F7a evidence bundle format.Host commands are dry-run by default. Real k3d/kubectl execution requires
--execute, and local cluster creation is additionally gated behind--create-cluster. The harness can render/apply namespace and SuperExec ServiceAccount/Role/RoleBinding manifests, run positive and negativekubectl auth can-ichecks, and record sanitized command evidence. TLS certificate generation is intentionally deferred; this slice records a supplied AppIo root certificate path/fingerprint or marks TLS material as planned.This does not implement the full integrated launch path. SuperLink AppIo, SuperExec task claiming, TaskExecutor Pod launch, capacity wait proof, cleanup proof, and CNI/NetworkPolicy validation remain future F7 work.
Checklist
#contributions)Any other comments?
Validation run locally:
python -m py_compile framework/dev/kubernetes_executor_harness.py framework/py/flwr/supercore/superexec/executor/kubernetes_executor_harness_test.pypython -m pytest framework/py/flwr/supercore/superexec/executor/kubernetes_executor_harness_test.pygit diff --checkpython -m black --check framework/dev/kubernetes_executor_harness.py framework/py/flwr/supercore/superexec/executor/kubernetes_executor_harness_test.pypython -m ruff check --no-cache framework/py/flwr/supercore/superexec/executor/kubernetes_executor_harness_test.pyOptional real proof was run by the implementation thread:
python framework/dev/kubernetes_executor_harness.py --mode infra-proof --output-dir /private/tmp/f7b-harness-real-2 --execute --create-cluster --apply-manifests --jsonResult: passed. The local k3d cluster
flower-f7was left in place for inspection.