Add rationale for not using conditions

Signed-off-by: Chris Doherty <[email protected]>

design/14_tinkerbell_crd_refactor/proposal.md

@@ -20,6 +20,7 @@
   - [Migrating from v1alpha1 to v1alpha2](#migrating-from-v1alpha1-to-v1alpha2)
   - [Rationale](#rationale)
     - [Comparison with existing resources](#comparison-with-existing-resources)
+    - [Use of explicit `State`, `Reason` and `Message` fields vs conditions](#use-of-explicit-state-reason-and-message-fields-vs-conditions)
   - [Implementation Plan](#implementation-plan)
   - [Future Work](#future-work)
 
@@ -486,6 +487,12 @@ Reasons for failures have been introduced as a core concept, via the `Reason` fi
 
 The `Workflow` provides a `TemplateData` field that can be used to inject arbitrary data into templates. This facilitates users wanting to model variable data on `Template`s that has per-`Workflow` values.
 
+### Use of explicit `State`, `Reason` and `Message` fields vs conditions
+
+Workflows operate as a state machine (detailed in [Workflow state transition](#workflow-state-transition)). [Conditions represent observations](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) about a resource and are not state machines in and of themeselves. Conditions should generally be complimentary to existing resource information, not replace it. Conditions in the Kubernetes API have a [well defined set of fields](https://github.com/kubernetes/community/blob/4c9ef2d/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties). Some tools such as [Cluster API](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20200506-conditions.md) break away by defining their own condition expectations.
+
+For these reasons, we think it would be more appropriate to have explicit fields to represent state and consider a separate conditions proposal that compliments the CRDs.
+
 ## Implementation Plan
 
 1. All services that have unreleased changes will be released under a new version. This provides a baseline of functional services that can be used in the Tinkerbell Helm charts.