services/horizon: Deprecation and Removal of --db-url Command Line Parameter about go HOT 3 CLOSED

As part of this we can also:

1. Assess whether there are any command-line flags that are not inherently "global" and could potentially vary based on the specific subcommand. In such case, we may need to allow users to override these specific environment variables using command-line options. We can start with identifying any flags falling within this category.
2. Review current validations for each command and their respective subcommands tree and make adjustments/improvements where necessary.

from go.

I have a PR that introduces a deprecation warning for the --db-url command-line parameter. This PR also includes the necessary changes to support a config flag exclusively via environment variables. However, I'm not sure if this is the best way to go. Here are a few reasons why:

1. If we make one config parameter exclusively environment variables, the inconsistency could confuse users.
2. Users can run multiple Horizon instances, and these instances might need to connect to different databases.
   For example, they might have an API-only instance and an ingestion instance on the same machine. In such cases, the API instance might need to use a read-only database (ro db instance), while the ingestion instance needs the db-url parameter to point to a read-write database (rw db instance). To manage this, users would have to create extra scripts to pass different environment variables. Keeping the option to set db-url via the command line might be simpler for users.

I agree that command-line parameters may not be the most secure approach, and we may need to rethink how we handle Horizon's configuration as a whole. However, recommending the use of environment variables for configuring Horizon in our public documentation guides users toward a more secure and proper setup.

I'd love to hear your thoughts on this, @mollykarcher, @sreuland, @aditya1702.

from go.

As discussed during the Partner Experience team meeting, we have decided not to proceed with this and instead favor #5045. Hence, closing this issue.

from go.