[ https://issues.jboss.org/browse/JBIDE-23490?page=com.atlassian.jira.plugi... ] Marián Labuda commented on JBIDE-23490: --------------------------------------- [~adietish] correct. Even if you would try to edit route to point to a pod instead of a service, OpenShift would not allow it. It would result into an error. Basically in hierarchy is Pod --> Service ---> Route. By exposing a pod you get a service which point to all relevant pods (specified by a selector). And by exposing a Service you get a routing to manage traffic to pods via pointing to a service. I am still not sure why there is a need of having a Server adapter pointing to a pod instead of a Service. Pods are volatile, but they are managed by replication controller so there is still a pod for application if needed. And to easily access an application we have a service which always know which pods belong to app. By pointing a server adapter to a pod we could throw away all what OpenShift offer. It would basically get down to a docker level - plain containers without orchestration, management... If server adapter would work for a pod instead of service there are other issues linked to the nature of pods - restarting in debug would make it unusable (it starts different pod), scaling won't be possible (there is a Service for it to point to multiple pods). I am replying because in the document (Fuse Integration Services and its integration to OpenShift) I haven't seen any answer since 11/2016 when I last time was wondering why is this "workflow" desired. -- This message was sent by Atlassian JIRA (v7.2.3#72005)