docs: split k0s deployment guide by connectivity - #155
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dcf4d5654e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| scp tools/cluster_setup/k0s_cluster_with_stack.sh \ | ||
| tools/cluster_setup/install_from_airgap_bundle.sh \ | ||
| admin@install-machine:/opt/splunk-ai/ |
There was a problem hiding this comment.
Transfer the required operator manifests
Following this air-gapped transfer recipe leaves splunk-operator-cluster.yaml and artifacts.yaml behind, even though the copied config references them by relative path. configure_images in k0s_cluster_with_stack.sh immediately copies both files to .original backups, so the documented offline install exits before preflight with a missing-file error. Include both manifests in this transfer step or package them in the bundle.
Useful? React with 👍 / 👎.
| ./upload_to_minio.sh | ||
| # Or use upload_to_s3.sh or upload_to_seaweedfs.sh. |
There was a problem hiding this comment.
Point model uploads at the configured object store
For any deployment not using the scripts' built-in local defaults, this command does not upload models to the object store described earlier in the guide: upload_to_minio.sh defaults to http://127.0.0.1:9000, the default bucket, and minioadmin credentials, while upload_to_s3.sh similarly uses a hard-coded default bucket and region. The cluster configuration is not loaded by these direct script calls, so the guide must show the matching OBJECT_STORE_* or S3_* variables; otherwise installation proceeds with models missing from the actual platform bucket.
Useful? React with 👍 / 👎.
|
|
||
| | Node type | Minimum CPU | Minimum RAM | Minimum disk | Count | | ||
| |---|---:|---:|---:|---:| | ||
| | Controller | 4 cores | 8 GB | 100 GB | 1, or 3 for high availability | |
There was a problem hiding this comment.
Remove the unsupported three-controller option
When an administrator follows the advertised HA option and supplies three controller IPs, install_k0s_cluster selects only CONTROLLER_IPS[0] and runs k0s install controller only there; the other controller IPs are prepared but never installed or joined, while still being included in the expected-node count. The installation therefore waits for nodes that cannot appear and the resulting cluster has no controller HA. Remove this option from both new guides or document a supported prebuilt/manual HA path.
Useful? React with 👍 / 👎.
| Validation is read-only. It checks the configuration, required tools, SSH | ||
| access, node operating systems, disk space, registry access, and object storage | ||
| settings. |
There was a problem hiding this comment.
Limit the validation claims to configuration checks
The validate subcommand only calls load_config and checks configuration values plus the two local manifest files; it never runs preflight_checks, connects over SSH, inspects node OS or disk space, or probes registry/object-store access. An administrator can therefore receive a clean validation result despite any of the listed prerequisites being unavailable. Reword this as a configuration-completeness check or make the documented checks part of the command.
Useful? React with 👍 / 👎.
| kubectl get svc -n ai-platform \ | ||
| -l app.kubernetes.io/component=saia | ||
| ``` |
There was a problem hiding this comment.
Select the SAIA service using labels it actually has
These SAIA discovery commands return no resources because reconcileSAIAService labels the public Service with app, then propagates the AIService's aiplatform and feature labels; it never adds app.kubernetes.io/component=saia. The same nonexistent selector is repeated in both verification and app-onboarding sections of both guides, preventing users from obtaining the service type, external IP, or NodePort. Use a real selector such as feature=saia or the generated service name.
Useful? React with 👍 / 👎.
|
|
||
| ### 1. Find the Splunk Web URL | ||
|
|
||
| The default service uses NodePort. Find the assigned port: |
There was a problem hiding this comment.
Do not claim Splunk Web is exposed through NodePort
The k0s installer creates the Splunk Standalone without a spec.serviceTemplate and only applies aiPlatform.serviceTemplate to the separate SAIA service, so the generated Splunk Web service is not exposed as the NodePort claimed here. Consequently http://<worker-node-ip>:<nodePort> is not reachable in the documented default installation even after fixing service discovery. Document a working port-forward or add an explicit Splunk service exposure step.
Useful? React with 👍 / 👎.
| kubectl get secret splunk-standalone-secret -n ai-platform \ | ||
| -o jsonpath='{.data.password}' | base64 --decode && echo | ||
| ``` |
There was a problem hiding this comment.
Retrieve the password from the generated Splunk secret
The Splunk Operator does not create a secret named splunk-standalone-secret for the installer-generated Standalone; its generated credential secret follows the splunk-<standalone-name>-standalone-secret-v1 convention (the default name is splunk-splunk-standalone-standalone-secret-v1, as used elsewhere in this repository). This command therefore returns NotFound and leaves users unable to sign in and complete app installation. Use the generated secret name or discover it from the Standalone resource.
Useful? React with 👍 / 👎.
| The minimum production topology is one controller, one CPU worker, and two GPU | ||
| workers. The controller and CPU worker can share one machine for lab testing, | ||
| but this configuration is not supported for production. One GPU worker is not | ||
| enough because AI inference is distributed across both workers. |
There was a problem hiding this comment.
Remove the unsupported controller-worker colocation claim
For the described lab topology with GPU workers present, the installer cannot make the controller double as the CPU worker: label_nodes adds CPU workload labels to a controller only when WORKER_IPS is completely empty, while listing the controller again as a worker causes the worker installation path to clean and replace its controller state. SAIA, Weaviate, and Ray-head workloads therefore have no CPU-labeled node and remain Pending. Remove this claim or document a supported configuration/manual labeling procedure.
Useful? React with 👍 / 👎.
| Model staging can be resumed. The scripts skip models that are already present | ||
| and valid. |
There was a problem hiding this comment.
Enable the advertised resumable model staging
The direct commands shown above do not set either SKIP_IF_EXISTS=1 or SKIP_IF_STAGED=1, but download_from_huggingface.sh only honors local completion markers when one of those flags is enabled. On a retry it removes every existing model directory, including completed ones, and downloads the full model set again instead of skipping valid artifacts as claimed here. Show the appropriate resume flag (and object-store variables for remote-marker checks) or remove the resumability promise.
Useful? React with 👍 / 👎.
| ```bash | ||
| kubectl get standalone splunk-standalone -n ai-platform -o json \ | ||
| | jq '.status.appContext.appSrcDeployStatus' | ||
| ``` |
There was a problem hiding this comment.
Verify manually uploaded apps through Splunk
This status field tracks Splunk Operator App Framework archives retrieved from the configured remote app source; it is not updated when an administrator follows the preceding Splunk Web flow and uploads the archive manually. In that documented scenario the query can remain empty even though the app is installed, so deployStatus: 3 is not a valid success criterion. Verify the app via Splunk's REST API/UI, or change the installation flow to use App Framework.
Useful? React with 👍 / 👎.
Description
Related Issues
Type of Change
Changes Made
Testing Performed
make test)make lint)Test Environment
Test Steps
Documentation
Checklist
Breaking Changes
Impact:
Migration Path:
Screenshots/Recordings
Additional Notes
Reviewer Notes
Please pay special attention to:
Commit Message Convention: This PR follows Conventional Commits