search

whitfin / local-cluster

Easy local cluster creation for Elixir to aid in unit testing
MIT License
223 stars 30 forks source link

Added root app option #20

Closed scohen closed 4 years ago

scohen commented 4 years ago

Prior to this, applications were started in a non-deterministic order, which could lead to misconfiguration or applications not booting. Now you can specify a root app that will be started prior to all the other applications. Due to the way that applications are loaded, specifying this single app should be enough to boot correctly.

scohen commented 4 years ago

This is a very helpful project, by the way. Is it still active?

pmenhart commented 4 years ago

Note that PR #15 already solves a superset of this problem by specifying which applications will be started on slave nodes, and in what order. Unfortunately, @whitfin does not seem to be responsive.

keathley commented 4 years ago

@pmenhart @scohen I've started incorporating some of these PRs into my fork here: https://github.com/keathley/local-cluster. This is something we use quite a bit at work.

scohen commented 4 years ago

@keathley would Bleacher Report care to host a fork of his repo? I wrote something like this when I was at Discord for cluster testing, and it was very helpful. By the way, I used to get beers with Ben Marx with some frequency.

@pmenhart With respect to the solution in pr #15, I'm having a bit of a hard time figuring out what the use case for specifying multiple apps is unless you're running multiple independent applications on a node. Applications themselves decide on how their dependent applications start up, and in what order, so isn't specifying a single top-level app the safest option?

whitfin commented 4 years ago

Hi, yes it's active - sorta. I have little time for Elixir these days - and this project is low on a list of already low priorities, particularly given the global situation. I'll take a look at this PR and the linked PR though, and see if we can't get them in soon :)

whitfin commented 4 years ago

Based on code alone, IMO, #15 is indeed the way to go seeing as you can accomplish what this PR does already, with extras. @scohen I believe your "root" app would simply be the first app in the multiple apps list in #15, thus making this PR redundant in the grand scheme of things. I'm going to merge #15 and close this one - but we can continue discussion here are more people are on the thread.

Side note @keathley I'm not sure what you have included in that fork, but if it's only a few of these PRs and you've been using them in production, I'm happy to try get it merged back here and push a release.

pmenhart commented 4 years ago

Re. why multiple apps: trying to isolate functionality in unit tests, we sometimes do not want to start the main application. Instead, we bring up a subset of dependencies, and explicitly start selected supervisors or processes.

whitfin commented 4 years ago

@pmenhart yeah it makes sense given that you can use it to exclude; I missed that initially but realised when merging. Thanks for the work! I'm going to push a new version soon with that PR included; sorry again for the delay.

scohen commented 4 years ago

@whitfin yes, the root app would be the first (and only) app to start. I'll just caution y'all to not go too crazy with the app order, since it's quite possible to create an app configuration that you'll never see in a production environment, and you might be chasing your tails a lot getting things to work.