Update status docs (#273)

* Add notes on HelmOps status

HelmOps have their own status fields, with information propagated from
various sources.

* Update resources lists

Resource keys no longer appear in bundles, yet both GitRepos and HelmOps
now share resources lists sourced from bundle deployments.

docs/helm-ops.md

@@ -83,3 +83,19 @@ When polling is enabled, Fleet does the following at the configured interval:
         * with `true` if polling was successful
         * with `false` with an error if a failure happened
     * updating the `Last Polling Time` field to the starting time of the last polling attempt, even if it failed.
+
+## Status updates
+
+Creating a HelmOp resource leads to a bundle being created, if Helm options are valid and a chart version can be found.
+
+The status of that bundle will evolve over time, as bundle deployments are created from it, for each target cluster, and
+as these bundle deployments' statuses themselves evolve and are propagated back to the bundle.
+
+Fleet propagates updates from the bundle status to the status of the HelmOp resource itself.
+This includes:
+* a display status with a summary, expected and ready cluster counts
+* conditions providing more information about the state of the resource, whether it is valid and its deployments are
+ready
+* resource counts by status
+
+See [status fields](./ref-status-fields.md) for more details on resource counts and conditions.

docs/ref-status-fields.md

@@ -48,17 +48,30 @@ Clusters and Bundles have different states in each phase of applying Bundles.
 
 **Stalled**: for errors
 
+## HelmOp Conditions
+
+**Ready**: All bundle deployments are ready
+
+**Accepted**: The HelmOp is able to properly manage deployments to target clusters. May be false if:
+* Helm options are invalid
+* a chart version cannot be resolved from those options
+* an issue occurred when scheduling a polling job
+
+**Polled**: `True` if polling is enabled and the last polling attempt was successful, `False` otherwise.
+If polling is enabled, a `False` condition will contain an error message explaining the reason for the polling failure.
+
 ## Resources List
 
-The resources lists contain the deployed resources, categorized under `Bundles` and `GitRepos`.
+The resources lists contain the resources deployed to target clusters, categorized under `GitRepos` and `HelmOps`.
-
-### Bundles
-
-The deployed resources within bundles can be found in `status.ResourceKey`. This key represents the actual resources deployed via `bundleDeployments`.
 
 ### GitRepos
 
-Similar to bundles, the deployed resources in `GitRepos` are listed in `status.Resources`. This list is also derived from `bundleDeployments`.
+The deployed resources are listed in `GitRepos` in `status.Resources`. This list is derived from `bundleDeployments`.
+
+### HelmOps
+
+Similarly to what happens for `GitRepos`, the deployed resources are listed in `HelmOps` in `status.Resources`.
+This list is derived from `bundleDeployments`.
 
 ## Resource Counts
 
@@ -69,6 +82,10 @@ This shows how resource counts are propagated from one resource to another:
 
 The `status.ResourceCounts` list for GitRepos is derived from `bundleDeployments`.
 
+### HelmOps
+
+The `status.ResourceCounts` list for HelmOps is derived from `bundleDeployments`.
+
 ### Clusters
 
 In Clusters, the `status.ResourceCounts` list is derived from GitRepos.