Better configuration needed for UI code

[hickey]

The following comments are from a comment that I made on https://github.com/FreeTAKTeam/FreeTakServer/issues/324. I went on a bit of a rant in that issue before I realized that I was going into a lot of things that did not pertain to the problem that https://github.com/FreeTAKTeam/FreeTakServer/issues/324 was filed against (although their are some related items).

It has taken me a bit longer to make the time to create an issue concerning some of the things I was going off on and after contemplating where the problem is I think that most of the problem resides in the UI code. Hence this issue.

So from my comment in that issue:

So digging into the current code branches for FreeTAKServer and FreeTAKServer-UI it is mounting to the frustration level that there are 2 different methods for configuration. The two projects are closely related--why are there different configuration methods?

....

In FreeTAKServer it is configured by reading in a YAML file (/opt/FTSConfig.yaml) and there is no entry that appears to be equivalent to SECRET_KEY. So yes, this still seems to be a problem with the current code bases. Which begs the question of how the software ever made it to the point of release without full integration testing which should have caught the problem of missing config values.

Now, I may be missing something. I have only been working trying to get working copies of the software for a couple of hours. Forgive me if I am missing something. Yet given what I have seen thus far and problems that should not have made it to a release and complexities of configuring the software, I am compelled to give up and just run the official TAK server.

A bit of these comments are a little bit more specific to https://github.com/FreeTAKTeam/FreeTakServer/issues/324, but I think it provides some of the context for this issue.

I should also state that I have submitted a PR (https://github.com/FreeTAKTeam/FreeTakServer/pull/376) to rework the configuration module in the FreeTAKServer code and I am thinking that something similar should be done for the UI code.

The way that the UI code gets configured is to set all the values statically in a Python file that gets read in when the code starts up. While that is great for having the configuration already processed, it is really a bad experience for trying to run the code in different environments or if there needs to be a different configuration used on some occasion.

In my case I was trying to get the Docker version of FreeTAKServer running and having two different configuration mechanisms in the same Docker container is a bit of a nightmare. Actually, the existing Docker container does not seem to have any real configuration of the UI code that can be done.

I would suggest that the UI code be changed to read in a YAML file similar to the one used for FreeTAKServer. Actually the same config could/should be used. Since some of the values (specifically several of the network addressing settings) are used by both code bases it would make sense to use the same key values for both projects.

This would allow a single configuration file to be created and fed to both services (if they are running on different machines) or if both services are running in the Docker or similar environment then the configuration is just passed in once.

[brothercorvo]

@hickey can you please contact me in Discord?

[hickey]

The new configuration module in FTS is nearing completion. It is expected that a copy of this module will be used in the UI code to provide better and a configuration mechanism that is consistent with FTS.

The configuration code is being worked on in https://github.com/FreeTAKTeam/FreeTakServer/pull/386.

[RadioAndrea]

May be OBE due to the work on FreeTAKTeam/FreeTakServer#388, #43 , and #42 .

New containerization strategy involves symlinking the necessary files into the host-provided container volume allowing for user configuration from there according to the normal FTS methods.

[brothercorvo]

@RadioAndrea I think we can close this?