Use conditions instead of phase

[gaocegege]

Some resources in the v1 API contain fields called phase, and associated message, reason, and other status fields. The pattern of using phase is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted system-design principles and hampered evolution, since adding new enum values breaks backward compatibility. Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See #7856 for more details and discussion.

https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#typical-status-properties

kubernetes suggests us to use conditions instead of phase, now the code uses phase heavily, I think we should have a plan to deprecate phase.

/cc @DjangoPeng

label/enhancement

[jlewi]

Makes sense to me.

Should we wait until #206 is fixed to fix this?

/cc @wackxu

[gaocegege]

I think so 🤔

We could design the correspondence between phase and conditions first and the implementation may be blocked until #215 merged.

[DjangoPeng]

Agree with @gaocegege. A slight question here: what's the design purpose of ReplicaStatuses and ReplicasStates here?

[jlewi]

ReplicaStatuses and ReplicaStates provide information about each replica. Not all replicas might be in the same state; some might be crashing for example. So ReplicaStatuses provide finer grained information then just the overall status of the job.

[gaocegege]

I think we could close the issue since v1alpha2 already implemented it.