Conditions Object Design

[jonathan-innis]

Because I realize that we could improve our Conditions object, I am proposing that we remove the Deploy condition and put all of our pertinent information in the Ready condition. Then, to get better visibility into the workflows, we create Workflow and ReverseWorkflow conditions to capture the status of the underlying Argo workflows

Ready
------
Progressing -> AppGroup is still creating/updating (this could also mean that the workflow is progressing)
Succeeded -> AppGroup has succeeded and all parts of the DAG have been rolled out
Failed -> AppGroup controller failed to Create/Update within the controller logic
RollingBack -> AppGroup is rolling the previous release back
Terminating -> AppGroup is terminating the release and calling the workflow reversal

WorkflowDone
------
Running
Succeeded
Failed

ReverseWorkflowDone
-------
Running
Succeeded
Failed

[jonathan-innis]

@nitishm @mgl1969 Please let me know if these conditions make sense and if we should change/add/delete anything to improve visibility and clarity

[nitishm]

Why are we using the Done suffix? Can we just say Workflow and ReverseWorkflow?

[jonathan-innis]

My understanding of how Conditions are supposed to be written is that they are an answer to the question Is <object>....?, meaning for Ready the question is Is ApplicationGroup Ready?. The reason for this is that the status in the conditions object either returns True or False answering the above question. Just having Workflow or ReverseWorkflow doesn't make sense in this context