Re: is sys.config mostly a convention?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: is sys.config mostly a convention?

Xavier Noria
I have done a walkthrough, and the only thing that I see special-cased is that sys.config has hard-coded support for nesting.

One of the first things that the application master does when it starts is to check `init:get_argument(config)`, which simply lists all the files passed to `-config` files. The `init/2` function iterates that list and *If* the basename of one of items is "sys.config", then we enter that `if` branch. But the implementation does not assume its existence. In particular, it does not assume its existence regardless of whether the mode is interactive or embedded (which is said in the config docs).

I confirmed with a sample release, changed the value of `-config` to point to a dummy foo.config, the system boots normally, and `init:get_arguments(config)` indeed returns

    {:ok, [['/Users/fxn/tmp/sample/_build/prod/rel/sample/foo.config']]}

So my conclusion is that it is really a convention (except for the fact that the documented nesting does not work in arbitrary config files).

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: is sys.config mostly a convention?

Xavier Noria
On Wed, Feb 14, 2018 at 10:24 AM, Xavier Noria <[hidden email]> wrote:

One of the first things that the application master

*application controller 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: is sys.config mostly a convention?

Xavier Noria
Even more, I see distillery supports an OS environment variable SYS_CONFIG_PATH to be able to point to an arbitrary config file (whose basename can be anything). I wonder if that may be handy for production deployments in which the machine that generates the release does not have access to sensible config data.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: is sys.config mostly a convention?

Richard Carlsson-3
In reply to this post by Xavier Noria
Like an operating system, Erlang has several levels. The runtime system boot stuff assumes very little about standard libraries at all, and what you're going to do with any flags that don't affect the runtime system directly. Then the kernel and stdlib basics adds some conventions but still don't assume too much about overall system behaviour. Then, the application controller adds conventions about applications and -config (but lets you have as many config files as you like, with arbitrary names). Then, the release handler and reltool, if you use them, add further conventions, such as "you should only have one main config file". (For historical reasons, you may also find abstraction leaks between these layers.)



        /Richard

2018-02-14 10:24 GMT+01:00 Xavier Noria <[hidden email]>:
I have done a walkthrough, and the only thing that I see special-cased is that sys.config has hard-coded support for nesting.

One of the first things that the application master does when it starts is to check `init:get_argument(config)`, which simply lists all the files passed to `-config` files. The `init/2` function iterates that list and *If* the basename of one of items is "sys.config", then we enter that `if` branch. But the implementation does not assume its existence. In particular, it does not assume its existence regardless of whether the mode is interactive or embedded (which is said in the config docs).

I confirmed with a sample release, changed the value of `-config` to point to a dummy foo.config, the system boots normally, and `init:get_arguments(config)` indeed returns

    {:ok, [['/Users/fxn/tmp/sample/_build/prod/rel/sample/foo.config']]}

So my conclusion is that it is really a convention (except for the fact that the documented nesting does not work in arbitrary config files).

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: is sys.config mostly a convention?

Xavier Noria
On Wed, Feb 14, 2018 at 11:13 AM, Richard Carlsson <[hidden email]> wrote:

Like an operating system, Erlang has several levels. The runtime system boot stuff assumes very little about standard libraries at all, and what you're going to do with any flags that don't affect the runtime system directly. Then the kernel and stdlib basics adds some conventions but still don't assume too much about overall system behaviour. Then, the application controller adds conventions about applications and -config (but lets you have as many config files as you like, with arbitrary names). Then, the release handler and reltool, if you use them, add further conventions, such as "you should only have one main config file". (For historical reasons, you may also find abstraction leaks between these layers.)

Thanks Richard.

Yes, I understand this has to be like an onion, with the inner levels providing generic support and assuming less, and the outer levels enforcing more and exposing the actual contract. Also, I guess documentation and implementation have gone through a lot of evolution with all its practical implications.

In this particular case, though, take this:

"When starting Erlang in embedded mode, it is assumed that exactly one system configuration file is used, named sys.config."

I believe that wording is not accurate, because I see actually no code assuming that. Inner, or outer! Don't you think that something like

"By convention, releases are expected to have one system configuration file named sys.config stored in such and such."

?

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: is sys.config mostly a convention?

Peti Gömöri-2
In reply to this post by Xavier Noria
hi Xavier

the rebar2 start script template also had a section "Use releases/VSN/sys.config if it exists otherwise use etc/app.config"

Exactly as you say this is useful to package the configuration (etc dir) separately from the release (which does not contain a sys.config)

On Wed, Feb 14, 2018 at 11:13 AM, Xavier Noria <[hidden email]> wrote:
Even more, I see distillery supports an OS environment variable SYS_CONFIG_PATH to be able to point to an arbitrary config file (whose basename can be anything). I wonder if that may be handy for production deployments in which the machine that generates the release does not have access to sensible config data.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: is sys.config mostly a convention?

Xavier Noria
Thanks Peti!

That adds confirmation to the mental model I am building.

All squares, I think:

* OTP as such does not assume anything, despite what the config docs say.
* Release or not, embedded or interactive, the interface is just -config.
* Each one of the release tools is responsible for the -configs they generate.
* Build tools may support a default that can be overridden, up to them and for them to document.
* By convention, sys.config is a common default choice you'll normally find.
* Files called "sys.config" may include other config files.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions