-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
%
-
We've created an 3 member ensemble. The first container patched correctly. When applying the patch to the another ensemble member, the patch artifacts would not resolve.
This was tracked down to the fact that our maven upload directory only had one endpoint exposed, i.e from cluster-list:
io.fabric8.fabric-maven-proxy/1.2.0.redhat-153/maven/upload em_q12 em_q12 - http://dhcp181-42.gsslab.rdu2.redhat.com:8181/maven/upload root root - http://10.10.181.61:8181/maven/upload
This machine (http://dhcp181-42.gsslab.rdu2.redhat.com) does not have the patched artifacts
. They are only available in the data/maven/upload directory where I originally patched the container.
To workaround this issue, we removed the fabric-maven-proxy agent from the other containers in the ensemble and restarted the fabric-maven-proxy agent on the container where I installed the patch. This forced the endpoint to be exposed on the machine where my artifacts were, i.e:
io.fabric8.fabric-maven-proxy/1.2.0.redhat-153/maven/upload
root root - http://10.10.181.61:8181/maven/upload
Restarting the fabric-agent forced my container to resync and as such find the artifacts correctly and come up.
We also noted in a customer environment that these endpoints seem to disappear. We think this may be related to ENTESB-3913. Restart the fabric-maven-proxy resolved the problem.
Problems:
1. Why aren't all three directories exposed? For one of my customers the other ensembles did eventually show up as endpoints, however, this was after a period of 30 - 60 minutes. In addition, we did not seem to iterate through the list to find the artifacts.
2. Shouldn't the patched artifacts be pushed out to all the maven/upload folders so that we are covered in the case a machine goes down?
It seems we may have an initial endpoint creation problem, potential search issue and propagation issue.