Extend the web service with /endpoints endpoint

[jbienkowski]

New endpoint (for example http://127.0.0.1/eidaws/routing/1/endpoints) is expected to respond with a list of URLs based on the local node config file containing base EIDAWS-Routing URLs and/or URLs to the static XML files exposed within the federation.
Response should also contain information about the local node running the service (whose configuration is not included in the local config file by design).

[damb]

@jbienkowski,

I know that it's almost too obvious implementing this feature by means of providing an additional endpoint at eidaws-routing. However, the question is whether the information is really related to eidws-routing or whether it is simply EIDA configuration related. If the latter is the case, I'd rather go for an implementation with etcd (or optionally Apache Zookeeper). Although it might seem overkill - this systems are designed to store configuration in distributed environments. Besides of configuration management they allow for features such as distributed locking and much more. Strong consistency is implemented by means of a distributed consensus algorithm (i.e. in case of etcd Raft).

IMO midterm to longterm EIDA could profit a lot from such a system. What do you think?

[javiquinte]

Hi everyone.
First of all. As @damb said, the implementation is almost trivial. Take into account that the Routing Service is independent from EIDA, so this method reflects only the RS configuration.
Apart from that, for EIDA we are exposing only the configuration of the ODC RS. We don't want to synchronize something complicated, or do complex operations on that. To introduce new dependencies and complicate systems that do work when we don't have any requirement seems definitely the best example of overkill.

[damb]

To introduce new dependencies and complicate systems that do work when we don't have any requirement seems definitely the best example of overkill.

@javiquinte, I fully agree on that. (OT: One reasonable example for a future application could be a heartbeat mechanism from endpoints allowing for dynamic routing coupled with priority!=1 routes (of course first of all it would be necessary to define what priority means). An application such as eida-federator would be able to react dynamically on endpoint outages (if the DC is for any reason not capable of handling this outage by itself). Let's call this feature eidaws-routing based failover management 😄).

[jbienkowski]

Gentlemen,
I really like the idea of having a distributed configuration system, especially for an organization such as EIDA. Considering that work requested in my original message can be delivered basically for free at any time, perhaps we could put it on hold and seriously consider Daniel's proposal first? It seems to be much cleaner, flexible and future-proof.

[javiquinte]

Implemented with commit a99890c

[nikosT]

Hi everyone,
I think the distributed idea sounds fabulous. However, before developing new ideas, we must be really sure that is really needed, otherwise, we will complicate things for no reason. In that case, I believe that we should write down use cases describing the necessity of this feature first and then move on.

I was also thinking if the endpoints method should have a format "=text" and "=xml", where the first one will give a quick view of the endpoints while the second could provide more info, like the DOI of the Datacenter.