-
Notifications
You must be signed in to change notification settings - Fork 0
docs(console): cluster deployments & AWS quota warnings, blueprint settings, billing details #199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -196,6 +196,16 @@ The engine block defines how the resource is provisioned. Which settings you can | |||||
| For Helm blueprints, engine version, credentials, and state backend do not apply — the chart and its version are defined by the blueprint, and the resources block is ignored because the chart declares its own. | ||||||
| </Info> | ||||||
|
|
||||||
| ## Editing a Blueprint Service | ||||||
|
|
||||||
| After a blueprint service is created, you can change the inputs it was provisioned with from its **Blueprint configuration** settings page. Open the blueprint service, go to its **Settings**, and select **Blueprint configuration** to review and edit the variables and any overridable engine settings the blueprint exposes (see [Variables & Engine Reference](#variables--engine-reference)). Secret values are handled without exposing the stored secret, and the **Overrides** section is collapsed by default. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. P3: This new paragraph says users can "review and edit the variables" on the Blueprint configuration page, but the same page states earlier that context variables (like Prompt for AI agents
Suggested change
|
||||||
|
|
||||||
| Save your changes, then redeploy the service to apply them. | ||||||
|
|
||||||
| <Info> | ||||||
| The **Blueprint configuration** page is only available for blueprint-backed services. For a blueprint service, source, build, and deployment-restriction settings are not shown, since they are managed by the blueprint. | ||||||
| </Info> | ||||||
|
|
||||||
| ## Updating a Blueprint | ||||||
|
|
||||||
| When Qovery maintains a newer version of a blueprint's template, the linked service surfaces an available update. Qovery compares your current tag to the latest catalog tag and reports exactly what changed: | ||||||
|
|
||||||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -144,7 +144,7 @@ Qovery tracks cluster health using two status categories: | |||||
| | Status | Description | | ||||||
| | -------------------------------------------------------------------------------- | ----------------------------------------- | | ||||||
| | <Icon icon="circle-check" iconType="solid" color="green" /> **Running** | Cluster is healthy and operational | | ||||||
| | <Icon icon="triangle-exclamation" iconType="solid" color="yellow" /> **Warning** | Minor issues detected, requires attention | | ||||||
| | <Icon icon="triangle-exclamation" iconType="solid" color="yellow" /> **Warning** | Minor issues detected, requires attention — for example an [AWS quota warning](#aws-quota-warnings) | | ||||||
| | <Icon icon="circle-xmark" iconType="solid" color="red" /> **Error** | Critical issues, intervention required | | ||||||
| | <Icon icon="circle" iconType="regular" color="gray" /> **Status unavailable** | Cluster unreachable or offline | | ||||||
|
|
||||||
|
|
@@ -157,6 +157,17 @@ Qovery tracks cluster health using two status categories: | |||||
| | **Last Deployment Failed** | The most recent deployment encountered errors | | ||||||
| | **Last Deployment Succeeded** | The most recent deployment completed successfully | | ||||||
|
|
||||||
| #### AWS Quota Warnings | ||||||
|
|
||||||
| On AWS clusters, when Karpenter cannot create new nodes because an AWS service quota has been reached, the cluster status becomes **Warning** and a yellow callout is shown on the cluster overview. The callout reports: | ||||||
|
|
||||||
| - the **quota name** (or code) that was hit, | ||||||
| - the **impacted resource**, | ||||||
| - a **message** describing the issue, | ||||||
| - a **suggested action** — typically requesting an AWS quota increase, then retrying or waiting for the cluster to scale again. | ||||||
|
|
||||||
| While the warning is active, the cluster-status indicator shown next to your services (on the service overview) reads **Quota issue** instead of the generic warning label. The warning clears automatically once new nodes can be scheduled again; it may remain visible for a short time after the last occurrence. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. P2: This describes a changed status label, but the feature is a Quota issue tooltip on services. Describe the tooltip rather than implying the visible indicator label changes. Prompt for AI agents
Suggested change
|
||||||
|
|
||||||
| ### Performing Actions on Clusters | ||||||
|
|
||||||
| Available cluster operations and their cloud provider compatibility: | ||||||
|
|
@@ -240,6 +251,16 @@ Permanently removes your cluster. You have three deletion options: | |||||
| securely and never commit to version control. | ||||||
| </Warning> | ||||||
|
|
||||||
| ## Deployments | ||||||
|
|
||||||
| Each cluster has its own **Deployments** tab that lists its past deployments, most recent first — each with its status, timestamp, duration, and who or what triggered it. Select a deployment to open its logs. This is the same [deployment history](/configuration/deployment/history) available on environments and services, applied to the cluster itself. | ||||||
|
|
||||||
| A cluster deployment run with the **Dry-run** option enabled — a checkbox in the cluster update dialog that previews the changes without applying them — is tagged with a **Dry run** badge in the list. | ||||||
|
|
||||||
| <Info> | ||||||
| Bookmarked links to the previous cluster logs URL are automatically redirected to the **Deployments** tab. | ||||||
| </Info> | ||||||
|
|
||||||
| ## Logs | ||||||
|
|
||||||
| Access cluster logs for troubleshooting and monitoring: | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
P3: Renaming this step leaves four other docs pointing at the old name. Update them so the labels match the new step title.
Prompt for AI agents