Update docs to use KRO instead

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

@@ -4,14 +4,15 @@ sidebar_position: 1
 
 # 1. ResourceGroups
 
-**ResourceGroups** are the fundamental building blocks in Symphony. They
-provide a way to define, organize, and manage sets of related Kubernetes
-resources as a single, reusable unit.
+**ResourceGroups** are the fundamental building blocks in KRO. They provide a
+way to define, organize, and manage sets of related Kubernetes resources as a
+single, reusable unit.
 
 ## What is a **ResourceGroup**?
 
 A **ResourceGroup** is a custom resource that serves as a blueprint for creating
 and managing a collection of Kubernetes resources. It allows you to:
+
 - Define multiple resources in a single, cohesive unit
 - Establish relationships and dependencies between resources
 - Create high-level abstractions of complex Kubernetes configurations
@@ -20,19 +21,21 @@ and managing a collection of Kubernetes resources. It allows you to:
 ## Anatomy of a **ResourceGroup**
 
 A **ResourceGroup**, like any Kubernetes resource, consists of three main parts:
+
 1. **Metadata**: Name, namespace, labels, etc.
 2. **Spec**: Defines the structure and properties of the ResourceGroup
 3. **Status**: Reflects the current state of the ResourceGroup
 
 The `spec` section of a ResourceGroup typically includes:
+
 - **Parameters**: Define the customizable aspects of the ResourceGroup
 - **Resources**: Specify the Kubernetes resources to be created
 - The **kind** and **apiVersion** fields within the spec define the CRD that
-  will be generated for this ResourceGroup.
-  Here's a simple example of a ResourceGroup:
+  will be generated for this ResourceGroup. Here's a simple example of a
+  ResourceGroup:
 
 ```yaml text title="simple-web-app.yaml"
-apiVersion: symphony.k8s.aws/v1
+apiVersion: kro.run/v1
 kind: ResourceGroup
 metadata:
   name: simple-web-app
@@ -77,59 +80,58 @@ spec:
               targetPort: 80
 ```
 
-In this example, the **ResourceGroup** defines a simple web application with
-a Deployment and a Service. The appName, image, and replicas are
-parameters that can be set when instantiating this ResourceGroup.
+In this example, the **ResourceGroup** defines a simple web application with a
+Deployment and a Service. The appName, image, and replicas are parameters that
+can be set when instantiating this ResourceGroup.
 
 ## **ResourceGroup** Processing
 
-When a **ResourceGroup** is submitted to the Kubernetes API server, the 
-Symphony controller processes it as follows:
+When a **ResourceGroup** is submitted to the Kubernetes API server, the KRO
+controller processes it as follows:
+
+1. **Formal Verification**: The controller performs a comprehensive analysis of
+   the ResourceGroup definition. This includes:
 
-1. **Formal Verification**: The controller performs a comprehensive analysis 
-   of the ResourceGroup definition. This includes:
    - **Syntax checking**: Ensuring all fields are correctly formatted.
-   - **Type checking**: Validating that parameter types match their 
-     definitions.
-   - **Semantic validation**: Verifying that resource relationships and 
+   - **Type checking**: Validating that parameter types match their definitions.
+   - **Semantic validation**: Verifying that resource relationships and
      dependencies are logically sound.
-   - **Dry-run validation**: Simulating the creation of resources to detect 
+   - **Dry-run validation**: Simulating the creation of resources to detect
      potential issues.
 
-2. **CRD Generation**: The controller automatically generates a new **Custom 
-   Resource Definition (CRD)** based on the ResourceGroup's specification. 
-   This CRD represents the type for instances of this ResourceGroup.
+2. **CRD Generation**: The controller automatically generates a new **Custom
+   Resource Definition (CRD)** based on the ResourceGroup's specification. This
+   CRD represents the type for instances of this ResourceGroup.
 
-3. **CRD Registration**: It registers the newly generated CRD with the 
+3. **CRD Registration**: It registers the newly generated CRD with the
    Kubernetes API server, making it available for use in the cluster.
 
-4. **Micro-Controller Deployment**: Symphony deploys a dedicated 
-   micro-controller for this ResourceGroup. This micro-controller will 
-   listen for **"claim" 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.
+4. **Micro-Controller Deployment**: KRO deploys a dedicated micro-controller for
+   this ResourceGroup. This micro-controller will listen for **"claim"
+   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.
 
-5. **Status Update**: The controller updates the status of the ResourceGroup 
-   to reflect that the corresponding CRD has been created and registered.
+5. **Status Update**: The controller updates the status of the ResourceGroup to
+   reflect that the corresponding CRD has been created and registered.
 
-For example, given our `simple-web-app` ResourceGroup, the controller 
-would create and register a CRD named `SimpleWebApps` (plural form of the 
-ResourceGroup name). This CRD defines the structure for creating instances 
-of the web application with customizable parameters. The deployed 
-micro-controller would then manage all **SimpleWebApps instances**, creating 
-and managing the associated **Deployments** and **Services** as defined in the 
-ResourceGroup.
+For example, given our `simple-web-app` ResourceGroup, the controller would
+create and register a CRD named `SimpleWebApps` (plural form of the
+ResourceGroup name). This CRD defines the structure for creating instances of
+the web application with customizable parameters. The deployed micro-controller
+would then manage all **SimpleWebApps instances**, creating and managing the
+associated **Deployments** and **Services** as defined in the ResourceGroup.
 
-The Symphony controller continues to monitor the **ResourceGroup** for any 
+The **KRO** controller continues to monitor the **ResourceGroup** for any
 changes, updating the corresponding CRD and micro-controller as necessary.
 
 ## **ResourceGroup** Claim 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:
+After the **ResourceGroup** is processed, users can create instances of it.
+Here's an example of how a claim for the `SimpleWebApp` might look:
 
 ```yaml title="my-web-app-claim.yaml"
-apiVersion: symphony.k8s.aws/v1alpha1
+apiVersion: kro.run/v1alpha1
 kind: SimpleWebApp
 metadata:
   name: my-web-app
@@ -140,4 +142,4 @@ spec:
 ```
 
 In the next section, we'll explore the `parameters` and `resources` sections of
-a **ResourceGroup** in more detail.
+a **ResourceGroup** in more detail.

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

@@ -4,14 +4,14 @@ sidebar_position: 2
 
 # 2. Simple Schema
 
-Symphony's Simple Schema provides a powerful yet intuitive way to define the structure
-of your ResourceGroup. Here is comprehensive example:
+KRO's Simple Schema provides a powerful yet intuitive way to define the
+structure of your ResourceGroup. Here is comprehensive example:
 
 ```yaml
-apiVersion: symphony.k8s.aws/v1alpha1
+apiVersion: kro.run/v1alpha1
 kind: ResourceGroup
 metadata:
-  name: webapplication.symphony.k8s.aws
+  name: web-application
 spec:
   apiVersion: v1alpha1
   kind: WebApplication
@@ -40,6 +40,7 @@ spec:
 ### 1. Spec Field Definition
 
 #### Basic Types
+
 - `string`: Basic string type
 - `integer`: Whole number
 - `boolean`: True/False value
@@ -53,11 +54,11 @@ age: integer
 
 #### Structure types
 
-Structure types or object types are defined by specifying the fields within the object. The fields
-can be of basic types or other structure types.
+Structure types or object types are defined by specifying the fields within the
+object. The fields can be of basic types or other structure types.
 
-for example to define a structure type for a person with name and age fields, you can define it as
-follows:
+for example to define a structure type for a person with name and age fields,
+you can define it as follows:
 
 ```yaml
 person:
@@ -68,34 +69,40 @@ person:
 #### Map Types
 
 - Arrays: Denoted by `[]`, e.g., `'[]string'`
-- Maps: Denoted by `map[keyType]valueType`, e.g., `'map[string]string'` and `'map[string]Person'`
+- Maps: Denoted by `map[keyType]valueType`, e.g., `'map[string]string'` and
+  `'map[string]Person'`
 
 ### 2. Validation and Documentation Markers
 
-In addition to the type, fields can also have markers for validation, documentation and
-other purposes that are OpenAPISchema compatible.
+In addition to the type, fields can also have markers for validation,
+documentation and other purposes that are OpenAPISchema compatible.
 
-For example to define a field that is required, has a default value and a description, you can
-define it as follows:
+For example to define a field that is required, has a default value and a
+description, you can define it as follows:
 
 ```yaml
 person:
-  name: string | required=true default="Kylian Mbappé" description="Name of the person"
+  name:
+    string | required=true default="Kylian Mbappé" description="Name of the
+    person"
 ```
 
 Currently supported markers include:
+
 - `required=true`: Field must be provided
 - `default=value`: Default value if not provided
 - `description="..."`: Provides documentation for the field
 - `enum="value1,value2,..."`: Restricts to a set of values **NOT IMPLEMENTED**
-- `minimum=value` and `maximum=value`: For numeric constraints **NOT IMPLEMENTED**
+- `minimum=value` and `maximum=value`: For numeric constraints **NOT
+  IMPLEMENTED**
 
 ### 3. Custom Types Definition
 
-Custom types are defined in the `customTypes` section, allowing for reusable complex
-structures. They can be referenced by name in the spec or status fields.
+Custom types are defined in the `customTypes` section, allowing for reusable
+complex structures. They can be referenced by name in the spec or status fields.
 
 Example:
+
 ```yaml
 customTypes:
   ConfigType:
@@ -107,48 +114,45 @@ spec:
 
 ### 4. Status Field Definition
 
-Status fields are defined similarly to spec fields and can include validation and documentation
-markers. However on top of that, status fields can also include value markers:
+Status fields are defined similarly to spec fields and can include validation
+and documentation markers. However on top of that, status fields can also
+include value markers:
 
 #### Value Marker **NOT IMPLEMENTED**
 
-- `value="${resource.status.field}"`: Specifies that this field's value should be dynamically
-  obtained from another resource. The value is a CEL expression that is validated at ResourceGroup
-  processing time and evaluated at runtime.
+- `value="${resource.status.field}"`: Specifies that this field's value should
+  be dynamically obtained from another resource. The value is a CEL expression
+  that is validated at ResourceGroup processing time and evaluated at runtime.
 
-:::tip
-  Note that the value marker is a symphony extension to the OpenAPISchema and is not part of the
-  official OpenAPISchema specification.
-:::
+:::tip Note that the value marker is a KRO extension to the OpenAPISchema and is
+not part of the official OpenAPISchema specification. :::
 
 Example:
+
 ```yaml
 status:
   url: string | value="${service.status.loadBalancer.ingress[0].hostname}"
 ```
 
 ## Default status fields
 
-Symphony automatically injects two common fields into the status of all claims
-generated from **ResourceGroups**: `conditions` and `state`. These fields provide
-essential information about the current status of the claim and its associated
-resources.
-
-:::tip
-`conditions` and `state` are reserved words in the status
-section. If a user defines these fields in their **ResourceGroup**'s status schema,
-Symphony will override them with its own values.
-:::
+**KRO** automatically injects two common fields into the status of all claims
+generated from **ResourceGroups**: `conditions` and `state`. These fields
+provide essential information about the current status of the claim and its
+associated resources.
 
+:::tip `conditions` and `state` are reserved words in the status section. If a
+user defines these fields in their **ResourceGroup**'s status schema, KRO will
+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. Symphony automatically manages this field.
+specific aspect of the claim's state. KRO automatically manages this field.
 
 ```yaml
 status:
-  conditions: '[]condition'
+  conditions: "[]condition"
 customTypes:
   condition:
     type: string
@@ -159,9 +163,12 @@ 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 state.
-- `Degraded`: Signals that the claim is operational but not functioning optimally.
+- `Progressing`: Shows if the claim is in the process of reaching the desired
+  state.
+- `Degraded`: Signals that the claim is operational but not functioning
+  optimally.
 - `Error`: Indicates that an error has occurred during reconciliation.
 
 ### 2. State
@@ -174,5 +181,5 @@ status:
 ```
 
 > These default status fields are automatically added to every claim's status,
-providing a consistent way to check the health and state of resources across
-different **ResourceGroups**.
+> providing a consistent way to check the health and state of resources across
+> different **ResourceGroups**.