New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RTC-345] Introduce JF dedicated env vars for running in a distributed mode #92
Conversation
d390a96
to
a565b54
Compare
Codecov Report
@@ Coverage Diff @@
## main #92 +/- ##
==========================================
- Coverage 84.27% 83.37% -0.90%
==========================================
Files 44 44
Lines 744 764 +20
==========================================
+ Hits 627 637 +10
- Misses 117 127 +10
Continue to review full report in Codecov by Sentry.
|
187881c
to
13600f8
Compare
fcca80d
to
75452e3
Compare
9df13c4
to
b417a03
Compare
b417a03
to
8765fe9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we are making that many change in configuration, maybe we should also add possibility to change the port on which epmd runs ERL_EPMD_PORT
env (more about epmd envs here). Other variables worth setting IMO are inet_dist_listen_min
and inet_dist_listen_max
. We already use these variables in jellyfish_videoroom, but we configure it by passing the option to elixir, which passes it as an option to erlang. Both of these changes we could add in the next PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A general idea I have is to group all of the distribution env variables under the same prefix, e.g.
JF_DIST_ENABLED
-> no changeJF_NODE_NAME
->JF_DIST_NODE_NAME
JF_COOKIE
->JF_DIST_COOKIE
JF_NODES
->JF_DIST_NODES
IMO this isn't overly verbose, and would clearly communicate that these variables are meant to be used together, and that users need to pay attention to them only if they wish to run Jellyfish in a cluster.
lib/jellyfish/config_reader.ex
Outdated
if read_boolean("JF_DIST_ENABLED") do | ||
node_name_value = System.get_env("JF_NODE_NAME") | ||
cookie_value = System.get_env("JF_COOKIE") | ||
nodes_value = System.get_env("JF_NODES") || "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick
nodes_value = System.get_env("JF_NODES") || "" | |
nodes_value = System.get_env("JF_NODES", "") |
.env.sample
Outdated
# The second part has to be Jellyfish address | ||
# it is accessible on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# The second part has to be Jellyfish address | |
# it is accessible on | |
# The second part has to be the address Jellyfish is accessible on |
rel/env.sh.eex
Outdated
# release always starts in a distributed mode | ||
# but to provide unified way of configuring Jellyfish | ||
# distribution both in the local and production environment | ||
# we introduce our own env vars and use them to | ||
# set RELASE_NODE and RELASE_COOKIE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# release always starts in a distributed mode | |
# but to provide unified way of configuring Jellyfish | |
# distribution both in the local and production environment | |
# we introduce our own env vars and use them to | |
# set RELASE_NODE and RELASE_COOKIE | |
# We introduce our own env vars and use them to set | |
# RELEASE_NODE and RELEASE_COOKIE. | |
# | |
# This is to provide a unified way of configuring Jellyfish distribution | |
# in both development and production environments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The info that release always starts in a distributed mode is crucial here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually maybe not 🤔
@sgfn Can do that but what about WebRTC or RTSP? I think we should prefix them too |
Yeah, I've no problem with that, we should go for it |
+1 from for comments from @sgfn - other than that LGTM |
a03a062
to
61dc6b8
Compare
d99b0f6
to
0c669c3
Compare
0c669c3
to
c33e893
Compare
.env.sample
Outdated
@@ -20,8 +20,7 @@ JF_HOST=localhost:8080 | |||
|
|||
# Node name used in a cluster. | |||
# The first part can be any string. | |||
# The second part has to be Jellyfish address | |||
# it is accessible on | |||
# The second part has to be Jellyfish address # it is accessible on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# The second part has to be Jellyfish address # it is accessible on. | |
# The second part has to be Jellyfish address it is accessible on. |
b87b5a9
to
316e5d0
Compare
316e5d0
to
eedfb37
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides one issue LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, with one small note:
Regarding the .env.sample
file: I'm still firmly against making the core Jellyfish documentation spread out in two or more places -- could you just confirm we will duplicate all of this info in the docs, and not have the docs say: "for more info, refer to the .env.sample
file"?
Sure, I will revisit this once I write official docs |
This PR introduces our own env variables for running JF in a cluster.
When we run erlang/elixir locally, we can setup distribution using flags like
--sname
--name
--cookie
etc. However, when we make a release, we are provided with special env variables e.g.RELEASE_NODE
RELEASE_COOKIE
etc. which results in multiple configuration options depending on environment we run Jellyfish in.Intoducing our own env vars we:
mix release
so this would add unnecessary complexity in the documentation