[RHOAIENG-7127] Changing image in serving runtime now updates isvc. Can use annotatio…

[andresllh]

…n to specify behavior for auto-updates.

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #3299

Type of changes
Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Feature/Issue validation/testing:

Please describe the tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

• Test A No Annotation

1. Created a serving runtime
2. Created an isvc that uses that serving runtime and no annotation
3. Verified that the deployment has been created with the image specified in the serving runtime
4. Updated the serving runtime spec.containers[0].image with a new image
5. Verified that the deployment now had the updated image

• Test B Annotation set to auto-update=true

1. Created a serving runtime
2. Created an isvc that uses that serving runtime with the annotation set to true
3. Verified the deployment was created correctly
4. Updated the serving runtime spec.containers[0].image with a new image
5. Verified that the deployment now had the updated image

• Test C Annotation set to auto-update=false

1. Created a serving runtime
2. Created an isvc that uses that serving runtime with the annotation set to true
3. Verified the deployment was created correctly
4. Updated the serving runtime spec.containers[0].image with a new image
5. Verified that the deployment DID NOT have the updated image

• Logs

Special notes for your reviewer:

1. Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

• Have you added unit/e2e tests that prove your fix is effective or that this feature works?
• Has code been commented, particularly in hard-to-understand areas?
• Have you made corresponding changes to the documentation?

Release note:

Re-running failed tests

• /rerun-all - rerun all failed workflows.
• /rerun-workflow <workflow name> - rerun a specific failed workflow. Only one workflow name can be specified. Multiple /rerun-workflow commands are allowed per comment.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andresllh

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

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

[andresllh]

/cc @brettmthompson @spolti @israel-hdez

[spolti]

Very nice @andresllh, a few things:

• can you also test having multiple inference services with different serving runtimes, and, you update one serving runtime only the ISVC that uses the changed SV is updated?

Also, I think that is a great candidate to go first on upstream (if the priority is not that high).

[spolti]

Did you run this test as well?

can you also test having multiple inference services with different serving runtimes, and, you update one serving runtime only the ISVC that uses the changed SV is updated?

[andresllh]

Did you run this test as well?

can you also test having multiple inference services with different serving runtimes, and, you update one serving runtime only the ISVC that uses the changed SV is updated?

@spolti
Yes, I added another unit test and also tested this in my cluster manually.