Use knative service for wathola receiver if available

[cardil]

Is related to #3175

This PR isn't doing #3175 a full justice. This is a minor improvement, in which we can get receiver report even if given K8s cluster doesn't a worker node external, reachable address. It's done when there is a Serving component available.

Such a situation arisen on our team when we were trying to incorporate upgrade tests in our product (see openshift-knative/serverless-operator#530 (comment)).

Proposed Changes

• If Serving.Use flag is set deploy a kservice and get it's URL instead of relying on worker node internal address

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: cardil
To complete the pull request process, please assign chizhg after the PR has been reviewed.
You can assign the PR to them by writing /assign @chizhg in a comment when ready.

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

Needs approval from an approver in each of these files:

• test/OWNERS

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

[codecov]

Codecov Report

Merging #4430 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4430   +/-   ##
=======================================
  Coverage   81.06%   81.06%           
=======================================
  Files         281      281           
  Lines        7981     7981           
=======================================
  Hits         6470     6470           
  Misses       1122     1122           
  Partials      389      389           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 766a24c...bb66221. Read the comment docs.

[cardil]

/hold

Some additional changes are required

[cardil]

/unhold

[matzew]

/test all

[zhongduo]

/assign @zhongduo

[zhongduo]

Thanks for adding this. I do think having the requirement of accessing from external can be a big headache and was considering doing similar thing for our CI test.

[zhongduo]

Do I understand correctly that all the extra logic, including the forwarder, is just to make an http request to /report, did you consider using the curl container instead of implementing all the logic?

[cardil]

/hold

Upgrading serving component causes the receiver ksvc to restart and loose track of transmitted events.

[cardil]

Do I understand correctly that all the extra logic, including the forwarder, is just to make an http request to /report, did you consider using the curl container instead of implementing all the logic?

Those are sending, and receiving cloud events. On receiving part those are keep track. At test end sender sends finished event with number of events he successfully pushed to eventing broker. That's why receiver can calculate and return report of propagated events. Forwarder component is there to test that if we don't loose events on ksvc autoscaling components. More info on upgrade readme file.

Yes. I think that's possible to deploy curl like job, request an internal in cluster address, and read json from jobs logs. That's good alternative to original idea of using configmaps and k8s events.

[AlexandraRoatis]

minor: perhaps this log should be updated as well since the preferred pattern seems to be not using Infof when there is a single variable at the end