Job: requirements for graduation to beta

[bgrant0607]

Before Job graduates from experimental:

• It needs to adopt the more general selector, as discussed in Generalize label selectors #341. This would be very hard to change later.

Broader discussion of revamping our approach to controllers: #14961. I'll try to flesh out that proposal soon and then will update this issue.

[bgrant0607]

cc @erictune @mikedanese @soltysh

[bgrant0607]

cc @derekwaynecarr @smarterclayton @ncdc @eparis

[ncdc]

It needs to adopt the more general selector

I'm not fully up to speed on 341 yet - will we be able to use the more general selector in Job in v1, or is that impossible?

Broader discussion of revamping our approach to controllers

I'm guessing the result of this discussion will be a series of code changes to the job controller. Is this an absolute prerequisite for moving Job out of experimental?

[derekwaynecarr]

@bgrant0607 - is it accurate to state then that Job moving out of experimental is not necessarily gated on API groups being completed?

[pmorie]

@bgrant0607 Why not just add a new field for the generalized label selector? That would be backward compatible.

[mikedanese]

@pmorie it wouldn't be backward compatible. See #341 (comment). If we defer moving things out of experimental until they've been transitioned to the new label selector, we avoid a difficult migration.

[mikedanese]

I'm not fully up to speed on 341 yet - will we be able to use the more general selector in Job in v1, or is that impossible?

@ncdc It is possible. It's not possible to transition existing API objects that use the current selector to the generalized selector without breaking compatibility . Since we can break compatibility of Job before moving it to v1, there shouldn't be an issue.

[bgrant0607]

@derekwaynecarr The only alternatives to moving Job to a new API group are:

1. move it to v1
2. clone v1 into v2beta1 and add it there but not in v1, using a custom storage version as was done for PodTemplate; hardcoded custom default version would also need to be added to kubectl

Before doing either of those things I'd at least want to try a new API group to see what didn't work.

[bgrant0607]

cc @davidopp

[soltysh]

I need to read through aforementioned issues and prepare necessary fixes to the job controller as soon as possible, if this is the blocking factor for moving jobs out of experimental.

[bgrant0607]

One more option: Rename the experimental group and create newname/v1beta1: #15378. I forgot that Eric and I had discussed that.

[erictune]

I think this is closed by #15520

@mikedanese @bgrant0607 FYI

[bgrant0607]

Yes, I don't think any of the changes discussed in #14961 need to be non-backward-compatible, so I believe we're fine for 1.1 now.