Prior to this change, when EMQX daemon mode failed to start
it's not quite easy for users to understand what went wrong.
All the know is the node did not start in time
and then instructed to boot the node in 'console' mode wishing
for some logs.
However, the node might actuay be running, causing 'console' mode
to fail with a different reason.
With this change, after a filure of daemon mode boot,
we issue a diagnosis.
1. if node can not be found from ps -ef, instruct the user
to find information in erlang.log.N
2. if the node is found running, but not responding to pings
instruct the user to check if the node name is
resolvable and reachable
3. if the node is responding to pings but emqx app is not
running, then it's likely a bug. so the user is advised
to report a github issue.
reason: 'ce' (Community Edition) is only for internal use,
when it comes to user/customer facing descriptions,
we should use Opensource edition and Enterprise edition.
Similary, for user/customer facing shell prompt,
use `v` for Opensource edition and `e` for Enterprise
While declaring `emqx_conf` as an application dependency of
`emqx_resource` worked for releases, it messed up the startup
relationship during tests. Since only removing `emqx_conf` from the
`applications` key in `emqx_resource` breaks the list of apps that
need to be rebooted on config changes (since `emqx_conf` is not on any
apps dependencies list, it was not being added to the final
topologically sorted list), we now always add it as a vertex to ensure
its presence there. This (apparently) makes the rebar3 release, the
mix release and test runs behave normally.
By treating the apps in the umbrella as dependencies to be managed and
built by rebar3, we can simplify the maintenance of the release, at
the cost of increased build times: using Mix as before, it could track
changed files better than using rebar. But the complexity and
possibility of discrepancies make it using rebar much more compelling.
ieQu1