[DO NOT MERGE] website/docs/cloud-docs/integrations/kubernetes: Add Deletion Policy page

website/data/cloud-docs-nav-data.json

@@ -648,6 +648,10 @@
             "title": "Annotations and Labels",
             "path": "integrations/kubernetes/annotations-and-labels"
           },
+          {
+            "title": "Deletion Policy",
+            "path": "integrations/kubernetes/deletion-policy"
+          },
           {
             "title": "Migration Guide",
             "path": "integrations/kubernetes/ops-v2-migration"

website/docs/cloud-docs/integrations/kubernetes/api-reference.mdx

@@ -42,7 +42,7 @@ _Appears in:_
 | --- | --- |
 | `maxReplicas` _integer_ | MaxReplicas is the maximum number of replicas for the Agent deployment. |
 | `minReplicas` _integer_ | MinReplicas is the minimum number of replicas for the Agent deployment. |
-| `targetWorkspaces` _[TargetWorkspace](#targetworkspace)_ | TargetWorkspaces is a list of HCP Terraform Workspaces which the agent pool should scale up to meet demand. When this field is omitted the autoscaler will target all workspaces that are associated with the AgentPool. |
+| `targetWorkspaces` _[TargetWorkspace](#targetworkspace)_ | **DEPRECATED**: This field has been deprecated since 2.9.0 and will be removed in future versions. TargetWorkspaces is a list of HCP Terraform Workspaces which the agent pool should scale up to meet demand. When this field is omitted the autoscaler will target all workspaces that are associated with the AgentPool. |
 | `cooldownPeriodSeconds` _integer_ | CooldownPeriodSeconds is the time to wait between scaling events. Defaults to 300. |
 | `cooldownPeriod` _[AgentDeploymentAutoscalingCooldownPeriod](#agentdeploymentautoscalingcooldownperiod)_ | CoolDownPeriod configures the period to wait between scaling up and scaling down |
 
@@ -227,6 +227,22 @@ More information:
 | `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. |
 | `spec` _[ModuleSpec](#modulespec)_ |  |
 
+#### ModuleDeletionPolicy
+
+_Underlying type:_ _string_
+
+Deletion Policy defines the strategies for resource deletion in the Kubernetes operator.
+It controls how the operator should handle the deletion of resources when triggered by
+a user action or system event.
+
+
+There is one possible value:
+- `retain`: When the custom resource is deleted, the associated module is retained. `destroyOnDeletion` must be set to false. Default value.
+- `destroy`: Executes a destroy operation. Removes all resources and the module.
+
+_Appears in:_
+- [ModuleSpec](#modulespec)
+
 #### ModuleOutput
 
 Module outputs to store in ConfigMap(non-sensitive) or Secret(sensitive).
@@ -267,8 +283,9 @@ _Appears in:_
 | `name` _string_ | Name of the module that will be uploaded and executed. Default: `this`. |
 | `variables` _[ModuleVariable](#modulevariable) array_ | Variables to pass to the module, they must exist in the Workspace. |
 | `outputs` _[ModuleOutput](#moduleoutput) array_ | Module outputs to store in ConfigMap(non-sensitive) or Secret(sensitive). |
-| `destroyOnDeletion` _boolean_ | Specify whether or not to execute a Destroy run when the object is deleted from the Kubernetes. Default: `false`. |
+| `destroyOnDeletion` _boolean_ | **DEPRECATED** Specify whether or not to execute a Destroy run when the object is deleted from the Kubernetes. Default: `false`. |
 | `restartedAt` _string_ | Allows executing a new Run without changing any Workspace or Module attributes. Example: ```kubectl patch KIND NAME --type=merge --patch '{"spec": \{"restartedAt": "'\`date -u -Iseconds\`'"\}\}'``` |
+| `deletionPolicy` _[ModuleDeletionPolicy](#moduledeletionpolicy)_ | Deletion Policy defines the strategies for resource deletion in the Kubernetes operator.<br />It controls how the operator should handle the deletion of resources when triggered by<br />a user action or system event.<br /><br />There is one possible value:<br />- `retain`: When the custom resource is deleted, the associated module is retained. `destroyOnDeletion` must be set to false.<br />- `destroy`: Executes a destroy operation. Removes all resources and the module.<br />Default: `retain`. |
 
 #### ModuleVariable
 
@@ -362,6 +379,20 @@ More information:
 | `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. |
 | `spec` _[ProjectSpec](#projectspec)_ |  |
 
+#### ProjectDeletionPolicy
+
+_Underlying type:_ _string_
+
+DeletionPolicy defines the strategy the Kubernetes operator uses when you delete a project, either manually or by a system event.
+
+
+You must use one of the following values:
+- `retain`: When the custom resource is deleted, the operator will not delete the associated project.
+- `soft`: Attempts to remove the project. The project must be empty.
+
+_Appears in:_
+- [ProjectSpec](#projectspec)
+
 #### ProjectSpec
 
 ProjectSpec defines the desired state of Project.
@@ -378,6 +409,7 @@ _Appears in:_
 | `token` _[Token](#token)_ | API Token to be used for API calls. |
 | `name` _string_ | Name of the Project. |
 | `teamAccess` _[ProjectTeamAccess](#projectteamaccess) array_ | HCP Terraform's access model is team-based. In order to perform an action within a HCP Terraform organization, users must belong to a team that has been granted the appropriate permissions. You can assign project-specific permissions to teams. More information: [Manage projects](/terraform/cloud-docs/workspaces/organize-workspaces-with-projects#permissions) and [Project permissions](/terraform/cloud-docs/users-teams-organizations/permissions#project-permissions).|
+| `deletionPolicy` _[ProjectDeletionPolicy](#projectdeletionpolicy)_ | DeletionPolicy defines the strategy the Kubernetes operator uses when you delete a project, either manually or by a system event.<br /><br />You must use one of the following values:<br />- `retain`: When the custom resource is deleted, the operator will not delete the associated project.<br />- `soft`: Attempts to remove the project. The project must be empty.<br />Default: `retain`. |
 
 #### ProjectTeamAccess
 
@@ -608,6 +640,9 @@ _Appears in:_
 | `repository` _string_ | A reference to your VCS repository in the format `<organization>/<repository>` where `<organization>` and `<repository>` refer to the organization and repository in your VCS provider. |
 | `branch` _string_ | The repository branch that Run will execute from. This defaults to the repository's default branch (e.g. main). |
 | `speculativePlans` _boolean_ | Whether this workspace allows automatic speculative plans on PR. Default: `true`. More information: [Speculative plans on pull requests](/terraform/cloud-docs/run/ui#speculative-plans-on-pull-requests) and [Speculative plans](/terraform/cloud-docs/run/remote-operations#speculative-plans).|
+| `enableFileTriggers` _boolean_ | File triggers allow you to queue runs in HCP Terraform when files in your VCS repository change.<br />Default: `false`.<br />More informarion:<br /> - https://developer.hashicorp.com/terraform/cloud-docs/workspaces/settings/vcs#automatic-run-triggering |
+| `triggerPatterns` _string array_ | The list of pattern triggers that will queue runs in HCP Terraform when files in your VCS repository change.<br />`spec.versionControl.fileTriggersEnabled` must be set to `true`.<br />More informarion:<br /> - https://developer.hashicorp.com/terraform/cloud-docs/workspaces/settings/vcs#automatic-run-triggering |
+| `triggerPrefixes` _string array_ | The list of pattern prefixes that will queue runs in HCP Terraform when files in your VCS repository change.<br />`spec.versionControl.fileTriggersEnabled` must be set to `true`.<br />More informarion:<br /> - https://developer.hashicorp.com/terraform/cloud-docs/workspaces/settings/vcs#automatic-run-triggering |
 
 #### Workspace
 
@@ -697,6 +732,7 @@ _Appears in:_
 | `organization` _string_ | Organization name where the Workspace will be created. [More information](/terraform/cloud-docs/users-teams-organizations/organizations).|
 | `token` _[Token](#token)_ | API Token to be used for API calls. |
 | `applyMethod` _string_ | Define either change will be applied automatically(auto) or require an operator to confirm(manual). Must be one of the following values: `auto`, `manual`. Default: `manual`. [More information](/terraform/cloud-docs/workspaces/settings#auto-apply-and-manual-apply).|
+| `applyRunTrigger` _string_ | Specifies the type of apply, whether manual or auto<br />Must be of value `auto` or `manual`<br />Default: `manual`<br />More information:<br />- https://developer.hashicorp.com/terraform/cloud-docs/workspaces/settings#auto-apply |
 | `allowDestroyPlan` _boolean_ | Allows a destroy plan to be created and applied. Default: `true`. [More information](/terraform/cloud-docs/workspaces/settings#destruction-and-deletion).|
 | `description` _string_ | Workspace description. |
 | `agentPool` _[WorkspaceAgentPool](#workspaceagentpool)_ | HCP Terraform Agents allow HCP Terraform to communicate with isolated, private, or on-premises infrastructure. [More information](/terraform/cloud-docs/agents).|
@@ -725,4 +761,4 @@ _Appears in:_
 | Field | Description |
 | --- | --- |
 | `id` _string_ | ID of the variable set. Must match pattern: `varset-[a-zA-Z0-9]+$` [More information](/terraform/tutorials/cloud/cloud-multiple-variable-sets).|
-| `name` _string_ | Name of the variable set. [More information](/terraform/tutorials/cloud/cloud-multiple-variable-sets).|
+| `name` _string_ | Name of the variable set. [More information](/terraform/tutorials/cloud/cloud-multiple-variable-sets).|

website/docs/cloud-docs/integrations/kubernetes/deletion-policy.mdx

@@ -0,0 +1,50 @@
+---
+page_title: Deletion policies
+description: >-
+    Deletion policies used by the HCP Terraform Cloud Operator for Kubernetes.
+---
+
+# Deletion policies
+
+The HCP Terraform Cloud Operator lets you specify how it should destroy the associated HCP Terraform resource when you delete the custom resource. 
+
+This topic lists the 
+
+## Workspaces
+
+You can choose one of the following deletion policies for an instance of the `Workspace` custom resource:
+
+- `retain`: When you delete the custom resource, the operator does not delete the workspace. This is the default value.
+- `soft`: The operator attempts to delete the associated workspace only if it does not contain any managed resources. 
+- `destroy`: The operator executes a destroy operation to remove all resources managed by the associated workspace. Once the destruction of these resources is successful, the operator deletes the workspace, then removes the custom resource.
+- `force`: Forcefully and immediately deletes the workspace and the custom resource. 
+
+If a workspace is retained, the custom resource deletion will not affect the workspace. 
+
+To migrate, you need to manually export the workspace configuration and apply it in the new cluster. The workspace remains active and managed in the new cluster.
+
+## Module
+
+- `retain`: When you delete the custom resource, the operator does not delete the module. This is the default value.
+- `soft`: Executes a destroy operation. Removes all resources and the module.
+
+If a module is retained, deleting the custom resource will not affect the module. 
+You can export the module configuration and apply it in the new cluster.
+
+## Project 
+
+- `retain`: When you delete the custom resource, the operator does not delete the project. This is the default value.
+- `soft`: Attempts to remove the project. The project must be empty.
+
+If the project is retained, it will remian in HCP Terraform and deleting the custom resource will not affect it.
+
+To migrate, export the project configuration and apply it to the new cluster.
+
+## Agent Pool
+
+- `retain`: When you delete the custom resource, the operator does not delete the agent pool. This is the default value.
+- `destroy`: Attempting to remove the agent pool is only possible when there are no associated workspaces. These workspaces need to be disconnected separately. In this case, the controller will remove all tokens and scale down the agents to zero.
+
+If the Agent Pool is retained, it and its associated resources remians unaffected.
+
+To migrate, you would export the agent pool configuration and apply it in the new cluster.