feat: add native DPF Sentry deployment workflow

README.md

@@ -4,7 +4,7 @@ Kubernetes Launch Kit (`l8k`) helps platform teams deploy NVIDIA networking on K
 Standard SR-IOV, RDMA-shared and host-device profiles enable NIC tuning by default; opt out with `--deploy-nic-configuration-template=false`. See [NIC configuration](docs/reference/configuration.md#nic-configuration-and-naming) for fabric-specific settings and operator ownership.
 
 
-The current lifecycle uses the `host` target by default. The `dpf` target provides an [experimental inventory discovery preview](docs/user/dpf-discovery.md); its provisioning phases remain unavailable.
+The current lifecycle uses the `host` target by default. The `dpf` target provides [experimental inventory discovery](docs/user/dpf-discovery.md) and a [Sentry workflow for enrolled BlueField-4 devices](docs/user/dpf-sentry.md), with generation, deployment and resource validation against existing DPF infrastructure.
 DPF inventory can use explicit host/ARM SSH or BMC Redfish sources without an existing
 management cluster. Inventory success is separate from provisioning readiness.
 DPF BMC discovery verifies TLS by default; lab endpoints can explicitly opt in to
@@ -171,7 +171,7 @@ Available Commands:
   version     Print the version number
 
 Target Selection Flags:
-      --target string   Deployment target: host (default) or dpf (experimental inventory discovery) (default "host")
+      --target string   Deployment target: host (default) or dpf (experimental discovery and Sentry workflow) (default "host")
 
 Host Target Common Flags:
       --config-dir string                   Directory containing optional l8k-config.yaml and presets/ overrides

docs/integrator/automation.md

@@ -43,14 +43,20 @@ Output contracts differ by command:
 
 | Command | Successful stdout with `--output json` |
 | --- | --- |
-| Root pipeline, `discover`, `generate` | One `JSONResult` envelope, including collected `messages`. |
+| Host root pipeline, `discover`, `generate` | One `JSONResult` envelope, including collected `messages`. |
 | `clean` | One result with a `cleanup` summary. |
-| Standalone `deploy` | No finalized success JSON envelope. Use the process exit status; progress is sent to stderr. |
-| `validate` | A sequence of JSON objects: manifest/version summary when full validation runs, connectivity when run, and `reportPath` when the HTML report is written. Do not parse the stream as one document. |
+| Host standalone `deploy` | No finalized success JSON envelope. Use the process exit status; progress is sent to stderr. |
+| Host `validate` | A sequence of JSON objects: manifest/version summary when full validation runs, connectivity when run, and `reportPath` when the HTML report is written. Do not parse the stream as one document. |
 | `schema` | One capability object; this command always emits JSON. |
 | `version` | One version/build object. |
 | `preset list`, `preset update`, `sosreport` | Text output; these commands do not provide a JSON success contract despite accepting the inherited flag. |
 
+DPF `generate`, `deploy` and `validate` emit one final workflow object with
+`target`, `phase`, `outcome`, `exitCode`, optional `generation`/`deployment`
+results, and `errors`. Inspect each check's state, reason code and explanation;
+a nonzero process status or unresolved admission check is not success. DPF
+run reports are saved beside the immutable bundle. See [Sentry workflow](../user/dpf-sentry.md).
+
 Lifecycle JSON mode sends human-readable progress to stderr and auto-confirms
 prompts. Structured error objects may be emitted on failures; invalid command-line arguments can instead write text to stderr. Validation can emit partial
 results before a failure. Always check the process exit status.

docs/llms.txt

@@ -19,7 +19,8 @@ This documentation covers the `l8k` CLI for deploying NVIDIA cloud-native networ
 
 - Discover cluster hardware: /k8s-launch-kit/user/discovery/
 - DPF discovery preview: /k8s-launch-kit/user/dpf-discovery/
-- DPF discovery workflows: /k8s-launch-kit/user/dpf-workflows/
+- DPF workflows: /k8s-launch-kit/user/dpf-workflows/
+- Deploy Sentry with DPF: /k8s-launch-kit/user/dpf-sentry/
 - Generate and review manifests: /k8s-launch-kit/advanced/generation/
 - Deploy manifests: /k8s-launch-kit/advanced/deployment/
 - Deploy on OpenShift: /k8s-launch-kit/user/openshift/

docs/reference/cli.md

@@ -32,9 +32,11 @@ with a source filename and document number where applicable.
 
 ## Target selection and flag ownership
 
-Omitting `--target` selects `host`. `dpf` provides an
-[experimental discovery preview](../user/dpf-discovery.md). Its other phases
-are unavailable and return exit `2`; they do not run against the host cluster.
+Omitting `--target` selects `host`. `dpf` provides experimental
+[inventory discovery](../user/dpf-discovery.md) and the [Sentry BF4
+generate/deploy/validate workflow](../user/dpf-sentry.md) on an existing DPF
+management cluster, tenant and enrolled devices. The root DPF pipeline remains
+unavailable; it does not fall through into Host execution.
 
 Host-only flags are rejected when they are explicitly supplied for another
 target. Defaults are ignored by this check, including explicit-value flags
@@ -45,18 +47,24 @@ flag groups and `l8k schema` for each flag's `targets` list.
 | --- | --- | --- | --- |
 | `--target` | discover, generate, deploy, validate, root pipeline | target-agnostic | Target name. Defaults to `host`. |
 | `--kubeconfig` | root, discover, generate with deploy, deploy, clean, validate, sosreport | host | Path to kubeconfig. Falls back to `$KUBECONFIG` and then `~/.kube/config`. It represents the host workload cluster, not a universal multi-context input. |
-| `--user-config` | root, discover, generate, deploy, clean, validate | host | Config file to merge, render, validate against, or use for cleanup namespace and Helm-ownership resolution. |
+| `--user-config` | root, discover, generate, deploy, clean, validate | host and dpf where the phase is available | Host configuration or DPF site input. DPF deploy/validate normally consume the bundle's resolved input; an explicit file must preserve generated intent. |
 | `--config-dir` | all | host | Directory containing optional `l8k-config.yaml` and `presets/` overrides. |
 | `--network-operator-release` | root, discover, generate | host | Catalogued release line such as `26.1`, `26.4`, `26.7`, or `26.10`. |
 | `--network-operator-namespace` | root, discover, generate, deploy, clean, validate | host | Override the Network Operator namespace. It is a no-op for discovery. |
 | `--skip-network-operator-helm` | generate, deploy, validate, root pipeline | host | Skip `values.yaml` generation, Network Operator chart installation, and Helm-specific validation. Custom-resource handling remains enabled. |
 | `--flavor` | root, discover, generate, deploy, validate, clean | host | `k8s` or `ocp`, overriding config. Clean accepts the flag to reject OpenShift cleanup explicitly. |
-| `--output json` | all (inherited) | target-agnostic | Command-specific output; validation emits a stream, preset/sosreport success remains text, and standalone deploy has no success envelope. See [Automation](../integrator/automation.md#json-mode). |
+| `--output json` | all (inherited) | target-agnostic | Command-specific output. DPF lifecycle emits one final target/phase result with report paths; Host validation emits a stream, preset/sosreport success remains text, and Host standalone deploy has no success envelope. See [Automation](../integrator/automation.md#json-mode). |
 | `--yes`, `-y` | root pipeline only | target-agnostic | Auto-confirm root prompts. Subcommands reject this flag; lifecycle JSON mode auto-confirms. |
 | `--quiet` | root pipeline, discover | target-agnostic | Suppress informational output; discovery keeps the final result and errors. |
 | `--log-level` | all | target-agnostic | Enable `trace`, `debug`, `info`, `warn`, or `error` logging. `debug` shows structured progress; `trace` also shows bounded command output. |
 | `--log-file` | all | target-agnostic | Write logs to a file instead of `stderr`. |
 
+DPF generation accepts `--dpf-release` and `--dpf-profile` on `generate` only.
+Select an explicit generation release and profile from `l8k schema` under
+`dpf.generationReleases` and `dpf.profiles`; `dpf.charts` lists the four required
+local archive coordinates and hashes. DPF credentials and management context
+come from its site/resolved input, never the Host `--kubeconfig` fallback.
+
 The public host config remains the flat `cluster-config.yaml` schema. Generated
 manifests remain under `deployment/network-operator/`; the exact resolved
 configuration is stored separately at
@@ -76,6 +84,7 @@ available throughout the command tree.
 | `--kubeconfig`, `--user-config`, `--flavor`, `--network-operator-namespace` | yes | yes | yes | yes | yes | yes |
 | `--network-operator-release`, `--image-pull-secrets`, profile/Spectrum-X flags | yes | yes | yes | — | — | — |
 | `--enabled-plugins` | yes | yes | yes | — | — | — |
+| `--dpf-release`, `--dpf-profile` | — | — | yes | — | — | — |
 | `--node-selector` | yes | yes | yes (`--for`) | — | — | — |
 | `--save-cluster-config`, `--collapse-nic-rails` | yes | yes | — | — | — | — |
 | `--keep-namespace` | — | yes | — | — | — | — |
@@ -115,8 +124,29 @@ resolves missing values from hardware defaults. With `--user-config`, only
 `clusterConfig` is replaced and explicit flags are the only changes made to
 the rest of the supplied configuration.
 
+## DPF workflow flags
+
+| Flag | Command | Meaning |
+| --- | --- | --- |
+| `--dpf-release` | generate | Explicit installed DPF release; overrides `dpf.release` in the site input. It does not upgrade the operator. |
+| `--dpf-profile` | generate | DPF profile; overrides `dpf.profile`. The available profile is `sentry-bf4`. |
+| `--save-deployment-files` | generate | Required immutable output directory for the DPF bundle. |
+| `--deployment-files` | deploy, validate | Previously generated DPF bundle; retained target metadata must identify DPF. |
+| `--deploy` | generate | Deploy the exact generated bundle through the same DPF deployment path. |
+| `--dry-run` | deploy or generate with deploy | Server-side admission of native resources; unavailable future APIs may remain unresolved. It does not prove service readiness. |
+| `--deploy-timeout` | deploy | Explicit end-to-end budget; use a bounded duration such as `45m`. DPF additionally has a 45-minute default when no explicit budget is supplied. |
+| `--wait` | validate | Bound resource validation, for example `10m`. Host connectivity/report flags are not DPF policy tests. |
+
+DPF generation alone reads local inputs and chart archives. Deploy/validate
+connect to the bound management and tenant APIs. The bundle remains unchanged;
+run reports are written beside it under `<bundle>.runs/`. Read the [DPF Sentry
+procedure](../user/dpf-sentry.md) for external prerequisites, physical effects,
+retry boundaries and separate allow/deny verification.
+
 ## Profile Flags
 
+These flags describe Host profiles; DPF uses the separate workflow flags above.
+
 | Flag | Description |
 | --- | --- |
 | `--fabric` | `ethernet` or `infiniband`. |
@@ -166,7 +196,7 @@ root pipeline. The remaining profile flags also apply to discovery.
 | --- | --- |
 | `--deployment-files` | Directory containing generated manifests. Defaults to `./deployment`. |
 | `--dry-run` | Use server-side dry run. |
-| `--deploy-timeout` | End-to-end deploy timeout, accepted by standalone deploy and the root pipeline. `0` means unbounded. Not available on `generate --deploy`. |
+| `--deploy-timeout` | End-to-end deploy timeout, accepted by standalone deploy and the root pipeline. Host `0` means unbounded; DPF retains its separate lifecycle guard. Not available on `generate --deploy`. |
 | `--overwrite-existing` | Upgrade conflicting Helm chart/values and delete reported stray CRs, including resources without l8k ownership annotations. See the [deletion boundary](../advanced/deployment.md#stray-resource-deletion-boundary). |
 | `--skip-network-operator-helm` | Skip chart installation and Helm chart-version/values preflight checks; still apply manifests and check component versions and strays. |
 
@@ -204,6 +234,10 @@ full deletion boundary.
 
 ## Validate Flags
 
+The following connectivity and HTML/JUnit report behavior describes Host
+validation. DPF validation checks resources against its frozen bundle and writes
+a separate JSON run report; it does not create a policy-test workload.
+
 When `--deployment-files` contains only user-provided `*example*.yaml` test
 DaemonSets, `validate` runs connectivity only. Adding `values.yaml` or any
 non-example YAML manifest selects the full validation pipeline. Connectivity

docs/user/dpf-discovery.md

@@ -24,8 +24,9 @@ deployment readiness checks do not block inventory collection. Overall deploymen
 Explicitly select `discovery.probes.mode: inventory`. The default `management`
 mode is unavailable in this preview; selecting it stops the command before
 remote access. Inventory reports management topology when a kubeconfig is supplied,
-but does not test management-network connectivity. DPF generate/deploy/validate
-and the DPF pipeline are unavailable.
+but does not test management-network connectivity. The separate experimental
+[Sentry BF4 workflow](dpf-sentry.md) provides generation, deployment and resource
+validation for an existing DPF environment. The root DPF pipeline remains unavailable.
 
 ## Inputs and invocation
 
@@ -81,7 +82,7 @@ remote access. Lists and credentials stay in YAML; no password CLI flag exists.
 | Observed | Physical-card/system identities, linked host adapters, named DPU firmware versions, administrator verification, runtime hardware/network facts and management nodes/version |
 | Release defaults | Software bill of materials (BOM), artifact coordinates and documented minima for supported models; omitted minima remain unknown and do not establish deployment readiness |
 | Optional lookup inputs | Explicit ARM/BMC MAC selectors; optional local `dnsmasq-leases` files. Lookup returns address hints, never identity or permission to connect |
-| Later phases | Deployment profile, DPU API allocation, DHCP/service networks and controller authentication |
+| Separate Sentry workflow | Explicit device/tenant bindings, deployment release, OS/firmware hashes, local charts, service networking and existing controller/Secret access; see [required deployment inputs](dpf-sentry.md#prepare-the-deployment-configuration) |
 
 The management kubeconfig must use verified HTTPS and certificate/key or bearer
 credentials. File and embedded representations of the same credential/trust field are mutually
@@ -278,7 +279,9 @@ The current catalog has exact BlueField-3 models `B3210`, `B3220` and `B3240`; g
 establish applicability. Desired BFB/component coordinates are not measured
 versions. Only documented minimum versions are compatibility checks; unsupported
 firmware requirements remain unknown. Model applicability and software checks do
-not qualify hardware or enable DPF deployment profiles.
+not qualify hardware. Sentry generation validates its separately selected BF4
+profile, desired cohort and explicit enrollment bindings; this discovery BOM is
+not a substitute for those deployment inputs.
 
 On the supported BF4/B4240 Redfish reader, `inventory.dpus[].psid`
 records a successfully verified PSID from the selected System's `AssetTag`, falling back to the