Fix/aip 4614 splunk tls hostname validation - #146
Conversation
A clean `install` run now reproduces every fix we previously had to apply by hand on the RTX PRO 6000 (Blackwell) bring-up, so these failures don't recur: - k0s API externalAddress now uses the node's PRIVATE bind address (spec.api.address) instead of the public controller IP. An EC2 instance cannot hairpin to its own public IP, so a public externalAddress left the control-plane NotReady (calico-node could not reach 10.96.0.1:443) and forced extra public-IP security-group rules for worker joins. The public IP stays in sans for external kubeconfig access. - Blackwell GPUs install the NVIDIA OPEN kernel module (nvidia-driver:open-dkms / nvidia-open); the proprietary cuda-drivers module binds zero Blackwell GPUs. Pre-Blackwell (L40S/H100) keep the proprietary path. - DKMS kernel-drift: auto-rebuild the nvidia module for the running kernel instead of hard-failing when it was built for a different kernel. - dnf module reset nvidia-driver before enabling the open-dkms stream, so a node that previously had the proprietary stream switches cleanly (no-op on fresh nodes). - Persist nvidia kmod autoload via /etc/modules-load.d/nvidia.conf so the driver loads after reboot (otherwise the device plugin crash-loops). - Worker-join failure warning now names the exact required ingress (TCP 6443 kube-apiserver, 8132 konnectivity) to the controller's private IP. Co-Authored-By: Claude <noreply@anthropic.com>
- instance.yaml: add RTX_PRO_6000_BLACKWELL tiers (0/1/2-GPU) with resource limits - saia.yaml: add Blackwell instanceScale profile - download_from_huggingface.sh: accept rtx_pro_6000_blackwell accelerator, reusing the H100 quantized (w4a16 Gemma) artifact config Co-Authored-By: Claude <noreply@anthropic.com>
feat(AIP-4445): Add RTX pro 6000 support for ai tier
…validation # Conflicts: # config/configs/instance.yaml # config/configs/model-scale.yaml # tools/artifacts_download_upload_scripts/download_from_huggingface.sh # tools/cluster_setup/k0s_cluster_with_stack.sh # tools/cluster_setup/test_k0s_cluster_with_stack.sh
…lunk-tls-hostname-validation # Conflicts: # config/configs/instance.yaml
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c15a7e8f03
ℹ️ 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".
| l40s|""|rtx_pro_6000_blackwell) CONFIG_FILE="./model_artifacts_configs.yaml" ;; | ||
| h100) CONFIG_FILE="./model_artifacts_configs_h100.yaml" ;; | ||
| l40s|"") CONFIG_FILE="./model_artifacts_configs.yaml" ;; | ||
| h100|rtx_pro_6000_blackwell) CONFIG_FILE="./model_artifacts_configs_h100.yaml" ;; |
There was a problem hiding this comment.
Keep Blackwell artifacts under the deployed blob prefix
When rtx_pro_6000_blackwell is selected, this now loads model_artifacts_configs_h100.yaml, whose Gemma artifact ID is gemma-4-31b-it; the upload scripts use that ID as the object-store directory. However, the Blackwell Gemma431bIt application still loads both model and tokenizer data from model_artifacts/gemma-4-31b-it-qat-w4a16-ct in config/configs/applications.yaml, so a fresh Blackwell staging run reports success but the deployed model cannot find its artifacts. Keep Blackwell on the default manifest or update the runtime blob prefixes consistently.
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