Fix Kserve Unmanaged Installation

[VaishnaviHire]

Description

https://issues.redhat.com/browse/RHOAIENG-2951

How Has This Been Tested?

1. Install operator using catalogsource quay.io/vhire/opendatahub-operator-catalog:v2.7.0
2. Create default DSCI
3. Create DSC with following spec

    kserve:
      managementState: Managed
      serving:
        ingressGateway:
          certificate:
            type: SelfSigned
        managementState: Unmanaged
        name: knative-serving

Merge criteria:

• The commits are squashed in a cohesive manner and have meaningful messages.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work

[Jooho]

The main changes looks good to me

[Jooho]

I didn't test this yet but the change looks good.

[zdtsw]

i did not see this PR but made an early comments on the sync PR red-hat-data-services#192
copy-paste it here:

this is for:
when serving is Managed + servicemesh is not-Managed, we do a check if these 2 operators are installed?

but for kserve to work, even both of these 2 dependent operator will be needed
even we do not create CR from them.

(some docs does say you do not must use servicemesh but other operator but if we exclude this option here)
my understanding is, as long as we set kserve to Managed, we will need the check on these 2.

[VaishnaviHire]

i did not see this PR but made an early comments on the sync PR red-hat-data-services#192 copy-paste it here:

this is for:
when serving is Managed + servicemesh is not-Managed, we do a check if these 2 operators are installed?

but for kserve to work, even both of these 2 dependent operator will be needed
even we do not create CR from them.

(some docs does say you do not must use servicemesh but other operator but if we exclude this option here)
my understanding is, as long as we set kserve to Managed, we will need the check on these 2.

For Unmanaged we should not prevent kserve controller deployment. Even when the prereq. operators are expected, given that the state is Unmanged, operator should go ahead with component installation

[zdtsw]

/retest

[zdtsw]

/retest

[zdtsw]

I think the whole confusion comes from:
what does "Unmanaged" mean?
if user set Unmanaged to Serving, and not install Serverless operator, is it a supported case for Kserve?

[VaishnaviHire]

The error in e2e is caused by https://github.com/opendatahub-io/opendatahub-operator/blob/incubation/tests/e2e/dsc_creation_test.go#L188.
I will update the PR to remove this

[israel-hdez]

I think the whole confusion comes from:
what does "Unmanaged" mean?
if user set Unmanaged to Serving, and not install Serverless operator, is it a supported case for Kserve?

For the time being, this is not a supported setup: KServe needs both Serverless and Service Mesh to be present in order to work properly.

However, there are talks about reducing the footprint and this may change in the near term.

[israel-hdez]

What I remember, is that this check was left here in order to prevent KServe from being installed if either OSSM or Serverless were missing from the cluster, regardless of the management state of OSSM and Serverless. This was simply a proactive check so that we don't end up with a broken installation of KServe.

Moving this code into configreServerless doesn't make much sense to me, because configureServerless has its own protections.

So, I think it is better to, simply, fully remove checkDependentOperators function. We may want to drop a note in the docs about that KServe installation will no longer test if there is a valid OSSM and Serverless setup.

[VaishnaviHire]

I agree we can remove the checkDependentOperators function entirely. I will update the PR.

For downstream though, we had included the function in configreServerless already for 2.7. We will remove the checkDependentOperators in 2.8. The behavior will be same though,

For `Unmanaged`, operator will not check for dependent operators.

[israel-hdez]

So, I had a meeting today and now I have a much better understanding about why this is needed.

I agree we can remove the checkDependentOperators function entirely. I will update the PR.
We will remove the checkDependentOperators in 2.8. The behavior will be same

This seems to be the optimal way, at the moment. I appreciate your help @VaishnaviHire .

[VaishnaviHire]

Looked more into this, I think we should keep the checkDependentOperators around since it looks for OperatorCondition resource rather than CRD. OperatorCondition helps with verifying if the operator subscription is present which is not the case with crd

[VaishnaviHire]

/cherry-pick main

[openshift-cherrypick-robot]

@VaishnaviHire: once the present PR merges, I will cherry-pick it on top of main in a new PR and assign it to you.

In response to this:

/cherry-pick main

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: zdtsw
Once this PR has been reviewed and has the lgtm label, please ask for approval from vaishnavihire. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[openshift-cherrypick-robot]

@VaishnaviHire: new pull request created: #874

In response to this:

/cherry-pick main

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.