docs: align hub deployment with 1.0 release, minor updates for miniku… - #108
docs: align hub deployment with 1.0 release, minor updates for miniku…#108maxju wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughThe deployment documentation now presents Kubernetes and Helm as the production path, updates CSI storage guidance, expands installation procedures, and clarifies Docker Compose, MicroK8s, and Minikube workflows. ChangesDeployment documentation
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
src/.vitepress/routes/sidebar/deployment.tsESLint skipped: missing config or dependency (missing-dependency). The ESLint configuration references a package that is not available in the sandbox. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/guide/deployment/hub-installation.md`:
- Around line 54-68: Clarify the introductory text to state that
`nginx.kind=daemonSet` configures only the NGINX data-plane component, while the
NGINX Gateway Fabric control plane remains a Deployment through
`nginxGateway.kind=deployment`. Keep the Helm command unchanged.
- Around line 189-193: Update the routing verification commands in the
deployment guide to branch on the installed routing API: run an Ingress-only
query when Gateway API is not installed, and include HTTPRoute and Gateway
resources only when Gateway API is available. Keep the pod/PVC and Helm status
checks unchanged.
- Around line 182-185: Expand the managed-installation guidance around the
existingSecret settings to cover every required Secret reference: PostgreSQL and
Harbor database credentials, RabbitMQ, Redis, Grafana, and authup. Instruct
operators to back up all required Secrets and keep the chart and subchart
existingSecret/existingPasswordSecret settings and referenced keys synchronized
together, while preserving the existing flame-hub-harbor.secretKey and cleanup
guidance.
- Around line 75-78: Update the NGF snippets policy generation to handle
gateway.external=true: target the configured external parentRef instead of the
chart-owned <release>-flame-hub-gateway, or suppress the SnippetsPolicy when no
valid chart-owned Gateway exists. Preserve the existing behavior for
chart-managed Gateways and ensure no policy references a missing resource.
In `@src/guide/deployment/hub-introduction.md`:
- Around line 40-41: Update the deployment overview guidance around the
Kubernetes preparation link to include both MicroK8s and Minikube preparation
options, while preserving the direct Hub chart installation path for users with
an existing cluster. Use the existing Minikube guide link rather than
introducing a new destination.
In `@src/guide/deployment/microk8s-quickstart.md`:
- Around line 102-104: Update the MicroK8s quickstart instructions and addon
configuration to make hostpath explicitly local-only rather than a production
default. Document the required reattachable CSI StorageClass and the
corresponding Hub Helm storage-class override for production or multi-node
deployments, while preserving hostpath guidance only for local setups.
- Around line 65-83: Update the deployment guide’s 0_format_drives.sh
description and invocation to match the helper’s actual interface and behavior:
document passing a bare device name such as vdb or nvme1n1, and accurately
describe the two GPT partitions, formatting, and /mnt mounting it performs. Keep
the warning about data destruction and verifying the intended unused device.
- Around line 10-14: The MicroK8s installation paths may use different channels
and Kubernetes versions. Update the manual installation command and, if
applicable, the linked 1_microk8s_setup.sh installer reference so both use the
supported Hub 1.0 MicroK8s channel, specifically channel 1.32.
In `@src/guide/deployment/minikube-quickstart.md`:
- Around line 265-266: Update the minikube-dns.ps1 guidance to ensure existing
Hub and Harbor hostname entries are replaced when the Minikube IP changes,
rather than leaving stale lines alongside new ones; alternatively, instruct
users to remove stale hosts-file entries before rerunning the command.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f8ddde3e-3f71-4779-b1bd-57ae453a5af8
📒 Files selected for processing (9)
.gitignoresrc/.vitepress/routes/sidebar/deployment.tssrc/guide/deployment/hub-docker-compose.mdsrc/guide/deployment/hub-installation.mdsrc/guide/deployment/hub-introduction.mdsrc/guide/deployment/hub-storage.mdsrc/guide/deployment/index.mdsrc/guide/deployment/microk8s-quickstart.mdsrc/guide/deployment/minikube-quickstart.md
| For a simple self-managed cluster without a `LoadBalancer` implementation, NGF can instead run as a | ||
| DaemonSet with fixed NodePorts: | ||
|
|
||
| ```bash | ||
| helm install <release-name> -f <values-file> flame/hub | ||
| NGF_VERSION=v2.6.7 | ||
|
|
||
| helm upgrade --install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \ | ||
| --namespace nginx-gateway --create-namespace \ | ||
| --version "${NGF_VERSION#v}" \ | ||
| --set nginxGateway.snippets.enable=true \ | ||
| --set nginx.kind=daemonSet \ | ||
| --set nginx.service.type=NodePort \ | ||
| --set nginx.service.externalTrafficPolicy=Local \ | ||
| --set-json 'nginx.service.nodePorts=[{"port":31437,"listenerPort":80},{"port":30478,"listenerPort":443}]' | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
helm show values oci://ghcr.io/nginx/charts/nginx-gateway-fabric --version 2.6.7 |
rg -n 'nginxGateway:|nginx:|kind:'Repository: PrivateAIM/documentation
Length of output: 200
🌐 Web query:
nginx-gateway-fabric v2.6.7 charts nginx-gateway-fabric values.yaml nginxGateway kind nginx kind
💡 Result:
In NGINX Gateway Fabric v2.6.7, the Helm chart values.yaml file provides specific parameters to configure the deployment kind for both the control plane (nginxGateway) and the NGINX data plane (nginx) [1]. 1. nginxGateway.kind: This parameter defines the kind of the NGINX Gateway Fabric control plane installation [1]. As of version 2.6.7, only "deployment" is supported [1]. It is located under the nginxGateway object in the values.yaml file [1]. 2. nginx.kind: This parameter defines the kind of the NGINX data plane deployment [2]. Similar to the control plane, it defaults to "deployment" [2]. This is located under the nginx object in the values.yaml file, which governs the configuration for all NGINX data plane deployments managed by the control plane [1][2]. These configurations allow users to manage the underlying Kubernetes resources created by the Helm chart [1]. For most standard installations, these remain set to their default values [1][3]. If you are customizing your deployment using Helm, you can override these using the --set flag, for example: --set nginxGateway.kind=deployment [4].
Citations:
- 1: https://github.com/nginx/nginx-gateway-fabric/blob/v2.6.7/charts/nginx-gateway-fabric/README.md
- 2: https://github.com/nginx/nginx-gateway-fabric/tree/main/charts/nginx-gateway-fabric
- 3: https://artifacthub.io/packages/helm/nginx-gateway-fabric/nginx-gateway-fabric
- 4: https://docs.nginx.com/nginx-gateway-fabric/install/helm/
Name the DaemonSet component precisely.
nginx.kind=daemonSet changes only the NGINX data-plane component, not the NGINX Gateway Fabric control plane, whose nginxGateway.kind remains deployment.
Proposed wording fix
-For a simple self-managed cluster without a `LoadBalancer` implementation, NGF can instead run as a
-DaemonSet with fixed NodePorts:
+For a simple self-managed cluster without a `LoadBalancer` implementation, the NGINX data plane can
+instead run as a DaemonSet with fixed NodePorts:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| For a simple self-managed cluster without a `LoadBalancer` implementation, NGF can instead run as a | |
| DaemonSet with fixed NodePorts: | |
| ```bash | |
| helm install <release-name> -f <values-file> flame/hub | |
| NGF_VERSION=v2.6.7 | |
| helm upgrade --install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \ | |
| --namespace nginx-gateway --create-namespace \ | |
| --version "${NGF_VERSION#v}" \ | |
| --set nginxGateway.snippets.enable=true \ | |
| --set nginx.kind=daemonSet \ | |
| --set nginx.service.type=NodePort \ | |
| --set nginx.service.externalTrafficPolicy=Local \ | |
| --set-json 'nginx.service.nodePorts=[{"port":31437,"listenerPort":80},{"port":30478,"listenerPort":443}]' | |
| ``` | |
| For a simple self-managed cluster without a `LoadBalancer` implementation, the NGINX data plane can | |
| instead run as a DaemonSet with fixed NodePorts: | |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/hub-installation.md` around lines 54 - 68, Clarify the
introductory text to state that `nginx.kind=daemonSet` configures only the NGINX
data-plane component, while the NGINX Gateway Fabric control plane remains a
Deployment through `nginxGateway.kind=deployment`. Keep the Helm command
unchanged.
| The chart can create its own Gateway, or attach HTTPRoutes to an existing Gateway. Enable | ||
| `global.flameHub.gatewayApi.enabled` and set `nginxGatewayFabric.snippets: true` when using NGF. | ||
| An external Gateway requires a `parentRef` and may require a `ReferenceGrant` when it lives in a | ||
| different namespace. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
helm repo add flame https://PrivateAIM.github.io/helm >/dev/null 2>&1 || true
helm repo update >/dev/null
helm template flame-hub flame/hub \
--set global.flameHub.gatewayApi.enabled=true \
--set global.flameHub.gatewayApi.gateway.external=true \
--set global.flameHub.gatewayApi.gateway.parentRef.name=external-gateway \
--set global.flameHub.gatewayApi.nginxGatewayFabric.snippets=true |
rg -n -A12 'kind: SnippetsPolicy'Repository: PrivateAIM/documentation
Length of output: 204
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "Helm availability:"
(command -v helm || true)
helm_version="$(helm version --short 2>/dev/null || true)"
echo "$helm_version"
echo
echo "Documentation line:"
if [ -f src/guide/deployment/hub-installation.md ]; then
sed -n '68,82p' src/guide/deployment/hub-installation.md | cat -n
else
echo "src/guide/deployment/hub-installation.md not found"
fi
echo
echo "Locate chart files:"
git ls-files | rg '(^|/)charts/(flame|hub|flame-hub|.*flame.*|gateway|snippets)' | head -200Repository: PrivateAIM/documentation
Length of output: 1081
🌐 Web query:
PrivateAIM helm chart flame-hub gateway.yaml SnippetsPolicy
💡 Result:
In the PrivateAIM flame-hub Helm chart, the integration of NGINX Gateway Fabric (NGF) features—specifically SnippetsPolicy and SnippetsFilter—is designed to be an opt-in mechanism to prevent deployment failures on non-NGF Gateway API controllers [1]. Key technical details regarding these components include: 1. Purpose and Configuration: The SnippetsFilter and SnippetsPolicy resources are used to inject custom NGINX configuration (such as proxy timeouts, buffers, and body size limits) into generated HTTPRoute and GRPCRoute resources [1][2]. The gateway.yaml template in the flame-hub chart conditionally renders these resources based on user settings [1][3]. 2. Opt-in Mechanism: Because NGF-specific CRDs (like SnippetsPolicy and SnippetsFilter) are not recognized by other Gateway API controllers (such as Envoy Gateway or Contour), the chart defaults these features to disabled [1]. Users must explicitly enable them in their values.yaml file [1][4]: nginxGatewayFabric: snippets: true 3. Implementation Location: The snippets: true flag in values.yaml controls the rendering of NGINX Gateway Fabric-specific resources [4]. When enabled, the chart generates templates such as snippetsfilter-timeouts.yaml for services like authup, harbor, and server-storage, which utilize SnippetsFilter to apply proxy-related directives [1]. 4. Compatibility Note: If you are using a standard Gateway API controller that does not support NGINX-specific policy CRDs, leaving the default snippets: false is required to avoid template rendering errors or failed deployments [1]. Documentation in the flame-hub chart advises that users should only enable these features when running NGINX Gateway Fabric and specifically requiring snippet-based proxy timeouts [1][4].
Citations:
- 1: feat(hub): Support Gateway API and provide gateway template with necessary nginx parameters helm#118
- 2: https://docs.nginx.com/nginx-gateway-fabric/reference/api/
- 3: 128 external gateway option helm#129
- 4: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "Tracked chart-related files:"
git ls-files | rg 'hub-installation\.md|githubusercontent\.com/PrivateAIM/helm|PrivateAIM/helm\.git|values\.ya?ml$|gateway\.ya?ml$|snippets|nginxGatewayFabric' | head -200
echo
echo "Try cloning chart repo metadata only:"
python3 - <<'PY'
import urllib.request
urls = [
"https://raw.githubusercontent.com/PrivateAIM/helm/master/charts/flame-hub/templates/gateway.yaml",
"https://raw.githubusercontent.com/PrivateAIM/helm/master/charts/flame-hub/values.yaml",
"https://raw.githubusercontent.com/PrivateAIM/helm/master/charts/flame-hub/templates/nginxGatewayFabric/snippetpolicy.yaml",
]
for url in urls:
print(f"\n--- {url} ---")
try:
with urllib.request.urlopen(url, timeout=20) as r:
text = r.read().decode("utf-8", "replace")
for i,line in enumerate(text.splitlines(),1):
if i <= 240:
print(f"{i:4}: {line}")
except Exception as e:
print(f"ERROR: {e}")
PYRepository: PrivateAIM/documentation
Length of output: 1029
🌐 Web query:
github.com PrivateAIM flame-hub charts templates gateway.yaml
💡 Result:
In the PrivateAIM/helm GitHub repository, the file charts/flame-hub/templates/gateway.yaml is a template responsible for generating the Kubernetes Gateway resource for the FLAME Hub chart [1][2][3]. This template provides support for the Kubernetes Gateway API [1]. Its key features and functionality include: Conditional Rendering: The template includes logic to generate a Gateway resource [1]. It can be suppressed if the deployment is configured to use an existing "external" gateway (controlled via the values.yaml setting global.flameHub.gatewayApi.gateway.external) [4][5]. Gateway Configuration: It handles the rendering of listeners per enabled service and supports optional NGINX-specific policies, such as SnippetsPolicy for proxy timeouts [1]. Integration with Services: The template works in conjunction with various HTTPRoute resources (e.g., for authup, client-ui, harbor, server-core, server-messenger, server-storage, and server-telemetry) to route traffic to the appropriate services within the FLAME platform [1][4]. Helper Usage: It relies on shared helpers defined in charts/flame-hub/templates/_helpers.tpl to manage configuration, such as parentRef definitions for external gateways and hostname generation for listeners [4]. The file was introduced as part of an effort to implement Gateway API support in the FLAME Hub, allowing users to move away from older ingress configurations toward more modern, standardized Kubernetes gateway routing [1][2][3].
Citations:
- 1: feat(hub): Support Gateway API and provide gateway template with necessary nginx parameters helm#118
- 2: PrivateAIM/helm@root-0.0.11...root-0.1.0
- 3: PrivateAIM/helm@755a513
- 4: 128 external gateway option helm#129
- 5: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
🌐 Web query:
"PrivateAIM/helm" "SnippetsPolicy" "external" "parentRef"
💡 Result:
The terms mentioned refer to two distinct technical contexts. First, SnippetsPolicy is a specific resource type within the NGINX Gateway Fabric project [1][2]. It is a policy attachment used to inject raw NGINX configuration snippets at the Gateway scope [3][4]. When using Helm to deploy NGINX Gateway Fabric, users enable this functionality by setting the configuration, typically via a Helm value like nginxGateway.snippets.enable=true [2][5]. Second, regarding PrivateAIM/helm, this is a separate GitHub repository containing Helm charts for a project named FLAME [6]. Recent updates in this repository (e.g., Issue #129) introduced an "external gateway option" for its charts [7][8][9]. This feature involves the use of helper templates—specifically flame-hub.gateway.parentRefs and flame-node.gateway.parentRefs—to conditionally configure Gateway API parentRefs [7]. These helpers allow the charts to either manage a Gateway internally or reference an externally managed Gateway by allowing users to specify name, namespace, and sectionName [7]. There is no functional overlap between the PrivateAIM/helm charts and the NGINX Gateway Fabric SnippetsPolicy; they are unrelated projects [7][2][6].
Citations:
- 1: nginx/nginx-gateway-fabric@15e26c2
- 2: https://docs.nginx.com/nginx-gateway-fabric/traffic-management/snippets/
- 3: Add SnippetsPolicy for Gateway level nginx/nginx-gateway-fabric#4461
- 4: Add support for Snippets at the Gateway level nginx/nginx-gateway-fabric#4071
- 5: Add snippets helm flag and example changes for snippets doc update nginx/nginx-gateway-fabric#4628
- 6: https://github.com/PrivateAIM/helm
- 7: 128 external gateway option helm#129
- 8: https://github.com/PrivateAIM/helm/blob/master/CHANGELOG.md
- 9: https://github.com/PrivateAIM/helm/releases
🌐 Web query:
github.com/PrivateAIM/helm raw/templates/gateway.yaml global.flameHub.gatewayApi.gateway.external SnippetsPolicy
💡 Result:
In the PrivateAIM/helm repository, the configuration setting global.flameHub.gatewayApi.nginxGatewayFabric.snippets (found within the charts/flame-hub/values.yaml file) controls whether NGINX Gateway Fabric (NGF) snippet-based features are enabled [1][2]. When enabled (set to true), this setting allows the use of NGF-specific Custom Resource Definitions (CRDs) such as SnippetsPolicy and SnippetsFilter to inject custom NGINX configuration snippets [1][2]. Specifically, SnippetsPolicy is used to apply NGINX configuration at the Gateway resource level, which affects the gateway and all attached routes [3][4]. This is useful for configuring global defaults like proxy timeouts, buffer sizes, or connection limits [1][3][4]. Key points regarding this configuration: * Purpose: It is an opt-in feature for users running NGINX Gateway Fabric who require granular NGINX configuration control via snippets [2]. * Deployment Note: Setting this to true when using non-NGF Gateway API controllers (such as Contour or Envoy Gateway) can cause deployment failures because those controllers will not recognize the NGF-specific SnippetsPolicy or SnippetsFilter resources [2]. * Background: The SnippetsPolicy API is an NGINX Gateway Fabric feature that allows inserting configuration into various NGINX contexts (main, http, http.server, http.server.location) at the Gateway scope [3][5][4]. It complements SnippetsFilter, which typically operates at the route level [3][6].
Citations:
- 1: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
- 2: feat(hub): Support Gateway API and provide gateway template with necessary nginx parameters helm#118
- 3: https://docs.nginx.com/nginx-gateway-fabric/traffic-management/snippets/
- 4: Add support for Snippets at the Gateway level nginx/nginx-gateway-fabric#4071
- 5: nginx/nginx-gateway-fabric@15e26c2
- 6: https://github.com/nginx/nginx-gateway-fabric/tree/main/charts/nginx-gateway-fabric
🌐 Web query:
gh raw gh PrivateAIM helm charts/flame-hub/templates/nginxGatewayFabric/snippetpolicy.yaml
💡 Result:
The file path referenced, charts/flame-hub/templates/nginxGatewayFabric/snippetpolicy.yaml, refers to a template file within the PrivateAIM/helm repository used for deploying the FLAME platform [1][2]. This file is part of the FLAME Hub Helm chart's support for the Kubernetes Gateway API, specifically when using NGINX Gateway Fabric (NGF) [3]. The SnippetsPolicy is a custom policy resource in NGINX Gateway Fabric that allows for the injection of raw NGINX configuration snippets directly into the Gateway resource [4][5]. Key technical points regarding this file and configuration include: Purpose: The snippetpolicy.yaml template enables the injection of NGINX configuration (such as proxy timeouts or buffer sizes) that are not natively supported by standard Gateway API resources [3][5]. Deployment Configuration: In the FLAME Hub Helm chart, this functionality is controlled via values in the values.yaml file under the global.flameHub.gatewayApi.nginxGatewayFabric.snippets path [6][3]. Usage: Users who deploy the FLAME Hub using NGINX Gateway Fabric and require specific NGINX proxy behaviors must explicitly set nginxGatewayFabric.snippets to true in their override values file [3]. If this is not set or if a different Gateway controller is used, the chart is configured to omit these resources to prevent deployment failures caused by unrecognized Custom Resource Definitions (CRDs) [3]. General NGINX Gateway Fabric Context: SnippetsPolicy is defined as a Direct PolicyAttachment in NGF, meaning it targets the Gateway object directly, rather than individual routes [7][4]. For the most up-to-date version of this template, you can access the repository directly at https://github.com/PrivateAIM/helm [1][2].
Citations:
- 1: https://github.com/PrivateAIM/helm/
- 2: https://github.com/PrivateAIM/helm/tree/master/charts
- 3: feat(hub): Support Gateway API and provide gateway template with necessary nginx parameters helm#118
- 4: https://docs.nginx.com/nginx-gateway-fabric/reference/api/
- 5: https://docs.nginx.com/nginx-gateway-fabric/overview/custom-policies/
- 6: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
- 7: https://docs.nginx.com/nginx-gateway-fabric/traffic-management/snippets/
🌐 Web query:
site:github.com/PrivateAIM/helm "global.flameHub.gatewayApi.gateway.external" "SnippetsPolicy"
💡 Result:
The term "global.flameHub.gatewayApi.gateway.external" refers to a configuration setting within the Flame Hub Helm chart used to enable or disable the creation of a Kubernetes Gateway resource [1][2]. When global.flameHub.gatewayApi.gateway.external is set to true, the Helm chart will not create its own Gateway resource [1][3]. Instead, it assumes an existing, externally managed Gateway is available and attaches HTTPRoutes to it [1][2]. This configuration is often used in conjunction with the parentRef setting, which allows users to specify the name, namespace, and optional sectionName of the pre-existing Gateway [1][4]. Conversely, when set to false (the default), the chart manages the Gateway resource lifecycle itself [1][2]. Regarding "SnippetsPolicy" (or SnippetsFilter), this is related to NGINX Gateway Fabric (NGF) features enabled via the configuration block global.flameHub.gatewayApi.nginxGatewayFabric.snippets [1][5]. When this feature is enabled, the chart can utilize SnippetsFilter-based proxy timeouts for services like Harbor [1][5]. It is important to ensure these snippets are explicitly enabled in your NGINX Gateway Fabric installation, as the chart disables them by default to avoid rendering NGF-specific Custom Resource Definitions (CRDs) when using non-NGF Gateway API controllers, such as Envoy Gateway [1][5].
Citations:
- 1: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
- 2: 128 external gateway option helm#129
- 3: PrivateAIM/helm@c6ae564
- 4: https://github.com/PrivateAIM/helm/blob/master/charts/flame-node/templates/_helpers.tpl
- 5: feat(hub): Support Gateway API and provide gateway template with necessary nginx parameters helm#118
🌐 Web query:
site:github.com/PrivateAIM/helm "snippetpolicy.yaml" "parentRefs" "SnippetsPolicy"
💡 Result:
There is no standard Kubernetes or NGINX Gateway Fabric (NGF) resource named snippetpolicy.yaml; rather, this refers to a specific implementation detail within the PrivateAIM Helm charts (flame-hub and flame-node) [1][2][3]. In these charts, SnippetsPolicy and associated SnippetsFilter resources are custom components used to inject NGINX directives (such as timeouts, buffers, and request body sizes) into the Gateway API configuration [1]. Key points regarding parentRefs and these resources include: 1. SnippetsFilter Association: SnippetsFilter resources are used alongside HTTPRoute objects [1][4]. The configuration relies on enabling these features via Helm values (e.g., nginxGatewayFabric.snippets: true) [1][2]. 2. parentRefs Usage: The parentRefs field is a standard Kubernetes Gateway API field used to attach HTTPRoutes to a Gateway [5][3]. In the flame-hub and flame-node Helm charts, a helper template (flame-hub.gateway.parentRefs or flame-node.gateway.parentRefs) is used to dynamically generate the parentRefs block [5][3][6]. This allows the charts to conditionally attach to either a chart-managed Gateway or an external, user-provided Gateway [2][5][3]. 3. Deployment Context: Users must be aware that if the snippet-related features (NGF SnippetsFilter) are enabled in the Helm values but the cluster is using a non-NGF Gateway API controller (like Contour or Envoy Gateway), the deployment will fail because the controllers will not recognize the NGF-specific CRDs [1]. In summary, parentRefs is used to define the attachment point for HTTPRoutes, while the "snippets" functionality is an opt-in configuration for specific NGINX-based gateway performance tuning [1][2][3].
Citations:
- 1: feat(hub): Support Gateway API and provide gateway template with necessary nginx parameters helm#118
- 2: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
- 3: 128 external gateway option helm#129
- 4: PrivateAIM/helm@root-0.0.11...root-0.1.0
- 5: https://github.com/PrivateAIM/helm/blob/master/charts/flame-node/templates/_helpers.tpl
- 6: https://github.com/PrivateAIM/helm/blob/master/charts/flame-node/templates/hub-adapter/httproute.yaml
🌐 Web query:
raw.githubusercontent.com PrivateAIM helm charts/flame-hub/templates/nginxGatewayFabric/snippetpolicy.yaml
💡 Result:
The file path you mentioned, raw.githubusercontent.com/PrivateAIM/helm/master/charts/flame-hub/templates/nginxGatewayFabric/snippetpolicy.yaml, refers to a template file within the PrivateAIM/helm repository [1][2]. This file is part of the flame-hub Helm chart, which supports NGINX Gateway Fabric (NGF) [1]. The snippetpolicy.yaml template is designed to conditionally generate an NGF SnippetsPolicy resource [1]. SnippetsPolicy is a custom resource provided by NGINX Gateway Fabric that allows users to inject reusable NGINX configuration snippets at the Gateway scope [3][4]. Unlike SnippetsFilter, which targets individual routes, SnippetsPolicy applies to a Gateway and all routes attached to it, making it suitable for defining consistent defaults such as buffer sizes, timeouts, or logging formats [3][4]. In the context of the PrivateAIM flame-hub chart: - The snippetpolicy.yaml template is used to implement Gateway-level configuration when NGF is utilized [1]. - To use this feature, users must enable snippets in the Helm chart configuration by setting global.flameHub.gatewayApi.nginxGatewayFabric.snippets to true in their values file [1][5]. - This configuration ensures the necessary NGINX parameters are applied to the Gateway resource [1]. It is important to note that NGINX Gateway Fabric requires specific RBAC permissions and enablement of the snippets feature in the NGF controller itself (typically via the Helm flag nginxGateway.snippets.enable=true) to process these policies correctly [3][6][7]. If you are not using NGINX Gateway Fabric, or if snippets are disabled, these templates may not function as expected or may cause errors if the controller does not support them [1].
Citations:
- 1: feat(hub): Support Gateway API and provide gateway template with necessary nginx parameters helm#118
- 2: https://github.com/PrivateAIM/helm/tree/master/charts
- 3: https://docs.nginx.com/nginx-gateway-fabric/traffic-management/snippets/
- 4: Add support for Snippets at the Gateway level nginx/nginx-gateway-fabric#4071
- 5: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
- 6: https://github.com/nginx/nginx-gateway-fabric/tree/main/charts/nginx-gateway-fabric
- 7: Add snippets helm flag and example changes for snippets doc update nginx/nginx-gateway-fabric#4628
🌐 Web query:
"snippetsPolicy" "parentRefs" PrivateAIM flame-hub
💡 Result:
In the context of the PrivateAIM "flame-hub" Helm chart and its integration with NGINX Gateway Fabric (NGF), these terms refer to specific components used for configuring custom NGINX behavior via Kubernetes Gateway API resources [1][2]. SnippetsPolicy and parentRefs are concepts related to NGINX Gateway Fabric's policy attachment model [3][4]. 1. SnippetsPolicy: This is a custom Kubernetes resource provided by NGINX Gateway Fabric [3][5]. It allows cluster operators to inject custom NGINX configuration snippets (such as timeout settings, buffer sizes, or NJS modules) directly into the Gateway resource [3][4][5]. Unlike the related SnippetsFilter, which is attached to specific HTTPRoutes, a SnippetsPolicy applies to the entire Gateway, affecting all routes associated with it [3][6]. 2. parentRefs: In the context of Gateway API resources like HTTPRoute, the parentRefs field is used to specify which parent resource (a Gateway) a route should attach to [3][5]. In the flame-hub Helm chart, configuration for parentRefs allows users to attach the chart's generated routes to an existing external Gateway rather than creating a new one [1]. 3. PrivateAIM / flame-hub: PrivateAIM is a project providing a privacy-preserving analytics infrastructure for federated data analysis [7][8][9]. The "flame-hub" is the central services component of this platform [7][10]. The Helm chart for flame-hub includes templates that can optionally generate NGINX Gateway Fabric resources (such as Gateway and SnippetsFilter/SnippetsPolicy) to manage traffic, timeouts, and other proxy settings for these services [2]. If NGF snippets are enabled in the chart's values, it creates these resources to inject required NGINX directives [1][2].
Citations:
- 1: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
- 2: feat(hub): Support Gateway API and provide gateway template with necessary nginx parameters helm#118
- 3: https://docs.nginx.com/nginx-gateway-fabric/traffic-management/snippets/
- 4: nginx/nginx-gateway-fabric@15e26c2
- 5: https://community.f5.com/kb/technicalarticles/nginx-gateway-fabric---data-plane-programmability-with-nginx-javascript/346765
- 6: Built-in variable support nginx/nginx-gateway-fabric#4587
- 7: https://github.com/PrivateAIM/hub
- 8: https://hub.docs.privateaim.net/
- 9: https://github.com/PrivateAIM/hub/blob/master/README.md
- 10: https://docs.privateaim.net/guide/deployment/hub-installation.html
Handle external Gateways when NGF snippets are enabled.
With gateway.external: true, the chart no longer creates <release>-flame-hub-gateway, but NGF snippets still emit a SnippetsPolicy that targets that missing Gateway. Use the external parentRef or do not emit the policy when no chart-owned Gateway exists.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/hub-installation.md` around lines 75 - 78, Update the
NGF snippets policy generation to handle gateway.external=true: target the
configured external parentRef instead of the chart-owned
<release>-flame-hub-gateway, or suppress the SnippetsPolicy when no valid
chart-owned Gateway exists. Preserve the existing behavior for chart-managed
Gateways and ensure no policy references a missing resource.
| For a managed installation, create and back up the Secrets before Helm or use the chart's | ||
| `existingSecret` settings. Preserve `flame-hub-harbor.secretKey`: Harbor uses it to decrypt robot | ||
| tokens and replication credentials. Chart-managed Secrets and important PVCs carry Helm's `keep` | ||
| policy and can remain after `helm uninstall`; inventory them explicitly during cleanup. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "## locate relevant markdown and chart files"
git ls-files | rg '(^|/)hub-installation\.md$|^(charts|helm|.*flame-hub.*)' | sed -n '1,120p'
echo
echo "## inspect target lines"
if [ -f src/guide/deployment/hub-installation.md ]; then
sed -n '160,205p' src/guide/deployment/hub-installation.md | cat -n -v
fi
echo
echo "## search existingSecret/existingPasswordSecret mentions"
rg -n "existingSecret|existingPasswordSecret|flame-hub-harbor.secretKey|credential table|credential.*table|Secrets before Helm" . --glob '!*.lock' --glob '!dist/**' --glob '!build/**' --glob '!node_modules/**' | sed -n '1,220p'Repository: PrivateAIM/documentation
Length of output: 3409
🌐 Web query:
PrivateAIM helm flame-hub existingSecret secretKey README
💡 Result:
In the PrivateAIM flame-hub Helm chart, the existingSecret and secretKey (or equivalent key-specific parameters) are used to manage sensitive credentials via externally created Kubernetes Secrets rather than auto-generated ones [1][2][3]. Configuration Overview: The flame-hub chart centralizes credential management under an auth block in values.yaml [1]. By default, it uses a generated secret named flame-hub-auth [1]. Using an Existing Secret: To use your own secret instead of the generated one, you must configure the existingSecret parameter in your values.yaml override file [1][3]. Important Implementation Details: 1. Scope: Because the chart contains multiple subcharts (e.g., Redis, RabbitMQ, Authup), simply setting the top-level existingSecret is often insufficient [1][4]. You must manually update the existingSecret fields within the individual subchart configurations in your values file to point to your custom secret [1][4]. 2. Key Mapping: When using an existing secret, you must also specify the key within that secret that contains the required value. The chart uses specific keys for different services, such as: - existingSecretPasswordKey for service passwords [1]. - existingSecretAdminPasswordKey for admin credentials [1]. Workflow Example: 1. Create a Kubernetes secret containing your credentials: kubectl create secret generic my-custom-secret --from-literal=redis-password=your-password --from-literal=harbor-admin-password=your-admin-password 2. Reference this in your values.yaml override file: auth: existingSecret: "my-custom-secret" redis: existingSecret: "my-custom-secret" existingSecretPasswordKey: "redis-password" harbor: existingSecret: "my-custom-secret" existingSecretAdminPasswordKey: "harbor-admin-password" For the flame-node chart, similar logic applies where existingSecret can be provided for crypto private keys or hub authentication credentials, avoiding the need to store raw credentials in your values file [5][6][7]. Always check the specific values.yaml for the chart version you are using, as key names and structure may vary [1][3].
Citations:
- 1: https://github.com/PrivateAIM/helm/blob/master/charts/flame-hub/values.yaml
- 2: PrivateAIM/helm@d88ef7a
- 3: https://docs.privateaim.net/versions/v0.1.0.html
- 4: feat(hub): Ingress controller independent ingress resources & merge root and hub sub path ingress helm#105
- 5: https://docs.privateaim.net/guide/deployment/node-installation.html
- 6: https://github.com/PrivateAIM/helm/blob/master/charts/flame-node/templates/secret.yaml
- 7: https://docs.privateaim.net/guide/deployment/node-troubleshooting.html
🌐 Web query:
site:raw.githubusercontent.com/PrivateAIM/helm master charts/flame-hub README.md existingSecret PostgreSQL auth existingPasswordSecret
💡 Result:
The README states:
- PostgreSQL credentials use
global.flameHub.postgresql.existingSecret. - The Secret must contain
usernameandpassword. - Harbor must reference the same Secret via
harbor.database.external.existingSecret. rabbitmq.auth.existingPasswordSecretis for the sharedflame-hub-authSecret, not PostgreSQL. (raw.githubusercontent.com)
Example:
global:
flameHub:
postgresql:
existingSecret: my-postgres-secret
harbor:
database:
external:
existingSecret: my-postgres-secretThe PostgreSQL Secret must contain keys username and password. (raw.githubusercontent.com)
Citations:
- 1: https://raw.githubusercontent.com/PrivateAIM/helm/master/charts/flame-hub/README.md
- 2: https://raw.githubusercontent.com/PrivateAIM/helm/master/charts/flame-hub/README.md
Document the full existingSecret synchronization requirement.
The chart has separate Secret references for PostgreSQL and Harbor database credentials, RabbitMQ auth, Redis credentials, Grafana credentials, and authup credentials. A managed installation can fail or use mismatched credentials when only one field is configured. Tell operators to back up all required Secrets and to update the chart and subchart existingSecret / existingPasswordSecret settings and keys together.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/hub-installation.md` around lines 182 - 185, Expand the
managed-installation guidance around the existingSecret settings to cover every
required Secret reference: PostgreSQL and Harbor database credentials, RabbitMQ,
Redis, Grafana, and authup. Instruct operators to back up all required Secrets
and keep the chart and subchart existingSecret/existingPasswordSecret settings
and referenced keys synchronized together, while preserving the existing
flame-hub-harbor.secretKey and cleanup guidance.
| ```bash | ||
| kubectl -n flame-hub get pods,pvc | ||
| kubectl -n flame-hub get ingress,httproute,gateway | ||
| helm -n flame-hub status flame-hub | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Relevant deployment file excerpt:"
sed -n '1,230p' src/guide/deployment/hub-installation.md
echo
echo "Occurrences of Gateway/Ingress prerequisite language:"
rg -n "Gateway|gateway|Ingress|ingress|httproute|flame-hub" src/guide/deployment/hub-installation.mdRepository: PrivateAIM/documentation
Length of output: 11084
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
p = Path('src/guide/deployment/hub-installation.md')
text = p.read_text()
needles = {
"get pods,pvc": False,
"get ingress,httproute,gateway": False,
"httproute": False,
"gateway": False,
"Ingress-only": False,
"Gateway API": False,
"Gateway-API": False,
}
for i,line in enumerate(text.splitlines(),1):
for n in needles:
if n in line:
needles[n] = True
print(f"{n}: line {i}: {line.strip()}")
print("\nneedle_found=", needles)
PYRepository: PrivateAIM/documentation
Length of output: 2024
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Current git status and diff summary:"
git status --short
git diff --stat -- src/guide/deployment/hub-installation.md || true
echo
echo "Check whether required Gateway CRDs exist in repo/chart examples:"
rg -n "HTTPRoute|Gateway" --glob '!*.png' --glob '!*.jpg' --glob '!*.svg' . \
| head -80 || trueRepository: PrivateAIM/documentation
Length of output: 3555
🌐 Web query:
Kubernetes kubectl get multiple resource types comma-separated if one not installed does it fail
💡 Result:
Yes, if you run kubectl get with a comma-separated list of multiple resource types and one of those types is not installed (or is unknown) on the cluster, the command will fail [1][2]. When kubectl attempts to retrieve multiple resources, it validates each resource type against the API server's discovery information [1]. If any requested resource type cannot be found—either because it does not exist in the cluster or because the group/version is specified incorrectly—kubectl will return an error, such as "the server doesn't have a resource type..." and the command will terminate without returning the data for the other, valid resource types [1]. Key points to keep in mind: - Command Behavior: The operation is treated as a single request for a set of resources; if any part of that set is invalid, the entire operation fails to return results [1]. - Error Messages: If you specify an incorrect group (e.g., resource.wronggroup), the error message may sometimes be misleading, indicating the resource type itself is unknown rather than just the group [1]. - Alternatives: There is no native flag for kubectl get to automatically ignore invalid resource types in a comma-separated list [3]. If you need to retrieve multiple resources and are unsure if all types exist, you typically need to use shell scripting (e.g., iterating through a list and running separate kubectl get commands) or use the --ignore-not-found flag, though that flag is specifically for suppressing errors when an individual object instance is missing, not for skipping entire missing resource types [4][3]. For more advanced needs, such as retrieving all available resources in a namespace, users often combine kubectl api-resources with other utilities to dynamically generate the list of resources to fetch [5][4].
Citations:
- 1: kubectl error message drops the group name for unknown resource types with a group qualifier kubernetes/kubectl#1865
- 2: https://github.com/kubernetes/kubernetes/blob/v1.32.0/staging/src/k8s.io/kubectl/pkg/cmd/get/get.go
- 3: https://github.com/kubernetes/kubectl/blob/master/pkg/cmd/get/get.go
- 4: https://www.baeldung.com/ops/kubernetes-list-all-resources
- 5: Need a real "get-all" command kubernetes/kubectl#527
Split routing verification by installed API.
In the verify step, the single kubectl get ingress,httproute,gateway command requires Gateway API resources even when only Ingress routing is configured. Use the Ingress-only command when Gateway API is not installed, otherwise gateway verification can fail before the other checks print.
Proposed command fix
kubectl -n flame-hub get pods,pvc
-kubectl -n flame-hub get ingress,httproute,gateway
+kubectl -n flame-hub get ingress
+# If Gateway API is enabled:
+kubectl -n flame-hub get httproute,gateway
helm -n flame-hub status flame-hub📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ```bash | |
| kubectl -n flame-hub get pods,pvc | |
| kubectl -n flame-hub get ingress,httproute,gateway | |
| helm -n flame-hub status flame-hub | |
| ``` |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/hub-installation.md` around lines 189 - 193, Update the
routing verification commands in the deployment guide to branch on the installed
routing API: run an Ingress-only query when Gateway API is not installed, and
include HTTPRoute and Gateway resources only when Gateway API is available. Keep
the pod/PVC and Helm status checks unchanged.
| Continue with [Kubernetes preparation](./microk8s-quickstart) or go directly to | ||
| [installing the Hub chart](./hub-installation) if a cluster is already available. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Link both cluster-preparation options from the Hub guide.
The deployment overview sends Hub users to MicroK8s or Minikube, but Lines [40-41] link only MicroK8s. Add the Minikube link or state why it is excluded.
Proposed documentation fix
-Continue with [Kubernetes preparation](./microk8s-quickstart) or go directly to
+Continue with [MicroK8s](./microk8s-quickstart), [Minikube](./minikube-quickstart), or go directly to
[installing the Hub chart](./hub-installation) if a cluster is already available.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Continue with [Kubernetes preparation](./microk8s-quickstart) or go directly to | |
| [installing the Hub chart](./hub-installation) if a cluster is already available. | |
| Continue with [MicroK8s](./microk8s-quickstart), [Minikube](./minikube-quickstart), or go directly to | |
| [installing the Hub chart](./hub-installation) if a cluster is already available. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/hub-introduction.md` around lines 40 - 41, Update the
deployment overview guidance around the Kubernetes preparation link to include
both MicroK8s and Minikube preparation options, while preserving the direct Hub
chart installation path for users with an existing cluster. Use the existing
Minikube guide link rather than introducing a new destination.
| Download: [`1_microk8s_setup.sh`](https://github.com/PrivateAIM/hub-deployment/blob/master/scripts/1_microk8s_setup.sh) | ||
|
|
||
| ```bash | ||
| chmod +x microk8s_setup.sh | ||
| ./microk8s_setup.sh | ||
| chmod +x 1_microk8s_setup.sh | ||
| ./1_microk8s_setup.sh |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== target file excerpt =="
if [ -f src/guide/deployment/microk8s-quickstart.md ]; then
nl -ba src/guide/deployment/microk8s-quickstart.md | sed -n '1,135p'
else
echo "target file not found"
fi
echo
echo "== MicroK8s channel references in repo =="
rg -n "snap install|microk8s|channel|1\.32|1\.33|1\.34|1\.31" src || true
echo
echo "== script contents if available =="
curl -fsS "https://raw.githubusercontent.com/PrivateAIM/hub-deployment/master/scripts/1_microk8s_setup.sh" -o /tmp/1_microk8s_setup.sh || true
if [ -f /tmp/1_microk8s_setup.sh ]; then
nl -ba /tmp/1_microk8s_setup.sh | sed -n '1,180p'
fiRepository: PrivateAIM/documentation
Length of output: 228
🌐 Web query:
Canonical MicroK8s default snap channel version current stable documentation
💡 Result:
When installing MicroK8s via snap, if no channel is specified, the installation defaults to the latest stable release tracked in the 'latest/stable' channel [1]. To install MicroK8s using the default stable channel, you can run the following command: sudo snap install microk8s --classic [2][3] The 'latest/stable' channel automatically tracks the most recent stable Kubernetes release supported by MicroK8s [1]. Because MicroK8s uses snap channels to manage versioning, you can also pin your installation to a specific Kubernetes minor version by explicitly selecting a channel (e.g., '1.35/stable') [1][4]. This ensures that your installation only receives automatic updates for patch releases (e.g., from 1.35.x to 1.35.y) and prevents an automatic upgrade to a new minor version (e.g., 1.36) [5][4]. As of August 7, 2026, the 1.35/stable channel is an active, current stable release channel for MicroK8s [6][2]. You can check for available channels and their corresponding versions by visiting the official Snap Store page for MicroK8s or by using the command 'snap info microk8s' on your system [6][4].
Citations:
- 1: https://canonical.com/microk8s/docs/setting-snap-channel
- 2: https://snapcraft.io/install/microk8s/ubuntu
- 3: https://canonical.com/microk8s
- 4: https://canonical.com/microk8s/docs/upgrading
- 5: https://canonical.com/microk8s/docs/snap-refreshes
- 6: https://snapcraft.io/microk8s
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== target file excerpt =="
python3 - <<'PY'
from pathlib import Path
p = Path("src/guide/deployment/microk8s-quickstart.md")
if not p.exists():
print("target file not found")
raise SystemExit
for i, line in enumerate(p.read_text().splitlines(), 1):
if 1 <= i <= 135:
print(f"{i:4}: {line}")
PY
echo
echo "== MicroK8s channel references in repo =="
python3 - <<'PY'
import subprocess, re, pathlib
text = subprocess.check_output(["git", "ls-files"], text=True)
for path in text.splitlines():
if not path.startswith("src/"):
continue
try:
lines = pathlib.Path(path).read_text(errors="ignore").splitlines()
hits = [(i+1, line) for i, line in enumerate(lines) if re.search(r"microk8s|snap install|channel|1\.3[1-5]", line, re.I)]
if hits:
print(f"== {path} ==")
for i, line in hits:
print(f"{i}: {line}")
except Exception as exc:
print(f"SKIP {path}: {exc}")
PY
echo
echo "== linked script contents =="
python3 - <<'PY'
import urllib.request
url = "https://raw.githubusercontent.com/PrivateAIM/hub-deployment/master/scripts/1_microk8s_setup.sh"
try:
data = urllib.request.urlopen(url, timeout=20).read().decode("utf-8", errors="replace")
for i, line in enumerate(data.splitlines(), 1):
if i <= 200 and ("microk8s" in line.lower() or "snap install" in line.lower() or "channel" in line.lower() or line.startswith("VERSION=") or line.startswith("CHANNEL=") or line.startswith("MICROK8S_VERSION") or line.startswith("MICROK8S_CHANNEL")):
print(f"{i}: {line}")
except Exception as exc:
print("FETCH_ERROR:", exc)
PYRepository: PrivateAIM/documentation
Length of output: 11867
🌐 Web query:
GitHub raw.githubusercontent.com PrivateAIM hub-deployment 1_microk8s_setup.sh default channel microk8s
💡 Result:
The file 1_microk8s_setup.sh is a bash script provided in the PrivateAIM/hub-deployment repository [1][2]. It is designed to automate the installation and configuration of MicroK8s on Debian-based systems (such as Ubuntu) to support the deployment of the FLAME Hub ecosystem [3]. The script performs several automated tasks, including: - Installing Snap and MicroK8s [3]. - Configuring roles, permissions, and environment paths (e.g., adding /snap/bin to PATH) [3]. - Generating and exporting the Kubeconfig [3]. - Allowing for optional configuration of a non-default MicroK8s storage path [3]. Recent updates to the script (as of February 2026) have introduced improved interactive logic, which allows users to optionally specify a MicroK8s channel during the setup process [4]. For users wishing to run the script, the standard procedure involves making it executable and running it directly on the host machine [3]: chmod +x 1_microk8s_setup.sh./1_microk8s_setup.sh This script is part of a broader set of deployment guides for the PrivateAIM FLAME Hub, which is a platform for federated, privacy-preserving data analysis [5]. Additional steps in the deployment workflow typically include setting up storage replication (e.g., using OpenEBS or Mayastor) and installing the FLAME Hub Helm chart [2][6][7]. Documentation for these processes is maintained on the official PrivateAIM project documentation site [3][6].
Citations:
- 1: https://github.com/PrivateAIM/hub-deployment/tree/master/scripts
- 2: https://github.com/PrivateAIM/hub-deployment
- 3: https://docs.privateaim.net/guide/deployment/microk8s-quickstart.html
- 4: PrivateAIM/hub-deployment@8e2750a
- 5: https://hub.docs.privateaim.net/
- 6: https://docs.privateaim.net/guide/deployment/hub-installation.html
- 7: https://github.com/PrivateAIM/hub-deployment/blob/master/README.md
🌐 Web query:
PrivateAIM hub-deployment 1_microk8s_setup.sh MicroK8s_CHANNEL 1.32
💡 Result:
The script 1_microk8s_setup.sh is part of the PrivateAIM hub-deployment repository, which provides automated deployment tools for the HUB ecosystem [1][2][3]. When configuring MicroK8s for this deployment, the use of the 1.32 channel corresponds to the MicroK8s channel for Kubernetes version 1.32 [4][5]. The standard command to install or refresh MicroK8s to this version is: sudo snap install microk8s --classic --channel=1.32/stable [4][6] Or, if updating an existing installation: sudo snap refresh microk8s --channel=1.32/stable [6][7] In the context of the PrivateAIM environment, the 1_microk8s_setup.sh script is intended to simplify these setup tasks [8]. If you are manually configuring or modifying the script to target this version, ensure you are referencing the 1.32/stable channel to align with the supported release track for Kubernetes 1.32 [4][9]. For detailed implementation, refer to the PrivateAIM documentation at docs.privateaim.net [8] and the official MicroK8s release notes [4].
Citations:
- 1: https://github.com/PrivateAIM/hub-deployment/tree/master/scripts
- 2: https://github.com/PrivateAIM/hub-deployment
- 3: https://github.com/PrivateAIM/hub-deployment/blob/master/README.md
- 4: https://canonical.com/microk8s/docs/release-notes
- 5: https://github.com/canonical/microk8s/releases/tag/v1.32
- 6: Unable to Update to Microk8s v 1.32 canonical/microk8s#4796
- 7: https://canonical.com/microk8s/docs/upgrading
- 8: https://docs.privateaim.net/guide/deployment/microk8s-quickstart.html
- 9: https://canonical.com/microk8s/docs/setting-snap-channel
Use the same supported MicroK8s channel in both installation paths.
The linked installer can use channel 1.32, while the manual command installs from the snap default channel. They can install different Kubernetes versions. Choose the supported Hub 1.0 channel and document or patch it so both paths match.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/microk8s-quickstart.md` around lines 10 - 14, The
MicroK8s installation paths may use different channels and Kubernetes versions.
Update the manual installation command and, if applicable, the linked
1_microk8s_setup.sh installer reference so both use the supported Hub 1.0
MicroK8s channel, specifically channel 1.32.
Source: MCP tools
| If you need to use a separate VM volume, create one filesystem on that volume and mount it. There is | ||
| no need to divide it into a second partition for Mayastor. Then either: | ||
|
|
||
| The [`0_format_drives.sh`](https://github.com/PrivateAIM/hub-deployment/blob/master/scripts/0_format_drives.sh) | ||
| helper can prepare an unused volume. It replaces the device with one GPT partition, formats it as | ||
| ext4, adds it to `/etc/fstab`, and mounts it below `/mnt`. This destroys all existing data on the | ||
| selected device and therefore requires the exact device path as confirmation: | ||
|
|
||
| ```bash | ||
| chmod +x 0_format_drives.sh | ||
| ./0_format_drives.sh /dev/vdb | ||
| ``` | ||
|
|
||
| Inspect the device with `lsblk` and confirm that it is the intended unused volume before running the | ||
| script. For NVMe devices, pass the complete disk path, such as `/dev/nvme1n1`, not a partition. | ||
|
|
||
| **Option A (Recommended for simplicity):** Mount (or symlink) the SNAP_COMMON directory to your preferred destination. | ||
| ::: tip | ||
| This storage configuration step should be performed **before** installing microk8s to avoid needing to migrate data later. | ||
| This storage configuration step should be performed **before** installing MicroK8s to avoid needing to migrate data later. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate guide and scripts =="
git ls-files | rg '(^|/)microk8s-quickstart\.md$|(^|/)scripts/0_format_drives\.sh$|(^|/)1_microk8s_setup\.sh$' || true
echo "== guide excerpt =="
if [ -f src/guide/deployment/microk8s-quickstart.md ]; then
sed -n '55,95p' src/guide/deployment/microk8s-quickstart.md | cat -n
fi
echo "== script excerpts =="
if [ -f scripts/0_format_drives.sh ]; then
wc -l scripts/0_format_drives.sh
sed -n '1,240p' scripts/0_format_drives.sh | cat -n
fi
echo "== search DEVICE/path handling =="
rg -n 'DEVICE|/dev/\$\{DEVICE\}|\$DEVICE|mkfs|parted|partition|volume|SNAP_COMMON|migrate|storage' src/guide/deployment scripts 2>/dev/null || trueRepository: PrivateAIM/documentation
Length of output: 10244
🌐 Web query:
github.com/PrivateAIM/hub-deployment scripts/0_format_drives.sh /dev/${DEVICE} partitions
💡 Result:
The script 0_format_drives.sh is a component of the PrivateAIM/hub-deployment repository [1][2], which provides infrastructure setup scripts for deploying the HUB ecosystem [3][4]. The script is designed to handle disk preparation by formatting drives [2]. In the context of Linux shell scripting for disk management, referring to /dev/${DEVICE} partitions typically addresses the naming convention differences between disk types [5]. Specifically, for standard storage devices like SATA drives, the first partition is commonly denoted by appending a number directly to the device name (e.g., /dev/sda1) [5]. Conversely, for devices such as NVMe drives, a p suffix is often required before the partition number (e.g., /dev/nvme0n1p1) [6][7][5]. Automated scripts often include logic to detect this distinction to ensure the correct partition path is targeted during formatting operations [7][5]. You should check the source code of 0_format_drives.sh within the PrivateAIM/hub-deployment repository to see how it specifically handles the ${DEVICE} variable and partition naming for your target hardware [1]. If the script is intended for general use, it likely contains conditional logic to determine whether to append p1 or 1 to the base device path [7][5].
Citations:
- 1: https://github.com/PrivateAIM/hub-deployment/tree/master/scripts
- 2: PrivateAIM/hub-deployment@14f3e0e
- 3: https://github.com/PrivateAIM/hub-deployment
- 4: https://github.com/PrivateAIM/hub-deployment/blob/master/README.md
- 5: https://git.logal.dev/LogalDeveloper/Arch-Linux-Installer/src/commit/f69d80775619d040a189e1388779d143fcff152f/lib/disk/partition.sh
- 6: https://github.com/DrInfinite/dotfiles/blob/main/shell/functions/drive.sh
- 7: https://github.com/batocera-linux/batocera.linux/blob/2c733ebd/package/batocera/core/batocera-scripts/scripts/batocera-format
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== fetch remote helper source =="
if command -v curl >/dev/null 2>&1; then
curl -fsSL 'https://raw.githubusercontent.com/PrivateAIM/hub-deployment/master/scripts/0_format_drives.sh' -o /tmp/0_format_drives_remote.sh
wc -l /tmp/0_format_drives_remote.sh
sed -n '1,260p' /tmp/0_format_drives_remote.sh | cat -n
else
echo "curl not available"
fi
echo "== static parser for relevant constructs =="
python3 - <<'PY'
from pathlib import Path
import re
remote = Path('/tmp/0_format_drives_remote.sh').read_text() if Path('/tmp/0_format_drives_remote.sh').exists() else ''
guide = Path('src/guide/deployment/microk8s-quickstart.md').read_text()
print("remote_has/dev_variable=", bool(re.search(r'/dev/\$\{?DEVICE', remote) or re.search(r'/dev/\$\(?DEVICE', remote))) if remote else 'NO_REMOTE')
print("parted_calls=", [(i,l.strip()) for i,l in enumerate(remote.splitlines(),1) if re.match(r'\s*parted\s+.*mkpart', l)])
print("mkfs_calls=", [(i,l.strip()) for i,l in enumerate(remote.splitlines(),1) if re.match(r'\s*mkfs\.', l)])
print("partition_count=", len(parted_calls := [(i,l) for i,l in enumerate(remote.splitlines(),1) if re.match(r'\s*parted\s+.*mkpart', l)]))
print("fstab_mount=", bool(re.search(r'FSTAB|/etc/fstab|m\s+', ' '.join(remote.splitlines()))))
example_args = ['/dev/vdb', '/dev/nvme1n1']
for arg in example_args:
print(f"arg={arg}, would_match_bare_device_regex=", bool(re.fullmatch(r'/dev/[a-zA-Z0-9_\-]+', arg)))
print("guide_mentions_one_partition=", "one GPT partition" in guide or "one filesystem" in guide)
print("guide_arg_examples=", [arg for line in guide.splitlines() for arg in re.findall(r'/dev/[a-zA-Z0-9_\-./]+(\b|")', ' '.join(line.strip().split('\t')))])
PYRepository: PrivateAIM/documentation
Length of output: 5108
Align the storage instructions with 0_format_drives.sh.
0_format_drives.sh expects a bare device name such as vdb, not /dev/vdb, and /dev/${DEVICE} becomes /dev//dev/vdb. The script also creates two GPT partitions, formats each, and mounts part of them to /mnt, while this section says one filesystem and one GPT partition. Update this guide’s examples and description to match the helper, or make the helper match the documented flow.
🧰 Tools
🪛 LanguageTool
[style] ~65-~65: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...as 435GB. If you need to use a separate VM volume, create one fi...
(REP_NEED_TO_VB)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/microk8s-quickstart.md` around lines 65 - 83, Update the
deployment guide’s 0_format_drives.sh description and invocation to match the
helper’s actual interface and behavior: document passing a bare device name such
as vdb or nvme1n1, and accurately describe the two GPT partitions, formatting,
and /mnt mounting it performs. Keep the warning about data destruction and
verifying the intended unused device.
Source: MCP tools
| For a production or multi-node Hub, do not use hostpath as the durable application-storage layer. | ||
| Install a reattachable CSI backend such as OpenStack Cinder and configure the Hub claims to use its | ||
| StorageClass; see [Storage for the FLAME Hub](./hub-storage). |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Prevent hostpath from becoming the production storage default.
This warning conflicts with the automatic setup and the later addon list, which enable hostpath-storage. MicroK8s marks this addon as the default StorageClass and stores data on the local node. A production user can therefore follow this guide and still place Hub claims on non-reattachable hostpath storage. Mark hostpath as local-only and show the required CSI StorageClass and Helm override for production. (raw.githubusercontent.com)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/microk8s-quickstart.md` around lines 102 - 104, Update
the MicroK8s quickstart instructions and addon configuration to make hostpath
explicitly local-only rather than a production default. Document the required
reattachable CSI StorageClass and the corresponding Hub Helm storage-class
override for production or multi-node deployments, while preserving hostpath
guidance only for local setups.
Source: MCP tools
| The script leaves matching existing entries unchanged. Both parameters are required; if bundled | ||
| Harbor is disabled, add the Hub hostname manually instead. |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate files =="
git ls-files | rg '(^|/)scripts/minikube-dns\.ps1$|src/guide/deployment/minikube-quickstart\.md$' || true
echo
echo "== changed files stat =="
git diff --stat || true
echo
echo "== script outline/search =="
if [ -f scripts/minikube-dns.ps1 ]; then
wc -l scripts/minikube-dns.ps1
nl -ba scripts/docker-dns.ps1 2>/dev/null | rg -n 'Hosts|hosts|IP|hostname|Replace|Remove|Add' -C 3 || true
fi
echo
echo "== markdown lines =="
if [ -f src/guide/deployment/minikube-quickstart.md ]; then
nl -ba src/guide/deployment/minikube-quickstart.md | sed -n '240,285p'
fi
echo
echo "== references to minikube-dns script =="
rg -n "minikube-dns|Hub hostname|script leaves|adds.*hosts|hosts" -S . --glob '!node_modules' --glob '!dist' --glob '!build' | sed -n '1,200p'Repository: PrivateAIM/documentation
Length of output: 343
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate files =="
git ls-files | grep -E '(^|/)scripts/minikube-dns\.ps1$|(^|/)src/guide/deployment/minikube-quickstart\.md$' || true
echo
echo "== changed files stat =="
git diff --stat || true
echo
echo "== markdown snippet =="
if [ -f src/guide/deployment/minikube-quickstart.md ]; then
awk 'NR>=240 && NR<=285{printf "%5d\t%s\n", NR, $0}' src/guide/deployment/minikube-quickstart.md
fi
echo
echo "== candidates scripts =="
find . -path './.git' -prUNE -o -type f -name 'minikube-dns.ps1' -print 2>/dev/null | sort
echo
echo "== search relevant mentions =="
grep -RIn "minikube-dns|Hub hostname|script leaves|adds.*hosts|hosts|Hosts" . --exclude-dir=.git --exclude-dir=node_modules --exclude-dir=dist --exclude-dir=build | sed -n '1,220p' || true
echo
echo "== script content if present =="
if [ -f scripts/minikube-dns.ps1 ]; then
awk '{printf "%5d\t%s\n", NR, $0}' scripts/minikube-dns.ps1
fiRepository: PrivateAIM/documentation
Length of output: 1845
🌐 Web query:
PrivateAIM hub-deployment master scripts minikube-dns.ps1
💡 Result:
The minikube-dns.ps1 script is part of the PrivateAIM/hub-deployment repository, located in the scripts/ directory [1][2]. It was added to the repository as part of a set of documentation and setup scripts to assist with local Kubernetes deployments [2]. While specific source code for this PowerShell script is hosted within the PrivateAIM/hub-deployment project, its purpose is to automate DNS configuration for Minikube on Windows environments [1][2]. It is designed to simplify accessing local Kubernetes services (such as the FLAME Hub) by handling the necessary DNS mapping without requiring manual entry updates to the host machine's /etc/hosts file, similar to the functionality provided by standard Minikube ingress-dns addons [3]. For further guidance on setting up the HUB ecosystem using this repository, you can refer to the repository's documentation, which includes instructions for K8s node setup and Helm chart installation [4][5]. Top results: [1] https://github.com/PrivateAIM/hub-deployment/tree/master/scripts [4] https://github.com/PrivateAIM/hub-deployment/blob/master/README.md [2] PrivateAIM/hub-deployment@7d9ae2b
Citations:
- 1: https://github.com/PrivateAIM/hub-deployment/tree/master/scripts
- 2: PrivateAIM/hub-deployment@7d9ae2b
- 3: https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/
- 4: https://github.com/PrivateAIM/hub-deployment/blob/master/README.md
- 5: https://github.com/PrivateAIM/hub-deployment
🌐 Web query:
raw.githubusercontent.com PrivateAIM hub-deployment master scripts minikube-dns.ps1
💡 Result:
The file minikube-dns.ps1 is a PowerShell script located in the scripts directory of the PrivateAIM/hub-deployment repository on GitHub [1]. This repository provides configuration and deployment instructions for the FLAME Hub, which is a platform for federated, privacy-aware data analysis [2][3][4]. The minikube-dns.ps1 script is part of the repository's tooling designed to assist users with setting up the infrastructure required for the FLAME Hub ecosystem, specifically within a Minikube-based Kubernetes environment [2][1]. Users typically utilize this repository to deploy the Hub either via Helm charts or Docker Compose [2][3]. Detailed documentation for these deployment methods, including guides that reference Minikube setups, is available on the official PrivateAIM documentation website [5][6].
Citations:
- 1: https://github.com/PrivateAIM/hub-deployment/tree/master/scripts
- 2: https://github.com/PrivateAIM/hub-deployment
- 3: https://github.com/PrivateAIM/hub-deployment/blob/master/README.md
- 4: https://hub.docs.privateaim.net/
- 5: https://docs.privateaim.net/guide/deployment/hub-installation.html
- 6: https://docs.privateaim.net/guide/deployment/hub-docker-compose.html
🌐 Web query:
GitHub raw PrivateAIM/hub-deployment scripts/minikube-dns.ps1
💡 Result:
The file minikube-dns.ps1 is a PowerShell script located in the scripts directory of the PrivateAIM/hub-deployment GitHub repository [1]. This repository provides deployment resources for the PrivateAIM platform, including instructions and scripts for setting up a Kubernetes environment using Minikube or MicroK8s [2][3]. While the specific contents of the minikube-dns.ps1 script are not indexed in public snippets, it is designed to assist with the Minikube configuration process [1][2]. In the context of Minikube, such scripts typically automate tasks related to the ingress-dns addon, such as configuring host-side DNS resolution to allow access to local Kubernetes services via domain names (e.g.,.test) without manually modifying the /etc/hosts file [4][5][6]. For authoritative guidance on Minikube DNS configuration, refer to the official Minikube documentation, which provides standard procedures for enabling the ingress-dns addon and configuring DNS settings on various operating systems, including Windows [4][6].
Citations:
- 1: https://github.com/PrivateAIM/hub-deployment/tree/master/scripts
- 2: https://github.com/PrivateAIM/hub-deployment
- 3: https://github.com/PrivateAIM/hub-deployment/blob/master/README.md
- 4: https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/
- 5: https://github.com/nexiles/minikube-ingress-dns
- 6: addon: improve ingress-dns addon for windows and bump to v0.0.4 kubernetes/minikube#21449
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== fetch minikube-dns.ps1 =="
curl -fsSL "https://raw.githubusercontent.com/PrivateAIM/hub-deployment/master/scripts/minikube-dns.ps1" -o /tmp/minikube-dns.ps1 || true
if [ -f /tmp/minikube-dns.ps1 ]; then
awk '{printf "%5d\t%s\n", NR, $0}' /tmp/minikube-dns.ps1
else
echo "failed to fetch script"
fi
echo
echo "== fetch related host update scripts if any =="
for url in \
"https://raw.githubusercontent.com/PrivateAIM/hub-deployment/master/scripts/update-hosts.ps1" \
"https://raw.githubusercontent.com/PrivateAIM/hub-deployment/master/scripts/docker-dns.ps1"
do
echo "--- $url"
curl -fsSL "$url" -o /tmp/script.ps1 || true
[ -f /tmp/script.ps1 ] && awk '{printf "%5d\t%s\n", NR, $0}' /tmp/script.ps1
doneRepository: PrivateAIM/documentation
Length of output: 1708
Update existing hostname entries if the Minikube IP changes.
minikube-dns.ps1 checks for an exact IP hostname line and appends only when missing. If Minikube changes IP, rerunning the command can leave old Hub or Harbor lines plus a new line for the current IP. Replace entries by hostname or tell users how to remove the stale hosts file entries before rerunning.
🧰 Tools
🪛 LanguageTool
[grammar] ~266-~266: Ensure spelling is correct
Context: ...equired; if bundled Harbor is disabled, add the Hub hostname manually instead.
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/guide/deployment/minikube-quickstart.md` around lines 265 - 266, Update
the minikube-dns.ps1 guidance to ensure existing Hub and Harbor hostname entries
are replaced when the Minikube IP changes, rather than leaving stale lines
alongside new ones; alternatively, instruct users to remove stale hosts-file
entries before rerunning the command.
Source: MCP tools
2 participants
…be and microk8s setup
Summary by CodeRabbit