@tsegismont The scope of this PR is admittedly larger than I would like; I found myself re-organizing the existing code to get a better understanding of its function.
This is a first attempt at implementing #148, missing tests coverage, and could no doubt be improved. Let me know your thoughts on the general approach.
This fixes #148.
@tsegismont The scope of this PR is admittedly larger than I would like; I found myself re-organizing the existing code to get a better understanding of its function.
This is a first attempt at implementing #148, missing tests coverage, and could no doubt be improved. Let me know your thoughts on the general approach.
Using 3 maps to track service selectors, service's active pods, and the sevices per pod feels sub-optimal, but the intention was to avoid calculating everything on the fly: https://github.com/vert-x3/vertx-service-discovery/blob/048b2e34ffc5a264d59164cc61c43194b1364a33/vertx-service-discovery-bridge-kubernetes/src/main/java/io/vertx/servicediscovery/kubernetes/KubernetesServiceImporter.java#L71-L73
The way that service status is updated also feels like it could be better (more reactive). For busier k8s instances, simply checking the size of the lists after modification may not work (concurrent modification). Ideally, we'd hook into the changes in the lists and update the services based on that. https://github.com/vert-x3/vertx-service-discovery/blob/048b2e34ffc5a264d59164cc61c43194b1364a33/vertx-service-discovery-bridge-kubernetes/src/main/java/io/vertx/servicediscovery/kubernetes/KubernetesServiceImporter.java#L535-L542 https://github.com/vert-x3/vertx-service-discovery/blob/048b2e34ffc5a264d59164cc61c43194b1364a33/vertx-service-discovery-bridge-kubernetes/src/main/java/io/vertx/servicediscovery/kubernetes/KubernetesServiceImporter.java#L550-L556
To-do: