Skip to content

docs: split k0s deployment guide by connectivity - #155

Open
kupratyu-splunk wants to merge 1 commit into
mainfrom
codex/split-deployment-guides-main
Open

docs: split k0s deployment guide by connectivity#155
kupratyu-splunk wants to merge 1 commit into
mainfrom
codex/split-deployment-guides-main

Conversation

@kupratyu-splunk

Copy link
Copy Markdown
Collaborator

Description

Related Issues

  • Related to #

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Refactoring (no functional changes)
  • Performance improvement
  • Test improvement
  • CI/CD improvement
  • Chore (dependency updates, etc.)

Changes Made

Testing Performed

  • Unit tests pass (make test)
  • Linting passes (make lint)
  • Integration tests pass (if applicable)
  • E2E tests pass (if applicable)
  • Manual testing performed

Test Environment

  • Kubernetes Version:
  • Cloud Provider:
  • Deployment Method:

Test Steps

Documentation

  • Updated inline code comments
  • Updated README.md (if adding features)
  • Updated API documentation
  • Updated deployment guides
  • Updated CHANGELOG.md
  • No documentation needed

Checklist

  • My code follows the project's style guidelines
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published
  • I have updated the Helm chart version (if applicable)
  • I have updated CRD schemas (if applicable)

Breaking Changes

Impact:

Migration Path:

Screenshots/Recordings

Additional Notes

Reviewer Notes

Please pay special attention to:


Commit Message Convention: This PR follows Conventional Commits

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment on lines +396 to +398
scp tools/cluster_setup/k0s_cluster_with_stack.sh \
tools/cluster_setup/install_from_airgap_bundle.sh \
admin@install-machine:/opt/splunk-ai/

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Comment on lines +351 to +352
./upload_to_minio.sh
# Or use upload_to_s3.sh or upload_to_seaweedfs.sh.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 |

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Comment on lines +249 to +251
Validation is read-only. It checks the configuration, required tools, SSH
access, node operating systems, disk space, registry access, and object storage
settings.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +338 to +340
kubectl get svc -n ai-platform \
-l app.kubernetes.io/component=saia
```

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +416 to +418
kubectl get secret splunk-standalone-secret -n ai-platform \
-o jsonpath='{.data.password}' | base64 --decode && echo
```

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +95 to +98
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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +374 to +375
Model staging can be resumed. The scripts skip models that are already present
and valid.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +459 to +462
```bash
kubectl get standalone splunk-standalone -n ai-platform -o json \
| jq '.status.appContext.appSrcDeployStatus'
```

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant