Create a rpc endpoint that returns a node's configuration. Also create a provenanced query config command that utilizes this new endpoint.
Problem Definition
As a troubleshooter, I would like to know how a node is configured so that I can possibly identify problems.
As a new node operator, I would like to know how an existing node is configured, so that I can configure mine similarly.
We already have the cli config command, which is handy when you have command-line access to a node. However, even then, somethings might be defined through environment variables, and those might be different for your command-line environment, and the environment that the node runs in. So having an endpoint that returns both the app.toml and config.toml configuration information, would make it easy to accurately get the node's current configuration.
This will also make it easier to create a new node, specially if using statesync. Instead of copying the config from one of our repos, the configuration could be retrieved from the node you're about to statesync from. You'd still have to set the moniker and statesync config pieces, but it would bypass the need to download the configs from another source (e.g. one of our mainnet or testnet repos).
Proposal
Create a new /config endpoint that can be used to get a nodes configuration. This endpoint should be added to the list of rpc endpoints, and should be listed when a request is made to the root. For example, going to https://rpc.test.provenance.io:443 returns a page with links to the various rpc endpoints available; this new endpoint should appear in there.
The result should be in json and should reflect the current configuration of the running node. That is, it should NOT just be a copy of the config files; those values might have been superseded by environment variables or command-line arguments. However, for the rest of this ticket, I'll refer to stuff in the app.toml and config.toml files because that's an easier way to reference them, but still, I'm actually referring to the final values being used (not necessarily the value specified in the file).
There are two desirable results:
All configuration key/value pairs, separated by configuration type (e.g. app vs config).
The packed config (similar to the packed config file created by provenanced config pack).
The client.toml configuration elements should not be included in the information returned because the nodes don't use those entries while running; they're only used when interacting with a node from somewhere else.
Similar to the packed.json file, the values should be strings representing what the values would look like in a config file. For example, the "rpc.cors_allowed_methods": "[\"HEAD\", \"GET\", \"POST\"]" and "p2p.max_num_outbound_peers": "10".
The returned JSON should look something like this: {"app":{...},"config":{...},"packed":{...}}, where each of those objects contains simple string/string key/value pairs. The "app" object is all of the configuration entries controlled by the app.toml file, and "config" is all the entries controlled by config.toml. The "packed" object should be all config entries (from either app.toml or config.toml that are different from their defaults. Doing something like curl <host:port>/config | jq '.result.packed> "$PIO_HOME/config/packed-conf.json" should make it easy to duplicate a nodes config.
The logic, functions, and processing used for the provenanced config command should be tweakable/reusable for this new endpoint. It might make sense to move some of that stuff to a more general area though (e.g. the internal/ directory).
I feel like adding parameters to this endpoint would not be desirable (at this time). Filtering the results on the server-side would not reduce processing by much (if any). Also, having filtering options would incentivize hitting the endpoint multiple times (for different filters), which would definitely increase processing more than what could be reduced by limiting work done. Also, returning all the app and config entries as well as duplicating any changed entries for the packed object, is still not much information. It's all less than 7K pretty printed (or 6K compacted). Also, that information isn't going to change very often, so having users get and store the response, and parse it out themselves shouldn't be problematic.
For the CLI, create a new command to put under the query command, e.g. provenanced query config. Make sure to note in the command description (.e.g. short and long) that this gets the remote node's config, and shouldn't be confused with provenanced config which deals with your local config.
iramiller
commented
2 years ago
Summary
Create a rpc endpoint that returns a node's configuration. Also create a
provenanced query configcommand that utilizes this new endpoint.Problem Definition
As a troubleshooter, I would like to know how a node is configured so that I can possibly identify problems.
As a new node operator, I would like to know how an existing node is configured, so that I can configure mine similarly.
We already have the cli
configcommand, which is handy when you have command-line access to a node. However, even then, somethings might be defined through environment variables, and those might be different for your command-line environment, and the environment that the node runs in. So having an endpoint that returns both theapp.tomlandconfig.tomlconfiguration information, would make it easy to accurately get the node's current configuration.This will also make it easier to create a new node, specially if using statesync. Instead of copying the config from one of our repos, the configuration could be retrieved from the node you're about to statesync from. You'd still have to set the moniker and statesync config pieces, but it would bypass the need to download the configs from another source (e.g. one of our mainnet or testnet repos).
Proposal
Create a new
/configendpoint that can be used to get a nodes configuration. This endpoint should be added to the list ofrpcendpoints, and should be listed when a request is made to the root. For example, going tohttps://rpc.test.provenance.io:443returns a page with links to the various rpc endpoints available; this new endpoint should appear in there.The result should be in json and should reflect the current configuration of the running node. That is, it should NOT just be a copy of the config files; those values might have been superseded by environment variables or command-line arguments. However, for the rest of this ticket, I'll refer to stuff in the
app.tomlandconfig.tomlfiles because that's an easier way to reference them, but still, I'm actually referring to the final values being used (not necessarily the value specified in the file).There are two desirable results:
appvsconfig).provenanced config pack).The
client.tomlconfiguration elements should not be included in the information returned because the nodes don't use those entries while running; they're only used when interacting with a node from somewhere else.Similar to the
packed.jsonfile, the values should be strings representing what the values would look like in a config file. For example, the"rpc.cors_allowed_methods": "[\"HEAD\", \"GET\", \"POST\"]"and"p2p.max_num_outbound_peers": "10".The returned JSON should look something like this:
{"app":{...},"config":{...},"packed":{...}}, where each of those objects contains simple string/string key/value pairs. The"app"object is all of the configuration entries controlled by theapp.tomlfile, and"config"is all the entries controlled byconfig.toml. The"packed"object should be all config entries (from eitherapp.tomlorconfig.tomlthat are different from their defaults. Doing something likecurl <host:port>/config| jq '.result.packed> "$PIO_HOME/config/packed-conf.json"should make it easy to duplicate a nodes config.The logic, functions, and processing used for the
provenanced configcommand should be tweakable/reusable for this new endpoint. It might make sense to move some of that stuff to a more general area though (e.g. theinternal/directory).I feel like adding parameters to this endpoint would not be desirable (at this time). Filtering the results on the server-side would not reduce processing by much (if any). Also, having filtering options would incentivize hitting the endpoint multiple times (for different filters), which would definitely increase processing more than what could be reduced by limiting work done. Also, returning all the
appandconfigentries as well as duplicating any changed entries for thepackedobject, is still not much information. It's all less than 7K pretty printed (or 6K compacted). Also, that information isn't going to change very often, so having users get and store the response, and parse it out themselves shouldn't be problematic.For the CLI, create a new command to put under the
querycommand, e.g.provenanced query config. Make sure to note in the command description (.e.g.shortandlong) that this gets the remote node's config, and shouldn't be confused withprovenanced configwhich deals with your local config.For Admin Use