Rename JobSet status to Complete

[andreyvelich]

What would you like to be added:

@tenzen-y and I noticed that JobSet uses the Completed status rather than Complete.

However, Kubernetes Job uses the Complete status.
We also use the Complete status in the TrainJob to be consistent with the Batch/Job.

Additionally, I would propose that we rename Succeeded ReplicatedJobStatus to Complete, since there is no such status as Succeeded on the Job level. E.g.

replicatedJobStatus:
 - name: Job-A
  complete: 1
  failed: 0
    ...

Any thoughts @tenzen-y @kannon92 @danielvegamyhre @ahg-g ?

Why is this needed:

Being consistent across various Kubernetes resources.

This enhancement requires the following artifacts:

• Design doc
• API change
• Docs update

The artifacts should be linked in subsequent comments.

[googs1025]

it makes sense to me, I am willing to make this change. 🤔

[kannon92]

I tend to prefer "Succeeded" as it matches terminal states like 'Suspended' and 'Failed'. I do think it unfortunate that Job uses complete.

I don't really have a strong feeling about the renaming but I think this should be considered a breaking change so we should probably introduce "Complete" and leave "Succeeded" as deprecated. And then maybe in a release or two we can drop "Succeeded".

But I don't really feel that this renaming is worth the effort.

[andreyvelich]

I tend to prefer "Succeeded"

We discussed before with @tenzen-y, that it is tricky to define what does Succeeded mean for Job or JobSet given all of the Success and Failure policies that we have: kubeflow/training-operator#2298.

But I don't really feel that this renaming is worth the effort.

I feel like if we want to be consistent across all of our Batch Jobs CRDs, we should not introduce such terminology for the Job status.

Especially, if we want to match our Jobs counters with the actual status of the Job: https://github.com/kubernetes-sigs/jobset/blob/main/api/jobset/v1alpha2/jobset_types.go#L180.

[ahg-g]

This is practically part of the api now, so we need to bump the api version for this change, we could do this only when we graduate to v1

[andreyvelich]

This is practically part of the api now, so we need to bump the api version for this change, we could do this only when we graduate to v1

I am ok to introduce this change in the newer version of API if we all agree with that naming.
E.g. we can create v1alpha3 or v1beta1 API for JobSet.

[tenzen-y]

This is practically part of the api now, so we need to bump the api version for this change, we could do this only when we graduate to v1

I am ok to introduce this change in the newer version of API if we all agree with that naming. E.g. we can create v1alpha3 or v1beta1 API for JobSet.

AFAIK, JobSet next API version is v1, right? @ahg-g @kannon92

[ahg-g]

I think we need to have one more v1alpha2 release to ensure we have at least one release with the old StartupPolicy api and the new DependsOn one before deprecating it.