wanted: mechanism to explicitly disable webhook server of a manager

AFAICT the webhook server is automatically started, based on the presence of hook registration calls. In an effort to guard against libraries setting up webhooks on a manager, or at least to be able to detect when they rely on such behavior, I'd like to be able to explicitly disable the webhook server to flag hook-registration attempts. One idea I had was to choose a bad port for the webhook server to trigger fail-fast behavior.

Current state appears to be that when the webhook server port is left at 0 in the config, it is upgraded to 9443 (the "default" webhook server port). So, setting the port to 0 won't disable the webhook server. In fact, any number 0 or less will result in the port 9443 being chosen - because the code implements a lower bound on the port setting. However, there appears to be no upper bound on the port setting.

As a workaround, in order to achieve my objective, I'm setting the port number to "max int", which is far above the maximum port number allowed by the networking stack. Attempts to bind on this port fail, which causes the fail-fast behavior that I want. But it's also kind of ugly and not very intuitive.

It would be nice if CR provided a nicer API to achieve this objective. Otherwise, I worry that it will only be a matter of time until perhaps someone implements an upper bound on the port, defaulting to 9443 when the limit is exceeded - and therefore obviating my workaround.

Slack thread

Start by tracing the manager's webhook-server setup, including how the configured port is normalized and how hook-registration calls trigger startup. Review the linked Slack thread for design context. Done means a documented API can explicitly disable the webhook server and reliably flag registration attempts without relying on an invalid maximum port.