services/horizon: Introduce "show-default-network" command in Horizon about go HOT 4 OPEN

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.

from go.

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?

from go.

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.

from go.

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.

from go.