Fix #304 - Operator driven service discovery API

[wmedvede]

Description of the change:

Motivation for the change:

Checklist

• Add or Modify a unit test for your change
• Have you verified that tall the tests are passing?

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.

If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

[ricardozanini]

I like this initial (big) step. Therefore, can we please have one package? It's uncommon in golang to have that many packages for this implementation. Especially in the scope of api package. This is a convention for the CRD types, might be confusing to introduce this here.

What I recommend is to create one single controllers/discovery package and in there, we create our files with meaningful prefixes such as parser_types.go. Also, we can implement it by adopting lowercase letters in the func/types and exposing just the discovery engine like: discovery.NewHandler(workflow).Do(). Just an example.

The other modules/packages don't care about unexposed data structures that we need to do the discovery.

[wmedvede]

I like this initial (big) step. Therefore, can we please have one package? It's uncommon in golang to have that many packages for this implementation. Especially in the scope of api package. This is a convention for the CRD types, might be confusing to introduce this here.

What I recommend is to create one single controllers/discovery package and in there, we create our files with meaningful prefixes such as parser_types.go. Also, we can implement it by adopting lowercase letters in the func/types and exposing just the discovery engine like: discovery.NewHandler(workflow).Do(). Just an example.

The other modules/packages don't care about unexposed data structures that we need to do the discovery.

Good suggestions, I'll apply all. Many thanks Ricardo.

[ricardozanini]

Great work! I really like it! Just a few points if you don't mind. I will refrain from adding more since it's a draft yet. 😅

[wmedvede]

@ricardozanini Service discovery was integrated according to the microprofile catalog properties strategy and working for kubernetes services and pods. The other kubernetes objects I think we can add in a separate PR.
I'll take a look at the builder image in the mean time to incorporate the kogito-addons-quarkus-microprofile-config-service-catalog

[ricardozanini]

@wmedvede

The other kubernetes objects I think we can add in a separate PR

Do we have an issue for this one?

[wmedvede]

@wmedvede

The other kubernetes objects I think we can add in a separate PR

Do we have an issue for this one?

No. but can I open, the only are the commit comments reffering to KOGITO-9867...., IDK, if you don't mind loosing the history of your review I can open a new PR and use an issue, otherwise I can open an issue and at least link it to this PR.

All good now, kie-issue was linked accordingly

[wmedvede]

Closes #304

[tchughesiv]

a couple nits, otherwise lgtm

[domhanak]

@wmedvede looks good but I really miss unit tests for all the different discovery functions. There are numerous branches in each, for example we have uri_parser_test.go Could we also do this for other parts?

[wmedvede]

@wmedvede looks good but I really miss unit tests for all the different discovery functions. There are numerous branches in each, for example we have uri_parser_test.go Could we also do this for other parts?

tests where added, this is good enough for now.