Handle port overrides

[charith-elastic]

The operator assumes Elasticsearch http.port to be 9200 even if the user specifies different values in the config section. We should either add this key to the settings blacklist or honour the value user has defined.

One complication of dealing with user-defined values is that http.port allows port ranges to be defined.

This issue applies to Kibana (server.port) and APM Server (host) as well.

[racevedoo]

Hi @charith-elastic, I can try to take on this one. Do you have any suggestions on how to deal with port ranges?

[charith-elastic]

I can't think of a good reason why users would want to change this setting in a Kubernetes context. If the requirement is to change the external port through which Elasticsearch is accessed, that should be done through a Service or an Ingress. Port range makes even less sense because the application has full access to all the ports in the container and doesn't need to find a free port.

I am inclined to just add http.port to the settings blacklist but we are re-considering the blacklist at the moment: #1760

If a single port value is defined for http.port, I don't see a problem with the operator using that instead of the hard-coded value. However, if the user specifies a port range, things become a bit tricky. We could:

• add a validation check to prevent it but then we are going down the path of "validating" Elasticsearch configuration and rejecting valid settings as invalid.
• assume that the first port in the range will always be available within the pod and that Elasticsearch will bind to it. This is a brittle assumption to make.
• make the operator apply a transformation to the user-supplied configuration so that port ranges get overwritten with the first value in the range. This feels overly invasive as well.

Neither one of these options is ideal so I think this issue needs to be discussed a bit more before making a decision.