Hi Timotheé,
yes I think this is valuable - the idea of the discovery API is to abstract
the discovery and if we can benefit in certain scenarios from already
available mechanism/information I think it makes totally sense to use that
instead of adding the same on top of it.
Right now, the
Hi,
+1 for distribution of properties via S3, makes perfect sense. Perhaps
abstracting behind an API so that any low latency globally distributed
storage provider could be used.
Not sure about discovery. Although [0] described the AWS VM, it
doesn't, without further validation describe if the
Hi,
2014-05-12 9:02 GMT+01:00 Ian Boston i...@tfd.co.uk:
Hi,
+1 for distribution of properties via S3, makes perfect sense. Perhaps
abstracting behind an API so that any low latency globally distributed
storage provider could be used.
Yes, discussing this offline with Felix, an alternative
If the usecase is only for Discovery it might be simpler to run Apache
Zookeeper [1] and use Apache Curator [2] as noted in SLING-2939.
While running on AWS one can possibly use Netflix Exhibitor [3] which
manages the Zookeeper instances and backup there state in S3.
The benefit of this approach
I'd agree with Chetan and Ian here in that S3 sounds feasible for
persisting properties in a topology (rather than relying on the
non-persistent nature of discovery-properties). The implementation of
discovery itself I see as a separate discussion.
Cheers,
Stefan
On 5/12/14 1:00 PM, Chetan
Hi,
I would like to discuss a potential implementation of the Sling Discovery
APIs over an eventually consistent distributed storages such as AWS S3.
Assuming the instances being part of the topology runs in AWS, then we
could leverage AWS APIs and service in order to implement the Discovery
