k8s-launch-kit-pipeline
Skill18 starsChanged 48 days agoApache-2.0View on GitHub
Use this skill when the user wants to run the full k8s-launch-kit (l8k) pipeline end-to-end: discover cluster hardware, select a profile, generate manifests, and deploy them all in one command. Also activate for CI/CD integration, automation pipelines, 'one-liner', 'complete workflow', or end-to-end NVIDIA networking deployment.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- docs/llms.txtllms.txt
- k8s-launch-kit-cleanSkill
- k8s-launch-kit-configSkill
- k8s-launch-kit-deploySkill
- k8s-launch-kit-discoverSkill
- k8s-launch-kit-dryrunSkill
- k8s-launch-kit-generateSkill
- k8s-launch-kit-sharedSkill
- k8s-launch-kit-troubleshootSkill
- k8s-launch-kit-validateSkill
- k8s-network-engineerSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Run discovery + generation + deployment as a single command.
- Distinctive: line 125
If any phase fails, subsequent phases are skipped.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
l8k: Full Pipeline
PREREQUISITE: Read
../k8s-launch-kit-shared/SKILL.mdfor install paths, global flags, and output modes.
Run discovery + generation + deployment as a single command.
The pipeline operates on the default host target. Omitting --target keeps
the established behavior; --target host is equivalent. Do not select dpf
until l8k schema reports all required DPF phases as available.
The root command snapshots its arguments and runs the complete concrete Host
pipeline as one bound target operation.
The Host pipeline validates the post-annotation artifacts before replacing generated output, then deploys that same retained snapshot. If artifact validation fails, it reports the source file/document and does not enter Helm or resource apply. A standalone deploy loads its own snapshot from disk.
Usage
The root command chains all phases in one invocation:
l8k --discover-cluster-config [--kubeconfig <PATH>] \
--fabric <FABRIC> --deployment-type <TYPE> \
--save-deployment-files <DIR> --deployOr use subcommands for a two-step approach:
l8k discover --save-cluster-config ./cluster-config.yaml && \
l8k generate --user-config ./cluster-config.yaml \
--save-deployment-files <DIR> --deployThe subcommand flow does not need to repeat profile flags: discovery resolves and persists them. Pass profile flags to either command only as explicit overrides.
Examples
# Full pipeline: discover + SR-IOV Ethernet + deploy (root command)
l8k --discover-cluster-config \
--kubeconfig ~/.kube/config \
--fabric ethernet --deployment-type sriov \
--save-deployment-files ./output --deploy
# Full pipeline: Spectrum-X
l8k --discover-cluster-config \
--kubeconfig ~/.kube/config \
--spectrum-x RA2.2 --multiplane-mode hwplb --number-of-planes 4 \
--save-deployment-files ./output --deploy
# Non-default operator namespace (applies to generate/deploy only — discover
# always uses its own nvidia-k8s-launch-kit namespace)
l8k --discover-cluster-config \
--kubeconfig ~/.kube/config \
--network-operator-namespace network-operator \
--fabric ethernet --deployment-type sriov \
--save-deployment-files ./output --deploy
# Agent / CI mode
l8k --discover-cluster-config \
--kubeconfig ~/.kube/config \
--fabric ethernet --deployment-type sriov \
--save-deployment-files ./output --deploy \
--output json --yes
# Pipeline with deployment dry-run (discovery still creates cluster resources)
l8k --discover-cluster-config \
--kubeconfig ~/.kube/config \
--fabric ethernet --deployment-type sriov \
--save-deployment-files ./output --deploy --dry-run
# Subcommand alternative: discover then generate+deploy separately
l8k discover --kubeconfig ~/.kube/config \
--fabric ethernet --deployment-type sriov \
--save-cluster-config ./cluster-config.yaml && \
l8k generate --user-config ./cluster-config.yaml \
--save-deployment-files ./output --deploy
# Skip discovery entirely with --for (known SKU)
l8k generate --user-config ./cluster-config.yaml \
--for ThinkSystem-SR680a-V3 \
--node-selector "nvidia.com/gpu.product=NVIDIA-H200" \
--fabric ethernet --deployment-type sriov \
--save-deployment-files ./output --deploy \
--kubeconfig ~/.kube/configCommon Variations
| Use Case | Command |
| Discovery only | l8k discover --save-cluster-config <PATH> |
| Generate only | l8k generate --user-config <CONFIG> --save-deployment-files <DIR> |
| Generate + deploy | l8k generate ... --deploy |
| Full pipeline (root) | l8k --discover-cluster-config ... --deploy |
| Full pipeline (subcommands) | l8k discover ... && l8k generate ... --deploy |
| Full pipeline dry-run | l8k --discover-cluster-config ... --deploy --dry-run |
| External Helm ownership | l8k ... --skip-network-operator-helm --deploy |
Note: The root command's strength is chaining all phases — it runs discover, generate, and deploy in a single invocation. Use subcommands when you need intermediate inspection or different flags per phase.
With --skip-network-operator-helm, generation omits values.yaml and deploy
skips the Network Operator Helm install/preflight boundary while continuing to
apply and reconcile the generated custom resources.
Phase Order
- Discover — Probe hardware and persist its inventory; fresh discovery also resolves profile settings, while
--user-configpreserves non-clusterConfigsections - Generate — Match profile, render templates, write YAMLs
- Deploy — Apply resources in dependency order
If any phase fails, subsequent phases are skipped. The JSON output includes which phase failed.
[!CAUTION] The full pipeline includes deployment. Verify the context and stay within the user's existing live-operation authorization.
--dry-runpreviews deployment; discovery still creates temporary cluster resources, so the pipeline is not read-only.
See Also
- k8s-launch-kit-shared — Global flags and exit codes
- k8s-launch-kit-discover — Discovery details
- k8s-launch-kit-generate — Profile selection details
- k8s-launch-kit-deploy — Deploy details
OpenShift
The root Host pipeline accepts --flavor ocp and requires externally installed certified operators. Set explicit clusterConfig[].workerNodes for bounded discovery and inspect generated selectors before live deploy.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

