Service with NodePort always gets a new port after 'fabric8:apply'

[rhuss]

Actually this happens always, but can have two causes, both resulting in the existing service and the service to apply to be considered different here. The difference is always in the MetaData as checked here

• When exposecontroller is used, then the exposecontroller adds two extra annotation (timestamp and a version). This make the annotation part different as these field obviously are missing from kubernetes.yml and so a replacement of the service happens
• When no exposecontroller is used and no namespace is set directly in kubernetes.yml, then both objects are also considered to be different, since the namespace gets set to the default namespace by kubernetes (so that this field is never empty).

The second issue can be easily solved by ignoring the namespace if set to null when doing the comparisation.

For the first issue, I can't see any easy solution. @davsclaus @jstrachan @rawlingsj @iocanel any idea how to fix this (without hardcoding the exposecontroller annotations into this check ?)

[rhuss]

Just found out that there is a fabric8.deploy.ignoreServices for fabric8:apply which is a workaround when doing a redeployment.

[davsclaus]

So this confuses the hell of out of people getting started with k8s and want to use the fmp plugin to deploy their java apps.

Having to add NodePort or LoadBalancer is a bit annoying as its not as easy to figure out.

I wonder if there is something we can do to make the fmp plugin lean and mean OOTB when you add it with the "setup" goal so it works in local development mode for developers.

[samolisov]

I get the same problem using fmp on Windows with minikube. So, the NodePort parameter isn't generated by fmp, so k8s generate new port number for every apply. I also tried using the exposecontroller, but the controller also binds my service on new ports. The fabric8.deploy.ignoreServices helps 'to save' ports after the first deploy, but the question is how to get the port number for integration tests?

I'm working on the following scenario: a Java EE application is deployed on docker inside k8s and exposes a number of REST services; there are integration tests that make requests to the services and analysing the responses. Yet I must know the port the docker container is exposed on to implement the scenario. I'm sure, I'm not the first who asks so, but no answer has been googled.

Thanks!

[rohanKanojia]

@rhuss : This doesn't seem like a refactoring issue. Do you want to pick this also or shall I pick this ?

[rohanKanojia]

@rhuss : Do you have any other solution in mind that I can try for the former case? since we are not using fabric8 dependency anymore?

[rhuss]

What's about this: When we detect that a service with a certain name already exists, we don't exchange it but patch it durin apply ? Could be a good strategy for any other object, too.

Otherwise, when we try to detect whether a serivce hase been exchanged we probably shouldn't take care about meta data. Or, when only meta data is changed (annotations, labels), we just update that metadata.

wdyt ?

[rohanKanojia]

@rhuss : Right now I'm not sure... how would we maintain what items we need to patch in a specific resource? Okay, let me think about it. The solution sounds good but I have to think a bit about implementation.