From 84837a23a75a8f1d72ad2abc66f2ec7e1641c4f9 Mon Sep 17 00:00:00 2001 From: Chris Doherty Date: Fri, 24 Feb 2023 17:17:04 -0600 Subject: [PATCH] Add rationale for not using conditions Signed-off-by: Chris Doherty --- design/14_tinkerbell_crd_refactor/proposal.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/design/14_tinkerbell_crd_refactor/proposal.md b/design/14_tinkerbell_crd_refactor/proposal.md index 5f58ae9..673e5cf 100644 --- a/design/14_tinkerbell_crd_refactor/proposal.md +++ b/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.