docs(install): reorder steps to install operator before platform package#449
docs(install): reorder steps to install operator before platform package#449
Conversation
Move the Cozystack operator installation step before the platform package preparation and application, aligning the tutorial and platform installation guides with the upgrade guide and other installation pages (Hetzner, Generic Kubernetes, BYOP). Co-Authored-By: Claude <[email protected]> Signed-off-by: Kirill Ilin <[email protected]>
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughThe installation documentation has been restructured to replace a direct package-based setup with an operator-driven workflow. Changes introduce Helm-based Cozystack operator installation, reorganize step numbering, add readiness check commands, and consolidate previously scattered installation guidance. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refactors the Cozystack installation documentation to improve clarity and consistency across various guides. The primary goal is to ensure that users install the Cozystack operator first, which manages the platform package lifecycle, before proceeding with the platform package configuration and application. This logical reordering streamlines the installation process and provides a more coherent user experience. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](proxy.php?url=https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the installation documentation to present the steps in a more logical order: installing the operator first, followed by configuring and applying the platform package. The changes are consistent across both the tutorial and the detailed installation guide, improving clarity for users. I have one minor suggestion to improve the wording in an informational alert.
| {{% alert color="info" %}} | ||
| The Package name **must** be `cozystack.cozystack-platform` to match the PackageSource created by the installer. | ||
| After installing operator you can verify available PackageSources with `kubectl get packagesource`. | ||
| You can verify available PackageSources with `kubectl get packagesource`. |
There was a problem hiding this comment.
While the operator is indeed installed in the previous step, removing the context of when to run this command makes the sentence a bit abrupt. To improve clarity, consider rephrasing to explain the purpose of running this command.
| You can verify available PackageSources with `kubectl get packagesource`. | |
| You can verify that the PackageSource is available with `kubectl get packagesource`. |
![coderabbitai[bot]](proxy.php?url=https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
content/en/docs/v1/install/cozystack/platform.md (1)
547-591:⚠️ Potential issue | 🟠 MajorNode Public IP flow is now inconsistent with the tutorial and may be incomplete.
This page no longer patches
ingresses.apps.cozystack.io ingresswithspec.externalIPs, whilecontent/en/docs/v1/getting-started/install-cozystack.md:507-519still does. If that patch is still required, readers following only this guide will not get theEXTERNAL-IPstate shown below. Please either restore that step here or remove it from the tutorial ifpublishing.externalIPsnow propagates automatically.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@content/en/docs/v1/install/cozystack/platform.md` around lines 547 - 591, The docs are inconsistent: this page patches the Platform Package with publishing.externalIPs (kubectl patch packages.cozystack.io cozystack.cozystack-platform) but no longer patches the ingress resource (ingresses.apps.cozystack.io ingress) with spec.externalIPs while another guide (getting-started/install-cozystack.md) still does; fix by choosing one approach and making both pages consistent — either restore the kubectl patch that sets spec.externalIPs on the ingress resource (ingresses.apps.cozystack.io ingress) here so the EXTERNAL-IP output matches the example, or remove the ingress spec.externalIPs patch from the other tutorial and update its text to state that publishing.externalIPs on the cozystack package propagates the external IPs automatically; update the text and any example outputs to match the chosen behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@content/en/docs/v1/install/cozystack/platform.md`:
- Around line 32-52: The intro paragraph under the "Installing on non-Talos OS"
section is still Talos-specific and must be broadened: update the opening
sentence that currently claims the step is "for clusters installed and
configured on Talos Linux nodes" to a generic phrasing that explains this
subsection covers installations on non-Talos systems (e.g., "If your cluster is
not running Talos Linux" or "For non-Talos Kubernetes distributions"); keep the
existing heading "Installing on non-Talos OS" and the helm install example (the
--set cozystackOperator.variant=generic and --set cozystack.apiServerHost flags)
unchanged, and ensure the introductory line clearly directs readers from the
generic Kubernetes guide to this subsection without referencing Talos-specific
features.
---
Outside diff comments:
In `@content/en/docs/v1/install/cozystack/platform.md`:
- Around line 547-591: The docs are inconsistent: this page patches the Platform
Package with publishing.externalIPs (kubectl patch packages.cozystack.io
cozystack.cozystack-platform) but no longer patches the ingress resource
(ingresses.apps.cozystack.io ingress) with spec.externalIPs while another guide
(getting-started/install-cozystack.md) still does; fix by choosing one approach
and making both pages consistent — either restore the kubectl patch that sets
spec.externalIPs on the ingress resource (ingresses.apps.cozystack.io ingress)
here so the EXTERNAL-IP output matches the example, or remove the ingress
spec.externalIPs patch from the other tutorial and update its text to state that
publishing.externalIPs on the cozystack package propagates the external IPs
automatically; update the text and any example outputs to match the chosen
behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 77ad4117-22e3-47a9-a9c0-f527b6e66e9f
📒 Files selected for processing (2)
content/en/docs/v1/getting-started/install-cozystack.mdcontent/en/docs/v1/install/cozystack/platform.md
| ### Installing on non-Talos OS | ||
|
|
||
| By default, the Cozystack operator is configured to use the [KubePrism](https://www.talos.dev/latest/kubernetes-guides/configuration/kubeprism/) | ||
| feature of Talos Linux, which allows access to the Kubernetes API via a local address on the node. | ||
|
|
||
| If you're installing Cozystack on a system other than Talos Linux, set the operator variant during installation: | ||
|
|
||
| ```bash | ||
| helm upgrade --install cozystack oci://ghcr.io/cozystack/cozystack/cozy-installer \ | ||
| --version X.Y.Z \ | ||
| --namespace cozy-system \ | ||
| --create-namespace \ | ||
| --set cozystackOperator.variant=generic \ | ||
| --set cozystack.apiServerHost=<YOUR_API_SERVER_IP> \ | ||
| --set cozystack.apiServerPort=6443 | ||
| ``` | ||
|
|
||
| Replace `<YOUR_API_SERVER_IP>` with the internal IP address of your Kubernetes API server (IP only, without protocol or port). | ||
|
|
||
| For a complete guide on deploying Cozystack on generic Kubernetes distributions, see [Deploying Cozystack on Generic Kubernetes]({{% ref "/docs/v1/install/kubernetes/generic" %}}). | ||
|
|
There was a problem hiding this comment.
Broaden the page intro to match the new non-Talos path.
This new subsection makes the guide applicable beyond Talos, but the opening text still says this step is for clusters “installed and configured on Talos Linux nodes.” That contradiction will confuse readers arriving here from the generic Kubernetes path.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@content/en/docs/v1/install/cozystack/platform.md` around lines 32 - 52, The
intro paragraph under the "Installing on non-Talos OS" section is still
Talos-specific and must be broadened: update the opening sentence that currently
claims the step is "for clusters installed and configured on Talos Linux nodes"
to a generic phrasing that explains this subsection covers installations on
non-Talos systems (e.g., "If your cluster is not running Talos Linux" or "For
non-Talos Kubernetes distributions"); keep the existing heading "Installing on
non-Talos OS" and the helm install example (the --set
cozystackOperator.variant=generic and --set cozystack.apiServerHost flags)
unchanged, and ensure the introductory line clearly directs readers from the
generic Kubernetes guide to this subsection without referencing Talos-specific
features.
2 participants
Summary
Test plan
Summary by CodeRabbit