Change `status.conditions` to the Kubernetes format

[tpiperatgod]

The current conditions field looks like the following:

type ResourceCondition struct {
	Condition ResourceConditionType  `json:"condition,omitempty"`
	Status    metav1.ConditionStatus `json:"status,omitempty"`
	Action    ReconcileAction        `json:"action,omitempty"`
}

If we use Kubernetes-format Conditions, we can carry some textual information through the message and reason fields that can help improve the usability of Function Mesh

[tpiperatgod]

Overview

The current Operator reconciliation workflow is to observe the maintained resource and update its status first, and then determine whether to reconcile the resource based on the status, and update its status after reconciliation.

We can see that the ability to effectively and accurately compare the state of resources in the cluster with the desired resource state is key to determining whether we need to make reconciliation or not.

This requires us to provide a reasonable set of judgment criteria which should be

• concise and effective
• accurate and with robustness

On the other hand, we can use Kubernetes' native Condition as the CRD.Status.Conditions format. The benefits are as follows.

• Provides seamless compatibility with Condition information when integrating upwards into some application platform frameworks
• Condition can be handled using the Kubernetes native function tools
• Native Condition provides fields such as reason, message, observedGeneration, etc. to enrich the information in CRD

Proposal

The proposal is as follows.

• Changing the style of CRD.Status

  The current CRD.Status style is as follows.

  // The `Status` of a given `Condition` and the `Action` needed to reach the `Status`
  type ResourceCondition struct {
  	Condition ResourceConditionType  `json:"condition,omitempty"`
  	Status    metav1.ConditionStatus `json:"status,omitempty"`
  	Action    ReconcileAction        `json:"action,omitempty"`
  }
  
  // FunctionStatus defines the observed state of Function
  type FunctionStatus struct {
  	// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
  	// Important: Run "make" to regenerate code after modifying this file
  	Conditions         map[Component]ResourceCondition `json:"conditions"`
  	Replicas           int32                           `json:"replicas"`
  	Selector           string                          `json:"selector"`
  	ObservedGeneration int64                           `json:"observedGeneration,omitempty"`
  }
  

  Where the Conditions field will be changed from map[Component]ResourceCondition to []metav1.Condition .

  Because the ObservedGeneration field is already present in Condition, we can remove the CRD.Status.ObservedGeneration

  The expected style is as follows.

  // FunctionStatus defines the observed state of Function
  type FunctionStatus struct {
  	// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
  	// Important: Run "make" to regenerate code after modifying this file
  	Conditions            []metav1.Condition  `json:"conditions"`
  	Replicas              int32               `json:"replicas"`
  	Selector              string              `json:"selector"`
  	ComponentsGenerations map[Component]int64 `json:"componentsGenerations,omitempty"`
  }
  

  For a sub-component, the followings are added.

  • condition type, e.g. sub-component is StatefulSet, i.e. StatefulSetReady
  • condition reason, which should normally have:
    • ErrorCreating<Component>, which means the resource creation failed
    • <Component>Error, indicating an exception during the observe phase
    • <Component>IsReady, which means the resource is ready

  Generic Condition content.

  • condition type:
    • Ready, means the CRD is ready will be determined based on the condition type of the sub-components
    • Error, means the CRD is abnormal or not ready
  • condition reason:
    • PendingCreation, means the resource is pending to be created And in ComponentsGenerations the latest ObservedGeneration of sub-component is stored.

• ObservedGenerations of sub-components are recorded in CRD.Status, and the ObservedGeneration is compared with the actual value of generation of sub-component in the cluster to determine whether the resource needs to be updated, according to the following rules.

  • When the latest ObservedGeneration of a sub-component is recorded in CRD.Status and the value is not equal to the actual value of generation of the sub-component in the cluster, it is determined that the sub-component needs to be reconciled

  After reconciling a sub-component, update the actual value of generation of the sub—component in the cluster as the ObservedGeneration

Case

The following assumes that the current CRD maintains one sub-component (StatefulSet) and demonstrates the full Operator process.