k8sutil: ExposeMetricsPort works for ClusterScoped

[dbenque-1a]

Description of the change:
When creating the Service to expose metrics, use the NAMESPACE env variable instead of the WATCH_NAMESPACE that is empty for an operator generated with --cluster-scoped

Motivation for the change:
ExposeMetricsPort was failing to generate the kubernetes service to scrape metrics if the operator was generated with --cluster-scoped flag

Closes #835

[estroz]

This probably needs an e2e test case.

[lilic]

Thanks for this! Few initial comments.

[lilic]

@hasbro17 had a good suggestion in #786 (comment) so pinging him on this.

[joelanford]

I think #786 (comment) makes a lot of sense.

I'd suggest we move this function to k8sutil.GetOperatorNamespace(), and then change this line to use it.

[dbenque-1a]

@joelanford i will do that. Thanks.

[dbenque-1a]

@joelanford @lilic changes done according to your comment to reuse the proposal of #786 (comment)

@hasbro17, @estroz FYI

If it is accepted, should I squash all commits before the merge?

Description of the change:
When creating the Service to expose metrics, use the namespace of the operator instead of the WATCH_NAMESPACE

[joelanford]

A couple of nits, but looks good to me overall.

Also, don't worry about squashing. That'll happen automatically when we merge the PR.

[lilic]

Thanks for doing the changes!

[lilic]

One leftover comment otherwise lgtm!

[lilic]

pinging @estroz @joelanford to re-review. LGTM from my side.

[joelanford]

Thanks @dbenque-1a!

LGTM

[estroz]

@dbenque-1a needs a rebase. LGTM on green tests.

[dbenque-1a]

@estroz, rebase done.
@estroz @lilic @joelanford , thanks for your reviews. At Amadeus ( https://amadeus.com/en | https://github.com/AmadeusITGroup/kubervisor ) we have already built couple of operators, the public ones are:
https://github.com/AmadeusITGroup/kubervisor
https://github.com/AmadeusITGroup/Redis-Operator
https://github.com/AmadeusITGroup/workflow-controller

I must say that this SDK should really improve our efficiency in that exercise. At some point we wanted to build such a SDK.. and you do it, thanks! So now we are going to be regular users and probably contributors.

Regards,
David Benque

[lilic]

I must say that this SDK should really improve our efficiency in that exercise. At some point we wanted to build such a SDK.. and you do it, thanks! So now we are going to be regular users and probably contributors.

Thanks for that! We are happy to welcome any contributions! And of course, feedback is always welcome.

I reran the tests they are 🍏 , this should be good to merge once @estroz dismisses his review. Thanks again!

[lilic]

@dbenque-1a Thanks again!