In terms of discovery, elasticsearch provides that out of the box https://www.elastic.co/guide/en/elasticsearch/reference/1.4/modules-discovery.html. We deploy elasticsearch via Marathon and it works great.
On Mon, Dec 28, 2015 at 2:17 PM, Eric LEMOINE <elemo...@mirantis.com> wrote: > On Mon, Dec 28, 2015 at 7:55 PM, Alex Rukletsov <a...@mesosphere.com> > wrote: > > Eric— > > > > give me a chance to answer that before you fall into frustration : ). > > Also, you can directly write to framework developers > > (mesos...@container-solutions.com) and they either confirm or bust my > > guess. Or maybe one of the authors — Frank — will chime in in this > > thread. > > > > Marathon has no idea about application logic, hence a "scale" > > operation just starts more application instances. But sometimes you > > may want to do extra job (track instances, report ip:port of a new > > instance to existing instances, and so on). That's when a dedicated > > framework makes sense. Each framework has a scheduler that is able to > > track each instance and do all aforementioned actions. > > > > How this maps to your question? AFAIK, all Elasticsearch nodes should > > see each other, hence once a new node is started, it should be somehow > > advertised to other nodes. You can do it by wrapping Elasticsearch > > command in a shell script and maintain some sort of an out-of-band > > registry, take a look at one of the first efforts [1] to run > > Elasticsearch on Mesos to get an impression how it may look like. But > > you can use a dedicated framework instead : ). > > > > [1] https://github.com/mesosphere/elasticsearch-mesos > > > That makes great sense Alex. Thanks for chiming in. > -- https://github.com/mindscratch https://www.google.com/+CraigWickesser https://twitter.com/mind_scratch https://twitter.com/craig_links
