Discussion around a Conditions api abstraction

[scrocquesel]

This is about managing primary resource conditions not the dependent one.

Like with GenerationAware, there could be a ConditionsSetAwareStatus.

interface ConditionsSetAwareStatus {
    List<Condition> getConditions();
    void setConditions(List<Condition> conditions);
}

The idea is to have a manager for a ConditionType which is basically a wrapper around the condition property. The ConditionType will explicit a Ready condition type and dependent conditions type. When all dependent conditions are True, the Ready is True, False otherwise.

public class ConditionTypeSet
{
   private String readyConditionType;
   private String[] dependentsConditionType;
}

A manager would then use this ConditionTypeSet configuration and allow to manage the list of condition with a set of methods

public interface ConditionManager
{
    // add all conditions defined in the conditionSet
    Initialize();
   // set a condition to True and set the ready condition to True if all depedents are True
    SetTrue(String conditionType);
   // set a condition to False and set theready condition to False 
    SetFalse(String conditionType);
   // some override of True/False to pass reason/message

   // some other method to get the Ready Condition, check wether Ready is True, etc... to allow for logging for eg
}

public class ConditionManagerImpl implements ConditionManager
{
    public ConditionManagerImpl (ConditionSet set, ConditionsSetAwareStatus status);
}

I think it can be used wisely with dependents. With the exemple given in #850, a status could be

conditions:
  - lastTransitionTime: 2022-02-04T00:00:00Z
    type: dep1
    status: TRUE
  - lastTransitionTime: 2022-02-04T00:01:00Z
    type: ser1
    status: TRUE
  - lastTransitionTime: 2022-02-04T00:02:00Z
    type: OtherResource
    status: FALSE
  - lastTransitionTime: 2022-02-04T00:02:00Z
    type: READY
    status: FALSE

I omit reason/message but they may be valued the same way.

I don't know how the ConditionTypeSet should be exposed. Should it be a getter on ConditionsSetAwareStatus. And maybe the Manager could then be made available from the context if the Resource implements the interface.

What do you think ?

[csviri]

thx for the issue @scrocquesel .
After the release of MVP the idea is indeed to go further and make next steps to automatically handle workflows. So I think managing conditions could be one of the features there. So we can revisit it that time.

[csviri]

FYI good article: https://maelvls.dev/kubernetes-conditions/

[csviri]

I don't see how this could be done elegantly in a generic way. If you have any idea pls let us know, closing for now.