Feat: InferenceService reconcile function

[Al-Pragliola]

Description

The InferenceService reconcile function is responsible for managing the lifecycle of Model Registry InferenceService entities, the prerequisite for an InferenceService to be associated with an MR entity is that the required labels "modelregistry.opendatahub.io/model-version-id" or "modelregistry.opendatahub.io/inference-service-id" are set, then the reconcile function will create (or get, if it already exists) a ServingEnvironment in the Model Registry whose name is the same as the namespace of the InferenceService. The reconcile function will also create (or get, if the label "modelregistry.opendatahub.io/inference-service-id" is set) an InferenceService in the Model Registry associated with the ServingEnvironment, the DesiredState will be "DEPLOYED", if the InferenceService is deleted, the reconcile function will set the DesiredState to "UNDEPLOYED".

How Has This Been Tested?

This has been tested by being imported in an already existing controller, I will automate testing in the follow-up PRs, I decided to split it in several ones to ease up the job of the reviewers

Merge criteria:

• All the commits have been signed-off (To pass the DCO check)

• The commits have meaningful messages; the author will squash them after approval or in case of manual merges will ask to merge with squash.
• 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.
• Code changes follow the kubeflow contribution guidelines.

[tarilabs]

Thank you very much @Al-Pragliola!

I assume this is tested by importing into other controllers and it's working, and that tests will be made here upstream in following PRs?

if that is correct for both, and
/lgtm
with the intent to close this PR early, to ease follow-up works/tasks

[tarilabs]

/approve cancel

[Al-Pragliola]

Thank you very much @Al-Pragliola!

I assume this is tested by importing into other controllers and it's working, and that tests will be made here upstream in following PRs?

if that is correct for both, and /lgtm with the intent to close this PR early, to ease follow-up works/tasks

thanks @tarilabs yes exactly as you said, I have updated the PR's description!

This has been tested by being imported in an already existing controller, I will automate testing in the follow-up PRs, I decided to split it in several ones to ease up the job of the reviewers

[tarilabs]

thanks @tarilabs yes exactly as you said, I have updated the PR's description!

This has been tested by being imported in an already existing controller, I will automate testing in the follow-up PRs, I decided to split it in several ones to ease up the job of the reviewers

awesome, much appreciated @Al-Pragliola

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tarilabs

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

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