KEP-2170: Update Training V2 APIs in the KEP

[andreyvelich]

I updated APIs in Training V2 KEP after our discussions in this PR: #2223.
Additionally, we discussed with @tenzen-y to rename Exporter Job to the Finalizer, since we might introduce another post-processing functionality later (in addition to model exporter).

Please take a look.

/assign @kubeflow/wg-training-leads @shravan-achar @vsoch @kannon92

[andreyvelich]

Part of: #2170

[coveralls]

Pull Request Test Coverage Report for Build 10632842905

Details

• 0 of 9 (0.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 31.761%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/apis/kubeflow.org/v2alpha1/zz_generated.deepcopy.go	0	9	0.0%

Totals
Change from base Build 10600609425:	0.02%
Covered Lines:	3945
Relevant Lines:	12421

---

💛 - Coveralls

[tenzen-y]

Additionally, could we clarify the criteria for when the Initializer, Trainer, and Finalizer will start?
For example, if the initializer fails, what happens? The Trainer and Finalizer will start or not?

I have similar questions about Trainer and Finalizer. So, I believe in clarifying the criteria for when each task will start.

[tenzen-y]

Suggested change

	type PodSpecOverrides struct {
	type PodSpecOverride struct {

Could we use the singular name instead of the plural since we used to select the singular name for field typed?
We can image the following fields:

PodSpecOverrides []PodSpecOverride `json:"podSpecOverrides"` 

vs

PodSpecOverrides []PodSpecOverrides `json:"podSpecOverrides"` 

[tenzen-y]

Suggested change

	type ContainerOverrides struct {
	type ContainerOverride struct {

I would recommend the singular name based on the above comment.

[andreyvelich]

Additionally, could we clarify the criteria for when the Initializer, Trainer, and Finalizer will start?
For example, if the initializer fails, what happens? The Trainer and Finalizer will start or not?

Sure, can we do that in the followup PR when we agree on the Initializer and Finalizer structure ? E.g. init container + sidecar container which will be triggered with preStop lifecycle hook.

[andreyvelich]

@tenzen-y I've done changes to PodSpecOverride API.

[tenzen-y]

Additionally, could we clarify the criteria for when the Initializer, Trainer, and Finalizer will start?
For example, if the initializer fails, what happens? The Trainer and Finalizer will start or not?

Sure, can we do that in the followup PR when we agree on the Initializer and Finalizer structure ? E.g. init container + sidecar container which will be triggered with preStop lifecycle hook.

@andreyvelich Sure. If so, can we treat the Initializer and Finalizer as a separate feature similar to PodSpecOverride: #2218?

And, can we create a dedicated issue and work on design and implementations in the issue?

[andreyvelich]

We have issue for Initializer job already: #2210.
Let me create one for Finalizer job.

[tenzen-y]

We have issue for Initializer job already: #2210.
Let me create one for Finalizer job.

Sounds great. Thanks!
/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tenzen-y

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [tenzen-y]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment