Allow metrics port configuration in Ansible and Helm operators

[janekbaraniewski]

Feature Request

Is your feature request related to a problem? Please describe.
When working with Golang based operator, I'm able to change metrics port in code before building the operator. However, when using Helm or Ansible ones, I have no way of configuring that at all without modifying Operator SDK itself and building custom base images.

Describe the solution you'd like
I would like to be able to configure metrics port without modifying and rebuilding Operator SDK.

[joelanford]

@janekbaraniewski Can you explain your use case so we have a better understanding for the motivation for custom port numbers?

[estroz]

Closing due to lack of response. If you still want this feature, feel free to re-open.

[mohamadnikan2013]

I have same issue
I want to configure metrics port by arg or env

[mohamadnikan2013]

I want to set metrics port because default ports are already in use in my server and I want to set up helm operator out of cluster in a virtual machine

[mohamadnikan2013]

It's bad practice if you have metrics port static in your code, it's obvious.

[janekbaraniewski]

Hey, I'm so sorry, must have missed email thread for this. Anyway, my use case changed from that time and I don't require this any longer, however I do agree that it would be just better practice to have it configurable in some way.
What I was testing was helm based and ansible based operators running side by side in a single pod. Idea was to have ansible operator manage release of the application + setup helm releases of some dependencies that would be deployed using helm operator. Both those containers however used the same metrics port.

[camilamacedo86]

Hi @joelanford,

I understand that helm plugin can allow us to pass this value as flags. (metrics-addr)
And users will be able to update their scaffold/config files. So, it would be achieved with the helm plugin.

IMO we can address it to 1.0.0 and add the label kb integration. Wdyt?

[estroz]

There will likely be metrics changes in the v1.0 timeframe so those need to happen before addressing this. Leaving this open to track this feature.