[post jobs] Like serving use generatedName

[matzew]

Signed-off-by: Matthias Wessendorf mwessend@redhat.com

Proposed Changes

• 🧹 Like Serving, using the generatedName for the upgrade job. See: https://github.com/knative/serving/pull/8514/files#r447739231. Also updating the job name and the labels, like: Update the job name and label into storage-version-migration-serving serving#8580

Pre-review Checklist

• At least 80% unit test coverage
• E2E tests for any new behavior
• Docs PR for any user-facing impact
• Spec PR for any new API feature
• Conformance test for any change to the spec

Release Note

The post job is now having a generated name, instead of an unmaintained versioned name.

Docs

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: matzew

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 [matzew]

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

[matzew]

/hold

/assign @dprotaso a change like on your serving PR for the generated name.
/assign @houshengbo doing the same for the name and the labling, like you did for serving

For the operator, since serving uses this generatedName, there is no issue if we in eventing now do the same, right?

[codecov]

Codecov Report

Merging #5664 (b8968c8) into main (de1b52b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #5664   +/-   ##
=======================================
  Coverage   82.68%   82.68%           
=======================================
  Files         200      200           
  Lines        6253     6253           
=======================================
  Hits         5170     5170           
  Misses        751      751           
  Partials      332      332           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update de1b52b...b8968c8. Read the comment docs.

[matzew]

@dprotaso, @houshengbo, @lionelvillard any comments 🙏 ?

[dprotaso]

Right now we still have the storage version migration job in serving but it's an effective NOOP until we change the storage version of some CRDs which we haven't done in a while. We currently use generateName it's possible to re-apply this job over and over when upgrading & downgrading.

Given that I thought maybe in serving we switch to versioning the jobs. Maybe be deleting and re-introducing the post-install jobs when needed. But it looks like you want to go the other way. There's also the caveat of some post-install jobs being optional (ie. default-domain) so we continue offering those. Either way switching to generate name makes sense in cause you want to re-apply or downgrade etc.

I'm curious to hear @houshengbo's take given the operator has been dealing with both the versioned post-install jobs (from eventing) and the non-versioned ones. (from serving).

[lionelvillard]

@houshengbo WDYT?

[matzew]

Given that I thought maybe in serving we switch to versioning the jobs. Maybe be deleting and re-introducing the post-install jobs when needed.

Ah, I thought it was intentionally done as is currently (e.g. have them always, even as NOOP).

In eventing we had be doing this before: deleting and re-introducing - but it was forgotten a for a few releases, which shows the downside of the "delete" and "re-introduce" model

[houshengbo]

Hi folks, thanks for reminding me.
There is no issue with the generated name for eventing.

[matzew]

/unhold

[matzew]

A follow up, like serving, will be done in here: #5694

@lionelvillard mind getting me some LGTM?

[lionelvillard]

/lgtm