Merge branch 'selhorn-inv-objects' into 'master'

Edited for style and clarity

See merge request gitlab-org/gitlab!81588

doc/user/infrastructure/clusters/deploy/inventory_object.md

@@ -4,66 +4,74 @@ group: Configure
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Inventory object **(PREMIUM)**
+# Tracking cluster resources managed by GitLab **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332227) in GitLab 14.0.
 
-An inventory object is a `ConfigMap` object for keeping track of the set of objects applied to a cluster.
-When you remove objects from a manifest repository, the agent uses a corresponding inventory object to
-prune (delete) objects from the cluster.
+GitLab uses an inventory object to track the resources you deploy to your cluster.
+The inventory object is a `ConfigMap` that contains a list of controlled objects.
+The managed resources use the `cli-utils.sigs.k8s.io/inventory-id` annotation.
 
-The agent creates an inventory object for each manifest project specified in the
-`gitops.manifest_projects` configuration section. The inventory object has to be stored somewhere in the cluster.
-The default behavior is:
+## Default location of the inventory object
 
-- The `namespace` used comes from `gitops.manifest_projects[].default_namespace`. If you don't specify this parameter
-  explicitly, the inventory object is stored in the `default` namespace.
-- The `name` is generated from the numeric project ID of the manifest project and the numeric agent ID.
+In the agent configuration file, you specify a list of projects. For example:
 
-  This way, the agent constructs the name and location where the inventory object is
-  stored in the cluster.
+```yaml
+gitops:
+  manifest_projects:
+  - id: gitlab-org/cluster-integration/gitlab-agent
+    default_namespace: my-ns
+```
 
-The agent cannot locate the existing inventory object if you:
+The agent creates an inventory object for every item in the `manifest_projects` list. 
+The inventory object is stored in the namespace you specify for `default_namespace`.
 
-- Change `gitops.manifest_projects[].default_namespace` parameter.
-- Move manifests into another project.
+The name and location of the inventory object is based on:
 
-## Inventory object template
+- The `default_namespace`. If you don't specify this parameter,
+  the inventory object is stored in the `default` namespace.
+- The `name`, which is the ID of the project with the manifest and the ID of the agent.
 
-The inventory object template is a `ConfigMap` object that allows you to configure the namespace and the name of the inventory
-object. Store this template with manifest files as a single logical group.
+WARNING:
+The agent cannot locate the existing inventory object if you change
+the `default_namespace` parameter or move manifests to another project.
 
-Example inventory object template:
+## Change the location of the inventory object
 
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
+You can configure the namespace and the name of the inventory object.
+This action changes the location of the object in the cluster.
+
+1. Create an inventory object template, which is a `ConfigMap` object.
+   For example:
+
+   ```yaml
+   apiVersion: v1
+   kind: ConfigMap
+   metadata:
      name: unique-name-for-the-inventory
      namespace: my-project-namespace
      labels:
        cli-utils.sigs.k8s.io/inventory-id: unique-name-for-the-inventory
-```
+   ```
+
+1. Specify a `namespace` and `name`. Ensure that the `name` is unique so it doesn't conflict with other
+   inventory objects in the same namespace in the future.
+1. Ensure the value for `cli-utils.sigs.k8s.io/inventory-id` is unique. This value is used for objects
+   tracked by this inventory object. Their `config.k8s.io/owning-inventory` annotation is set to this value.
+   
+   The value doesn't have to match the `name` but it's convenient to set them to the same value.
+
+1. Save the file with the manifest files as a single logical group.
 
-- The `namespace` and `name` fields configure where the real inventory object is created.
-- The `cli-utils.sigs.k8s.io/inventory-id` label with its corresponding value is set on the inventory object, created
-  from this template. Make sure that the value is unique (for example, a string of random characters) and doesn't clash
-  with any existing or future inventory object templates.
-- Objects tracked by this inventory object have the `config.k8s.io/owning-inventory` annotation set to the value of
-  the `cli-utils.sigs.k8s.io/inventory-id` label.
-- The label's value doesn't have to match the `name` but it's convenient to have them set to the same value.
-- Make sure that the `name` is unique so that it doesn't conflict with another inventory object in the same
-  namespace in the future.
+## `inventory_policy` options
 
-## Using GitOps with pre-existing Kubernetes objects
+Sometimes your manifest changes affect resources that aren't tracked by the GitLab inventory object.
 
-The agent treats manifest files in the manifest repository as the source of truth. When it applies
-objects from the files to the cluster, it tracks them in an inventory object. If an object already exists,
-The agent behaves differently based on the `gitops.manifest_projects[].inventory_policy` configuration.
-Check the table below with the available options and when to use them.
+To change how the agent behaves when it overwrites existing and previously untracked resources,
+change the `inventory_policy` value.
 
 `inventory_policy` value | Description                                                                                 |
 ------------------------ | ------------------------------------------------------------------------------------------- |
-`must_match`             | This is the default policy. A live object must have the `config.k8s.io/owning-inventory` annotation set to the same value as the `cli-utils.sigs.k8s.io/inventory-id` label on the corresponding inventory object to be updated. Object is not updated and an error is reported if the values don't match or the object doesn't have the annotation. |
-`adopt_if_no_inventory`  | This mode allows to "adopt" an object if it doesn't have the `config.k8s.io/owning-inventory` annotation. Use this mode if you want to start managing existing objects using the GitOps feature. Once all objects have been "adopted", we recommend you to put the setting back into the default `must_match` mode to avoid any unexpected adoptions. |
-`adopt_all`              | This mode allows to "adopt" an object even if it has the `config.k8s.io/owning-inventory` annotation set to a different value. This mode can be useful if you want to migrate a set of objects from one agent to another one or from some other tool to the agent. Once all objects have been "adopted", we recommend you to put the setting back into the default `must_match` mode to avoid any unexpected adoptions. |
+`must_match`             | The default policy. To be updated, a live object must have the `config.k8s.io/owning-inventory` annotation set to the same value as the `cli-utils.sigs.k8s.io/inventory-id` label on the corresponding inventory object. If the values don't match or the object doesn't have the annotation, the object is not updated and an error is reported. |
+`adopt_if_no_inventory`  | Adopt an object if it doesn't have the `config.k8s.io/owning-inventory` annotation. Use this mode if you want to start managing existing objects by using the GitOps feature. To avoid unexpected adoptions, after all objects have been adopted, put the setting back to the default `must_match` mode. |
+`adopt_all`              | Adopt an object even if it has the `config.k8s.io/owning-inventory` annotation set to a different value. Use this mode if you want to migrate a set of objects from one agent to another, or from some other tool to the agent. To avoid unexpected adoptions, after all objects have been adopted, put the setting back to the default `must_match` mode. |