Allow definition of loadBalancerIP

[rbraeunlich]

Hi everyone,
when I deploy an application via SCDF the problem is that the service name changes due to the version being appended. Because I would like to have a consistent way to address my services, it would be great if I could give the LoadBalancer service a static cluster IP.
I created a simple PR to add this but I'm not sure how to test this properly. #339

[sabbyanandan]

Hi, @rbraeunlich. While this seems like a feasible option, I believe in a production setting folks tend to explicitly rely on well-defined DNS names/IPs or Ingress in its native form. I described the solution in response to the StackOverflow (also: spring-cloud/spring-cloud-dataflow#3645).

Please have a look, and let us know what your thoughts, and whether this is still required.

[chrisjs]

related: #196

[chrisjs]

this would also be a per-app deployer property if it were to happen vs. the existing PR where it would be global.

thanks for the PR, will look into it

[rbraeunlich]

Hi @sabbyanandan and @chrisjs
thank you for you quick responses. Regarding the Stackoverflow thread, wouldn't that mean that for every source I'd have to do another deployment of a service, just to have a static IP assigned?
In that case it seems better to me to just set the loadBalancerIP on the service that Deployer creates anyways.
Alternatively, if the deployed services wouldn't changes their names with each deployment (because the version is being appended) I could deploy an Ingress.
@chrisjs does that mean I have to move my changes to another class?

[chrisjs]

@rbraeunlich for the time being the response @sabbyanandan had posted would be a viable option. in regards to the PR, yes, the code would need to change as the existing PR would imply the same LB IP would get applied to all services, rather than a deployment property for specific apps so would need some re-working.

additionally, i am going to close this issue and the associated PR given the above in favor of an existing one which you can track located at: #196 which i believe would resolve your issue here. it may be possible changes outside deployer may need to be made, so i think using that issue would be preferred.