Deprecate kfdefApplication field in OdhApplications

[andrewballantyne]

Closes: #1510

Description

Remove the reliance on kfdefApplications field in the OdhApplication CRs (when there are no KfDefs installed).

When the new Operator is installed, it does not use KfDefs... the CRD does not exist, the items do not exist. In #1537 we removed the error when no KfDef CRD exists.

This is to adjust us back to working -- kfdefApplications is not needed when no KfDefs are found and are completely ignored. Moving forward we'll use the "component model" and each component will offer resources if they wish for Dashboard to render.

Couple screenshots...

Should be noted, I could not actually deprecate the field. K8s doesn't allow it.

How Has This Been Tested?

Note: I started on a fresh cluster and not one that had the existing Operator on it -- this PR is not about how to upgrade the operator nor is it about issues with installing the operator. Seek out https://github.com/opendatahub-io/opendatahub-operator with issues and questions for more information

1. Install the Operator (steps) -- I used Cluster Bot to create me a short lived OpenShift instance so nothing else was left around -- if you have remaining KfDefs then you'll fall back into the other model (this is expected -- since you'll have duplicate deployments of resources)
   • Install the Operator (link)
   • Use the Operator by creating the CR (link)
2. Fire up the Dashboard and see if the Jupyter tile is showing
3. You can disable the Jupyter tile (notebookController.enabled = false) but that'll fallback on JupyterHub tile (which we should be getting rid of in Remove JH References #534)

Test Impact

No tests were changed or added.

Request review criteria:

Self checklist (all need to be checked):

• The developer has manually tested the changes and verified that the changes work
• Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

• Included any necessary screenshots or gifs if it was a UI change.
• Included tags to the UX team if it was a UI/UX change.

After the PR is posted & before it merges:

• The developer has tested their solution on a cluster by using the image produced by the PR to main

[VaishnaviHire]

/lgtm

[DaoDaoNoCode]

Maybe you need to remove this type

[manaswinidas]

/lgtm

Tested this on my end. The changes work fine for me.

[openshift-ci]

New changes are detected. LGTM label has been removed.

[andrewballantyne]

Removed the unused type (diff).

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by: manaswinidas

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

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

[andrewballantyne]

Readding the LGTM because of the removal of the unused type.