Merge pull request #101 from awslabs/instance

updating docs - Instance

Author: a-hilaly

website/docs/docs/concepts/00-resource-groups.md

@@ -107,10 +107,10 @@ controller processes it as follows:
    Kubernetes API server, making it available for use in the cluster.
 
 4. **Micro-Controller Deployment**: KRO deploys a dedicated micro-controller for
-   this ResourceGroup. This micro-controller will listen for **"claim"
+   this ResourceGroup. This micro-controller will listen for **"instance"
    events** - instances of the CRD created in step 2. It will be responsible for
    managing the **lifecycle of resources** defined in the ResourceGroup for each
-   claim.
+   instance.
 
 5. **Status Update**: The controller updates the status of the ResourceGroup to
    reflect that the corresponding CRD has been created and registered.
@@ -125,12 +125,12 @@ associated **Deployments** and **Services** as defined in the ResourceGroup.
 The **KRO** controller continues to monitor the **ResourceGroup** for any
 changes, updating the corresponding CRD and micro-controller as necessary.
 
-## **ResourceGroup** Claim Example
+## **ResourceGroup** Instance Example
 
 After the **ResourceGroup** is processed, users can create instances of it.
-Here's an example of how a claim for the `SimpleWebApp` might look:
+Here's an example of how an instance for the `SimpleWebApp` might look:
 
-```yaml title="my-web-app-claim.yaml"
+```yaml title="my-web-app-instance.yaml"
 apiVersion: kro.run/v1alpha1
 kind: SimpleWebApp
 metadata:

website/docs/docs/concepts/10-simple-schema.md

@@ -136,9 +136,9 @@ status:
 
 ## Default status fields
 
-**KRO** automatically injects two common fields into the status of all claims
+**KRO** automatically injects two common fields into the status of all instances
 generated from **ResourceGroups**: `conditions` and `state`. These fields
-provide essential information about the current status of the claim and its
+provide essential information about the current status of the instance and its
 associated resources.
 
 :::tip `conditions` and `state` are reserved words in the status section. If a
@@ -148,7 +148,7 @@ override them with its own values. :::
 ### 1. Conditions
 
 The `conditions` field is an array of condition objects, each representing a
-specific aspect of the claim's state. KRO automatically manages this field.
+specific aspect of the instance's state. KRO automatically manages this field.
 
 ```yaml
 status:
@@ -164,22 +164,22 @@ customTypes:
 
 Common condition types include:
 
-- `Ready`: Indicates whether the claim is fully reconciled and operational.
-- `Progressing`: Shows if the claim is in the process of reaching the desired
+- `Ready`: Indicates whether the instance is fully reconciled and operational.
+- `Progressing`: Shows if the instance is in the process of reaching the desired
   state.
-- `Degraded`: Signals that the claim is operational but not functioning
+- `Degraded`: Signals that the instance is operational but not functioning
   optimally.
 - `Error`: Indicates that an error has occurred during reconciliation.
 
 ### 2. State
 
-The `state` field provides a high-level summary of the claim's current status.
+The `state` field provides a high-level summary of the instance's current status.
 
 ```yaml
 status:
   state: string | enum="Ready,Progressing,Degraded,Error,Terminating,Unknown"
 ```
 
-> These default status fields are automatically added to every claim's status,
+> These default status fields are automatically added to every instance's status,
 > providing a consistent way to check the health and state of resources across
 > different **ResourceGroups**.

website/docs/docs/concepts/15-claims.md …bsite/docs/docs/concepts/15-instances.mdwebsite/docs/docs/concepts/15-claims.md renamed to website/docs/docs/concepts/15-instances.md website/docs/docs/concepts/15-claims.md renamed to website/docs/docs/concepts/15-instances.md

@@ -2,23 +2,23 @@
 sidebar_position: 15
 ---
 
-# 3. Claims
+# 3. Instances
 
-Claims are a fundamental concept in **KRO** that represent instances of
+Instances are a fundamental concept in **KRO** that represent instances of
 ResourceGroups. They define the desired state of a set of resources, which KRO
 continuously works to maintain.
 
-## What is a Claim?
+## What is an Instance?
 
-A Claim is a Kubernetes custom resource that:
+An Instance is a Kubernetes custom resource that:
 
 - References a specific ResourceGroup
 - Provides values for the parameters defined in the ResourceGroup
 - Represents the desired state of a set of Kubernetes resources
 
-## Anatomy of a Claim
+## Anatomy of an Instance
 
-Here's an example of a Claim for a `WebApplication` ResourceGroup:
+Here's an example of an Instance for a `WebApplication` ResourceGroup:
 
 ```yaml
 apiVersion: kro.run/v1alpha1
@@ -37,65 +37,65 @@ spec:
     LOG_LEVEL: debug
 ```
 
-:::tip The spec fields of a Claim correspond to the parameters defined in the
+:::tip The spec fields of an Instance correspond to the parameters defined in the
 ResourceGroup. :::
 
 ## The reconciliation loop
 
-KRO manages Claims through a continuous reconciliation process:
+KRO manages Instances through a continuous reconciliation process:
 
-- **Desired state detection**: KRO observes the Claim, which represents the
+- **Desired state detection**: KRO observes the Instance, which represents the
   desired state of resources.
 - **Current state assessment**: KRO talks to the api-server and checks the
-  current state of resources in the cluster related to the Claim.
+  current state of resources in the cluster related to the Instance.
 - **Difference identification**: Any differences between the desired state
-  (Claim) and the current state are identified.
+  (Instance) and the current state are identified.
 - **State Reconciliation**: KRO takes necessary actions to align the current
   state with the desired state. This may involve creating, updating, or deleting
   resources as needed.
-- **Status Updates**: The Claim's status is updated to reflect the current state
+- **Status Updates**: The Instance's status is updated to reflect the current state
   of reconciliation and any issues encountered.
 - **Continuous Loop**: This process repeats regularly, ensuring the cluster
-  state always converges towards the desired state defined in the Claim.
+  state always converges towards the desired state defined in the Instance.
 
 ## Advantages of declarative management [need better title]
 
 - **Declarative Management**: Users define what they want, not how to get there.
 - **Self-healing**: The system continuously works to maintain the desired state.
-- **Idempotency**: The same Claim always results in the same end state,
+- **Idempotency**: The same Instance always results in the same end state,
   regardless of the current state.
 - **Abstraction**: Complex resource relationships are managed behind the scenes.
 - **Consistency**: All resources for an application are managed as a unit.
-- **Auditability**: The Claim serves as a single source of truth for the
+- **Auditability**: The Instance serves as a single source of truth for the
   application's desired state.
 
 :::tip Best Practices
 
-- Treat claims as declarative definitions of your application's desired state.
-  Use version control for your Claims to track changes over time.
-- Leverage labels and annotations in Claims for organization and filtering.
-- Regularly review Claims to ensure they reflect current requirements.
+- Treat instances as declarative definitions of your application's desired state.
+  Use version control for your Instances to track changes over time.
+- Leverage labels and annotations in Instances for organization and filtering.
+- Regularly review Instances to ensure they reflect current requirements.
 - Use KRO's dry-run feature to preview reconciliation actions before applying
-  changes to Claims.
-- Monitor Claim statuses to understand the current state of your applications.
+  changes to Instances.
+- Monitor Instance statuses to understand the current state of your applications.
   :::
 
 ## Common Status Fields
 
-KRO automatically injects two common fields into the status of all claims:
+KRO automatically injects two common fields into the status of all instances:
 **Conditions** and **State**. These fields provide crucial information about the
-current status of the claim and its associated resources.
+current status of the instance and its associated resources.
 
 ### 1. Conditions
 
 Conditions are a standard Kubernetes concept that KRO leverages to provide
 detailed status information. Each condition represents a specific aspect of the
-claim's state. Common conditions include:
+instance's state. Common conditions include:
 
-- **Ready**: Indicates whether the claim is fully reconciled and operational.
-- **Progressing**: Shows if the claim is in the process of reaching the desired
+- **Ready**: Indicates whether the instance is fully reconciled and operational.
+- **Progressing**: Shows if the instance is in the process of reaching the desired
   state.
-- **Degraded**: Signals that the claim is operational but not functioning
+- **Degraded**: Signals that the instance is operational but not functioning
   optimally.
 - **Error**: Indicates that an error has occurred during reconciliation.
 
@@ -121,16 +121,16 @@ status:
 
 ### 2. State
 
-The State field provides a high-level summary of the claim's current status. It
+The State field provides a high-level summary of the instance's current status. It
 is typically one of the following values:
 
-- **Pending**: The claim is being processed, but resources are not yet fully
+- **Pending**: The instance is being processed, but resources are not yet fully
   created or configured.
-- **Running**: All resources are created and the claim is operational.
-- **Failed**: An error occurred and the claim could not be fully reconciled.
-- **Terminating**: The claim is in the process of being deleted.
-- **Degraded**: The claim is operational but not functioning optimally.
-- **Unknown**: The claim's status cannot be determined.
+- **Running**: All resources are created and the instance is operational.
+- **Failed**: An error occurred and the instance could not be fully reconciled.
+- **Terminating**: The instance is in the process of being deleted.
+- **Degraded**: The instance is operational but not functioning optimally.
+- **Unknown**: The instance's status cannot be determined.
 
 Example:
 
@@ -140,6 +140,6 @@ status:
 ```
 
 These common status fields provide users with a consistent and informative way
-to check the health and state of their claims across different ResourceGroups.
+to check the health and state of their instances across different ResourceGroups.
 They are essential for monitoring, troubleshooting, and automating operations
 based on the status of KRO-managed resources.

website/docs/docs/concepts/20-collections.md

@@ -59,9 +59,9 @@ based on the `podCount` parameter.
 2. **definition**: Defines the structure of each resource instance in the
    collection. The `${index}` variable ensures uniqueness of each resource.
 
-## Using Collections in Claims
+## Using Collections in Instances
 
-When creating a claim, users can specify the count for the collection:
+When creating an instance, users can specify the count for the collection:
 
 ```yaml
 apiVersion: kro.run/v1alpha1
@@ -73,7 +73,7 @@ spec:
   podCount: 3
 ```
 
-This claim will result in the creation of three Postgres Pods named
+This instance will result in the creation of three Postgres Pods named
 `production-db-node-0`, `production-db-node-1`, and `production-db-node-2`.
 
 ## Deployment Strategy

website/docs/docs/getting-started/02-deploy-a-resource-group.md

@@ -92,11 +92,11 @@ spec:
    deployment-service                     v1alpha1     DeploymentService   ACTIVE   16m
    ```
 
-4. **Install a resource group claim**: Create a claim for the resource group you
-   just deployed. Claims are used to define the desired state of the resources
+4. **Install a resource group instance**: Create an instance for the resource group you
+   just deployed. Instances are used to define the desired state of the resources
    in the ResourceGroup.
 
-   Here's an example of a Claim for the `EKSCluster` ResourceGroup:
+   Here's an example of an Instance for the `EKSCluster` ResourceGroup:
 
    ```yaml
    apiVersion: kro.run/v1alpha1
@@ -107,5 +107,5 @@ spec:
      name: app1
    ```
 
-   The spec fields of a Claim correspond to the parameters defined in the
+   The spec fields of an Instance correspond to the parameters defined in the
    ResourceGroup.