Listen socket is not created after restart of the instance, if set using environmental variable. #9485
Assignees
Comments
|
Defaults are passed to I agree that we should consider it as a bug and support the old names (where possible) in the env configuration source. |
Ok, thanks for answer. I understood that but why an old "TT_LISTEN"(which as i understood should not work) variable still works with first launch? |
|
Tarantool re-reads a configuration and applies it second time if there is an existing snapshot. The idea is that the startup may take a long time and the configuration may be changed while it was starting. See c80b121 for details. Here we lean on the assumption that an attempt to call I need to test/dig it a bit more to say for sure. |
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Dec 18, 2023
TODO: changelog TODO: doc request -- list supported and unsupported vars Fixes tarantool#9485
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Dec 21, 2023
There may be some confusion, so let's start with a background information. There are `TT_*` environment variables introduced in commit 1b33012 ("box: set box.cfg options via environment variables"). They're interpreted by the `box.cfg()` call. There are `TT_*` environment variables introduced in commit 82b0cff ("config: introduce env source"). They're interpreted by the declarative configuration logic, when tarantool starts with the `--name <...>` CLI option. box.cfg's env variables have names deduced from box.cfg option names, while config's env variable names are deduced from the config schema. Some options have the same names here and there, for example `TT_REPLICATION_ANON` (from `box.cfg.replication_anon` and `replication.anon`). However, there are ones that have different names, for example `TT_LISTEN` and `TT_IPROTO_LISTEN`. Moreover, the declarative configuration has its own restrictions on the configuration data. For example, `TT_IPROTO_LISTEN` is always a list of URIs (like `[{"uri": <...>, "params": {<...>}}]`), not a single URI, not a string, not a number. The declarative configuration has a certain shape and doesn't allow polymorphic values. Next, handling of box.cfg's variables by the old code in `load_cfg.lua` doesn't work well with the declarative configuration flow. The main reason is that the new configuration flow calls `box.cfg()` with all the `box.cfg` values set, including default ones. If a user removes an option from its config, it applies its default. On the same time it instructs `box.cfg()` to don't read the corresponding variables. This commit offers a partial solution: it performs mapping of the most of box.cfg's options to box.cfg's environment variables and adds them into the configuration data if the configuration value is not provided in another way (new env var, file, etcd, tarantool storage). This mapping mostly works, but technically it is incomplete. At least it doesn't handle the following environment variables. * `TT_LOG` * `TT_METRICS` * `TT_INSTANCE_NAME` * `TT_REPLICASET_NAME` * `TT_CLUSTER_NAME` * `TT_FORCE_RECOVERY`, * `TT_READ_ONLY` * `TT_BOOTSTRAP_LEADER` * `TT_REPLICATION_CONNECT_QUORUM` If there is a demand, it is possible to support `TT_LOG`, `TT_METRICS` and `TT_BOOTSTRAP_LEADER`, while the rest of the options are either have no sense in the declarative configuration flow or deprecated. Fixes tarantool#9485 NO_DOC=looks more like a bug fix
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Dec 24, 2023
This function makes it easier to run a code that can't be run directly for some reason: for example, it needs the initialized database. It is a wrapper around treegen and justrun. Part of tarantool#9485 NO_DOC=testing helper change NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Dec 24, 2023
There may be some confusion, so let's start with a background information. There are `TT_*` environment variables introduced in commit 1b33012 ("box: set box.cfg options via environment variables"). They're interpreted by the `box.cfg()` call. There are `TT_*` environment variables introduced in commit 82b0cff ("config: introduce env source"). They're interpreted by the declarative configuration logic, when tarantool starts with the `--name <...>` CLI option. box.cfg's env variables have names deduced from box.cfg option names, while config's env variable names are deduced from the config schema. Some options have the same names here and there, for example `TT_REPLICATION_ANON` (from `box.cfg.replication_anon` and `replication.anon`). However, there are ones that have different names, for example `TT_LISTEN` and `TT_IPROTO_LISTEN`. Moreover, the declarative configuration has its own restrictions on the configuration data. For example, `TT_IPROTO_LISTEN` is always a list of URIs (like `[{"uri": <...>, "params": {<...>}}]`), not a single URI, not a string, not a number. The declarative configuration has a certain shape and doesn't allow polymorphic values. Next, handling of box.cfg's variables by the old code in `load_cfg.lua` doesn't work well with the declarative configuration flow. The main reason is that the new configuration flow calls `box.cfg()` with all the `box.cfg` values set, including default ones. If a user removes an option from its config, it applies its default. On the same time it instructs `box.cfg()` to don't read the corresponding environment variables. This commit offers a partial solution: it adds support of the most of the box.cfg environment variables. The values are added into the configuration data with the lowest priority: if the same value is set in, for example, a file configuration, the file's value is preferred. The following box.cfg's environment variables are not handled in this commit. * `TT_LOG` * `TT_METRICS` * `TT_INSTANCE_NAME` * `TT_REPLICASET_NAME` * `TT_CLUSTER_NAME` * `TT_FORCE_RECOVERY`, * `TT_READ_ONLY` * `TT_BOOTSTRAP_LEADER` * `TT_REPLICATION` * `TT_REPLICATION_CONNECT_QUORUM` Fixes tarantool#9485 NO_DOC=looks more like a bug fix or a kind of compatibility layer
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Dec 24, 2023
This function makes it easier to run a code that can't be run directly for some reason: for example, it needs the initialized database. It is a wrapper around treegen and justrun. Part of tarantool#9485 NO_DOC=testing helper change NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Dec 24, 2023
There may be some confusion, so let's start with a background information. There are `TT_*` environment variables introduced in commit 1b33012 ("box: set box.cfg options via environment variables"). They're interpreted by the `box.cfg()` call. There are `TT_*` environment variables introduced in commit 82b0cff ("config: introduce env source"). They're interpreted by the declarative configuration logic, when tarantool starts with the `--name <...>` CLI option. box.cfg's env variables have names deduced from box.cfg option names, while config's env variable names are deduced from the config schema. Some options have the same names here and there, for example `TT_REPLICATION_ANON` (from `box.cfg.replication_anon` and `replication.anon`). However, there are ones that have different names, for example `TT_LISTEN` and `TT_IPROTO_LISTEN`. Moreover, the declarative configuration has its own restrictions on the configuration data. For example, `TT_IPROTO_LISTEN` is always a list of URIs (like `[{"uri": <...>, "params": {<...>}}]`), not a single URI, not a string, not a number. The declarative configuration has a certain shape and doesn't allow polymorphic values. Next, handling of box.cfg's variables by the old code in `load_cfg.lua` doesn't work well with the declarative configuration flow. The main reason is that the new configuration flow calls `box.cfg()` with all the `box.cfg` values set, including default ones. If a user removes an option from its config, it applies its default. On the same time it instructs `box.cfg()` to don't read the corresponding environment variables. This commit offers a partial solution: it adds support of the most of the box.cfg environment variables. The values are added into the configuration data with the lowest priority: if the same value is set in, for example, a file configuration, the file's value is preferred. The following box.cfg's environment variables are not handled in this commit. * `TT_LOG` * `TT_METRICS` * `TT_INSTANCE_NAME` * `TT_REPLICASET_NAME` * `TT_CLUSTER_NAME` * `TT_FORCE_RECOVERY`, * `TT_READ_ONLY` * `TT_BOOTSTRAP_LEADER` * `TT_REPLICATION` * `TT_REPLICATION_CONNECT_QUORUM` Fixes tarantool#9485 NO_DOC=looks more like a bug fix or a kind of compatibility layer
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Dec 25, 2023
This function makes it easier to run a code that can't be run directly for some reason: for example, it needs the initialized database. It is a wrapper around treegen and justrun. Part of tarantool#9485 NO_DOC=testing helper change NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Dec 25, 2023
There may be some confusion, so let's start with a background information. There are `TT_*` environment variables introduced in commit 1b33012 ("box: set box.cfg options via environment variables"). They're interpreted by the `box.cfg()` call. There are `TT_*` environment variables introduced in commit 82b0cff ("config: introduce env source"). They're interpreted by the declarative configuration logic, when tarantool starts with the `--name <...>` CLI option. box.cfg's env variables have names deduced from box.cfg option names, while config's env variable names are deduced from the config schema. Some options have the same names here and there, for example `TT_REPLICATION_ANON` (from `box.cfg.replication_anon` and `replication.anon`). However, there are ones that have different names, for example `TT_LISTEN` and `TT_IPROTO_LISTEN`. Moreover, the declarative configuration has its own restrictions on the configuration data. For example, `TT_IPROTO_LISTEN` is always a list of URIs (like `[{"uri": <...>, "params": {<...>}}]`), not a single URI, not a string, not a number. The declarative configuration has a certain shape and doesn't allow polymorphic values. Next, handling of box.cfg's variables by the old code in `load_cfg.lua` doesn't work well with the declarative configuration flow. The main reason is that the new configuration flow calls `box.cfg()` with all the `box.cfg` values set, including default ones. If a user removes an option from its config, it applies its default. On the same time it instructs `box.cfg()` to don't read the corresponding environment variables. This commit offers a partial solution: it adds support of the most of the box.cfg environment variables. The values are added into the configuration data with the lowest priority: if the same value is set in, for example, a file configuration, the file's value is preferred. The following box.cfg's environment variables are not handled in this commit. * `TT_LOG` * `TT_METRICS` * `TT_INSTANCE_NAME` * `TT_REPLICASET_NAME` * `TT_CLUSTER_NAME` * `TT_FORCE_RECOVERY`, * `TT_READ_ONLY` * `TT_BOOTSTRAP_LEADER` * `TT_REPLICATION` * `TT_REPLICATION_CONNECT_QUORUM` Fixes tarantool#9485 NO_DOC=looks more like a bug fix or a kind of compatibility layer
Totktonada
added a commit
that referenced
this issue
Dec 25, 2023
This function makes it easier to run a code that can't be run directly for some reason: for example, it needs the initialized database. It is a wrapper around treegen and justrun. Part of #9485 NO_DOC=testing helper change NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC
Totktonada
added a commit
that referenced
this issue
Dec 25, 2023
There may be some confusion, so let's start with a background information. There are `TT_*` environment variables introduced in commit 1b33012 ("box: set box.cfg options via environment variables"). They're interpreted by the `box.cfg()` call. There are `TT_*` environment variables introduced in commit 82b0cff ("config: introduce env source"). They're interpreted by the declarative configuration logic, when tarantool starts with the `--name <...>` CLI option. box.cfg's env variables have names deduced from box.cfg option names, while config's env variable names are deduced from the config schema. Some options have the same names here and there, for example `TT_REPLICATION_ANON` (from `box.cfg.replication_anon` and `replication.anon`). However, there are ones that have different names, for example `TT_LISTEN` and `TT_IPROTO_LISTEN`. Moreover, the declarative configuration has its own restrictions on the configuration data. For example, `TT_IPROTO_LISTEN` is always a list of URIs (like `[{"uri": <...>, "params": {<...>}}]`), not a single URI, not a string, not a number. The declarative configuration has a certain shape and doesn't allow polymorphic values. Next, handling of box.cfg's variables by the old code in `load_cfg.lua` doesn't work well with the declarative configuration flow. The main reason is that the new configuration flow calls `box.cfg()` with all the `box.cfg` values set, including default ones. If a user removes an option from its config, it applies its default. On the same time it instructs `box.cfg()` to don't read the corresponding environment variables. This commit offers a partial solution: it adds support of the most of the box.cfg environment variables. The values are added into the configuration data with the lowest priority: if the same value is set in, for example, a file configuration, the file's value is preferred. The following box.cfg's environment variables are not handled in this commit. * `TT_LOG` * `TT_METRICS` * `TT_INSTANCE_NAME` * `TT_REPLICASET_NAME` * `TT_CLUSTER_NAME` * `TT_FORCE_RECOVERY`, * `TT_READ_ONLY` * `TT_BOOTSTRAP_LEADER` * `TT_REPLICATION` * `TT_REPLICATION_CONNECT_QUORUM` Fixes #9485 NO_DOC=looks more like a bug fix or a kind of compatibility layer
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug description
If setting box.cfg{listen} using "TT_LISTEN" environmental variable, socket is not created after restart of the instance.
Steps to reproduce
Config file:
Instances file:
Set environmental variable 'TT_LISTEN':
Start tarantool instance.
In another console check that socket was created.
Stop instance and start again.
In another console check that socket is not here.
Check env:
Log file:
Actual behavior
After restart of the instance socket is not created.
Expected behavior
After restart of the instance socket is created.
The text was updated successfully, but these errors were encountered: