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.
This commit enables a minimal working build of EMQX release using
Mix. However, to properly start the release, several configuration
steps are still missing. A `mix_release.sh` script does a few hacks
to get the release built with Mix to start properly, by first assuming
that `make emqx` has been run prior to the release, ran once to
generate the `app.*.config` files, and then it copies that and some
other files to the expected places.
Also, `emqx_telemetry` hangs the start procedure because it thinks
it's in an official release and tries to make a request. We disable
it temporarily via config just to get a working build for now.
* feat(emqx_conf): move conf manager for emqx_machine to emqx_conf
* chore(emqx_conf): change emqx:get_config/2 to emqx_conf:get/2
* fix: common test failed
* fix: badmatch by typo wrong key
* fix(emqx_conf): get the wrong core nodes
* fix(emqx_conf): get core node's tnx_id not latest tnx_id
* fix: add ro_transation when copy conf file
* fix: delete debug info
* fix: change ekka_rlog to mria_rlog
* fix: remove cluster_rpc from emqx_machine.
* fix: don't call ekka:start/0 explicitly
* fix: ekka should be start in emqx_machine
* fix(emqx_machine): Fix start/stop callbacks
* chore(ekka): Bump version to 0.11.1
* fix(router): Wait for the tables
* fix(emqx_cluster_rpc): Stop cluster RPC when joining a cluster
* fix(emqx_app): Fix a deadlock when joining the cluster
* fix(emqx_telemetry): Wait for mnesia tables
* test(ct_helper): Start ekka before emqx
client and server ssl options share some common fields
this commit make an abstraction for the common fields
then export server_ssl_options_schema/2 and client_ssl_options_schema/1
for other schema modules to call
Stefan Strigler