services/horizon: Introduce "show-default-network" command in Horizon

[urvisavla]

What problem does your feature solve?

Add an option in Horizon to list the hosts that horizon and captive core will initiate outbound tcp/ip connections based on the NETWORK type, includes hosts from core's quorum set and archive urls.

This feature is part of the recent addition of the NETWORK parameter, which simplifies the process of starting Horizon with Stellar networks (#4913). With that update, Horizon will automatically utilize the default configuration for the selected network and generates the captive core config file.

Adding show-default-network command will allow users to view the list of hosts in the network quorum and the lists of hosts in the archive urls list, enabling them to configure firewalls and other settings accordingly.

What would you like to see?

Add a new command to Horizon called show-default-network, which allows users to view the generated quorum set for the chosen Stellar network.

Usage:
stellar-horizon --show-default-network [testnet|pubnet]
Running this command will display two lists: the hosts in the network quorum and the hosts in the archive urls list. The output format of the command is TBD.

What alternatives are there?

users manually open the generated captive core .cfg file that horizon places on disk when using NETWORK and after ingestion has started, get the quorum set from that.

[urvisavla]

In the context of this ticket, the term "network-quorum set" refers to the list of validator names along with their addresses and history urls, as configured in the captive-core config file. The main objective is to simplify Horizon setup by displaying the URLs that users should consider adding to their firewall rules, without the need to manually inspect the captive-core config file.

Originally, the plan was to implement show-network-quorum as an ad hoc command that would fetch the network-quorum from the currently running Horizon (captive-core) process. However, this approach has a problem since it requires that the command horizon --show-network-quorum is invoked with the same shell context (environment variables) as the running Horizon process. Now It is possible to run multiple Horizon (captive-core) with different shell contexts by starting them as separate processes with its own sets of environment variables. That is to say that each process can have its own environment variables, allowing them to point to different captive-core config files which means we need to supply our new command with captive-core config path to work, leading to a chicken and egg problem.

There are two possible options to move forward:

Option 1:
Expose an admin endpoint that fetches the captive-core config file and returns the quorum set.
Pros: Generic approach that works for all networks, no need to worry about environment variables when invoking horizon --show-network-quorum.
Cons: Increases the scope of the work and may be considered excessive, concerns about exposing internal details.

Option 2:
Limit the scope of the new command to display the default network-quorum set introduced through the NETWORK parameter. So the command wouldhorizon --show-network-quorum --network [testnet|pubnet]
Pros: Simpler as it removes the dependency on running Horizon process and instead it is available statically in the code. If users want to view the quorum set before starting Horizon, and they are using one of the default networks, this will serve their need.
Cons: Very limited, restricted to the pubnet and testnet static configurations, not possible to query Horizon at runtime to retrieve the quorum set.

@mollykarcher, What are your thoughts on the best approach to move forward?

[sreuland]

I would vote for option 2, a minor suggestion for simiplification of the sub-cmd to horizon show-network-quorom [testnet|pubnet]

I think option 1 is cool, if it resonates, maybe we add that in another iteration, the one caveat with that is that you have to install horizon first, before can retrieve the list of quorum hosts, which is the chicken/egg thing as a typical deployment timeline will want to identify fw rules for outbound traffic up front first before running the system.

[mollykarcher]

Amongst those options, I would agree that Option 2 sounds like our best option right now. Though I may change the name subtlety to make it super-explicit it's purpose (ie. show-default-network-quorum or something similar).

However, I actually would question whether or not we really need this command. You can still get this info in viewing the generated file, though I get that might be annoying. Given that, my inclination would be to not add it now, but to add it later, should the need arise or if we notice user pain around it.

[sreuland]

I think the generated captive core config file won't be available until horizon has been run in the 'serve' or 'ingest' mode at least once, it seems like that type of cycle was where show-default-network-quorum command could provide the info prior to executing horizon in those modes.