feat!: split bind address to manage host and port separately

[cpitstick-latai]

Adds webhook port and bind port for metrics server to the Deployment for the main operator. Also allows customization of the metrics bind port for the operator container. This is to prevent port conflicts when hostNetwork: true is set (#680)

This PR

The bindPort for the metrics server was not customizable for the open-feature-operator. Enabling this to be configured. Also explicitly specify both the metrics server port and the webhook port in the deployment.

Related Issues

Notes

This is necessary for enabling hostNetwork: true which is in this PR

Follow-up Tasks

How to test

On an EKS cluster where the CNI has been replaced with Calico, and combined with hostNetwork: true

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.51%. Comparing base (499661e) to head (5e1b1fb).
Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #679   +/-   ##
=======================================
  Coverage   86.51%   86.51%           
=======================================
  Files          19       19           
  Lines        1587     1587           
=======================================
  Hits         1373     1373           
  Misses        173      173           
  Partials       41       41           

Flag	Coverage Δ
unit-tests	86.51% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[toddbaert]

My only concern is that things still aren't quite consistent. For example, managerConfig.controllerManagerConfigYaml.health.healthProbeBindAddress includes the : and doesn't work the same as these new params (separate host/port). However, it's the case that things already weren't quite consistent here, and I'm not sure if it's worth addressing in this PR or not.

I'm approving, but I'd like to hear from others. cc @bacherfl @thisthat @odubajDT

[cpitstick-latai]

@toddbaert A dev anti-pattern is to hold a PR hostage by demanding that changes that are not in the PR's scope be made to fix other technical debt. I saw this early in my career, and have learned to aggressive fight it.

Fixing the consistency here can be the NEXT PR. But I'm not sure I'm the right person to do this fix, as your team seems to have a particular and peculiar view of what you desire.

[bacherfl]

lgtm

[toddbaert]

@toddbaert A dev anti-pattern is to hold a PR hostage by demanding that changes that are not in the PR's scope be made to fix other technical debt. I saw this early in my career, and have learned to aggressive fight it.

Fixing the consistency here can be the NEXT PR. But I'm not sure I'm the right person to do this fix, as your team seems to have a particular and peculiar view of what you desire.

Agreed, we just need 2 approvals and I wanted to point out the implicit choice. I'm fine to merge as is.