Revisit the documentation with respect to the concepts of Job and Workload

[mimowo]

/kind documentation

What would you like to be added:

Historically Kueue was only for "Jobs", so there was a clear 1:1 mapping between user's Job (and thus user's workload) and Kueue Workload API. This is no longer the case since:

• we support serving workloads too (Deployments, StatefulSets, LWS)
• for some user workloads Kueue creates multiple Workload API objects (like for Deployment or LWS), this is by design to allow scaling which is very important for serving workloads.

To reflect that I would like to revisit the documentation, specifically:

• change Jobs to Workload in most places of the documentation
• add a note to the documentation that historically Kueue supported Jobs but we not support serving workloads too, so we say Workload
• when we want to refer to the internal Kueue Workload API object in the documentation, to make it non-ambigous I would suggest consistent naming like "Kueue's Workload API", "Kueue's Workload API object" or "internal Workload API object" (we can decide during review about the specific term.

Why is this needed:

To avoid confusions which has already been encountered a couple of times.

Completion requirements:

This enhancement requires the following artifacts:

• Docs update

The artifacts should be linked in subsequent comments.

[tenzen-y]

I guess that we want to consider what is appropriate name instead of Jobs something like Task? Workload (this conflict with Workload API)? Application?

[mimowo]

cc @dgrove-oss

[mimowo]

I guess that we want to consider what is appropriate name instead of Jobs something like Task? Workload (this conflict with Workload API)? Application?

I'm ok with Task, but would need to see how this presents itself in the docs.

[tenzen-y]

I guess that we want to consider what is appropriate name instead of Jobs something like Task? Workload (this conflict with Workload API)? Application?

I'm ok with Task, but would need to see how this presents itself in the docs.

SGTM

[mimowo]

cc @PBundyra who is also looking into improvements for docs

[dgrove-oss]

I agree that using something other than Job in the documentation as the generic name for the user-level "thing Kueue manages" is desirable. Job has a strong connotation of "batch job" and there is also the confusion between a generic Job and a batch/v1 Job.

I wish I could come up with a good synonym for workload that we weren't already using. Failing that, I do still think that overloading workload to mean both the user's notion of a workload and Kueue's Workload API object would still be an improvement. If we consistently said "Kueue Workload" for the later, that might be enough.